8 ms·

So this is an old article. I wonder if his perception of Rust has changed since it's 1.0 debut. > Rust is “C syntax” and Nim is Python-ish. Nim wins this one h

So this is an old article. I wonder if his perception of Rust has changed since it's 1.0 debut. > Rust is “C syntax” and Nim is Python-ish. Nim wins this one hands down for me. This is always going to be a really personal choice for most people. I actually prefer all the clarity I get from the curly brackets. > Nim has Exceptions with tracking (!) and Rust has explicit error handling via the return value. Personally… that feels like a big step backwards, much like error handling in Go. Again, for me, a clear win for Nim. I know others feel differently, but that is ok :) Rust has made a plain distinction between expected error return behavior (like parse errors) that you can recover from, and panic! which is the closest thing to exceptions. If you come from languages and code bases that suffer from huge amounts of confusion b/c of things like RuntimeExceptions vs. CheckedExceptions vs. Errors (Java) it's a blessing to have strongly typed return values that require doing something with the error case. Though, errors in rust could be easier to work with, they are a bit painful now. It looks like there is some stuff on the road map to do just this, based on a merge I saw recently. > Rust is pushed by Mozilla, Nim is a grass root “true open source” language. Having a “backer” might be good, but I like grass root efforts since they tend to be more open and easier to participate in as a “full” member. Mozilla is a saint for backing this effort. Love them or hate them, it's like Redhat's support of Linux. It's great that there are paychecks paying for this development. The Rust community is really strong, and doesn't (IMO) suffer from the issues related to BDFL and has open transparent discussions around requested changes.

nextos 11y ago
I also prefer Nim to Rust, but I haven't done anything extensively in either. How does Nim do in the safety area? AFAIK, Rust has e.g. regions and linear types to achieve memory safety.
- pcwalton 11y ago
  Last I looked: - Nim had a lot of undefined behavior. Dereferencing a null pointer, for example, led to undefined behavior because of compiling to C. - Nim seemed to have less flexible data race prevention (though the abstract interpretation stuff that Nim does to determine disjointness of arrays could be more ergonomic than Rust's split_at_mut, albeit more complex). Data races were also more of a problem in Nim because the lack of a thread-safe GC meant that races could result in use-after-free. - Nim was in the typical "memory safety requires a GC; opt out of GC and you lose memory safety" category of languages (reference counting being a form of GC). Rust, by contrast, retains safety even when GC is not used (which it rarely is). This was many months ago, so it may well have changed.
  - kirbyfan64sos 11y ago
    In most cases, though, the GC is light enough that it can stay enabled, and you'll rarely ever end up with raw pointers. For threading, you can use the capabilities at: http://nim-lang.org/docs/threadpool.html http://nim-lang.org/docs/threadpool.html
    - pcwalton 11y ago
      The GC was not thread-safe at that time, so you did not need raw pointers to get the unsafety.
- dom96 11y ago
  This forum thread might be of interest http://forum.nim-lang.org/t/1961 http://forum.nim-lang.org/t/1961
grayrest 11y ago
> It looks like there is some stuff on the road map to do just this, based on a merge I saw recently. The "Trait Based Exception Handling" RFC is in final comments: https://github.com/rust-lang/rfcs/pull/243 https://github.com/rust-lang/rfcs/pull/243
kenko 11y ago
The comparison of Rust's errors-by-return-values to Go's is really off-base.
- onetwotree 11y ago
  Exactly, between a powerful type system and macros like try!, you're basically rolling on the same level as Haskell and other advanced languages in Rust.
  - rspeer 11y ago
    I'd say you should hold off on that claim until Rust errors are composable (RFC #243). I know it's close. The macros aren't quite up to the job of safely coping with the tangle of different errors that different libraries can return without writing Go-like error handlers yet.
    - jonreem 11y ago
      I disagree. The RFC you are citing is effectively just syntax sugar baking the `try!` macro into the language; it doesn't allow you to express anything you couldn't express today with `try!` and closures.
steveklabnik 11y ago
Also > I would however urge Rust people to add a section in their > documentation called “Error handling” or similar so that one > can find it without having to read the entire manual! We have this today! http://doc.rust-lang.org/book/error-handling.html http://doc.rust-lang.org/book/error-handling.html
- gokr 11y ago
  That's great! :)
guelo 11y ago
The main complaint that "Rust is much more complicated to program in." Is still very valid. The learning curve for Rust's memory handling is steep. But this is to be expected when comparing any GC to a non-GC language. GC languages are always going to be easier for the programmer, that's the whole point of the GC. Rust's claim of being memory-safe without a GC is great but it's not an advantage if you can afford the GC.
- pcwalton 11y ago
  I think that's a bit oversimplified. The same mechanisms that allow memory-safe manual memory management also eliminate data races without having to use a race detector. They also provide a very flexible form of const correctness, if that's your thing. I think the cognitive overhead of Rust's memory model outweighs its benefits only if all of the following are true for your application: 1. Your application can afford the cost of GC and a runtime. 2. Your application does not use concurrency, or you are willing to tolerate data race errors, or you can eliminate all data races with a runtime race detector (due to extensive test coverage or similar). 3. The help that compiler-enforced immutability affords to your ability to reason about the code isn't important enough to you to justify the cost. I think that there are a lot of apps that meet (1), (2), and (3), don't get me wrong. But I also think there are a good deal of apps that meet (1) but not (2) or (3), and they can benefit from Rust as well.
  - lobster_johnson 11y ago
    I don't use Rust, so pardon my ignorance, but my impression is that Rust will be very annoying if you're doing something that does not require safety. For example, these days I write a lot of data processing stuff that is closer to scripting than anything else, and is usually "one-offs" that get scrapped afterwards. But the code needs to be super fast, talk to databases, parallelize across multiple cores and nodes, which rules out many languages. On the other hand, safety is the absolute least concern. I've been using Ruby when it's not performance-sensitive, and Go when it is, and while Go is significantly less pleasant, it gives me decent performance, concurrency and access to libraries. Nim would probably also be ideal, if not for the lack of libraries. But Rust just seems like a terrible choice for this stuff because of the syntactical overhead of its abstractions, in particular memory. That limits its usefulness. A single language for all my work would reduce context switching and allow code reuse. In general, my impression is that Rust is good at the complex, heavy stuff, but it doesn't scale down.

nextos 11y ago

I also prefer Nim to Rust, but I haven't done anything extensively in either. How does Nim do in the safety area? AFAIK, Rust has e.g. regions and linear types to achieve memory safety.

pcwalton 11y ago
Last I looked: - Nim had a lot of undefined behavior. Dereferencing a null pointer, for example, led to undefined behavior because of compiling to C. - Nim seemed to have less flexible data race prevention (though the abstract interpretation stuff that Nim does to determine disjointness of arrays could be more ergonomic than Rust's split_at_mut, albeit more complex). Data races were also more of a problem in Nim because the lack of a thread-safe GC meant that races could result in use-after-free. - Nim was in the typical "memory safety requires a GC; opt out of GC and you lose memory safety" category of languages (reference counting being a form of GC). Rust, by contrast, retains safety even when GC is not used (which it rarely is). This was many months ago, so it may well have changed.
- kirbyfan64sos 11y ago
  In most cases, though, the GC is light enough that it can stay enabled, and you'll rarely ever end up with raw pointers. For threading, you can use the capabilities at: http://nim-lang.org/docs/threadpool.html http://nim-lang.org/docs/threadpool.html
  - pcwalton 11y ago
    The GC was not thread-safe at that time, so you did not need raw pointers to get the unsafety.
dom96 11y ago
This forum thread might be of interest http://forum.nim-lang.org/t/1961 http://forum.nim-lang.org/t/1961

grayrest 11y ago

> It looks like there is some stuff on the road map to do just this, based on a merge I saw recently. The "Trait Based Exception Handling" RFC is in final comments: https://github.com/rust-lang/rfcs/pull/243 https://github.com/rust-lang/rfcs/pull/243

kenko 11y ago

The comparison of Rust's errors-by-return-values to Go's is really off-base.

onetwotree 11y ago
Exactly, between a powerful type system and macros like try!, you're basically rolling on the same level as Haskell and other advanced languages in Rust.
- rspeer 11y ago
  I'd say you should hold off on that claim until Rust errors are composable (RFC #243). I know it's close. The macros aren't quite up to the job of safely coping with the tangle of different errors that different libraries can return without writing Go-like error handlers yet.
  - jonreem 11y ago
    I disagree. The RFC you are citing is effectively just syntax sugar baking the `try!` macro into the language; it doesn't allow you to express anything you couldn't express today with `try!` and closures.

steveklabnik 11y ago

Also > I would however urge Rust people to add a section in their > documentation called “Error handling” or similar so that one > can find it without having to read the entire manual! We have this today! http://doc.rust-lang.org/book/error-handling.html http://doc.rust-lang.org/book/error-handling.html

gokr 11y ago
That's great! :)

guelo 11y ago

The main complaint that "Rust is much more complicated to program in." Is still very valid. The learning curve for Rust's memory handling is steep. But this is to be expected when comparing any GC to a non-GC language. GC languages are always going to be easier for the programmer, that's the whole point of the GC. Rust's claim of being memory-safe without a GC is great but it's not an advantage if you can afford the GC.

pcwalton 11y ago
I think that's a bit oversimplified. The same mechanisms that allow memory-safe manual memory management also eliminate data races without having to use a race detector. They also provide a very flexible form of const correctness, if that's your thing. I think the cognitive overhead of Rust's memory model outweighs its benefits only if all of the following are true for your application: 1. Your application can afford the cost of GC and a runtime. 2. Your application does not use concurrency, or you are willing to tolerate data race errors, or you can eliminate all data races with a runtime race detector (due to extensive test coverage or similar). 3. The help that compiler-enforced immutability affords to your ability to reason about the code isn't important enough to you to justify the cost. I think that there are a lot of apps that meet (1), (2), and (3), don't get me wrong. But I also think there are a good deal of apps that meet (1) but not (2) or (3), and they can benefit from Rust as well.
- lobster_johnson 11y ago
  I don't use Rust, so pardon my ignorance, but my impression is that Rust will be very annoying if you're doing something that does not require safety. For example, these days I write a lot of data processing stuff that is closer to scripting than anything else, and is usually "one-offs" that get scrapped afterwards. But the code needs to be super fast, talk to databases, parallelize across multiple cores and nodes, which rules out many languages. On the other hand, safety is the absolute least concern. I've been using Ruby when it's not performance-sensitive, and Go when it is, and while Go is significantly less pleasant, it gives me decent performance, concurrency and access to libraries. Nim would probably also be ideal, if not for the lack of libraries. But Rust just seems like a terrible choice for this stuff because of the syntactical overhead of its abstractions, in particular memory. That limits its usefulness. A single language for all my work would reduce context switching and allow code reuse. In general, my impression is that Rust is good at the complex, heavy stuff, but it doesn't scale down.