| Just a suggestion... you might want to include an example on your main README. As someone building a language myself, I'm interested in the other languages actively in development... But you start with an info dump, no examples, and then a table of features - where the first feature is not something anyone would pick a language for. You claim to be a memory safe language... And those are buried in the middle of the list. You want to highlight that, and say how you accomplish it. You say you have no GC, but no mention of Affine Ownership or Ref Counting. You talk about thread safety, but no mention of how. You need to show WHY anyone should care about your language, what problem it's solving, and what that looks like as fast as possible. In your comparison table, you leave out Go and include Odin - that seems like a mistake. Go punches FAR above its weight class. Dismissing it because it "comes with a heavy runtime" is likely to get your project dismissed, no offense. Odin is - essentially - experimental. People's attention is fleeting. Everyone and their mother is building a language or two... Some things I want to know right away: 1) what stage are you at (honestly, not wishfully)? 2) what problems have you ACTUALLY solved instead of INTEND to solve at some point in the future? 3) how thorough is your testing, what do you have, how much, what's the coverage by category? 4) this seems like a performance language - I want benchmarks. If you don't have a good concurrency story, you better have something, and you better have convincing benchmarks that it actually works, otherwise - 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? |
> 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.