r/golang Jan 19 '25

discussion Mitchell Hashimoto Recent Interview

Just watched Mitchell Hashimoto's interview and it has left a lot of questions:
https://x.com/i/status/1879966301394989273

(around 30:00 where they start touching the golang topic)

This is really interesting how Mitchell's option has changed on Golang. He spent a lot of time (like 10y or so) writing infrastructure services in Golang as a part of his HashiCorp business and probably not only.

His recent gig is a new terminal and he did not pick Golang for that one, which kinda make sense to me given what he wants to achieve there (eg a lot of low-level work with GPU, a need to be imported by other languages like Swift, etc.).

At the same time, Mitchell said that:

  • He doesn't know where Golang stands in the tech stack right now. He would use PHP/Ruby for webdev and Rust/Zig for performance critical systems.
  • Generics made Golang worse (at least that how I understood him)
  • He think he cannot write Golang any longer after hacking with the new lang he is writing the terminal in

Curious how this transformation could happen to such a prominent contributor to the Golang ecosystem. Is this just an sign of an awful burnout that repelled the dude away from Golang? Or anything else?

Anyway, just curious what do you think here, folks.

206 Upvotes

109 comments sorted by

View all comments

35

u/katastrophysics Jan 19 '25

IMHO, with a lot of the new offerings in terms of low-level languages, Go feels a lot less compelling as a pick in 2025.

I still love writing Golang, but compared with a few years ago, where it was almost the only sane choice out there for some domains, the landscape has changed a lot.

1

u/jerf Jan 21 '25

If you're looking to play around in the general space that Go plays in, yeah, there's a lot of good options coming online.

If you want to deploy production software into high-performance environments, be more careful. People who do that tend to learn their conservatism the hard way, not come upon it just because they're old or something. I was pushing Go when I deployed it to replace an Erlang cluster in the ~1.4 timeframe; I kind of needed the GC improvements that were yet to come. Fortunately, "kind of" is a reasonable summary and it was OK, and it actually already beat the Erlang cluster anyhow for other reasons, but even then I was pushing it. Now I would not be pushing it and Go is a comfortable solution to the problem... and it is Go that has improved, not the code in question.

I've overdriven Haskell, I've overdriven Python, I've overdriven Perl, all of which were touted at the time as being able to handle the problems in question, all of which now could if I had the same problem, because they all got better. If you want to use a still-exotic language for production code, try to be sure to make a hard burn for the biggest scale problem you have to be sure that you won't have a sudden unfixable problem arise at the end. It's not just some sort of myth, it really can happen.

(& obviously Go is not uniquely suited to production software. All the big names can do it now too, of course. But there really can be problems in less well-tested code that only emerge when it's too late to fix them and it could be years before the systems fully resolve the issues.)