5 ms·

I think the reason I don't like Nimrod is the same as the reason I don't like C++(11): it has too many features. Rust's (relative) simplicity and memory safety

I think the reason I don't like Nimrod is the same as the reason I don't like C++(11): it has too many features. Rust's (relative) simplicity and memory safety make it much more attractive to me.

andreasvc 13y ago
I think Rust is very interesting, but a language with a "periodic table of types" is definitely not one of the simpler languages out there. Just like the zero-cost abstractions of C++, the memory safety in Rust comes at a price of increased complexity.
- andolanra 13y ago
  I'd assert that the "periodic table of types"[^1] radically overstates the complexity of the Rust type system, largely because of the rampant misuse of the "periodic table" as a means of presenting groups of things. A "periodic table" of (for example) food items or Perl operators tends to have a bunch of distinct elements in its cells arranged by loose groupings[^2], whereas the Rust periodic table (like the periodic table of elements, but unlike other pop-culture periodic tables) has cells whose contents are for the most part[^3] a function of their row and column. Tabular nomenclature aside: Rust has values and two kinds of pointers, and a handful of built-in types, and you can have pointers to those types. While the semantics of the pointers are unusual, I don't think that makes it that much more complicated. It should also be noted that many of the proposed language changes make said table even more regular (e.g. replacing the [T] syntactic sugar for vectors with a more conventional Vec<T>.) Rust is in some ways complicated, and I'll grant that a beginner to the language will likely curse the borrow-checker more than a few times. But I don't think Rust is nearly as complicated as it is sometimes reputed to be. [^1]: http://cosmic.mearie.org/2014/01/periodic-table-of-rust-types/ http://cosmic.mearie.org/2014/01/periodic-table-of-rust-type... [^2]: http://www.ozonehouse.com/mark/periodic/ http://www.ozonehouse.com/mark/periodic/ is an egregious example. [^3]: There are exceptions (e.g. the closure types) but they are few and easily memorized.
  - burntsushi 13y ago
    As someone without experience with linear types who learned Rust in the last week while porting quickcheck, I think my experience supports your claim here. In the first few days I was cursing the borrow-checker in every way imaginable. I was comfortable with everything except the pointer types and their borrowing semantics. After a few days, the borrowing logic really started to click and I was fighting much less with the compiler. Admittedly, I still have some fogginess about some areas (particularly the borrowing/sending semantics of closures), but I understand that there's still some work left to be done on that before 1.0. But the point I want to stress here is that once the borrowing logic clicked, Rust became a reasonably simple language. Which is really important to me. But, I now get to say that I just wrote quickcheck without manually freeing memory and without the use of a garbage collector. That's pretty damn cool if I say so myself.
    - sanderjd 13y ago
      Hey I think I was just playing with your quickcheck library and gave it a star earlier today! Small world. Nice project, I'm looking forward to using it for stuff :)
      - burntsushi 13y ago
        Ah great! Thanks :-) Feedback/criticism is appreciated. Still kind of learning the ropes of the Rust ecosystem.
barchar 13y ago
I like nimrod because it has a sane syntax. I can write a function declaration in one line of nimrod that would be 6 lines of c++. I also like Nimrod's focus on static dispatch and easy to use generics. Rust makes me uneasy because the whole lifetime tracking adds a lot of complexity and I fear it may make some programs harder to write or some libraries harder to use. Also I think that garbage collection, if fast (which nimrod's is very much so) is the right way to go in some situations. I don't actually want to go and spend time freeing a bunch of strings right after I use them.
- steveklabnik 13y ago
  Ultimately though, if you don't have GC, you _must_ deal with lifetimes, wheather or not the compiler helps you with them.
  - barchar 13y ago
    well yes. This is true. But nimrod has (very fast) GC. And it also has destructors and RAII so if you really, really need unique_ptr style memory management you can do that. Rust has lifetime tracking but I would be interested to know how it performs against Nimrod's GC when the ownership gets really tricky.
    - pcwalton 13y ago
      > Rust has lifetime tracking but I would be interested to know how it performs against Nimrod's GC when the ownership gets really tricky. You can use GC or reference counting in Rust—the same that Nimrod uses. (You could use DRC like Nimrod in Rust if you wanted, but it's not my preferred form of memory management due to the cost of making it thread safe.)
    - sanxiyn 13y ago
      I think one issue is that people have different opinions on whether "ownership gets really tricky" is a common case or an edge case. Many people with unique_ptr experience seem to assume that Rust's owned pointer is more of the same and not really applicable when ownership is even slightly complex, but this is not the case. Rust's owned pointer is vastly more powerful than unique_ptr and in my experience (and in Rust compiler and Servo browser's experience) and "ownership gets really tricky" is an edge case.

I think the reason I don't like Nimrod is the same as the reason I don't like C++(11): it has too many features. Rust's (relative) simplicity and memory safety make it much more attractive to me.

andreasvc 13y ago

I think Rust is very interesting, but a language with a "periodic table of types" is definitely not one of the simpler languages out there. Just like the zero-cost abstractions of C++, the memory safety in Rust comes at a price of increased complexity.

andolanra 13y ago
I'd assert that the "periodic table of types"[^1] radically overstates the complexity of the Rust type system, largely because of the rampant misuse of the "periodic table" as a means of presenting groups of things. A "periodic table" of (for example) food items or Perl operators tends to have a bunch of distinct elements in its cells arranged by loose groupings[^2], whereas the Rust periodic table (like the periodic table of elements, but unlike other pop-culture periodic tables) has cells whose contents are for the most part[^3] a function of their row and column. Tabular nomenclature aside: Rust has values and two kinds of pointers, and a handful of built-in types, and you can have pointers to those types. While the semantics of the pointers are unusual, I don't think that makes it that much more complicated. It should also be noted that many of the proposed language changes make said table even more regular (e.g. replacing the [T] syntactic sugar for vectors with a more conventional Vec<T>.) Rust is in some ways complicated, and I'll grant that a beginner to the language will likely curse the borrow-checker more than a few times. But I don't think Rust is nearly as complicated as it is sometimes reputed to be. [^1]: http://cosmic.mearie.org/2014/01/periodic-table-of-rust-types/ http://cosmic.mearie.org/2014/01/periodic-table-of-rust-type... [^2]: http://www.ozonehouse.com/mark/periodic/ http://www.ozonehouse.com/mark/periodic/ is an egregious example. [^3]: There are exceptions (e.g. the closure types) but they are few and easily memorized.
- burntsushi 13y ago
  As someone without experience with linear types who learned Rust in the last week while porting quickcheck, I think my experience supports your claim here. In the first few days I was cursing the borrow-checker in every way imaginable. I was comfortable with everything except the pointer types and their borrowing semantics. After a few days, the borrowing logic really started to click and I was fighting much less with the compiler. Admittedly, I still have some fogginess about some areas (particularly the borrowing/sending semantics of closures), but I understand that there's still some work left to be done on that before 1.0. But the point I want to stress here is that once the borrowing logic clicked, Rust became a reasonably simple language. Which is really important to me. But, I now get to say that I just wrote quickcheck without manually freeing memory and without the use of a garbage collector. That's pretty damn cool if I say so myself.
  - sanderjd 13y ago
    Hey I think I was just playing with your quickcheck library and gave it a star earlier today! Small world. Nice project, I'm looking forward to using it for stuff :)
    - burntsushi 13y ago
      Ah great! Thanks :-) Feedback/criticism is appreciated. Still kind of learning the ropes of the Rust ecosystem.

barchar 13y ago

I like nimrod because it has a sane syntax. I can write a function declaration in one line of nimrod that would be 6 lines of c++. I also like Nimrod's focus on static dispatch and easy to use generics. Rust makes me uneasy because the whole lifetime tracking adds a lot of complexity and I fear it may make some programs harder to write or some libraries harder to use. Also I think that garbage collection, if fast (which nimrod's is very much so) is the right way to go in some situations. I don't actually want to go and spend time freeing a bunch of strings right after I use them.

steveklabnik 13y ago
Ultimately though, if you don't have GC, you _must_ deal with lifetimes, wheather or not the compiler helps you with them.
- barchar 13y ago
  well yes. This is true. But nimrod has (very fast) GC. And it also has destructors and RAII so if you really, really need unique_ptr style memory management you can do that. Rust has lifetime tracking but I would be interested to know how it performs against Nimrod's GC when the ownership gets really tricky.
  - pcwalton 13y ago
    > Rust has lifetime tracking but I would be interested to know how it performs against Nimrod's GC when the ownership gets really tricky. You can use GC or reference counting in Rust—the same that Nimrod uses. (You could use DRC like Nimrod in Rust if you wanted, but it's not my preferred form of memory management due to the cost of making it thread safe.)
  - sanxiyn 13y ago
    I think one issue is that people have different opinions on whether "ownership gets really tricky" is a common case or an edge case. Many people with unique_ptr experience seem to assume that Rust's owned pointer is more of the same and not really applicable when ownership is even slightly complex, but this is not the case. Rust's owned pointer is vastly more powerful than unique_ptr and in my experience (and in Rust compiler and Servo browser's experience) and "ownership gets really tricky" is an edge case.