Iāve just had confirmation that there will be an update of the languages just before the Spring Challenge which begins next week. Hopefully, end of this week.
Rust and Python (among others) versions will be updated. But not for C#, GO, PHP, and TypeScript. Also, the Dart update will not be retro-compatible, and will break every existing codes 
Iāll email impacted people.
I will share the complete list update as soon as itās up.
Last time C++ had a language update, we lost all the stacktraces/error messages.
Any chance this bug will be fixed with the future language update?
Using C++ for a contest is really hard without any information when your code crashes.
most likely, it wonāt be fixed
Iām going to double-check though
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.