Hacker News Reader

Comment by PMunch | Hacker News Reader

They work only as long as they don't use any garbage collected types (the compiler will warn you of this when you turn the GC off). Unfortunately this means most libraries are out, and you have to do your own thing. Turning the GC off is more meant as a way to use Nim on micro-controllers and for things like kernels and such. In this case many libraries that aren't written for this use-case doesn't really make sense to use anyways, so I'm not sure how big of an issue this is in reality.

View on HN

> I'm not sure how big of an issue this is in reality

I agree - embedded programming is a sufficiently separate world that you'll always need a different foundation with different assumptions.

Rust which doesn't have a GC at all, but stillhas this problem to some extent. On a microcontroller you generally don't want to use the standard library with all its assumptions about heap allocations always succeeding. This is why 'nostd' and libraries like heapless exist.

> Rust which doesn't have a GC at all, but stillhas this problem to some extent.

I agree, but there is a big difference between not being able to use almost any library, and being able to use most libraries.

There are many many libraries on embedded Rust, and my embedded and not embedded projects do share many libraries.

> so I'm not sure how big of an issue this is in reality.

I have audio programming in mind. Not that you can't do audio programming in GC-enabled languages, it's just that's it's quite frown upon in this circle (for good reasons). I'm sure there are workarounds though.

Audio programming? And why is it frowned upon? If it is because of the Java-like GC freezes that is something you can ensure will not happen in Nim by turning on manual control and only running it when its suitable.

Not the person you responded to, but yes. The audio must never be interrupted, everything else first.

Audio programming in Nim is completely possible and reasonable.

Here is an example of a super collider plugin written entirely in Nim with the GC turned off: https://forum.nim-lang.org/t/3625

The author seemed to find the experience very pleasant, and the performance was great.

Not (yet) a Nim user, but another post mentioned that GC is thread-specific, so you can remove all traces of GC-types from your real-time thread(s) in order to avoid deallocations at the wrong times.

A related question is whether you can disable GC on a thread by thread basis.

Reply on news.ycombinator.com