[sergiotapia]

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:

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.

[icedchai]

I'm going to check it out this weekend... I'm very intrigued by what I see.

[MaxBarraclough]

It uses a rather primitive garbage-collector though, right?

[sp33der89]

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

Recent versions also use this fancy thing: http://www.gii.upv.es/tlsf/

[MaxBarraclough]

'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?

[rayman22201]

Did you see the parent comments about the new -gc:arc? It's suitable for hard real time. https://www.youtube.com/watch?v=yA32Wxl59wo

[MaxBarraclough]

> Reference cycles cause memory leaks, beware.

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.

[beagle3]

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

[dom96]

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.

[rayman22201]

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.

[jjtheblunt]

Isn't it announced here in this release : --gc:arc and linked explanatory video https://www.youtube.com/watch?v=yA32Wxl59wo ?

[rayman22201]

yup! That is the one :-)

[treeform]

Neat project!