4 ms·

Honestly, the more you program in rust, the more you get used to its mannerisms. I don't at this point find that I'm less productive in it than in Go, and with

Honestly, the more you program in rust, the more you get used to its mannerisms. I don't at this point find that I'm less productive in it than in Go, and with gennerics I'm generally able to reuse code more often meaning that I usually write less code. Similarly in C I lose time on screwing up basic things that I have to debug in testing, whereas in Rust I don't have to even worry about that. I'm actually not buying the productivity argument, after you've learned the language. Claiming that it is less productive when you barely know it isn't fair, it's similar to saying that Italian (as an English speaker) is much more complex and hard to communicate in than English, when you've only studied the language for a month. It does have a steep learning curve, so it's either worth it to you to learn it, or not. But once you know it, I think your overall productivity is higher or the same as other languages, and on top of that you end up with fewer production issues!

burntsushi 10y ago
I'd say my experience matches this. I've written well over 50 KLOC of both Go and Rust in the last few years (I love both), and I don't personally experience a big productivity difference between them. There is one dimension where I feel like Rust makes me more productive though: when writing code that I want to go as fast as possible. I bet there are things that would be more productive in Go, maybe building web applications, but I haven't built any in Rust yet, so it's hard to compare. As a reference point, I feel much more productive in Rust/Go than I do in any unityped language. I suspect the same is true of C, but I've never been a heavy C practitioner. I'll stop here though, because this is all pretty subjective and wishy washy, and it will undoubtedly vary from person to person and be dependent on what kinds of problems you're solving most frequently.
shadowmint 10y ago
Claiming that it is less productive when you barely know it isn't fair... I'm really quite familiar with both go and rust, and I can say straight out that go is more productive than rust. ...but because rust is in any way a worse or less productive language (that remains to be seen), but because it has an immature ecosystem with few high quality crates and virtually no tooling. Go has a lot of very polished tooling (eg. gocode) that is supported in multiple editors, and a variety of high level packages for all kinds of things. Certainly I'm willing to acknowledge that if you're using vim without any plugins to write your code, or if you're evaluating the effectiveness of writing individual functions, it's a much more abstract kind of thing. ...but have you actually bench marked yourself coding a real world project, from scratch, in both, from idea to delivery? I have, and for me rust was an order of magnitude less productive than go. At least. Once the tooling for rust gets up and going we'll be a much better position, but... You're effectively saying that there is zero productivity boost in the extensive go tooling ecosystem (which rust currently doesn't have); that's pretty hard sell...
- steveklabnik 10y ago
  > You're effectively saying that there is zero productivity boost in the extensive go tooling ecosystem (which rust currently doesn't have); that's pretty hard sell... You could say something like "you're effectively saying that there is zero productivity drain from not having features like generics (which Rust currently does have); that's a pretty hard sell... Tooling matters a lot, and that's why we're investing in it. But "tooling" is not a synonym for "productivity." There's a lot of factors.
  - shadowmint 10y ago
    You'd have a much easier time arguing that go not having a package manager makes you less productive compared to cargo (very true); you're kidding yourself if you think having generics makes up for having to write your own AWS client in terms of productivity. Can you build something more quickly in go right now, than in rust? For many applications, the answer is, right now: Yes. Building (using the tooling that does exist, and the libraries that do exist) make completing a project successfully easier and quicker than in rust. Does that make go 'more productive' than rust? Or is 'productivity' just how effective you are at expressing logic as code? Well, I guess it depends what word games you want to play. My personal experience has been that using rust is great, fun (if verbose) and you can spend 5 or 6 hours writing a nice crate that doesn't do anything meaningful; and when you do have to do something meaningful, its a tonne of work to get it to compile (ugh, c libraries...) and you end up having to write or modify/fix the packages to do many of the things yourself. That is not productive. Perhaps you see a different side to it from where you sit, but I do think #rust suffers from a certain degree of confirmation bias. I think 'productivity' depends on your problem domain. For building actual applications rust simply isnt even in the same space as java, c++, c# or go at this point in terms of 'productivity'.
    - steveklabnik 10y ago
      I'm arguing _against_ any one feature; I picked generics because it's the classic criticism of Go. I do think that package management might be a bigger factor, but my point is that there are multiple factors. You can't say "well Rust doesn't have tooling, so it's not productive." I think we're mostly in agreement here, other than that I think your first post put too much weight on one specific part of a complex equation, and that you feel there's a clear-cut answer, and I don't. (I do agree that "there's a package for this" vs "there isn't" is a huge factor of productivity. It's actually the one I personally cite most often when talking about my own productivity in Rust.)

burntsushi 10y ago

I'd say my experience matches this. I've written well over 50 KLOC of both Go and Rust in the last few years (I love both), and I don't personally experience a big productivity difference between them. There is one dimension where I feel like Rust makes me more productive though: when writing code that I want to go as fast as possible. I bet there are things that would be more productive in Go, maybe building web applications, but I haven't built any in Rust yet, so it's hard to compare. As a reference point, I feel much more productive in Rust/Go than I do in any unityped language. I suspect the same is true of C, but I've never been a heavy C practitioner. I'll stop here though, because this is all pretty subjective and wishy washy, and it will undoubtedly vary from person to person and be dependent on what kinds of problems you're solving most frequently.

shadowmint 10y ago

Claiming that it is less productive when you barely know it isn't fair... I'm really quite familiar with both go and rust, and I can say straight out that go is more productive than rust. ...but because rust is in any way a worse or less productive language (that remains to be seen), but because it has an immature ecosystem with few high quality crates and virtually no tooling. Go has a lot of very polished tooling (eg. gocode) that is supported in multiple editors, and a variety of high level packages for all kinds of things. Certainly I'm willing to acknowledge that if you're using vim without any plugins to write your code, or if you're evaluating the effectiveness of writing individual functions, it's a much more abstract kind of thing. ...but have you actually bench marked yourself coding a real world project, from scratch, in both, from idea to delivery? I have, and for me rust was an order of magnitude less productive than go. At least. Once the tooling for rust gets up and going we'll be a much better position, but... You're effectively saying that there is zero productivity boost in the extensive go tooling ecosystem (which rust currently doesn't have); that's pretty hard sell...

steveklabnik 10y ago
> You're effectively saying that there is zero productivity boost in the extensive go tooling ecosystem (which rust currently doesn't have); that's pretty hard sell... You could say something like "you're effectively saying that there is zero productivity drain from not having features like generics (which Rust currently does have); that's a pretty hard sell... Tooling matters a lot, and that's why we're investing in it. But "tooling" is not a synonym for "productivity." There's a lot of factors.
- shadowmint 10y ago
  You'd have a much easier time arguing that go not having a package manager makes you less productive compared to cargo (very true); you're kidding yourself if you think having generics makes up for having to write your own AWS client in terms of productivity. Can you build something more quickly in go right now, than in rust? For many applications, the answer is, right now: Yes. Building (using the tooling that does exist, and the libraries that do exist) make completing a project successfully easier and quicker than in rust. Does that make go 'more productive' than rust? Or is 'productivity' just how effective you are at expressing logic as code? Well, I guess it depends what word games you want to play. My personal experience has been that using rust is great, fun (if verbose) and you can spend 5 or 6 hours writing a nice crate that doesn't do anything meaningful; and when you do have to do something meaningful, its a tonne of work to get it to compile (ugh, c libraries...) and you end up having to write or modify/fix the packages to do many of the things yourself. That is not productive. Perhaps you see a different side to it from where you sit, but I do think #rust suffers from a certain degree of confirmation bias. I think 'productivity' depends on your problem domain. For building actual applications rust simply isnt even in the same space as java, c++, c# or go at this point in terms of 'productivity'.
  - steveklabnik 10y ago
    I'm arguing _against_ any one feature; I picked generics because it's the classic criticism of Go. I do think that package management might be a bigger factor, but my point is that there are multiple factors. You can't say "well Rust doesn't have tooling, so it's not productive." I think we're mostly in agreement here, other than that I think your first post put too much weight on one specific part of a complex equation, and that you feel there's a clear-cut answer, and I don't. (I do agree that "there's a package for this" vs "there isn't" is a huge factor of productivity. It's actually the one I personally cite most often when talking about my own productivity in Rust.)