4 ms·
I believe you can turn off the GC for Nim. Then you're just limited to libraries that don't rely on the GC, and fully manual memory management.
by vbit 12y ago
I believe you can turn off the GC for Nim. Then you're just limited to libraries that don't rely on the GC, and fully manual memory management.
- steventhedev 12y agoThis is more of an option than you might think. Nim plugs in to C libraries much easier than you would expect from an FFI. That means even if the stdlib depends on the GC heavily, you can eschew it for the C stdlib. For example: proc printf(formatstr: cstring) {.header: "<stdio.h>", importc: "printf", varargs.} I'd be interested in seeing a comparison of higher level language features rather than performance (which is generally a result of data structure choices, etc). Stuff like package managers, concurrency primitives, cross compiler support, memory management, and general syntax.
- skrebbel 12y agoWow, that's a pretty cool insight. Basically that means you could use "Nim without GC" as "a better C". I can see very few downsides. You could probably start using it in existing C projects much like you could start adding .scala files to an existing Java project.
- girvo 12y agoAs an example, that's exactly what I'm doing with my SDL game experiments; I'm using Nim as a "better C", effectively. It works rather brilliantly.
- pcwalton 12y agoThat isn't Rust's semantics though (as specified in the parent post): Rust's semantics are about ensuring safe manual memory management.