Item — HN Reader

I have little doubt that Go is easier to get started with than Rust. However, I'm very skeptical that Go "scales" better on any other axis than onboarding new people quickly. Also not convinced the Go toolchain is better than Rust (other than in terms of compile time).

Especially for "big scope", I place a lot of value on leveraging Rust's more extensive type system and abstractions to model the "complex domains".

I would also bet that services written in Rust would be more robust than those initially written in Go. Initially standing it up is, in the end, such a small part of your long-term productivity, and Rust really shines in all the other parts.

Seems to me that Go is more compelling than Rust for enterprise software development because many businesses do a bad job of looking at their development costs over a longer time frame, thus valuing short learning curve over high reliability.

So really, it seems like the author does not have a profound familiarity with Rust. Which is fine, but not a great basis for confidently expressing semi-universal truths on your blog.

2 comments

I'm an open-source, solo dev. Not an enterprise dev. I use Go for most of my projects.

For me, the biggest hit to productivity are long compile times. One of my projects is ~80k loc C++ app (SumatraPDF) and I pretty much abandoned working on it because the long compilation times are killing me.

Go is good in that regard. My medium sized projects compile pretty much instantly.

I hear Rust is not doing well there.

The second productivity boost is GC (Garbage Collector). I don't want to manually track every allocation (C++) or think about how to contort the code to a form that Rust will be happy about.

Long term productivity is very much why I use Go.

In addition to GC and fast compile times, there's now a very rich ecosystem of libraries for almost everything you might need.

The language has been stable in past 10 years. I don't need to fix the code every major release because language changed (Swift) and I don't need to learn a large number of new things because of significant new addition (Rust).

And for what I use it (backend servers, cmd-line apps) Go is more than fast enough (which can't be said about out languages that have similar productivity, like Python, Ruby, Node).

If there's a C++ competitor I'll be willing to look at, it'll be JAI (when it's released).

> Also not convinced the Go toolchain is better than Rust (other than in terms of compile time).

Never claimed this. I compared the Go toolchain with other toolchains I happened to encounter in enterprise development.

> I place a lot of value on leveraging Rust's more extensive type system and abstractions to model the "complex domains". I would also bet that services written in Rust would be more robust than those initially written in Go.

In my experience it's not easy to get there in an environment like the one I described in my post, and any non-trivial abstraction carries a relative risk to later become a problem. The problem is that it doesn't matter how "sound" the abstraction is, the product owner will come in and change things in surprising ways. So at that point investing in sophisticated mechanisms becomes a form of premature optimization. That's the reason you can't afford microservices if the business doesn't have a well-defined structure.

>Seems to me that Go is more compelling than Rust for enterprise software development because many businesses do a bad job of looking at their development costs over a longer time frame, thus valuing short learning curve over high reliability.

For some business, "high reliability" does have less value than a shorter time-to-market, and in enterprise software development providing value to the business is the entirety of your job, not building cool tech. That's why reconciliation procedures exist even now that we have tons of tools to ensure transactional/eventual consistency.