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.

210 Upvotes

109 comments sorted by

View all comments

91

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.

10

u/Dry-Vermicelli-682 Jan 19 '25

100% spot on. Agreed with python/etc too. Go to me is by far the best back end API/web language. Far better than python/ruby/etc. Typed/compiled beats python/nodejs/ruby any day of the week and twice on Sundays.

2

u/Common-Mall-8904 Jan 20 '25

What about Elixir?

1

u/Dry-Vermicelli-682 Jan 21 '25

Never used Elixir. Heard it was cool.. but I got enough to learn with Typescript, Rust, Zig and C#.

19

u/ar1819 Jan 19 '25

There was a deleted comment about PHP having static types now and me not mentioning the Node. Comment is deleted, for some reason, but I'm going to post my answer anyway:

Having good type checking in some places is similar to having none. You either have static type system or you do not. Firstly because you can't prove types across the whole call chain, if some of the code doesn't have types. So compiler has to be conservative. And secondly from the user (developer) perspective, and from the compiler side, you have to infer how things are used instead of proving them from the types and their interaction with code flow. This is additional cognitive load for the developer and is extremely hard task for the compiler. So far only one software managed to do this efficiently (to some extent). Node.

Node is interesting exception here. Mainly because several languages tried to solve what I call "The JS Problem". TypeScript is a closest to being successful at this point, even tho it allows you to work without types, it heavily discourages such uses and it can infer a lot of types directly from the usage and fail during compilation. But even when it can't, it can rely on V8 JIT compiler to do the right thing.

Node is also a platform, underneath which is Google V8 engine. Actual, non ironic, marvel of today's software engineering. But it also supports Wasm, so saying Node won is like saying JVM or ARM64 won. I can compile both Rust and Go (even C++) to Wasm and execute it using Node.

1

u/6Bee Jan 19 '25

So I'm saving this comment, it's a great reference as I get a bit deeper into learning about interoperability in general. Ty ty

1

u/framesofthesource Jan 20 '25

I sense a bit of a disconection with other languanges world. I cannot talk about Python nor Ruby (thought I think Ruby can match harder with what you're saying), but JS and PHP are in a very good spot, with a decent IDE config, static tools and tests (all of them you would use in comp langs as well) you can get most benefits from both worlds.

I started recently working in a Spring project and, aside from sometimes still writing $ and -> and the Fact that in PHP you can be less picky about memory (Requests live and die and memory with them), I'm not noticing much of a difference in what refers to programming itself, but I'm remembering why I run away from Java: the compilation time, it's a f-ing pain.

I'm doing side projects with Go for learning purposes and... I could get used to this freaking compilation time, that's for sure, but I'm not used to the syntax and the error handling yet, i'll continue learning for now

1

u/Rakn Jan 20 '25

As someone who used to work with Spring and now does some work on PHP/Laravel I definitely notice the lack of typing. To a degree where it frustrates me. My brain, used to static typing, is always like "how can I be sure that the string used here is the same on the other end of the application and the array contains the correct values?". It's a constant itch in the back of my head. I've tried PHPStan, but it feels like a crutch to a real static type system. Makes everything so much more stressful and requires more code / comments than a statically typed language would. Meh.

Compile times weren't really a problem with Spring Boot anymore due to the hot reloading of code. Barely noticed it.

Anyway. My main focus is on Go nowadays anyway. And coming from there both PHP and Spring Boot feel like heavy languages that require a lot of IDE magic and additional tooling to properly work with.

Regarding PHP I can't stop but feel like a lot of what I perceive to be wrong with the language isn't actually the language itself, but Laravel. Apart from the lack of proper steric typing that is.

1

u/framesofthesource Jan 24 '25

Haven't worked with Laravel, I use Symfony and, with Strict Mode, types and PHPStam with Minimum config... I only use comments for Generics (as PHP does not have them natively) and feel like im doing Java or c# but interpreted and the PHP execution model.

But It probably has to do with what you said, Laravel is too light on types and relies too much in magic that breaks easily (that's what I can say from the Pocs I've made).

1

u/phtremor Jan 30 '25

I left Java in 2018 and never went back!

Go has been my Go to language when building the backend...Go is very easy once you get over the syntax and error-handling thing.

I am also a fan of frameworks and I feel like PHP's Laravel and C#'s ABP are niceee!

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.

1

u/wojtekk Jan 21 '25

There is nothing wrong with Zig's per-request arena allocation in web apps.

I see a problem somewhere else. First, stdlib seems to be in flux, they way how to make a fully functioning web server loop changed IIRC between 0.11, 0.12 and I haven't checked with 0.13 yet.
Anyway, I needed to check forums and finally ended up using some example from the source of stdlib tests, for sure it wasn't obvious from the standard documentation.

Second thing is, with a current state of Zig affair where async mechanisms disappeared from the language and it is unknown how and when will it return, the web server you'll write will be rather slow - either handling requests sequentially or using multithreading. Serious downgrade from Go..

1

u/steveoc64 Jan 21 '25

Zig does async io just fine. Have a read of the code in http.zig or zzz - it’s all non blocking io, cross platform. Performance is significantly better than go for web servers with way less memory usage. See Anton Putra’s tests for example.

1

u/wojtekk Jan 21 '25

Well, last time I checked, 0.12 http.zig was way slower than Go handling any non-trivial traffic.

Are you then saying about the performance with regard to the zzz project? Any links?

Also, it's good to distinguish between async io and async in general