4 ms·

>>People who say Rust is hard are probably skipping on reading the really well written Rust book. Do you need to read a really good Go book to be productive in

>>People who say Rust is hard are probably skipping on reading the really well written Rust book. Do you need to read a really good Go book to be productive in Go? If not, I think the OP's point stands, no?

jacobwcarlson 10y ago
I believe he's saying that the Rust book[0] is very good (and completely free). [0]: https://doc.rust-lang.org/stable/book/ https://doc.rust-lang.org/stable/book/
Someone1234 10y ago
I'm not sure that's fair. There are certain languages which are different enough from traditional semantics to need an explanation. While others are similar enough to be "obvious" if you've used a semantically similar language before. To give a specific example, Powershell. It is semantically a very different scripting language from almost anything else in the market. Extremely well designed and powerful, but you'll want to sit down and read an actual book on how it works to get to handle on it because you won't have the mental map already to do so. Overall this is why the programming language market is so predisposed for new languages looking and feeling like old languages. People just aren't comfortable stepping too far outside of their comfort zone semantically (even if they'll happily do so for a few new language features and libraries).
- disordinary 10y ago
  Yeah one of the best things about Go is how familiar it is, you can pick it up and run with it very quickly. One of the best things about Rust is that it's a paradigm change, it takes time to get your mind around it but it is worth it if the language fits your use case.
- weberc2 10y ago
  > People just aren't comfortable stepping too far outside of their comfort zone semantically (even if they'll happily do so for a few new language features and libraries). I'm not sure that's fair. It seems more likely that people who choose "boring" languages do so because they have things to build, and want to pick a language with a good risk/reward value. Not out of some academic interest or comfort calculation.
verletx64 10y ago
I think that focusing on how long it takes to be productive is a mistake, within reason at least. How well does it hold up once I'm knowledgeable with the language matters a lot more. If it takes me 4 days or 3 weeks to be productive, ok, that's fine, but it needs to be a good solution once I'm there, because I'll spend years using it potentially.
- strken 10y ago
  The really, really important thing about the time it takes to be productive in a language is selling the language to other people. If it takes 3 weeks to learn enough Rust to make interesting projects, then it's going to be absolute hell convincing a team of largely ambivalent co-workers to use Rust, because 3 weeks is equivalent to months of weekend tinkering. You're restricted to using Rust either when it has mass adoption, it interests your devs, or the domain needs provable safety guarantees. On the other hand, if someone can pick up Go and produce a side project with two weekends worth of messing around, they're much more likely to be supportive of the language. Obviously this isn't ideal, but I don't know how you'd fix the problem.
  - dorfsmay 10y ago
    Do you really want people on your team who think that having to read a free book and investing 3 weeks to learn a new language is too much of an effort?
    - strken 10y ago
      Firstly, when the initial impression of a language is that it's not fast to code in, people seem to assume that it will remain unproductive in regular use. This is clearly the case with ESR, and is a problem that's relevant to the Rust community in general. Secondly, as per the Rolling Stones, you can't always get what you want.
    - solidsnack9000 10y ago
      Sometimes you don't have a choice. You don't want those people but they are forced on you. It's strange the short term focus that is accepted in what are nominally professionals.
lmm 10y ago
If you've come from an ML background you'd need a good book to be productive in Go, and jump straight into Rust. Go is more C-like which makes it easier to pick up coming from C, not absolutely easier.

jacobwcarlson 10y ago

I believe he's saying that the Rust book[0] is very good (and completely free). [0]: https://doc.rust-lang.org/stable/book/ https://doc.rust-lang.org/stable/book/

Someone1234 10y ago

I'm not sure that's fair. There are certain languages which are different enough from traditional semantics to need an explanation. While others are similar enough to be "obvious" if you've used a semantically similar language before. To give a specific example, Powershell. It is semantically a very different scripting language from almost anything else in the market. Extremely well designed and powerful, but you'll want to sit down and read an actual book on how it works to get to handle on it because you won't have the mental map already to do so. Overall this is why the programming language market is so predisposed for new languages looking and feeling like old languages. People just aren't comfortable stepping too far outside of their comfort zone semantically (even if they'll happily do so for a few new language features and libraries).

disordinary 10y ago
Yeah one of the best things about Go is how familiar it is, you can pick it up and run with it very quickly. One of the best things about Rust is that it's a paradigm change, it takes time to get your mind around it but it is worth it if the language fits your use case.
weberc2 10y ago
> People just aren't comfortable stepping too far outside of their comfort zone semantically (even if they'll happily do so for a few new language features and libraries). I'm not sure that's fair. It seems more likely that people who choose "boring" languages do so because they have things to build, and want to pick a language with a good risk/reward value. Not out of some academic interest or comfort calculation.

verletx64 10y ago

I think that focusing on how long it takes to be productive is a mistake, within reason at least. How well does it hold up once I'm knowledgeable with the language matters a lot more. If it takes me 4 days or 3 weeks to be productive, ok, that's fine, but it needs to be a good solution once I'm there, because I'll spend years using it potentially.

strken 10y ago
The really, really important thing about the time it takes to be productive in a language is selling the language to other people. If it takes 3 weeks to learn enough Rust to make interesting projects, then it's going to be absolute hell convincing a team of largely ambivalent co-workers to use Rust, because 3 weeks is equivalent to months of weekend tinkering. You're restricted to using Rust either when it has mass adoption, it interests your devs, or the domain needs provable safety guarantees. On the other hand, if someone can pick up Go and produce a side project with two weekends worth of messing around, they're much more likely to be supportive of the language. Obviously this isn't ideal, but I don't know how you'd fix the problem.
- dorfsmay 10y ago
  Do you really want people on your team who think that having to read a free book and investing 3 weeks to learn a new language is too much of an effort?
  - strken 10y ago
    Firstly, when the initial impression of a language is that it's not fast to code in, people seem to assume that it will remain unproductive in regular use. This is clearly the case with ESR, and is a problem that's relevant to the Rust community in general. Secondly, as per the Rolling Stones, you can't always get what you want.
  - solidsnack9000 10y ago
    Sometimes you don't have a choice. You don't want those people but they are forced on you. It's strange the short term focus that is accepted in what are nominally professionals.

lmm 10y ago

If you've come from an ML background you'd need a good book to be productive in Go, and jump straight into Rust. Go is more C-like which makes it easier to pick up coming from C, not absolutely easier.