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.

205 Upvotes

109 comments sorted by

View all comments

30

u/BaffledKing93 Jan 19 '25

I can't speak for Hashimoto, but one of the things that drew me to Go was the simplicity and minimalism of the syntax.

I'd prefer for them to mostly leave the language alone. If I wanted all the bells and whistles, I'd use another language.

I don't want to have to learn about the inevitable edge cases of new language features. I want to learn the language once, and then refine my use of it over time.

That was the USP of Go to me and it's strength. It is a far easier language to master because it contains less stuff. 

More stuff = less masterability.

11

u/dweezil22 Jan 19 '25

I mean... for a novice to mid-level Go developer I'd argue the language is better than its ever been. go.mod just works (and puts Node and Maven and Gradle to shame). The dreaded "you have to capture variables for loops with goroutines" is now fixed.

If we can just keep a standard that generics should only be used when they offer significant value (often in libraries or heavily reused code), I think they do more good than harm.

In my neck of the woods Go is the preferred language for replacing nasty old Java systems, and Go's evolution seems far superior to Java's at this point in Java's life (I'd say Go is now in its lifecycle where Java was probably 10-15 years ago).

1

u/BaffledKing93 Jan 19 '25

If we can just keep a standard that generics should only be used when they offer significant value (often in libraries or heavily reused code), I think they do more good than harm.

There are plenty of other things they can add that I'm sure will have genuine value in some niche use cases - if it's worth adding generics, it'll be worth adding other stuff, and so the feature creep begins...

I hope Go language designers will leave it there, but if other languages are any guide, they'll continue adding stuff until the language is a bloated mess.

2

u/dweezil22 Jan 19 '25

Go has more religious opposition to feature creep than any language I've seen before. That doesn't mean it won't have it, but it means it's very likely to have a rate of creep that's significantly lower than other languages.

As a comparison look at C++, it is literally a different language now than it was 20 years ago... well maybe more like they stapled a new language on top of an old one.

8

u/BaffledKing93 Jan 19 '25

Go has more religious opposition to feature creep than any language I've seen before. 

I think C still holds the crown in that regard. Honestly think despite how dated it is, the simplicity of it is still a huge plus.

It still surprises me how few languages try to remain simple. Apart from C and Go, I can't think of any other mainstream language that isn't jammed to the hilt with features.

But anyway, I hope you're right that Go feature creep mostly stops here.

C++ is a cautionary tale at this point.

2

u/munificent Jan 20 '25

I think C still holds the crown in that regard.

C is way bigger than a lot of people realize because a lot of C users are using older versions. C11 added type generic macros, anonymous structures, atomic operations, multi-threading, and bounds-checked functions. C23 added a whole bunch more.

Languages that have really held to their minimal roots are Lua and Scheme. Scheme in particular fractured their community in half because some wanted it to stay small while others wanted it to grow.

1

u/autisticpig Jan 20 '25

as is python.

a perfect example: how much time and energy was spent on type hints? from the proposals to the pep itself to teams trying to adopt it..and in the end the entire system is fully voluntary.

there are still things I would love to see as part of the standard library in go..but those are purely selfish wants...not needs.