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!

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.

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

> Go has a lot of very polished tooling (eg. gocode) that is supported in multiple editors

Have you tried racer? It seems quite similar, and apparently it does more (see [1]).

I mean, I agree in the abstract that yes, having tooling and a bigger library ecosystem matters a lot. But the things you've cited so far (code completion and an AWS library) are things that Rust does have. I'd be more interested in hearing specific problems with those.

[1]: https://github.com/nsf/gocode/issues/307#issuecomment-155080...

     It seems quite similar, and *apparently it does more*

Have you tried the go-plus (https://atom.io/packages/go-plus) tooling?

Really, please try it out. That's the kind of experience that's really missing from rust; autocomplete, fmt, test watcher, linter, code coverage, debugger, doc summary; you hit install and it works.

Racer isn't there yet.

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

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

> 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

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

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

No sure why you were down-voted, but it probably has something to do with connotation. I agree though -- library maturity, tooling maturity are also very important factors when it comes to productivity. A steep learning curve, however, probably has less to do with productivity and more to do with adoption, which I think is what the parent was trying to get across.

But, of course, adoption rate can indirectly impact library and tooling maturity. :)