| Thanks for the suggestions! > what stage are you at More than 10 years of development, the core aspects of the language are pretty stable and are unlikely to be changed in future. New features can be added, especially in the standard library. > what problems have you ACTUALLY solved instead of INTEND to solve at some point in the future? The main problem is memory safety. It's already solved and not planned to be solved. You already can't shoot your leg with typical memory-related errors. > how thorough is your testing, what do you have, how much, what's the coverage by category? I have a lot of tests, several thousands of test-cases covering each language feature, including tests for specific compilation errors, tests for compilation into actual binary code, many tests for each standard library feature, tests for the build system. And of course I have a self-hosted compiler, which proves that everything works as intended in actual code. > this seems like a performance language - I want benchmarks Nice suggestion, probably it's worth to adding some benchmarks. > it actually works It does. There is just nothing there in the language, which can degrade performance significantly. The same LLVM library is used as in C++ or Rust compilers, no GC is involved, runtime safety checks are sparse. In many cases the result binary code is identical for identical C++ or Rust code or at least closely matches it. My own rough measurements between two compiler generation (first one written in C++ and second one written in Ü) show nearly identical performance. > why is anyone from Go or Rust or Zig or Nim or Crystal or Swift or even Java/Kotlin/Scala or C# going to think about switching? Go and Java-VM based languages are garbage-collected, which is problematic in some areas (like video-games). Rust is fine, but is sometimes too complicated. Zig is just a better C with no memory safety. Nim isn't known for me. |