5 ms·

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

by 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.
  - ZenoArrow 11y ago
    > "On the other hand, safety is the absolute least concern." In that case, you may be interested to know Rust permits unsafe code: https://doc.rust-lang.org/book/unsafe.html https://doc.rust-lang.org/book/unsafe.html
    - onetwotree 11y ago
      Unsafe code isn't for things that "don't require safety". It's for things that are intrinsically unsafe, like calling foreign functions, and the unsafe keyword is basically saying "I promise to be very, very careful".
      - ZenoArrow 11y ago
        Unsafe code in Rust is for anything the programmer wants to use it for. If someone is writing their own scripts (like the GP), and wants a strongly-typed system-level programming language, and has explicitly stated they care very little about safety, I see no reason why they couldn't use unsafe Rust code.
  - steveklabnik 11y ago
    Don't forget that memory safety is the building block of a lot of other things, like safe concurrency: http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht... "Safe by default" saves a lot of different kinds of bugs.
  - pcwalton 11y ago
    Well, since you mentioned performance, the stuff I mentioned also buys you performance. Rust is in a category of language performance that GC'd languages with runtimes or JITs never reach in practice. I don't believe Go will be an exception to this (especially not now, with its lack of an optimizing compiler). In general, I think if you're looking for "one language to rule them all", that can scale up to the highest performance and down to one-off apps you would write in Rails, you will be disappointed. Even if you don't care about safety. That's because, no matter what people say, static and dynamic typing is a tradeoff. Rust is more statically typed than Go is. Go is more statically typed than Ruby is. Which you should use depends on your circumstances. A lot of language designers and enthusiasts, from all communities, believe there's a "sweet spot" of language design where your language can scale up or down at will. I don't believe it. That experiment was tried with Lisp and Java and failed. Multiple languages are here to stay. At the end of the day, all I can say is: If you're happy with Go, use Go. Rust was never designed with all use cases in mind, and I don't see that fact as a failure at all. I see it as just acknowledging reality: trying to make a language that scales up and down indefinitely to all use cases is chasing the impossible, and language enthusiasts who believe their language is the one language that can do that are all mistaken.
bsder 11y ago
> 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. People forget that the learning curve for correct memory handling in C is steep.

by guelo 11y ago

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.
- ZenoArrow 11y ago
  > "On the other hand, safety is the absolute least concern." In that case, you may be interested to know Rust permits unsafe code: https://doc.rust-lang.org/book/unsafe.html https://doc.rust-lang.org/book/unsafe.html
  - onetwotree 11y ago
    Unsafe code isn't for things that "don't require safety". It's for things that are intrinsically unsafe, like calling foreign functions, and the unsafe keyword is basically saying "I promise to be very, very careful".
    - ZenoArrow 11y ago
      Unsafe code in Rust is for anything the programmer wants to use it for. If someone is writing their own scripts (like the GP), and wants a strongly-typed system-level programming language, and has explicitly stated they care very little about safety, I see no reason why they couldn't use unsafe Rust code.
- steveklabnik 11y ago
  Don't forget that memory safety is the building block of a lot of other things, like safe concurrency: http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht... "Safe by default" saves a lot of different kinds of bugs.
- pcwalton 11y ago
  Well, since you mentioned performance, the stuff I mentioned also buys you performance. Rust is in a category of language performance that GC'd languages with runtimes or JITs never reach in practice. I don't believe Go will be an exception to this (especially not now, with its lack of an optimizing compiler). In general, I think if you're looking for "one language to rule them all", that can scale up to the highest performance and down to one-off apps you would write in Rails, you will be disappointed. Even if you don't care about safety. That's because, no matter what people say, static and dynamic typing is a tradeoff. Rust is more statically typed than Go is. Go is more statically typed than Ruby is. Which you should use depends on your circumstances. A lot of language designers and enthusiasts, from all communities, believe there's a "sweet spot" of language design where your language can scale up or down at will. I don't believe it. That experiment was tried with Lisp and Java and failed. Multiple languages are here to stay. At the end of the day, all I can say is: If you're happy with Go, use Go. Rust was never designed with all use cases in mind, and I don't see that fact as a failure at all. I see it as just acknowledging reality: trying to make a language that scales up and down indefinitely to all use cases is chasing the impossible, and language enthusiasts who believe their language is the one language that can do that are all mistaken.

bsder 11y ago

> 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. People forget that the learning curve for correct memory handling in C is steep.