It also compiles to JS.
The grandparent's scientific/Go interests suggests a need for a large, working ecosystem and there are probably several places in ArrayMancer which need some love for "fallback cases" to work with tcc (or elsewhere in the as you note much smaller Nim eco-system).
EDIT: E.g., for ArrayMancer you need to make stb_image.h work with tcc by adding a nim.cfg/config.nims `passC="-DSTBIW_NO_SIMD -DSTBI_NO_SIMD"` directive, though. And, of course, to optimize compile times, just generally speaking, you always want to import only exactly what you really need which absolutely takes more time/thought.
I try to learn the basics of new programming language regularly and write a small lisp alike interpreter in it and give myself a maximum of 2 days working on it. It covers things like string handling, regexp, recursion, lambdas, garbage collection, ... and run them through a tiny test suite.
In Python and JS, it was easy to do it and the code was still very readable. In C++, the language I earn my money from, I had a bug I was not able to fix within the given time frame, happening just with gcc not clang, assuming some undefined behavior. In C, I was able to add my own garbage collector with muss less work than I expected ... but
Nim really impressed me, it really felt almost like I wrote it in Python, but an executable which run on its own and being quite a bit faster.
Working mostly in the embedded world, where ecosystem matters somewhat less. If any employee ever would give me a chance to choose a language myself I would definitely try to write a first prototype in Nim.
It's syntax is significantly different from python, but it does have operator overloading.
It's performance is comparable to go, and has good concurrency support, although it is different than go, and there are still some rough edges with "async" code. Compile times aren't as good as go though.
The type system is excellent, although I'm not really sure what you mean by "flexible".
And FFI support is great.
“Flexible” means the range from gradual typing (‘any’) to Turing complete conditional types that can do stuff like string parsing (for better or for worse). Structural typing vs instanceof and so on.
There’s really no comparison between Typescript’s type system and Rust’s. It’s worth noting though that Typescript is a bolted on typesystem that has explicitly traded soundness for flexibility. That’s the real tradeoff between Rust and TS IMHO. Rust is sound and expressive but not flexible, while Typescript is expressive and flexible but not sound.
Rust compiles fast if your translation units don’t need too much macro expansion. You add something like Diesel, and you can call for the lunch break.
It’s also worth mentioning Scala with Scala Native and maybe Kotlin with Kotlin/Native. OpenJDK Project Panama FFM now gives a better FFI experiences than JNI.
So the flexibility means one gets to pretend they are doing typing, but in reality they get to sprinkle the code with void casts, because expressing ideas is apparently hard? For better or worse, that is probably the main pillar Rust is designed on.
It's kind of a meme here on HN but while Rust compilation times are indeed higher than I wished they were, calling them “crippling” is a massive exaggeration.
My daily driver is a mid-range desktop computer from 2018 and I regularly code on a laptop from 2012, and even then it's completely manageable: cargo check is nigh instant on both, incremental compilation in debug mode is more than fast enough and even incremental rebuild in release mode and full debug builds are OK-ish (especially since they don't happen as often as the other above). There's only full builds in release mode that are arguably slow in the 2012 laptop (though on the project where it's the biggest problem, the majority of the time is spent compiling a C++ dependency), but then again it's a very obsolete piece of hardware and this isn't supposed to happen more than every six week when you update your compiler toolchain.
Then you can build a DAG of crates and stick e.g. the Protobuf stuff in its own separate corner where it only needs to be recompiled on full rebuilds or when you work on it.
Feels a bit shitty to have to resort to managing crates instead of modules simply due to the compile times, but it is what it is.
And it makes total sense to me, it’s a way of organizing your dependency graph by the lifetimes of your components.
This will also simplify testing, development, and audit. You won’t need to recompile autogen schemas as often as the business logic implementation anyway. Depending on artifacts pushed through a release pipeline is even more reliable. You can QA everything in guaranteed isolation while keeping it conveniently a workspace monorepo.
I’m not memeing here, I’ve struggled with this issue on a variety of different projects since I first started using Rust seven years ago.
Worse, typescript may even run out of it's allocated memory sometimes.
Go feels like C with training wheels.
Rust feels like riding a bike where one leg pedals the front wheel and another one pedals the back wheel, and you have one handlebar for each wheel as well and a very smart alarm system but it is very clunky to ride (and they tell you it's "flexible")
I only wish discussions happened elsewhere than Discord, e.g. Zulip, where you can have web-public channels, which is great for searchable documentation, and you can interact with channels by email if you so desire.
One question, more out of curiosity than any genuine need: do you (or do you plan to) support any kind of trait/interface based polymorphism? E.g. it's a pretty common idiom to have a function that works on "any iterable type" and that sort of thing, which seems like it would be best modeled as an interface. I guess you could argue that's at odds with Python's tradition of "duck typing" but then again, so is static typing in general so I'm not sure.
Does it deliver on the bold claims of its designers?
* Performance - the JVM is very competitive with C/C++ performance.
* Compile times - Not go fast, but not C/C++/Rust slow.
* Concurrency - Virtual threads (finalized in 21) bring in the concurrency capabilities of go to the JVM
* Type System Flexibility - Kotlin isn't quite as flexible as Typescript, but it's pretty close. It's more flexible than java but not as flexible as scala. I think it strikes a good middle ground.
* Native platform integration - This is probably the weakest part of the JVM but it's gotten a lot better with the work done on Project Panama (mostly delivered in 22). Jextract makes it a lot easier to make native integrations with Java. Definitely not as painful as the JNI days.
There's also kotlin native that you could play around with (I haven't).
You really just want operators when you're performing tons of operations, it's an absolute wall of text when it's all method calls.