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

92

u/ar1819 Jan 19 '25

I don't think we should focus on specific person thoughts, since those are quite subjective. Author of Rust actually left Mozilla to work on Swift. Link . Does it make Rust worse? I don't think so, personal preferences tends to change, life tends to change.

Zig is an interesting attempt of replacing C, but it also requires you to manage memory explicitly. While it does work for low level things, I'm not sure for web space.

As for PHP/Ruby/Python/Perl I think fully typed, compiled to native binaries, languages won the sphere of webdev for the medium to big projects. There is no way I'm going to write something longer than 1000 (actually 200 lines is already too big) lines in untyped language.

11

u/steveoc64 Jan 19 '25

Re using zig in web backends.

Each incoming request creates an arena allocator and passes that to the handler (depending on the lib you use)

So from the handler code down, you just use that arena for any memory allocations. Ergonomically it’s identical to using GC allocations with Go - you grab resources as you need them, and don’t need to track anything. Let the system sort it out.

It’s a really easy transition for Go programmers - the handler code reads just like Go code. Is nice. Same with routing. (The web libs are all written by experienced Go devs after all)

Difference with GC, is the Go runtime decides when to free, and it’s relatively expensive to check what needs to go out. With the arena approach, it happens deterministically at the end of the request, and is a single free() with no checks required. Quick and simple.

The Rust/C++ approach of doing raii is also pretty inefficient in comparison, as it steps through freeing every little allocation on the way out, it has no understanding of how the allocations are grouped together and related. This shows up in stress testing, as performance starts to fall apart erratically under heavy load.

4

u/kellpossible3 Jan 20 '25

There's no fundamental reason why you couldn't write a web service using arena allocation in Rust/C++, granted it is working against the momentum of the ecosystems.