Superficially similar, but from a look at the README, it has no polymorphism or generics, which hugely differentiates it from Nim, which leans very, very heavily on templates/generics throughout the entire language/standard library.

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).

▲

tines 2 hours ago | parent [-]

> would likely be more amiable to creating shared libraries.

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.

	▲	spijdar 2 hours ago \| parent [-]
		I was thinking more along the lines of compiling Tomo code, then being able to link against that pre-compiled binary from other Tomo code. Basically being able to substitute a source file module for a binary module. 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". [0] https://nim-lang.org/docs/nimrtl.html