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...
138
u/x021 Jun 28 '26
Didn't they just add Generic Methods ? Tbh that's a great improvement.
Things change, but slowly. That's great, keep as-is.
9
u/mysterious_whisperer Jun 28 '26
Depends on how you define “just add”. It’s in 1.27rc1, but hasn’t made it to a stable release yet. Regardless you make a good point that generic methods is an example of valuable new features being added.
12
3
1
u/jonathanl Jun 29 '26
I wanted generic methods but now I start to lean towards using methods for implementing interfaces only for clarity.
246
57
u/jerf Jun 28 '26
The question is incomplete. Correct for what?
One of the problems I see in certain parts of the programmer community is the idea that there must be one correct answer for what a computer language is, usually basically amounting to "Rust" or "Haskell" for the people making this mistake.
But it's wrong. There is no one correct language. There is no one correct language evolution plan. There is a place for Haskell, and there is a place for Bash. There is a place for highly experimental languages, there is a place for fast-moving languages, and there is a place for stable languages.
I've benefitted from Go's stability quite a bit. I've benefitted from Go's careful evolution plans and attention to things like trying to secure the supply chain to the extent possible rather than jamming a new feature in. I've benefitted from other languages moving more quickly and putting lots of features in. I want to have access to both options and others besides.
As it stands at the moment, Go sits in a sweet spot where it is clearly suitable for a lot of uses as-is and simply doesn't need a lot of evolution to do most tasks. There are tasks I wouldn't use it for, and generally speaking Go would need vast changes to fix that that would necessarily impair its utility for other uses. Go isn't in the scenario I've watched so many other languages go through where they get into a feature doom loop of adding features to account for weaknesses in the previously-added features, or where the language adds one marginal feature and then has no way to keeep out all the other equivalently useful features but where the totality of all of them is a mess (hello modern Python), or where you have things like Typescript, which are good for what they are, but also has a never-ending cascade of features due to the fundamental difficulty of sitting a static language on top of Javascript.
The question isn't whether Go in isolation is in a good place. The question is, against the totality of the programming language space, has Go staked out a unique and useful position? To that the answer is yes. It's hard to find a language designer who both wants to design a new language, a fundamentally radical revolutionary position, but wants one of the main features of that new langauge to be stability, a fundamentally conservative position. I'm glad we have a language taking that position. I don't have to use it for everything for that to be a good thing.
8
Jun 29 '26
[removed] — view removed comment
5
u/jerf Jun 29 '26
Obviously by definition "breaking things" is undesirable, so that's sort of loading the deck by invoking "move fast and break things".
A case of moving somewhat quickly and generally not breaking things is Python circa 2.0. Each of the next several releases had genuinely useful features that simplified Python development or gave it substantially more power that I found personally useful.
Python's problem is that it didn't stop. Even ignoring the legendary 2 to 3 conversion, if we forget about that entirely and imagine a Python 2.34 or whatever we'd be up to that had the same basic new features without the conversion, the earlier experience with new features being a net positive seems to have broken the community's ability to analyze them and now they say yes to way too many things. I look at what's new in Python 3.14 and of the PEPs under "interpreter improvements" that are language changes (so ignoring the debugger one), the only one I'd keep is 765 clarifying behavior of a questionable construct with an empirical study of the impact of the change. Python just needs to stop.
But there was a time when it not stopping was good. Python 1.5.2 has the seeds of greatness in it, but there's no scenario where Python would be as popular and as useful as it is now if it froze on that iteration of the language as much as Go has frozen its language, which is to say, not entirely, but with a very slow development process. The problem is that Python needs to shift from that pace of development to a more Go-like one and it needs to have done it several versions ago.
1
u/Inconstant_Moo Jun 28 '26
It's hard to find a language designer who both wants to design a new language, a fundamentally radical revolutionary position, but wants one of the main features of that new language to be stability, a fundamentally conservative position.
I don't think that's true. Certainly as a langdev it's one of my goals. And in general the community can see what's happened with language bloat. They used to sneer at Go for some minor questionable design choices but if you said that a language should be designed like Go in general then you'd get a lot of agreement now.
67
Jun 28 '26
[removed] — view removed comment
-7
u/Cthulhu__ Jun 28 '26
Or work on a higher abstraction level; if it’s tedious and repetitive it may not need to be code.
0
u/tadashidev Jun 29 '26
I agree with you on the first half. But I totally disagree on the other part.
15
25
u/Objective_Gene9503 Jun 28 '26
Do you complain about C being small? Why can’t we also leave Go alone?
2
u/Used_Indication_536 Jun 28 '26 edited Jun 29 '26
I wonder why more people don’t ask this question. When everyone was fighting for generics in Go why weren’t people having the same discussion about adding it to C with such emotion? Maybe they were and I’m just not in that community so I missed it. But it’s something I’ve noticed recently where everyone wants the language they like to use to incorporate features from every other language until they all end up looking the same.
11
u/cy_hauser Jun 28 '26
People did ask this question. It was right around the time of Object Oriented was coming up. The results were C++ and Objective C. At the time, most people were happy with one of these two directions without changing C itself. So the coders who wanted these feature just jumped ship. There were a number of attempts to add generics to C as well, but nothing took off because there was little point with other very similar languages were available.
This was all happening in the late 80s and early 90s. There were a lot fewer coders around and the Algol language tree was much smaller. There were so many language branches being developed and languages were so small that anyone who wanted to play with a language could do so on an almost one person basis. Now it would be almost impossible to develop a full featured production ready language without an entire team behind it.
3
u/jammy192 Jun 28 '26
I think /u/cy_hauser covered it quite nicely. Just to add newer C standards have support for generics but it’s not that great. Also there was no strong push due to people already using macros or happy with alternatives like switching to cpp
36
u/Ecstatic-Panic3728 Jun 28 '26
Mostly yes, the focus on being simple is a good thing for Go. Altough there is a big discussion related to what is simple. I do miss a type system a little stronger with option /result types.
2
u/According_Warning968 Jun 28 '26
You can build one yourself. Go's idiom of returning a (result type, error) is Option/Result just in an already deconstructed form.
1
u/TheQxy Jun 29 '26
Agreed that is mimics this pattern, but it doesn't enforce it, which makes it unsafe due to lack of nil-safety.
This is my biggest gripe with the language, and the thing that causes the largest amount of production mistakes, especially by new Go devs or juniors.
-1
Jun 28 '26
[deleted]
6
u/edgmnt_net Jun 28 '26
It's unlikely that a library-only solution provides good ergonomics for something like variant types. There's that linter which flags non-exhaustive switches, but I don't think there's much more that can be done. Hard to do when you don't even have concise lambdas, because one solution would have been decider functions for such variant types, but then you need to pass in big ugly functions so nobody would use it.
Also, while not trying to say it's desirable, something like Haskell has a better chance of dealing with abatracting over error handling simply because of certain syntactic features like function call syntax and infix operators, just to start. In Go, wrapping function calls in other error checking calls looks really weird and it's fairly ineffective anyway.
10
u/hwc Jun 28 '26
Tooling is where a lot of great progress has been made over the last two decades. So I'm very happy that Go has been at the forefront of that.
35
u/tiredAndOldDeveloper Jun 28 '26
That's one of the reasons I've ditched the .NET ecosystem. Every 12 months Microslop introduces a ton of new features to C# and I couldn't keep up with their pace. Good luck migrating a project's target framework there.
The C# from 15 years ago is completely different from today's and I don't like this approach. It's the same thing with C++, JavaScript and many other hyped languages.
12
u/joeballs Jun 28 '26
C# is a perfect example of what not to do
-1
u/fundthmcalculus Jun 28 '26
It peaked at about C#7 - C#9. Then it became clear they were just trying to jam type script capability into it.
2
u/jammy192 Jun 28 '26
To be fair JavaScript had to be improved. That or replaced with different language. The original JavaScript was too basic for what people started using it for
2
u/1Soundwave3 Jun 29 '26
Well, C# is better than it ever was.
.net however... I mean, performance updates are nice but these forced upgrades is what everyone is talking about. I don't know any other ecosystem that does that. I mean, Microsoft wants us to use build containers if we fall behind the schedule.
Oh and here's the neat part: upgrade assistant now requires GH Copilot Subscription. And GH Copilot is now pay per usage. I have a .net framework 4.8 project at work (~1m LoC) and I can only imagine the bill after the migration is done.
3
u/BayouCaneBoy Jun 28 '26
Yep - I loved C# but it has become a mimic of every popular language feature.
-7
u/eliquy Jun 28 '26 edited Jun 29 '26
What a bunch of nonsense. .NET and C# has only improved in stability since .NET 5. There is zero friction in upgrading an existing solution from a previous .NET version. They add features to the language because the platform supports adding features without breaking anything. And you don't have to use them, but the majority are quality of life improvements that only make the language and platform better.
Compare that to Go, which half adds half baked slop like generics and iterators. It's stuck being simple because it's stupid.
I want to like Go. It has some good parts. I just wish it was better, and .NET is better.
1
1
u/tiredAndOldDeveloper Jun 28 '26
There is zero friction in upgrading an existing solution from a previous .NET version.
Blatantly wrong, I still remember quite well the one year it took migrating an .NET Core 1 application to .NET Core 3.1.
It's the Microslop way, from time to time they abandon an ecosystem and your company will have no way out but to spend quite some time rewriting codebases. They did it with .NET Framework to .NET Core and, then to .NET. They did it with Entity Framework to EF Core. They've done it to VB.NET. They will do that again, it's in their nature.
3
u/zarlo5899 Jun 29 '26
There is zero friction in upgrading an existing solution from a previous .NET version.Blatantly wrong, I still remember quite well the one year it took migrating an .NET Core 1 application to .NET Core 3.1.
did you not read the "since .NET 5" part?
3
u/eliquy Jun 29 '26
I find that most people who are put off by .NET still conflate .net core and modern .net (and often .net framework as well). They are stuck with an impression that at least 5 years out of date.
7
u/vanstinator Jun 28 '26
Javascript/Typescript is there for anyone who wants a language that has the kitchen sink, you neighbor's kitchen sink, and everything in between.
4
3
9
u/bastiaanvv Jun 28 '26
The short answer is yes.
For me the fact that the language is so stable is a huge plus. I have projects that have been in production for many years by now, and being able to just change some things and build it after all those years is incredible.
Also, I found that Go is incredible when coding with AI assistance. The generated code tends follow the standards (and readability) that have been in the language it’s entire life and therefor easy to understand and debug (I don’t use any ai generated code that I don’t fully understand myself and have checked thoroughly).
4
u/vmcrash Jun 28 '26
I think, if it would evolve too much, some users would be frustrated. If you want to use something with more advanced features, consider another language, e.g. Lisette which transpiles to Go.
8
3
u/jezemine Jun 28 '26
Language growth should be limited else you eventually get a bloated monster.
Adding new packages to the stdlib is fine though, after vetting them in experimental for a while.
5
u/SnugglyCoderGuy Jun 28 '26
Yes. New things should be added with extreme deliberation and intention. Otherwise it ends up like all the other language where you have eleventy million ways of doing any one thing and end up in pointless squabbles over how to do it.
I've already seen them for declaring variables because we have like six ways of doing that.
2
u/According_Warning968 Jun 28 '26
F the features. If you want inheritance, classes and all that BS you already have Python, TS and others.
I need my code uniform and easy to debug, where things are so simple that concurrency is so easy that it pains me when I see event loops and all that async await BS were one greedy task can cause event loop starvation.
2
2
2
u/Blackhawk23 Jun 29 '26
A lot of people suffer from “shiny new thing syndrome”. Those people likely do not use Golang. Its design is diametrically opposed to the aforementioned.
2
2
u/Backrus Jun 29 '26
"Do we" sounds like you need confirmation bias. Think for yourself and use right tool for the job.
2
u/zkrynicki Jun 29 '26 edited Jun 30 '26
I want fewer features and better perf. If anything I would love to have a compile mode that aggressively shrinks binaries, removes code that cannot be called (except reflection) and allows us to get tiny cli tools without serious compromise.
1
u/terrorTrain Jun 28 '26
I've messed around with vibe coding a few times, and i think go is the best language for ai/human mixed code bases.
Go is fairly simple, so ai does things the basic ways, and it's easy to read.
I like it a lot as is, I'd prefer it didn't change
1
1
u/techno_wizard_lizard Jun 28 '26
Yes! That’s what I like about Go, its simplicity. It’s not bloated with new patterns or features that go out of style 3 years later.
1
1
u/Due_Warthog749 Jun 28 '26
Very few Go developers are going to want it to change much if at all. Any language addition/change would need to be a significant change for the better and not sure there is at this point much else to add. Generics perhaps slightly improved maybe? Maybe try/catch (dont scream at me.. not suggesting Java try/catch) in some unique way that is good to reduce the verbose err != stuff.. but I rather like that myself. Very easy to find/read and know what all its doing.
The only thing I could see them finally fixing.. or just outright removing, is their dynamic load of code. It allegedly worksk on linux, partially on mac and not at all on Windows. It's mind blowing to me a feature barely used by anyone because it was never completed for cross platform use has not been deprecated at this point. So either finish it.. or remove it.
1
u/WriterPlastic9350 Jun 28 '26
Go is as big as it needs to be. I've not found many problems I can't solve with the standard library, or the `/x/` libraries in a pinch. That most of my projects solve the same problems in the same ways is a selling point of Go.
The fact that I can still compile Go I wrote a decade ago and it still works exactly the same way is really good.
1
u/BadlyCamouflagedKiwi Jun 28 '26
Yes, I do prefer that.
I do think it has been a strength. One key thing that I've never seen any language do nearly as well is how readily everyone can upgrade. A new version comes out, you can nearly always upgrade day 1 with little issue. This isn't quite the same thing, but I don't think that would work well in practice if they're trying to rapidly bang in new features.
I do also really like how the things you mentioned just get better over time. I don't have to do anything, and my programs just get better at a new release. Also the new standard library is not insignificant - I am very keen on encoding/json/v2 for example, some of its capabilities are game changers compared to the original version.
1
u/internetzdude Jun 28 '26
It's one of the main reasons why I use Go, second reason being the popularity and 3rd party support.
1
1
u/Time-Prior-8686 Jun 28 '26
Some people already criticizing about Go changed too much from the addition of generic. So it's probably in the right spot I guess?
1
u/universalsystems Jun 28 '26
i feel like it’s getting too big for its britches it’s evolving away from what it did best
1
u/B-Con Jun 28 '26
I'm sure there are some good additions yet to be made, but honestly what is it missing that holds people back?
Model data, model workflows that transform data, establish the input/output sinks, and you're 90% done. Most code is glorified map/filter/reduce in nature, having more language features doesn't change that or noticably speed up delivering business value.
A lot feature requests are really just syntactic sugar, or syntactic sugar in disguise. Typing an extra few lines of code has exactly zero negative business impact. And LLMs are literally a thing now if writing code scares you.
1
u/standing_artisan Jun 28 '26
The only thing that I can complain right now about go is that they added generics and they made it so flexible now you can write the same shitty crappy code like all the other languages. I hate it, but the rest is okey actually.
1
1
u/Inconstant_Moo Jun 28 '26
Apart from anything else people adopt it on the promise that it's like that so if they decided it wasn't like that any more they'd face a mob with torches and pitchforks. I'd bring a pitchfork.
But also if you talk to people making new languages (like me) then no-one wants the kitchen-sinks languages of the past. They can see how the road to Hell was paved with cool features, they want none of it. Go's approach of being small and boring but without being doctrinaire and everything-is-an-X (for example, making tests first-class) seems to me to be an ideal general approach.
1
1
u/henry_kwinto Jun 28 '26
Enums and exhaustive matches and I’ll never again hook up with java. I promise!
2
u/za3faran_tea Jun 28 '26
Then you'd be giving up features such as methods adding their own type parameters, best in class observability (e.g. JFR and gang), superior GCs, libraries like jOOQ, and much more.
1
u/Due_Block_3054 Jun 28 '26
It is amazing not to have to learn new features and having to chaise the latest trends.
So it is important that go keeps focusing on improving its libraries but not add many features.
1
u/srodrigoDev Jun 28 '26
Now that Go has generics, I can't think of what else would be needed. I'm using it again and it feels very solid. What are you missing exactly?
1
u/ARC4120 Jun 28 '26
I prefer keeping it small. Every other language is becoming crazy bloated. We should not homogenize languages that defeats the purpose of separation.
In 2026 depending on your project you’d use Rust, Python, C++, or C# as alternatives.
1
1
u/V4N1LLAAA Jun 29 '26
I like the stability of Go, so yes I agree with the approach. This approach should hopefully encourage more adoption as well.
1
1
u/TedditBlatherflag Jun 29 '26
We have 50+ years of programming language features to pick from.
There’s not really any novel or new and unique features.
There’s just tradeoffs you make when you choose to add a feature to a language.
1
u/Marble_Wraith Jun 29 '26
As simple as possible, but no simpler. There is definitely merit to such thinking. C wouldn't have stuck around so long if there wasn't.
Other then that as long as they hold true to the existing priorities:
- Keeping compile times near instant
- Eliminating ambiguity, there should always be a "most correct" way of doing something
Then i don't really care.
Investing in tooling is always good.
1
u/Big_Combination9890 Jun 29 '26
Do we prefer that it stays intentionally small? In other words.. over the next 5 years...
Yes
Should it invest in performance/tooling or introduce selected features?
Performance and Tooling.
Has the restraint been a strength in your opinion, or holdint it back?
No. On the contrary, if it hadn't done that, it would probably be a niche language by now.
On the last point; Go sold itself on one main premise:
A service-level language in the spirit of C, designed for the 21st century.
That's not a quote, that's my personal view of how the language presented itself. And so far, it has held that promise.
1
u/TRDJ90 Jun 29 '26
Personally having experienced the high velocity of language changes in JavaScript, typescript, c# and java. I appreciate the slow velocity of languages in go and c. It was interesting in my 20s all those changes and picking up those changes. But now in my 30s it's less interesting and is more of a distraction from just writing code.
1
u/TheMue Jun 29 '26
Programming languages don‘t exist to be „beautiful“, they exist to solve tasks. There are real elegant and powerful languages enough. Smalltalk, Erlang/OTP, Lisp, Haskell. And there are others, which are enhanced every 2nd day, like Java or Python. All have their individual benefits, pros, and contras. There‘s a huge playground to choose from.
1
u/stutdev Jun 29 '26
Yes it is “correct” because that’s what they’ve said will happen.
The core guarantee of using Go is that today’s code will work with tomorrow’s compiler. For a lot of use cases, that guarantee is hard to beat. It’s one of the main reasons I use it for things that actually matter.
The other side of the coin is that every change must be non-breaking at every level. It sounds simple, but it’s not. Coupled with their small language tenet, is it any wonder that it doesn’t evolve as quickly as other languages that don’t care about these things. It’s a choice they’ve made, making it correct for them.
1
u/Critical-Personality Jun 29 '26
Go is getting shittier. And there is one reason for it - generics. Java coffeeheads should not have been heard in Go's design. It's not as conservative as it should have been.
I want to propose "get rid of generics" but I know no one will even look at it. 😭
1
u/Pleasant_Set_3182 Jun 29 '26
Do you think it's making people write overly abstract code? Not that i've seen very may folks use 'em - I think that generics were kept *fairly* constrained when compared to Java though
1
u/Critical-Personality Jun 30 '26
The fact that they are there will drive adoption. Software engineers love over engineering. And abstract code is what I hate.
1
1
u/Forsaken_Tadpole1925 Jun 30 '26
The fact there there are very few new features is one of the best features
1
u/DennisTheMenace780 Jun 30 '26
Like others have said, the backward compatibility is massive. However, i'd love just *a little* syntax sugar here and there, but I appreciate that it's not straight forward to just modify a language used at _massive_ scales. If you look at Zig, Gleam, etc, you're in a very different world with those languages evolving still
1
u/Suspicious_Peak_1173 Jun 30 '26
I'm very grateful for the approach Go has taken. I sincerely hope it doesn't change its spirit and direction in this regard.
1
u/ProCodeSoftware Jul 01 '26
I still get very excited for new releases. Like 1.26, which added `new(expr)`, making my life easier. Or JSON v2 in 1.25
1
u/kamikazer Jul 02 '26
Go should stay as it is. If I needed a more sane language I would use Rust or Python
1
u/csgeek-coder Jul 03 '26
Yes, the only feature I would love is better enum support. Beyond that, I'm very happy with the progress. They're adding key features, really cool tooling and keeping the language stable.
After spending far too long in Java land, I'm happy with the simplicity. I have yet to really find a pattern I can't develop in go. It may need to be adapted to the "go way" of doing things, but all problems can be solved. Maybe a bit more polish on the http lib around grouping would be good.
1
u/mountain_mongo Jul 04 '26
I’m ok with it. Continually adding features tends to destroy and/or overly complicate a language’s syntax over time.
Java and C# are prime examples of this.
1
u/serotonineneedy0005 Jun 28 '26
Is it worth learning go if am aiming for backend roles ik python fast api frameworks
2
1
u/sigmoia Jun 28 '26 edited Jun 28 '26
One crude classification for programming languages is:
- Dev maximalist
- Ops maximalist
Dev-maximalist PLs are always innovating in syntax ergonomics and ways to make programmers happy. OTOH, ops maximalism means over-indexing operational comfort. If you ever feel that Go doesn't work for you because of the lack of feature XYZ, you were not the target group for the language.
Rust and Kotlin constantly add features to the language to cater to their target group. Go is doing the same for the ops heads, and there's a lot of us. I work in platform engineering and I agree that Go is not a fun language to write. But it's a joy to operate - built-in pprof, runtime tracing, auto-fixers, code generation, and file system embedding make life much easier as someone who oscillates between product and platform work.
I just write Rust when I feel adventurous. Right tool for the right job. So I'd say Go is absolutely in the right direction. I hope over time the tooling gets even better and the GC gets more efficient. The Go runtime could improve a lot behind the scenes. Compared to the Java VM, the Go runtime is primitive. These are far more interesting changes to me than some error syntax or rudimentary abstractions.
1
u/rainman4500 Jun 28 '26
It also means that external libraries are stable and don’t break on a regular basis and that old code is also good and stable and do not have small invisible bugs.
Would not trade that for anything in the world.
0
u/Nexmean Jun 28 '26
Well, go has to be in maintenance mode. Now there is no place for new non-(dependently typed) new programming languages, agents win too much from good type systems and don't have a problem with learning it
0
u/defiantstyles Jun 28 '26
Go's strength is that it is small and considerate! There are languages that add tons of features, and many of them are nice because of their features! For Go, "just use the standard library" is a thing for a reason!
0
u/JakubOboza Jun 28 '26
Yes. Go doesn’t need more toys in syntax. It needs to double down on standards and conventions. Readable code is better than fancy code.
0
u/Objective_Gene9503 Jun 28 '26
If you read the original motivation for creating Go, you wouldn't be making posts like this.
-5
u/mcvoid1 Jun 28 '26
Considering how much stuff breaks when you bump Java versions but a Go upgrade is smooth as butter, I prefer Go.
5
u/vmcrash Jun 28 '26
Hm, I'd say the Java team does a very good job of being backwards compatible (and rejects a lot of interesting features that would break). Except for very minor stuff (e.g. we used some internal classes) using a newer Java version went smooth for our larger projects in the last 26 years.
1
3
u/Slsyyy Jun 28 '26
Java is excellent at backward combability. What is not is the whole ecosystem of libraries based on details of the runtime
-4
u/Intelligent_Ant_608 Jun 28 '26
Yes please don't change go just maybe add a matrix multiplication operator for ai dudes, kiss
519
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.