The change of Rust version is probably on-going as I noticed a not backward compatible change in the new version of the rand module.
It also seems that the program is not executed in “release” mode anymore. It is probably temporary, could you please check that the release mode will be re-activated once the change of version is finished?
The FAQ page has already been updated with the proper versions 
and I +1 for the release mode !
We have updated the languages 
Feel free to report here any weird issue that could be related.
Looks like D is broken: Error: cannot find source code for runtime library file ‘object.d’
D has been fixed.
We’ll put back Rust in release mode, most probably everywhere (In/Out, solo, multi… so no more Rust in debug mode) unless there is strong reaction from Rust players.
Is Rust compiled with -C target-cpu=native? If not, could it be added? It enables emission of instructions specific to the host architecture like SIMD, allowing for autovectorization.
For lua, I see the classical problem of the syntax checker in IDE not aware of new syntax introduced in the version 5.4 (ie local TOTO<const>=3 and local FOOBAR<close> =...)
For me it is a very light problem (I don’t think that this new syntax would be used in CG), but in general is it planned to update the IDE syntax checker when the syntax of the language evolve ?
no, it’s not compiled this way. Why this option is not activated by default? Does it impact the compilation time?
it should. Depends on the languages though. We’ll update it for Lua.
It shouldn’t significantly impact compile time. It’s not enabled by default because it potentially reduces the portability of the binary. By default, the compiler is limited to SSE2 instructions since they’re part of the x86_64 spec, so the binary is guaranteed to run on any x64 CPU, but autovectorization opportunities are limited.
If you compile with -C target-cpu=native (native means detect host architecture) the compiler is allowed to use all instruction extensions supported by the host CPU (e.g. SSE3, SSSE3, SSE4.x, AVX, AVX2, etc.) The binary is then only guaranteed to run on CPUs with the same architecture, but if you’re compiling and running the binary on the same machine, which I presume you’re doing, then it’s guaranteed to work. If not, you can instead use -C target-feature=+sse4.2,+avx2, for example, to enable features that are supported by all runners (you can list features by running rustc --print target-features).
This is an area where JITed languages currently have an advantage since they do this stuff automatically.
It works now, thank you 
We’ve upgraded Kotlin to 1.5.0 (from 1.3.31) using the classic, but much slower, compiler.
We’re in the process of increasing the allowed compilation time (plays in IDE should be failing now). Also we’ll increase the LSP version to 1.4 (1.5 not available)
I understand better now the random message “Compilation took too long and has been interrupted…”.
Are there any plans to support C# 9? Top-level statements would make the language a lot more competitive in short mode against languages like Python3.
Is there any plans to support for scala 3? The new optional brace is pretty neat, would be great if scala 3 available before fall challenge.
Are there plans to move on to another Kotlin compiler (version) in the near future? The current one takes ages to compile even one liners and has problems with language assist. This is a surmountable inconvenience for puzzles, as long as it’s temporary, but it makes Kotlin totally useless in clash of code.
There are no plans for now. Unfortunately, using another infrastructure to compile Kotlin requires quite some dev on our side so I’m not sure we’d like to go for it. I’ll bump the issue to my team and keep you updated.
That’s sad to hear, but thanks for the info.
I’m not sure if putting lots of work into a different infrastructure is even that helpful if the problem lies with the compiler itself. Perhaps you could consider not waiting for the next major Kotlin release, but already try out the next incremental release, which should arrive in July, I think.
Yep, and scala 2.13 code (with no warnings) is compatible with scala 3. The migration should be really easy !
The Kotlin compilation is really slow at the moment, so I is basically unusable for anything requiring coding speed or performance.
Any update on this? Seems really important for Rust performance