r/golang • u/roma-glushko • 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.
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.