Thanks for the translation. Approved :)

Changing it to a function is absolutely fine. I should have made it a function instead of a class in the first place.

Thanks! Approved.

Opened https://github.com/codewars/runner/issues/101

What I meant was that it's a trade-off like anything and not necessarily a flaw by itself.

It's obviously soooo much faster to execute with more optimization, but it also takes longer to compile and that might be significant as well (compile time is included in the time limit and it can require more resources). Haskell had some kata that required the author to adjust with pragmas, which is not possible with Rust yet.
Also, Rust is evolving fast and the compilation speed of the optimized build or the effect of the optimization are not part of the stability guarantee. This means it might make it more difficult to update kata automatically or lead to significant differences between versions. (I'm assuming dev builds will be relatively stable.)

Just to be extra clear, I'm not against the change. We just need to find the right balance after experimenting. I'm all for improving the user experience and enabling more advanced challenges. We can start by few specific examples like the kata you mentioned and experimenting with different profiles to see how it affects everything else.

I should definitely shut up and stop talking about things I have no idea about.

I obviously don't know everything about all the languages we support, so it's really helpful for users with the knowledge I lack to reach out and provide insights. Even just bringing something up to my attention can help sometimes because I can be missing something obvious. This interaction at least made me look into possible options and found [profile.dev.package."*"] that can be used to optimize the dependency independently.

I wouldn't want you or anyone to shut up, but this is not the right place to continue discussing.

Is the difference between Rust debug/release modes something similar to C++'s -O0/-O2? If it is, then it can be challenging to translate many kata to Rust, in particular these with performance requirements. There's a kata which used to have upper bound of a problem set at 50 with C++14 ant no optimizations, and it got increased to 1000 with C++ 17 and -O2.

But if impact on Rust is nothing similar to what C++ experienced, then I should definitely shut up and stop talking about things I have no idea about.

is it because Rust is still something of a niche language?

For what it's worth, Rust is getting more popular on Codewars. It's currently 10th in the number of requests to test. I can see Codewars having active Rust community similar to Haskell. Rust gets more frequent language updates because it's my favorite language been painless to update in the past and few users helped when a crate had some breaking changes. I'd like to keep it relatively up-to-date as long as we can keep up with updating the kata.

I honestly don't consider the current setup of using the default test profile is flawed. However, feedback is appreciated. The issue tracker for the code runner is at https://github.com/codewars/runner.

It's a common experience to feel dissatisfied when your kata spends two weeks in beta, but one can get used to that after it stays there six months more. Don't worry.

But no, seriously now: beta reviews are not very popular activity, and beta reviews of unpopular languages are even less popular activity. Easy kata in popular languages get approved quite quickly, if issues are fixed actively by the author. But some kata, even in a good shape, can sit in beta forever. Like, years. Just go to kata search list, filter by beta and sort by oldest. I have quite a few interesting kata which I'd like to out-beta, but them being created in Swift or C++ or C# does not help.

To increase a chance of the kata being approved, you can try following things:

• fix reported and incoming issues,
• translate it to more popular language. JS and Python are very good choices.
• advertise it, for example here: https://gitter.im/Codewars/codewars.com/kata-authoring-help . Just not too much :)

Haskell is kind of a peculiar exception, because Codewars has quite a number of very active and advanced Haskell (and FP/brainf**ky-math-related in general) users. That's why Haskell kata are likely to be reviewed and fixed quite quickly. I would not say the same about Rust, but what's interesting, recently two Rust users became quite active on Gitter. Posting there could help.

You might also want to take a look at this post reporting a flaw in Rust setup and report it on forum if you consider it important. The original finder has not reported it yet.

Nevermind, it was just a string. I can edit strings. I've fixed the offending code.

I probably should not have approved a rust translation I am incapable of editing. I don't know rust.

There was a bug with the solution verification function. It should be fixed now. Thanks for raising the issue and feel free to post any further updates. (Also, helps to mention the language; in this case, Rust)

Moved into a issue

I think your program is fine for small inputs listed. The real problem is that one of the inputs is so incredibly huge, that traceShow cannot even print it.

any chance you could give more insight as to what you mean here. My program is passing most of the tests but seems to be timing out on a short inputs

traceShow xs
[9,8]
[9,4]
[5,7]
[6]
[8,6]

The equivelent python code of what I am doing works no problem. I am tearing my hair out trying to figure out why it wont work as like you my program handles massive numbers and massive lists on my machine

Probably fixed - I just completed the Kata in Java and did not encounter any issues

Solved.