It has more to do with maturity and reliability.

Go has mature and fast standard libraries included in the language for web-related things like http, gateway/api, proxies and above all encryption.

For rust, you'll need quite a lot of crates with a lot of unknown variables to consider.

Why do large businesses choose Webpack when there's a lot of faster, more feature-full alternatives? Because it's reliable and maintained.

Because Go is more mature than Rust for web development.

I get Rust is the current trendy language and people on HN love to argue that $TRENDY should be used instead of $BORING but this is exactly the kind of domain which Go was built for and it actually does a pretty fine job of too.

Rust is not just trendy. It is inherently more powerful when it comes to express and check invariants. I had thought that after decades of buggy dynamic code, people have come around to value that. Comparing go and rust, I see two statically compiled languages with many different and interesting features. But one has a strong type system and the other has a trivial one. I'd choose the strong one for any new project that I expect to maintain for years to come.

> Rust is not just trendy. It is inherently more powerful when it comes to express and check invariants.

It's also massively complicated and the language is still in flux as it hasn't yet matured. Which is fine for hobby web dev projects but NOT what you want to base the long term future of any business on.

> I had thought that after decades of buggy dynamic code, people have come around to value that.

Get a grip. Dynamic code doesn't have to be any more buggy if you have the right developers and the right tool chains. Rust currently benefits from being a relatively niche language but once it's mainstream you can expect similar buggy code as less competent developers are forced into using it. Rust might have a fantastic compiler at catching specific bug types, but lets remember that it's not going to save you against any or all bugs. Claiming otherwise is, at best, massively ignorant.

But even assuming your biased opinion was fact, it's still not as if Rust is the only language out there that covers the non-dynamic market space. In fact Rust is one of the least mature languages in that area and particularly when it comes to web development. This isn't a subjective point either, try spending a few years building and supporting applications in other languages and compare that to Rust. I have done just that and while Rust will get there, it isn't there yet.

> Comparing go and rust, I see two statically compiled languages with many different and interesting features

Yes, one has been built with web development in mind and has been mature in that space for a decade. The other is Rust.

> But one has a strong type system and the other has a trivial one. I'd choose the strong one for any new project that I expect to maintain for years to come.

Well then you'd be choosing Rust for a stupid reason. If you're worried about maintaining something for years to come then you want API stability above all else. Rust cannot yet offer you that. C#, Java and Go are all better choices. Heck, even LISP, Haskell, etc would be better choices than current Rust.

Don't get me wrong, I have a lot of respect for Rust designers and the language itself. But some of the fanboyism demonstrated in your comments are ridiculous. Rust isn't ready for the kind of web development you're advocating for it. It also isn't going to magically save you from every known bug (and actually Go's compiler warning are pretty damn good too by the way). I'm sure one day Rust will be a solid option but not today.

Another thing to consider is that Go is much easier for beginners to contribute to, I've contributed to a couple of Go projects without having written a single program myself. Rust is a different story, and often larger projects tend to abstract things behind type level "magic", which for a beginner/drive-by contributor is a big ask to understand.

If your primary use case is setting up a web server then there is no reason to choose Rust over Go.

Why Rust over Go? Imagine I'm the CTO of an ownCloud-like company who is showing a strong preference for Go.

I'd also go with Go, just because of the amazing standard library. The ability to reuse part of Google's production code for HTTP / JSON is a huge win in my book.

Also, Go has been around for long enough that you'll find libraries and tutorials even for rare issues. When I evaluated Rust, I was missing that. Their ecosystem, while highly motivated, isn't mature enough yet for infrastructure level code.

You should choose rust for the long term. The type system will pay off any initial investment. Trust me, I am maintaining a large python code base. The number of problems that appear "organically" and would have been caught with a good type system is staggering.

I don't like Python personally but even I can see the problem here is you're doing Python wrong. Look up "type annotations" and include them as part of your tox testing.

Also, as I've commented elsewhere, if what you want is a static type system then there is still a plethora of better languages for web development than Rust. Rust might be a hugely impressive language but it's not yet ready for prime time web development.

Lets reverse that - why write in a language without a GC when you can write in a language with a GC? Rust's advantages shine when it's time to go low-level, but being without a GC is a disadvantage otherwise.

This application isn't merely 'performance-sensitive', it's a very particular form of performance - performance over network (I assume that's the main bottleneck here). Better write in a ecosystem all-but-officially optimized for networked applications rather than lose developer productivity dealing with low-level stuff.

Have you ever done web development with Rust?

I have. Rust is a great language and I really enjoy working with it, but it is far from mature as a web development language.

Go is the correct choice here if those are your only two options.

I would argue that go has a more strict policy for language proposal changes too.. This can be good or bad depending on situation.

I would like some more article in OP about the process of 'rewritting' it would be more interesting than all the buzzwork bizspeak.

All major components communicate via grpc so rust is not out of the picture. GC-less languages might make sense for storage-drivers.