[jeffrallen]

A goal of Go was to put working on complex distributed systems within the reach of the junior people Google had access to in the quantity they were hiring. To whit, the kind of people who would have been able to work on a big Python system with 3 months ramp up or on a big C++ system with a year of ramp up.

It is pretty clear that with respect to that goal, Go is a success. It has attracted Python programmers who need type safety and performance. Someone with no Go experience could land a useful new feature in a big Go program in 3 months.

Introducing a junior person to a large Rust system would still take a year, because it is so much more difficult than Go. Which means to me that if Rust had been aiming at this same adoption goal (it wasn't) it would not have succeeded where Go did.

[weinzierl]

> "Introducing a junior person to a large Rust system would still take a year, because it is so much more difficult than Go."

A recent study done at Google disagrees with this assessment.

""it takes about the same sized team about the same time to build it, so that's no loss of productivity",

said Google's Director of Engineering Lars Bergstrom about porting Go to Rust in the talk https://youtu.be/6mZRWFQRvmw?t=27012

[hu3]

His direct quote contradicts your assertion:

"When we have rewritten from Go into Rust, we found that it takes the same size of team and same time to build it."

Important part here being: rewrite. I would expect a rewrite to take less time, not the same time, than writing from scratch. Yet a Rust rewrite took as long as Go from-scratch project.

So to me, this implies the opposite, that Rust takes longer to write.

[tm-guimaraes]

Time to build a new system and time to onboard a new team member without professional experience in a given language are 2 very difficult things.

Go is much more optimised for quick onboarding, fast feedback, more “code look” consistency across projects then rust.

Now a team that knows both rust and go well might have the same proditivity in rust and go (maybe even more in rust), but with lots of changes in personell, specifically in quick growing departments, go can make a huge difference.

This is obviously just an anecdote, but i’ve seen more companies or departments running mostly a go backend stack, having job postings saying “no go experience required”, than the equivalent other companies (or departments ) focused on any other lang.

[zozbot234]

> Introducing a junior person to a large Rust system would still take a year, because it is so much more difficult than Go.

Do you really think large Golang codebases are so easy to survey? I could see the argument wrt. C++, but Rust actually has a great featureset for programming "in the large". Take a look at the k8s codebase for an example of a large project that's written in Golang - doesn't seem all that easy to get started with.