If you would like to see some simple to parse Nim code and get a feel for what a "1 month of experience during weekends" Nim looks like, check out my project:
Nim is a very interesting language, with a lot of upsides. It just needs that killer framework to get the ball rolling and allow devs to solve business needs quickly. Once that's done I think Nim will grow a lot! Tiny binaries, static binaries, fast, low memory usage, macros, compiles to C.
It really doesn't! It's GC story is pretty great, because you can choose out of several GC's, one of them being good for real-time systems: https://nim-lang.org/docs/gc.html
'TLSF' sounds very interesting, I'll have to keep an eye on that project. What are the reference-counting options for though, given the absence of weak references? Under what circumstances is it acceptable to permit memory-leaks in case of cycles? Short-lived processes (i.e. arena-based memory management)?
When I say 'primitive GC', I mean Boehm, which is obviously decades behind the state of the art, but easy to get off the ground. GNU Guile uses it, for instance. Serious garbage collectors are tremendously complex, and are something less popular languages unfortunately tend to lack. I believe even D is miles behind Java.
Can't say I know much about Go's GC.
Edit Oops I misread, TLSF isn't a GC, it's an allocator. It sounds then like Nim doesn't have a proper real-time solution, does it? useRealtimeGC is actually a leaky reference-counting system?
It isn't acceptable to just permit memory-leaks in case of cycles. There's no way we'd ever see something like that in a serious JVM.
Unless there's some serious machinery to provide assurances against reference cycles, of course. Which sounds like an interesting research project, come to think of it.
> It isn't acceptable to just permit memory-leaks in case of cycles.
That's only in the new --gc:arc which is still somewhat experimental. The old gc, --gc:markandsweep IIRC, does detect cycles, and has a deadline schedule (i.e. you can tell it "I now have 5ms, collect as much as you can"); But it has per-thread heaps, which means passing data between threads often entails a copy. You also have --gc:boehm (no cycles, shared heap), and --gc:none (no gc, you should take care of freeing memory yourself).
Primitive in what sense? Nim has a soft real-time garbage collector which doesn't sound primitive to me. Actually Nim supports more than one GC including boehm so you really have a lot of choice here.
As others have said, Nim has plugabble garbage collectors, some are quite advanced.
In addition there is active work on a swift like reference counting, lifetime based memory management option. This will be suitable for hard real-time use cases.
https://github.com/sergiotapia/torrentinim
Nim is a very interesting language, with a lot of upsides. It just needs that killer framework to get the ball rolling and allow devs to solve business needs quickly. Once that's done I think Nim will grow a lot! Tiny binaries, static binaries, fast, low memory usage, macros, compiles to C.