6 ms·

> It's a pain to get working, it sucks to program in, it requires so much thought, it's just a bloody fucking fuck. I could not disagree more! Rust is a great

> It's a pain to get working, it sucks to program in, it requires so much thought, it's just a bloody fucking fuck. I could not disagree more! Rust is a great joy to program in. I would rather program in Rust than any other language. Rust is challenging for many people to learn. That is very different.

zbobet2012 10y ago
Language design is about trade-offs: The borrow checker and ownership model is a huge tradeoff. Even those very experienced in it still fight it from time to time. Go made a different trade, they chose GC. And GC _is_ easier. But it has computational overhead (well today anyway). Consider the cascading implications. Rust has a trait for Copy vs. Move types. This means every type has an implicit, and unknown behavior, on certain assignments: let v2 = v; println!("v is: {}", v); You can't actually tell me whether the above code compiles without consulting other parts of the code. That's not the case for Go. It is thus simpler and more intuitive to program in. But it is a trade-off. Go as a language must have a GC. It will never be suitable for certain tasks as a result. Go also has less compile time checking. This means faster compiles, quicker dev cycles but less compile time safety. Go chose easier here again. These trade-offs are what make rust seem "difficult" in comparison to go. I don't know if you can ever "fix" them.
- tetha 10y ago
  Exactly this. If you're a massively parallel web service, who cares about some GCs, and who cares about crashing like 0.01% of all transactions? Monitor it, crash it, fix it, deploy it, move on. If you operated a nuclear reactor with this mentality, I'd be concerned. If you're operating acme.org with that mindset... godspeed?
  - AnimalMuppet 10y ago
    If you're running amazon.com with that mindset, 0.01% of transactions is millions of dollars a day.
    - woah 10y ago
      If you're running amazon.com, a project that takes 2 weeks longer to complete is hundreds of millions of dollars of lost sales.
- vvanders 10y ago
  The thing is if you don't want to fight the borrow checker you can use RefCell and Arc/Rc. People are discouraged because then you lose a lot of architectural advantages that come with Rust but nothing is keeping you from writing unsafe{} and RefCell in the places where you know things are safe but can't formulate something that Rust understands.
  - empath75 10y ago
    I suspect that if you can't formulate it into something rust understands, you don't understand it well enough to know it's safe.
- tatterdemalion 10y ago
  I am a member of the Rust language design team, I am very aware that language design is about trade offs. I find the ownership model has non-performance advantages in that I find it provides strong design pressure to factor my system well. I would not describe my experience as 'fighting' the borrow checker - I feel positively when the borrow checker sends me back to the drawing board, because it teaches me things about my system I had not properly comprehended. (There are areas where the borrow checker is overly conservative, but I never hit these in practice.) > You can't actually tell me whether the above code compiles without consulting other parts of the code. That's not the case for Go. It is thus simpler and more intuitive to program in. I'm sorry this is just silly. Here's some Go code: v2 := v + 1 You can't actually tell me if the above code compiles without consulting other parts of the code, because you don't know if `v` can be added to `1`. In Rust, type inference is only local to a function, so you will be able to determine from an actual compile-able code snippet whether or not that use after move is valid. Go also actually might not compile on the exact example you cited (translated to Go, of course) because that code contains an error if `v2` is never used after it is assigned. In general, you cannot reason about the correctness of incomplete code snippets. This is not specific to Rust.
  - zbobet2012 10y ago
    I think you've missed my point. The ownership and borrowing model may provide many benefits, but those benefits come at the cost of complexity (as defined by Rich Hickey in Simple Made Easy). I have never found the owning/borrowing thing to be very hard. But it is _more complex_. There are _far_ more fundamental concepts baked into Rust then Go. And the interplay of those concepts creates complexity. It requires more knowledge and inherently complicates more things. The parent that started this says "it requires so much thought". What that means is they have to hold a lot more concepts in their head. It's not that any one concept is hard. It's that holding all those concepts and the interplay in their head at once is hard(er). This is what people mean when they say "Rust needs to improve to attract more non-genius developers." A huge portion of things you have to think about in the ownership/borrowing model simply doesn't exist with a garbage collected language. You just _don't_ have to think about a huge set of things at all. Type inference is an example of this tradeoff that both Go and Rust agreed on. This adds complexity and decreases clarity in both languages. The upside is expressiveness and conciseness. We could always make you specify the type with a declaration (like C) and then the snippet you posted would need less external reasoning: int v2 = v + 1; While you can't fully reason about any snippet of code, the more core language level concepts I have to address with any snippet the _harder_ and more complex it is for me to consider them.* I'm _not_ trashing Rust here. I'm just stating that some of the good tradeoffs you made here leave the language inherently more complex and thus difficult to use. There are _upsides_ to that. You gain safety, performance, and "pressure to factor [your] system well". Simplicity is very far from everything. When you're writing acme.org most of those tradeoffs are may not be worth the complexity. When you are writing a safety critical system they damn well are. *PS on the subject of code snippets and compilation. As engineers, the primary audience of our code is other engineers. As such, I always find some programming language debates have real insight when addressed by my Strunk and White (no really). Consider the following two sentences: The compiler must know the lvalue. It may then use it later on. Too me this is the English language equivalent of type inference. We know "it" is "the compiler" based on previous statements. Using pronouns too often in a sentence makes it unclear. Using them too sparingly makes it tedious (and also often difficult to read). A similar balance holds with concepts the reader must address in a given paragraph. This is the line we all dance when we write code. How many concepts must we hold at once to comprehend what is written?
- tankenmate 10y ago
  Go has one GC benefit that a lot of other GC wielding languages do not; avoid using GC whenever sensible. Variables that are strictly local are almost always allocated on the stack, so a function return has free built in GC; a sizeable number of allocated variables never hit the heap. Compare that to say CPython where everything is allocated on the heap.
  - osd 10y ago
    That's an unfair comparison. Python is notoriously bad with memory/speed in every flavor
    - scriptkiddy 10y ago
      I have yet to understand why people are always trying to compare Go and Python. Python isn't made for the same use cases as Go is. Can Go do the work Python can? To an extent, yes. Can Python do the things Go can do? To an extent, yes. Python will always be slower with the CPython runtime. In short, I agree with you.
      - tankenmate 10y ago
        In the case of Google Go was developed in part to take over some of workloads previously done in Python; a language that is comparably as easy to develop in, with better tools and better performance. I suspect this is why the comparisons keep popping up.
        scriptkiddy 10y ago
        >In the case of Google Go was developed in part to take over some of workloads previously done in Python; a language that is comparably as easy to develop in, with better tools and better performance. Go definitely performs better, buy I think it'd disingenuous to claim that Go has better tooling.
        sfifs 10y ago
- burntsushi 10y ago
  FWIW, I've been programming in both Rust and Go for years and I can't really perceive a productivity difference between them. I think it's uncontroversial to say that Rust has a tougher learning curve. But once you're past that, I think the jury is still out.
- CyberDildonics 10y ago
  GC is not easier when you care about how and when memory is allocated/deallocated
jandrese 10y ago
I don't know, that is the kind of comment you used to hear from LISP programmers about how their program was really an elegant mathematical proof of its own correctness. That's great until you try to do some real world things with it and run into endless impedance mismatches. Rust isn't quite so far up its own butt, however the developer community doesn't seem to realize that there's a massive gap between the toy example programs in their documentation and the level of knowledge needed to build something worthwhile.
- AlexCoventry 10y ago
  "Go is a blub language" was actually my hot take on this article.
- AsyncAwait 10y ago
  > the developer community doesn't seem to realize that there's a massive gap between the toy example programs in their documentation and the level of knowledge needed to build something worthwhile. I don't think Servo and rustc itself are "toy example programs".
  - civility 10y ago
    Are Servo and rustc in the Rust documentation? Literate programming of some sort? Maybe you're replying to a different criticism. I've been through the Rust Documentation (doc.rust-lang.org) and Rust By Example (rustbyexample.com) several times now, and I have to jump on IRC to get answers to (what I think should be) some pretty simple questions.
    - AsyncAwait 10y ago
      If you think something important is missing from the docs, please open an issue. Steve Klabnik is very keen on making the documentation as useful as possible.
      - civility 10y ago

zbobet2012 10y ago

Language design is about trade-offs: The borrow checker and ownership model is a huge tradeoff. Even those very experienced in it still fight it from time to time. Go made a different trade, they chose GC. And GC _is_ easier. But it has computational overhead (well today anyway). Consider the cascading implications. Rust has a trait for Copy vs. Move types. This means every type has an implicit, and unknown behavior, on certain assignments: let v2 = v; println!("v is: {}", v); You can't actually tell me whether the above code compiles without consulting other parts of the code. That's not the case for Go. It is thus simpler and more intuitive to program in. But it is a trade-off. Go as a language must have a GC. It will never be suitable for certain tasks as a result. Go also has less compile time checking. This means faster compiles, quicker dev cycles but less compile time safety. Go chose easier here again. These trade-offs are what make rust seem "difficult" in comparison to go. I don't know if you can ever "fix" them.

tetha 10y ago
Exactly this. If you're a massively parallel web service, who cares about some GCs, and who cares about crashing like 0.01% of all transactions? Monitor it, crash it, fix it, deploy it, move on. If you operated a nuclear reactor with this mentality, I'd be concerned. If you're operating acme.org with that mindset... godspeed?
- AnimalMuppet 10y ago
  If you're running amazon.com with that mindset, 0.01% of transactions is millions of dollars a day.
  - woah 10y ago
    If you're running amazon.com, a project that takes 2 weeks longer to complete is hundreds of millions of dollars of lost sales.
vvanders 10y ago
The thing is if you don't want to fight the borrow checker you can use RefCell and Arc/Rc. People are discouraged because then you lose a lot of architectural advantages that come with Rust but nothing is keeping you from writing unsafe{} and RefCell in the places where you know things are safe but can't formulate something that Rust understands.
- empath75 10y ago
  I suspect that if you can't formulate it into something rust understands, you don't understand it well enough to know it's safe.
tatterdemalion 10y ago
I am a member of the Rust language design team, I am very aware that language design is about trade offs. I find the ownership model has non-performance advantages in that I find it provides strong design pressure to factor my system well. I would not describe my experience as 'fighting' the borrow checker - I feel positively when the borrow checker sends me back to the drawing board, because it teaches me things about my system I had not properly comprehended. (There are areas where the borrow checker is overly conservative, but I never hit these in practice.) > You can't actually tell me whether the above code compiles without consulting other parts of the code. That's not the case for Go. It is thus simpler and more intuitive to program in. I'm sorry this is just silly. Here's some Go code: v2 := v + 1 You can't actually tell me if the above code compiles without consulting other parts of the code, because you don't know if `v` can be added to `1`. In Rust, type inference is only local to a function, so you will be able to determine from an actual compile-able code snippet whether or not that use after move is valid. Go also actually might not compile on the exact example you cited (translated to Go, of course) because that code contains an error if `v2` is never used after it is assigned. In general, you cannot reason about the correctness of incomplete code snippets. This is not specific to Rust.
- zbobet2012 10y ago
  I think you've missed my point. The ownership and borrowing model may provide many benefits, but those benefits come at the cost of complexity (as defined by Rich Hickey in Simple Made Easy). I have never found the owning/borrowing thing to be very hard. But it is _more complex_. There are _far_ more fundamental concepts baked into Rust then Go. And the interplay of those concepts creates complexity. It requires more knowledge and inherently complicates more things. The parent that started this says "it requires so much thought". What that means is they have to hold a lot more concepts in their head. It's not that any one concept is hard. It's that holding all those concepts and the interplay in their head at once is hard(er). This is what people mean when they say "Rust needs to improve to attract more non-genius developers." A huge portion of things you have to think about in the ownership/borrowing model simply doesn't exist with a garbage collected language. You just _don't_ have to think about a huge set of things at all. Type inference is an example of this tradeoff that both Go and Rust agreed on. This adds complexity and decreases clarity in both languages. The upside is expressiveness and conciseness. We could always make you specify the type with a declaration (like C) and then the snippet you posted would need less external reasoning: int v2 = v + 1; While you can't fully reason about any snippet of code, the more core language level concepts I have to address with any snippet the _harder_ and more complex it is for me to consider them.* I'm _not_ trashing Rust here. I'm just stating that some of the good tradeoffs you made here leave the language inherently more complex and thus difficult to use. There are _upsides_ to that. You gain safety, performance, and "pressure to factor [your] system well". Simplicity is very far from everything. When you're writing acme.org most of those tradeoffs are may not be worth the complexity. When you are writing a safety critical system they damn well are. *PS on the subject of code snippets and compilation. As engineers, the primary audience of our code is other engineers. As such, I always find some programming language debates have real insight when addressed by my Strunk and White (no really). Consider the following two sentences: The compiler must know the lvalue. It may then use it later on. Too me this is the English language equivalent of type inference. We know "it" is "the compiler" based on previous statements. Using pronouns too often in a sentence makes it unclear. Using them too sparingly makes it tedious (and also often difficult to read). A similar balance holds with concepts the reader must address in a given paragraph. This is the line we all dance when we write code. How many concepts must we hold at once to comprehend what is written?
tankenmate 10y ago
Go has one GC benefit that a lot of other GC wielding languages do not; avoid using GC whenever sensible. Variables that are strictly local are almost always allocated on the stack, so a function return has free built in GC; a sizeable number of allocated variables never hit the heap. Compare that to say CPython where everything is allocated on the heap.
- osd 10y ago
  That's an unfair comparison. Python is notoriously bad with memory/speed in every flavor
  - scriptkiddy 10y ago
    I have yet to understand why people are always trying to compare Go and Python. Python isn't made for the same use cases as Go is. Can Go do the work Python can? To an extent, yes. Can Python do the things Go can do? To an extent, yes. Python will always be slower with the CPython runtime. In short, I agree with you.
    - tankenmate 10y ago
      In the case of Google Go was developed in part to take over some of workloads previously done in Python; a language that is comparably as easy to develop in, with better tools and better performance. I suspect this is why the comparisons keep popping up.
      - scriptkiddy 10y ago
        >In the case of Google Go was developed in part to take over some of workloads previously done in Python; a language that is comparably as easy to develop in, with better tools and better performance. Go definitely performs better, buy I think it'd disingenuous to claim that Go has better tooling.
        sfifs 10y ago
burntsushi 10y ago
FWIW, I've been programming in both Rust and Go for years and I can't really perceive a productivity difference between them. I think it's uncontroversial to say that Rust has a tougher learning curve. But once you're past that, I think the jury is still out.
CyberDildonics 10y ago
GC is not easier when you care about how and when memory is allocated/deallocated

jandrese 10y ago

I don't know, that is the kind of comment you used to hear from LISP programmers about how their program was really an elegant mathematical proof of its own correctness. That's great until you try to do some real world things with it and run into endless impedance mismatches. Rust isn't quite so far up its own butt, however the developer community doesn't seem to realize that there's a massive gap between the toy example programs in their documentation and the level of knowledge needed to build something worthwhile.

AlexCoventry 10y ago
"Go is a blub language" was actually my hot take on this article.
AsyncAwait 10y ago
> the developer community doesn't seem to realize that there's a massive gap between the toy example programs in their documentation and the level of knowledge needed to build something worthwhile. I don't think Servo and rustc itself are "toy example programs".
- civility 10y ago
  Are Servo and rustc in the Rust documentation? Literate programming of some sort? Maybe you're replying to a different criticism. I've been through the Rust Documentation (doc.rust-lang.org) and Rust By Example (rustbyexample.com) several times now, and I have to jump on IRC to get answers to (what I think should be) some pretty simple questions.
  - AsyncAwait 10y ago
    If you think something important is missing from the docs, please open an issue. Steve Klabnik is very keen on making the documentation as useful as possible.
    - civility 10y ago