> No polymorphism, generics
makes it DOA for me. Also the fact that this is a GC language makes it feel like it's aiming at higher level applications than C.
Granted, that also means Tomo probably has better incremental compilation, and would likely be more amiable to creating shared libraries. You can do that with Nim, too, but the external interface (generally) has to be "C" semantics (similar to most other "high level" languages).
Why's that? There's a gc/no-gc barrier to cross, and also being able to use other features in an implementation doesn't make creating a C interface harder.
I don't know if Tomo supports anything like that, but not having generics would make it easier/simpler to implement (e.g. no need to mangle symbol names). Note "easier/simpler", Nim can also "precompile Nim libraries for Nim code", but the resulting libraries are brittle (API-wise), and only really useful for specific use cases like creating binary Nim plugins to import to another Nim program, where you'll want to split out the standard runtime library [0] and share it across multiple images. It's not useful for e.g. precompiling the standard library to save time.
I know Nim has been working on incremental compilation, too, but I don't know what the state of that is. I think it might have been punted to the rewritten compiler/runtime "Nim 3".
It's also smart to facilitate integration with C or other languages that have an abundance of libraries, because it's unlikely that you will create the momentum to rewrite everything in your facorite baby language.
I wish it was an embeddable language like Lua though - there are a gazillion languages that are similar to this that you can use for non-embeddable cases... But there are very very few statically typed embeddable scripting languages. The only ones I know of are Gluon, which leans waaaay too far into the obscure functional stuff for a scripting language... and AngelScript which is just a bit too ancient and Javaesque for me.
az09mugen•2d ago