Tomo: A statically typed, imperative language that cross-compiles to C [video]

jll29 39 minutes ago | parent | next [-]

It's a very clever aspiration to devise a new language not as something you hope everyone is going to switch to, but, as the OP states more of a test-bed to demonstrate a bunch of nice features, which you hope other people (that implement mainstream languages) will borrow/steal/copy. For instance, I very much appreciate the automatic parsing of command line arguments (and beyond just strings), which I hope the Rust folks will take over one day. Who would not like to skip all the boiler plate writing, but still offer decent cmd line options? For that reason, I will not compare the current Tomo feature set with any other language (as many other commenters do). But I will say that 150 lines for a complete terminal "snakes" game is pretty cool!

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.

▲

az09mugen 2 days ago | parent | prev | next [-]

TLDW; For those interested in the syntax, here the repo with some examples : https://github.com/bruce-hill/tomo

▲

tines an hour ago | parent | prev | next [-]

I like the effort, but this

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

▲

az09mugen 2 days ago | parent | prev | next [-]

Well thought language, I like the concepts.

▲

IshKebab 35 minutes ago | parent | prev | next [-]

Looks like a neat little language. I didn't see anything especially novel that other languages would want to steal though. The CLI parsing stuff is very similar to Typer, or clap_derive. Arbitrary precision integers are in Python (though I wish more scripting languages would do this too). Zig has great C interop.

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.

▲

netbioserror an hour ago | parent | prev [-]

The feature list here has significant overlap with Nim. Maybe we need a website that categorizes languages with feature tags, so we can visualize the overlap!

▲

spijdar an hour ago | parent [-]

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 an hour 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 4 minutes 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