4 ms·

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 y

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.)
MaulingMonkey 10y ago
> you're kidding yourself if you think having generics makes up for having to write your own AWS client in terms of productivity. It doesn't appear you need to write your own AWS client - or at least, not from scratch: https://github.com/rusoto/rusoto https://github.com/rusoto/rusoto > 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. From the outsider perspective of one who knows neither Go nor Rust well - Rust seems to acknowledge it has problems and gaps they're working on. Poor IDE support is one close to my heart. Compile times are another. Heck, I'm just rehashing the roadmap, aren't I. With Go I hear more about how they've intentionally avoided things in the name of simplicity, and having some opinionated stance on having one correct way to do things. I get the impression that Go will never have generics, by design. C# already covers most of the things I'd use Go for pretty well - I don't see much advantage to switching to Go. Rust, even in it's relatively untooled state, already has me seriously considering trying my hand at nontrivial projects in it. I've been chasing static analysis and appropriate annotations to catch threading bugs, data races, iterator invalidation, potential null derefs, etc. in C++ for some time, to great effect - and who knows how much time saved - in bugs avoided. I'm convinced it's a question of when, not if, I'll try switching over properly.

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.)

MaulingMonkey 10y ago

> you're kidding yourself if you think having generics makes up for having to write your own AWS client in terms of productivity. It doesn't appear you need to write your own AWS client - or at least, not from scratch: https://github.com/rusoto/rusoto https://github.com/rusoto/rusoto > 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. From the outsider perspective of one who knows neither Go nor Rust well - Rust seems to acknowledge it has problems and gaps they're working on. Poor IDE support is one close to my heart. Compile times are another. Heck, I'm just rehashing the roadmap, aren't I. With Go I hear more about how they've intentionally avoided things in the name of simplicity, and having some opinionated stance on having one correct way to do things. I get the impression that Go will never have generics, by design. C# already covers most of the things I'd use Go for pretty well - I don't see much advantage to switching to Go. Rust, even in it's relatively untooled state, already has me seriously considering trying my hand at nontrivial projects in it. I've been chasing static analysis and appropriate annotations to catch threading bugs, data races, iterator invalidation, potential null derefs, etc. in C++ for some time, to great effect - and who knows how much time saved - in bugs avoided. I'm convinced it's a question of when, not if, I'll try switching over properly.