3 ms·

How does Nimrod compare to Rust, in terms of goals?

616c 12y ago
Many people see them sitting in a similar space, but all things considered Rust's goal is safety, well Nimrod is more interested in metaprogramming and other features that take precedence over safety. All in all, I have looked into Nimrod a few times. It is very, very cool. One guy is even using the Obj-C bridge to run a core of an iOS app on it. You could theoretically now write a web API, an Android app core (not the GUI), and an iOS app core (not the GUI), and have them running all off the same logic written in Nimrod. I highly recommend checking out the forum and see the caliber of stuff these guys are putting out. Very impressive stuff. http://forum.nimrod-lang.org/ http://forum.nimrod-lang.org/
dbaupp 12y ago
Rust focuses very much on low/no-overhead memory safety (especially memory safety without a GC), while Nimrod seems to be more focused at more convenient low-level programming, but without quite such a strong push for memory safety and reliable very high performance (e.g. GC is compulsory for safety). That's not to say that Rust isn't convenient, but the quest for strong memory safety & performance guarantees doesn't come for free: satisfying the borrow checker can get a little tricky at times. An example of this: Rust's type system is designed to allow things like building a safe shared memory abstraction[1], that is, a shared memory type that enforces non-thread-safe data can't be shared without being inside a mutex. My reading of the Nimrod FAQ[2] ("An unsafe shared memory heap is also provided") implies this isn't (as easily) possible in Nimrod. (Disclaimer: I know a lot of Rust, but very little Nimrod.) [1]: http://static.rust-lang.org/doc/master/sync/struct.Arc.html http://static.rust-lang.org/doc/master/sync/struct.Arc.html [2]: http://nimrod-lang.org/question.html http://nimrod-lang.org/question.html
- pcwalton 12y ago
  > My reading of the Nimrod FAQ[2] ("An unsafe shared memory heap is also provided") implies this isn't (as easily) possible in Nimrod. Nimrod's GC is not thread safe, so you have to use raw unsafe allocation and deallocation in order to share objects between threads (last I looked anyway). This is in contrast to Rust, for which memory safety is important even in multithreaded scenarios.
  - rbehrends 12y ago
    Right now, Nimrod uses thread-local heaps (similar to what Erlang does). Threads can communicate via channels, and you can access global variables or the shared heap unsafely if that is needed for performance. My understanding (from talking to Nimrod's author) is that the concurrency model is still being finalized, but that safe shared memory is going to be part of it.
pcwalton 12y ago
Rust provides memory safety with no garbage collection. Like every other industrial language, Nimrod requires garbage collection in the form of (deferred) reference counting to achieve safety.

616c 12y ago

Many people see them sitting in a similar space, but all things considered Rust's goal is safety, well Nimrod is more interested in metaprogramming and other features that take precedence over safety. All in all, I have looked into Nimrod a few times. It is very, very cool. One guy is even using the Obj-C bridge to run a core of an iOS app on it. You could theoretically now write a web API, an Android app core (not the GUI), and an iOS app core (not the GUI), and have them running all off the same logic written in Nimrod. I highly recommend checking out the forum and see the caliber of stuff these guys are putting out. Very impressive stuff. http://forum.nimrod-lang.org/ http://forum.nimrod-lang.org/

dbaupp 12y ago

Rust focuses very much on low/no-overhead memory safety (especially memory safety without a GC), while Nimrod seems to be more focused at more convenient low-level programming, but without quite such a strong push for memory safety and reliable very high performance (e.g. GC is compulsory for safety). That's not to say that Rust isn't convenient, but the quest for strong memory safety & performance guarantees doesn't come for free: satisfying the borrow checker can get a little tricky at times. An example of this: Rust's type system is designed to allow things like building a safe shared memory abstraction[1], that is, a shared memory type that enforces non-thread-safe data can't be shared without being inside a mutex. My reading of the Nimrod FAQ[2] ("An unsafe shared memory heap is also provided") implies this isn't (as easily) possible in Nimrod. (Disclaimer: I know a lot of Rust, but very little Nimrod.) [1]: http://static.rust-lang.org/doc/master/sync/struct.Arc.html http://static.rust-lang.org/doc/master/sync/struct.Arc.html [2]: http://nimrod-lang.org/question.html http://nimrod-lang.org/question.html

pcwalton 12y ago
> My reading of the Nimrod FAQ[2] ("An unsafe shared memory heap is also provided") implies this isn't (as easily) possible in Nimrod. Nimrod's GC is not thread safe, so you have to use raw unsafe allocation and deallocation in order to share objects between threads (last I looked anyway). This is in contrast to Rust, for which memory safety is important even in multithreaded scenarios.
- rbehrends 12y ago
  Right now, Nimrod uses thread-local heaps (similar to what Erlang does). Threads can communicate via channels, and you can access global variables or the shared heap unsafely if that is needed for performance. My understanding (from talking to Nimrod's author) is that the concurrency model is still being finalized, but that safe shared memory is going to be part of it.

pcwalton 12y ago

Rust provides memory safety with no garbage collection. Like every other industrial language, Nimrod requires garbage collection in the form of (deferred) reference counting to achieve safety.