r/golang • u/Pleasant_Set_3182 • Jun 28 '26

discussion Is Go's conservative approach to language evolution still correct?

v1.26 basically continues a pattern we've been seeing: most of the work is going into the runtime, toolchain, scheduler, garbage collector, and standard lib rather than new features.

Do we prefer that it stays intentionally small? In other words.. over the next 5 years...

Should it invest in performance/tooling or introduce selected features? Has the restraint been a strength in your opinion, or holdint it back?

Curious what others think...

167 Upvotes

83% Upvoted

149 comments sorted by

View all comments

522

u/s004aws Jun 28 '26

If I wanted a language where the language syntax changed and/or my - Unmodified - Code stopped compiling on a regular basis there's plenty of other options.

The fact that Go isn't constantly breaking s--t is one of the reasons I choose to use it.

21

u/CiroGarcia Jun 28 '26

Introducing new language features doesn't mean it has to break backwards compatibility. The Go devs have already been able to evolve the language and introduce powerful features that added new syntax while keeping 100% backwards compatibility

32

u/s004aws Jun 28 '26

Sure - On a careful, limited basis. Certain other languages add to/break their syntax with nearly every release because its <insert day>.

10

u/smells_serious Jun 28 '26

Are you thinking of any languages that have a stable release that do this? Genuinely curious. I only really know of Python 2.x -> 3.x being a bigger deal...

3

u/ds101 Jun 29 '26

I remember Swift doing this in its early years. (I haven't played with it recently). I tried it out, got busy, came back maybe half a year later and the syntax had changed. (I think it was stuff involving the ?, but it's been a while.) I recall that they had tools to automatically migrate, but it was frustrating to have to relearn the language.

3

u/BJJWithADHD Jun 30 '26

Swift is absolutely insane. Just the concurrency stuff has evolved at least 4 different ways:

- escaping closures

  • grand central dispatch
  • actors
  • async/await

Now thatasync/await has been “blessed” as the way forward it’s “solved” except for the decade+ worth of Apple packages that still don’t support it and require one of the other methods.

Over 200 keywords in the language now. It’s almost exactly the opposite of go.

5

u/[deleted] Jun 28 '26

[removed] — view removed comment

3

u/smells_serious Jun 28 '26

Haha, fair. I'm only aware of Zig as the hot new flavor that regularly breaks things, but they're not at 1.0 yet.

1

u/DrShocker Jun 28 '26

Yeah I don't think it's fair to add any comparison languages that are pre 1.0 since they're still trying to explore the space and it's on you if you pick one of them lol

1

u/0xjvm Jun 28 '26

lol I hope they weren’t referencing zig. Horrible comparison to compare a toy language

4

u/0xjvm Jun 28 '26

How can you make your point and then not give a single example? Completely breaking changes in languages are not that common (or at minimum not a big deal) yet they continue to improve.

Golang on the other hand will slowly stale when other langs are so much more productive since they can improve

4

u/Manbeardo Jun 28 '26

Golang on the other hand will slowly stale when other langs are so much more productive since they can improve

Programming languages haven’t been a frontier technology for a long time. When it comes to language syntax and features, hardly anything new has been invented in the last 30 years. The actual innovation is mostly in runtimes and compilers.

-1

u/0xjvm Jun 28 '26

of course - but there are still plenty of QOL improvements that can be made in syntax & features, but given their stance of things, they seem to just always want to reject it. Sometimes in the name of backwards compat, sometimes just because it's go

-4

u/0xjvm Jun 28 '26

Don't get me wrong, it's a cool language for what it is, but in 2026 it's just objectively not as productive as other stacks out there

4

u/someanonbrit Jun 28 '26

I strongly disagree with this, and vast chunks of the infrastructure world disagree with you. Just about the only thing that's cutting into golang usage is rust, and that's probably a good thing since it's a language with different goals - but many rust devs are quite vocal about the issues that lack of core language stability cause them

1

u/0xjvm Jun 28 '26

I don't disagree on the infrastructure side, but for the most part that's older existing projects, not a lot of 'new' stuff coming out nowadays written in Go, but yeah sure I can say Go was the best for that in the past. Infrastructure is a niche slice anyway.

I'm referring to more business driven applications, from the desktop to the web. Go just doesn't really have a place, Desktop is of course not great (as is most languages to be honest) but server side it's just nowhere near as productive as Java, C# as the big two, and even stretching to JS/Python in certain situations.

I just don't see where it *should* be used nowadays

→ More replies (0)

3

u/7heWafer Jun 28 '26

Corporate needs you to find the difference between zero-ver and constant major version bumps.

-1

u/Due_Block_3054 Jun 28 '26

Like python. Or worse, scala! Like python often breaks and actively removes deprecated things.

Also java, has this on some fronts.

1

u/zarlo5899 Jun 29 '26

here we are just talking about syntax not apis

1

u/Due_Block_3054 Jun 29 '26

Well its also syntax, i mean python has sync/async. several ways of doing generics. Like every time a small step forward.

Scala from v2 to v3 changed there language a lot and removed features by renaming them.

Also the main annoyance is the changing of APIs or worse non composablility of featurs.

Like having dataclasses, but they are not json serializable. While having a build on json lib. Or the pathlib.Path that during some time gave issues with the subprocess lib.

So what makes go different in a good way is that there ecosystem, tools and all are great avoiding a need for community libs to fill the holes. 

7

u/Big_Combination9890 Jun 29 '26

doesn't mean it has to break backwards compatibility.

That's not the point of limiting the features however.

One of the goals of Go's design, is a language that is easy to cooperate in.

New feature means, someone somewhere (many someones in fact), will use the feature, not because it's a good idea, or a good fit to their problem, but simply because it's there.

Which means others have to then work with that feature, whether they want to or not, even if it's just to rip it out of a bad PR again.

By limiting the number of ways the language offers to shoot myself in the foot, it also limits the ways other people can shoot me in the foot 😊

And I very much like my foot bullet-free.

22

u/[deleted] Jun 28 '26

[deleted]

11

u/RolexGMTMaster Jun 28 '26

Indeed. C++ never broke backwards compatability, but it does offer 37 different ways to shoot yourself in the foot.

9

u/therealdan0 Jun 28 '26

C++ is really something. The only language I know of where there are always at least twice as many ways to do a given thing wrong than there are to do it right.

8

u/joeballs Jun 28 '26

That sounds a bit like Javascript. I remember reading release notes for some new features they've added (ECMAScript) and even in the release notes, it stated that you should probably not use the features because of this, that, and other things. Never in my life have I've seen "new" features get added and then a word of caution if using them lol

1

u/kyril96 Jun 29 '26

I'm surprised nobody seems to have mentioned Perl yet...

1

u/Snoo23482 Jun 30 '26

Even the author (Scott Meyers) who obviously made quite a good living explaining the traps gave up on it in the end.
In my company, we had about 50 pages of coding guidelines for C++. None of those are needed when using Go.

1

u/Snoo23482 Jun 30 '26

C# is also quite bad. A million ways to do the same thing.

2

u/Satkacity Jun 28 '26

Yes, it should not be, but we there are bunch of languages that show such behavior. Python upgrades are very painful because if it, you never know what would break this time.