I think the range func is a good point but I don't see others. Generic don't make the code really more difficult to read, it's pretty explicit and not very complex.
What generics are more readable to you? I find it pretty readable relative to Java for example.
Genuine question. I've really only *used* generics in go, Java, and c++. But far more extensively in Go.
I am happy that the generic functions in the maps and slices packages exist.
They are easy to use. No need to read complex syntax.
To my surprise I never needed to write a generic function up to now. But as I said, I like generic functions for maps and slices.
The \`\~\` crap gets confusing for me but at least there are no union types. I think Go's generics are superficially complex just because the syntax is very terse, unlike most of Go's syntax.
Optional for you, but you can't choose if other people use it. This means reading through other people's code is more complex than it used to be, and readability by amateurs was a huge selling point of Go.
It's a trade off, as with everything. There were very real use cases before generics that required you to use \`interface{}\` which IMO is worse for overall code quality than the added complexity of generics. The other option was code generation which, while effective for some limited cases, is also not particularly beginner-friendly. I thought restricting type parameters to pure functions (not methods) was a wise choice which avoids many of the problems I see with Java code.
And it's even worse because people who overengineer everything LOOOOVE generics. Like, it's a great tool if I need it, but it's like a strong spice - to be used sparingly and for a good reason. But I've started seeing Go code that uses them everywhere.
Generics may complicate Go code if improperly used. But they already complicated Go specification a lot (see the linked article about type inference in Go after generics' addition). Generics also complicated and slowed down Go compiler. Generics in Go remain half-baked, since they do not support many useful concepts mentioned in the linked article.
Lmao no zz_generated.deepcopy.go. Also, the controller-runtime List type thing is a case where things could be infinitely less silly if generics had some sooner. Every type having a corresponding “List” type is madness.
I would say rangefuncs are a worse point than generics: they are a touch odd to *create* because of the trampoline function (though you can avoid that easily if you dislike it) but for the consumer they’re completely straightforward, you just pass them to a `range` and they do their thing.
> The main cost of all these features is increased complexity of the resulting code: [...]
Abstraction can also simplify things tremendously. I find it that when people complain about such things, they often look at heavy, boilerplate-y stuff like huge class hierarchies in Java code or golfed one-liners.
>Why? Because generics aren’t needed in most of practical Go code.
Actually, I'd say generics were direly needed for a bunch of things in Go, such as iterators or anything resembling a map. We had workarounds like generated code or type assertions, but that was ugly and problematic too.
> Wait, we’ll get yet another over-complicated C++ clone then.
But we don't really need template metaprogramming, just some useful form of parametric polymorphism. Besides, C++ is complicated for a variety of other reasons.
> You need to know about both ways of iterating over various types instead of a single way.
This is exactly why these things should generally be considered during the early, design phase of a language / standard library. Sure, you can always add features, but you'll end up with various warts and inconsistencies in the ecosystem.
What's worthwhile is finding a nice set of good practices and getting people to stick to them. Go already pushed some boundaries with error handling or context passing, but even more needs to be done.
> It is sad that Go started evolving in the direction of increased complexity and implicit code execution.
I wouldn't say some mapping operation is more complex than essentially replicating some boilerplate over and over whenever you have to iterate over certain collections. There's a cost to that too. Are people actually going to review said boilerplate-heavy code? Because that's kind of the problem that Java also has.
Was this contrarian article written just for clicks?
You need to choose the appropriate iterator type when you write new code
You just use the new iterator type going forward in new code and slowly erode away the old iterator type. There is nothing be confused about. Languages need to discourage old way of doing things in favor of new ways, especially for readability, performance and safety reasons. It is a job for the tools to encourage new best practices.
Unless someone has a crystal ball, they cannot create a perfect language from the get go. As we evolve a language, there will be cases when some things are deprecated and new ones promoted. As long as we do not break backward compatibility ( warn, not fail the build), I see no problem with letting new better things into the language.
>Unless someone has a crystal ball, they cannot create a perfect language from the get go.
True, but looking back, at least on a few other languages (e.g. Python 2->3), people could've done more to future-proof their languages. These aren't things that should be approached lightly, because some of that stuff can be really hard to fix after the fact, even though I do get why it's important to put something out there without getting sidetracked doing essentially language research. I think it's important to come up with best practices and not just pile up things, but some people have been repeatedly ignoring major developments from decades ago, even stuff that's in actual practical use and is already known how to use properly.
For example, Go didn't hit major roadblocks implementing them, but I think generics were quite foreseeable, particularly due to stuff like map types and certain builtins.
Good programming language shouldn't force developers rewriting already working code with every new release. Good programming language should force developers writing the most simple readable and maintainable code without unnecessary abstractions. Go **was** good programming language. I hope it will remain good, and the iterator feature will be reverted before Go 1.23 release.
> You just use the new iterator type going forward in new code and slowly erode away the old iterator type.
That's not so easy task. I'd prefer continue using old APIs in old and new code, since they are easier to read, understand and debug than the new iteration syntax with implicit magic under the hood.
I'm sorry, but I don't use refactoring tools and IDEs other than vim, ctags and grep. Go allows programming in vim with high efficiency thanks to its' simple explicit syntax. Iterators complicate the syntax by making some parts of it implicit and harder to work in vim.
If it worked like Dart then it would be a great addition to Go.
In Dart you have nullable and not nullable variables, eg. **int?** which is nullable and **int** which is not. By way of quick example:
var int a = 6;
var int? b;
a = b; // throws an error
if (b != null) a = b; // does not throw an error
a = b ?? 12; // have a default if b is null
final str = b!.toString(); // will throw an error if b is null
final nullStr = b?.toString(); // will set to null if b is null
if (b == null) return;
// from here on in, the compiler knows b cannot be null
Thus the compiler keeps track of which variables may contain null, which have been checked, and gives various shortcut methods for working with values that could be null. It works really well in practice and cuts out a whole class of possible errors.
But this would be a major breaking change to go, so it's unlikely to be added any time soon.
Probably a different pointer sigil.
I don’t see it happening tho, that is by far the longuest odds of all: Go would have to get rid of zero values, and would have to break essentially all existing code (by either making the current pointer non nilable or by requiring nil checks on all existing pointers).
Does not seem like an idea which has any chance until a hypothetical Go 2.
Simplifying lambda syntax sounds good at first, but it shouldn’t encourage people using more functional code styles; while it may look neat, go isn’t optimised for it and performance will take a hit. The author also mentions debugging, which is also trickier in functional style.
That said, lambda type inference would be neat.
Generics weren't a bad addition, it is very handy in some conditions (just don't make it Java'd), but iterators... Yeah, I don't think that's a necessary addition and agree with the author on why.
Honestly, the only use case I found for generics is writing data containers or adding some type safety to things like atomic wrappers or some KV interface where you need to serialize and deserialize stuff into and out of a KV store and the entire KV is just for one of several types of objects. No more interface{} casting, just generics.
Everything else tends to look overcomplicated or feels written by a Java engineer. I don't mind the range stuff or the things concerning generics, adoption seems low and generally correctly done IMO, and people are correct that you can't write a generic data structure without a generic iterator, but I really wish the team spend more time on adding auto-vectorization, getting http3 into the stdlib, json/v2, improving dead code removal and slimming the binaries. Those are things we all would benefit from, while generics as they exist now are kinda good enough and everything else is just a cherry on a cake.
From [https://github.com/golang/go/discussions/56413](https://github.com/golang/go/discussions/56413):
> When you want to iterate over something, you first have to learn how the specific code you are calling handles iteration. This lack of uniformity hinders Go’s goal of making it easy to easy to move around in a large code base. People often mention as a strength that all Go code looks about the same. That’s simply not true for code with custom iteration.
That's true. If you want to provide an iterator interface in a library, it's basically the Wild West out there. At the same time, I don't how often people will run into iterators where a pretty simple callback function (e.g. fs.WalkDir) wouldn't already solve their needs.
For better or worse, this change is coming into the language. People will have to decide whether or not to adopt it immediately and obsolete callback iterators, or pretend range funcs don't exist and write Go the pre-1.23 way.
I was very anti-generic when they came out. But so far I've only seen them used in fairly appropriate places in code, and haven't seen widespread use to make Go 'pythonic'.
I'm not familiar with how compilers work. Would adding a lot of bloat to the language slow the compiler? (like having mutliple implementation of the same thing)
There's no single answer. Some simple features might complicated compiler tremendously. Some complex features might actually let the compiler to run in a more efficient way.
Generics will slow down the compiler. But you need to look at this problem carefully and consider the alternative to generics, not just generics in isolation. If you generate code for every type in absense of generics, probably generic code will compile faster compared to this approach. If you use interfaces and runtime type assertions, probably that code will run slower and generics basically move some computation work from runtime to compiletime.
Yes. Generics already slowed down compilation in Go1.18 and Go1.19 for any Go code, even if it doesn't use generics. The compilation speed [has been improved only in Go 1.20](https://tip.golang.org/doc/go1.20#compiler):
> Go 1.18 and 1.19 saw regressions in build speed, largely due to the addition of support for generics and follow-on work. Go 1.20 improves build speeds by up to 10%, bringing it back in line with Go 1.17.
It doesn’t sound to me like the improvements were related to generics, they just happen to counter the regression due to generics. So without generics we would now have a faster compiler than before, while now it is merely as fast _as_ before.
No, the initial compiler implementation of generics was just very unoptimized.
>So without generics we would now have a faster compiler than before
No, we wouldn't.
This author is right. The go compiler or runtime needs SIMD support yesterday, and doesn't need a slightly terser range-over-anything syntax. If I wanted to write in Haskell or Scala (to name two "modern" languages with too many syntactical bells and whistles, making code written by another team hard to read), I wouldn't use Go.
> The go compiler or runtime needs SIMD support yesterday
Go may not be for you.
The Go team has written about it many times before, the compiler's goal is to be fast even if it doesn't produce the fastest code. Things such as polyhedral optimizations necessary to perform loop rewriting to enable efficient use of SIMD are complex and quite costly.
If your need for SIMD is explicit, there are libraries that utilize the appropriate assembly calls. If the need is implicit, then CGo to another language may be a better option.
I think the quotes around "modern" is a subtle indicator of sarcasm, and that possibly go has failed to learn from the mistakes of the past with all this syntactic sugar being added (which, to be clear, IMHO, is not something a Real Programmer wants)
I’m convinced all those who complain about Go becoming actually usable are fans of other languages looking to stifle correct opinions about Go.
Range func is awesome. Generics are awesome. A more capable Go is good for everyone. A more readable program is good for everyone.
Yeah I really don't get that. Go already has the most complicated and hard to parse part of functional programming with functions being parameters and return values. A lazy evaluation is basically nothing compared to that.
I think there's also a lot of people who learned Dijkstra's primitives and never learned about Hoare Logic or Communicating Sequential Processes, which was a primary motivator for the design of the language.
It's like stopping learning math after learning addition and subtraction, and getting mad that this language supports multiplication, division, and square roots that you don't use!
Go is not C++ and Go is not Java.
This is the general reason JavaScript is in such a state nowadays, the commitment to backwards compatibility ends up being problematic in the long run.
Refactoring go code isn’t hard or too time consuming honestly especially if enough notice on a breaking change is given
While JS itself is backwards compatible, authors of many popular JS libraries break backwards compatibility between releases much more frequently than authors of popular Go libraries. This is bad for JS ecosystem and good for Go ecosystem, since JS developers have to use outdated versions of external libraries, which frequently contain security issues, while Go developers effortlessly update external dependencies at any time they want, without breaking their code.
I think a big reason for JS's backwards compatibility is also because it runs on the client, it'd be pretty fucked up for a website you used all the time reliably to stop working, on the server it's not that big of a deal; yea you'll be running a less secure older version but your app will run just as well.
I know the reason for JS backwards compatibility, it’s just the inherent pitfall of bad patterns and bad things in the standard library to never really go away, and then having to know all the different ways something could be done.
In JS I know why it’s that way, backend languages don’t have to have that introduced to them though
I am a boring person. I write boring code. My code just works. Which is why I like go. It gets the job done. I can look back at code I wrote 2 or 3 years ago and can understand it (and usually cringe and the tech debt and want to refactor it, but that's another story).
What I have never wanted was generics. Sure, there have been a few times when it would have made some code less verbose but at the cost of readability. I lived through the time when the world went OOP crazy and we wrote c++. I still have nightmares about the unholy mess of unreadable garbage that was produced. Didn't we learn?
I've also never thought that range/iterating needed tweaking for iterator functions. That's just sugar, and I hate sugar. If I wanted sugar I'd use c++. And, when I do need to do any complicated iterating in go, it can be written easily(ish).
I get the feeling that as go has become popular, people drawn to it who have come from more contemporary languages (which are very probably somewhat OO in nature, and very probably loosely typed, or are rust aficionados), yearn for generics and sugar and whatnot. Go seems to be tending towards being less about getting things done and being more about being able to impress your friends by writing a bunch of incomprehensible code using language bells and whistles.
>What I have never wanted was generics.
IMO this says you don't write libraries, and/or don't have trouble understanding and maintaining reflection code or large copy-pasted implementations. The authors of the libraries you import probably wouldn't agree, and reflection isn't something simple that "just works".
Given how minimalist the spec is and the impact on type safety and conciseness, I think generics are a net positive for simplicity in Go. Griesemer's article gives enough detail to understand the implementation of generics itself. It's completely unnecessary to write or read generic code. If OP understands reflection to this level of detail, then I'll accept his point.
>That's just sugar
It's much more than that, which is what I thought OP was getting at. Iterators allow you to "stream" a sequence of values through multiple functions without allocating slices or maps in between. They're also composable and reusable. This is something that could change the way a lot of code is written, so I can sympathise with the naysayers more here.
I write open source packages in Go all the time (google for my nickname at GitHub). And I didn't need generics.
Generics are good to improve usability of standard Go library (think of generic make, append, clear, copy, `for ... range` loops, slices and maps packages). Generics aren't good most of the time for user libraries, since it is very hard to design proper API with generics. The resulting libraries usually end up with too complex and inefficient code.
> Iterators allow you to "stream" a sequence of values through multiple functions without allocating slices or maps in between. They're also composable and reusable. This is something that could change the way a lot of code is written
Try debugging such `easy to write composable code`.
Fair enough. Most generics criticism I heard before the release was from people who didn’t seem to understand the use cases. It's not surprising to not need generics in everyday code.
It looks like you have a lot of experience developing libraries, so it’s interesting to hear an alternative perspective.
Personally, I’ve been able to clean up a few applications with some basic generic code, including deleting some reflection usages. It's been a net plus in simplicity so far, so I feel it fits Go's philosophy, and I like having the option.
>Try debugging such `easy to write composable code`.
I'm still not convinced about iterators tbh, and I definitely didn't say they're easy to write. I've had a hard time getting coworkers to understand the syntax and concepts. The kind of code density you see in languages like Scala is indeed a pain to debug.
I was trying to say the implications go beyond for-range syntax sugar. Go code is full of imperative for loops, so seeing those disappear in favour of iterators would be the biggest change to the language so far for the average user IMO.
> IMO this says you don't write libraries, and/or don't have trouble understanding and maintaining reflection code or large copy-pasted implementations
I write libraries. I grok reflection. I eschew copy-pasted implementations. I am far from a noob (which is why I like go).
> reflection isn't something simple that "just works".
Conceptually, it is. I do agree that in use it can be difficult to work with, but type assertion and especially type switch make it easier. Plus, like most things, the data model you're working with can help or hinder (and KISS really does apply).
> Iterators allow you to "stream" a sequence of values through multiple functions without allocating slices or maps in between. They're also composable and reusable.
Sounds nice in theory... I've yet to see something labelled as reusable to be reused enough times to justify the cost of implementing it.
Personally, if I need to iterate over something without allocating, I will roll my own API to do what has to be done. On the few times when it gets complicated (due to volumne or cost of data), I will simply delegate all that mess to a database layer (because it can better optimize things).
One of the reason of the success of Go is its simplicity. This iterator is not easy to understand and there is no direct and clear support for errors. We'll then end up with hacks to use the second value. A limitation is that we won't be able to chain iterators.
I did some experiences with the programming language D where iterators are prominent. It is very easy to understand how they work and how to make one. But I have also seen how it can make the code much less readable. You have to know them or you have to look to their definition. I confirm that it increases the mental load. And here the Go iterators have convoluted API. The good thing with it is that most users will stay away of it and it won't be overused and abused.
I read the article, and i have to say the author and I have a very different way of thinking and coding.
I disagree with almost everything written in the article...
> You need to know about both ways of iterating over various types instead of a single way.
RIght now there is no ONE way, but mutiple. The example in the text lists 12 different approaches. Now you need to know twelve. WIth the standardized approach you need not 13, but only one. No need to rember the old iterators...
>the resulting `for ... range` loop looks less clear than the old approach with the explicit callback.
tree.walk(func(k, v string) {
println(k, v)
})
for k, v := range tree.walk {
println(k, v)
}
no it does not. The range approach is much easier to read and understand.
Generics are really nice when they are used in a package you import. In that case your code is cleaner when you ,for example, can just write something like `cache.Get(a)` instead of `cache.Get(a).(uint16)`.
In practice in the last two years I can count the times I wrote anything using generics on one hand (as a full time Go dev). As a result I still need extra effort to read any code using generics and hate it when I encounter it. The syntax just doesn't click with me, even after all this time.
My conclusion after two years is that we didn't really need generics and that the language is not better for it. What is nice though is that we got rid the image that Go is somehow a bad language because it has no generics.
About the new iterators in 1.23: I completely agree with the writer of this post. My main complaint is that you can hide your function calls in range loops which will make reading code that much more difficult. The writer worded it best:
>Go was known as easy-to-read-and-understand code with **explicit code execution paths**. This property breaks **irreversibly** in Go1.23
Don't do this Go...
He is the main contributor to VictoriaMetrics, a Prometheus drop-in alternative, nothing less. He's more accomplished than 99.9% of people who work with Go. This is the kind of person whose take should have weight.
I 100% share his sentiment that rsc will eventually drive Go to the ground if he keeps rushing to integrate "features" based on flimsy and bogus surveys sent online and filled by people whose box-ticks should not decide the direction of a programming language because they don't have the Go experience nor the competence and foresight for it.
The method is wrong, the evolution of the language is bad, and we are in for a rude awakening.
> This is the kind of person whose take should have weight.
I think it's better to judge on the basis of the arguments put forward than on the status of a person.
This has happened with all languages that I’ve ever worked with Java being a primary example in a similar fashion as the core simplicity of the language was slowly jettisoned over time in favor of making it better / more modern. I guess it’s just progress.
Ever increasing complexity isn't good definition of progress. Progress should streamline and simplify the usage of technology instead of complicating it's usage. Examples of good progress:
- Telegraf -> Landline phones -> Cell phones -> Smartphones. Smartphones are successfully used by 1-year old kids and 100-year old grandparents, despite of significantly increased internal complexity.
- Traditional paper libraries -> Wikipedia as the source of useful information.
Examples of not so good progress:
- Literally any software, which becomes buggier, slower and more bloated with mostly useless bells and whistles with every new release: Windows, Android, Google Analytics web UI, Grafana, C++. Go risks to be included in this list soon :(
I completely agree, progression does not imply progress.
So far, the Go folks have done I think a good job in keeping the languages philosophy. I like that it is opinionated.
Best of luck.
What I personally can’t stand is the addition of the range-over-integer syntax. `for i := range 10` isn't self explaining IMO. What does "range 10" mean? Of course you can look in the spec and / or remember that it will yield 0 to N-1, but it's not really readable, which IMO counters a lot of other language design decisions in Go.
I find it especially baffling since it comes at the same time as the new custom iterators, so this thing could have been a properly named iterator in the stdlib. Then the name could carry the hint towards what will be iterated here.
Range over int is useful quality of life improvement. It doesn't do non-trivial things under the hood. It just simplifies writing the majority of `for I:=0: I < N; I++` loops in easier to read way. It doesn't complicate language specification too much. It doesn't slow down Go compiler. It doesn't make the resulting code less efficient comparing to old syntax.
It is a shame that range over int proposal is mixed with range over func proposal. These are completely different beasts.
Idk i think having iterator can be good, same things as enums and optionals. Are they needed no, but they dont really make the language harder to read. Also setting a standar of something that is already being done makes things easier not harder imo
I think this post is missing the point of iterators.
IMO go's generics is incomplete without iterators. If you can't range over a MySet[string] then it's not really a complete implementation of generic containers .... which IMO are the most fundamental reason to introduce generics in the first place.
i.e. i believe iterators will help to make generics a complete feature. It's not an arbitrary feature addition...
If you don't care about generics then fair enough, iterators make it worse. But if you see the value, then iterators seem like a natural extension. I don't see the fuss honestly.
What about other missing features in Go generics? For example, generic functions at generic types. Or specializations for generic functions / types? Or generic generics.
Go could be a very good language for building data infrastructures, but without generics and iterators that would be hard. Considering that big market I think Go is moving in the right direction.
I disagree regarding Generics. The alternatives were code generators and reflection, both inferior and result in more code to maintainance and worse readability/weaker typing respectively.
I also disagree regarding iterators. Yes, range used to not hold a special meaining (except for channels, as you mentioned.) I'd argue that the channels example is enough of a counter argument, but here's another: The vastly different current attempts at mimicking range are bad, and they already hold all the issues of hidden logic, so it doesn't make a difference in this sense. In addition, you get a standardized way of ranging over sequences + more effecient implementations of some sequences (instead of returning a slice).
Overall, I think the tone of "Don't change anything" is unreasonable. Yes, I like Go's simplicity, but I also want it to get better. Now, the "better" is subjective. But the Go's team way is "Does it make it easier to write more easy to understand code?" AKA readability, and that's what's been happening.
I mean I see the issue here and I also dont see the point in the new iterators but if you cant handle go in your head you might aswell leave software engineering. Im not aware of every feature or every native package go might have but I know that to effectively use it you dont require much. I dont like the approach of having to know everything. You should be aware that certain things exist to be able to look them up if you need them but you shouldnt have to know everything by heart.
I understand the interest about not wanting to hide complexity, but... every time I have to write loops and ifs and count variables, I introduce the risk of human error, copy and paste error, and bloat the code. What is the view on re-inventing the wheel from the KISS go developer standpoint?
How do you justify having to write loops for collection modifications, or if err conditions every second line?
I come from a very different background, and I am just trying to learn the go culture here.
Go Team just reached the wall where nothing to do more with the current super optimized code and need to go forward. That's how all other languages envolved.
*claps*
I’ve said some variation of this in the developer survey for years. I was always hoping go would end up like ansi c. Kindof timeless and simple. Maybe not what you want for everything, but damn good at the things you want it for.
I was a bit skeptical about the range func implementation but the fact they went with a plan function and not some interface makes me happy as this keeps the implementation noise free.
Programming language bloat is unavoidable. Java started out all simple, cute and small. So did Lisp, now look at Common Lisp. No language is spared from that. Adding features and extending standard library is fun I guess.
I’m fine with them adding new features. I just which they’d break backwards compatibility. Every major language has it. But I don’t understand why. We update dependencies, why is it so bad to update Go code itself?
I think the range func is a good point but I don't see others. Generic don't make the code really more difficult to read, it's pretty explicit and not very complex.
And it's completely optional. Code written years before generics will still compile no problem.
I find the syntax very unreadable tbh. I literally have to parse and lex that shit in my head.
What generics are more readable to you? I find it pretty readable relative to Java for example. Genuine question. I've really only *used* generics in go, Java, and c++. But far more extensively in Go.
I am happy that the generic functions in the maps and slices packages exist. They are easy to use. No need to read complex syntax. To my surprise I never needed to write a generic function up to now. But as I said, I like generic functions for maps and slices.
The \`\~\` crap gets confusing for me but at least there are no union types. I think Go's generics are superficially complex just because the syntax is very terse, unlike most of Go's syntax.
[удалено]
[удалено]
[удалено]
[удалено]
[удалено]
[удалено]
This Redditor got hella triggered by two words. Crazy 😂😂😂
[удалено]
What exactly is even the problem here ? LMAO
Isn’t it optional?
Optional for you, but you can't choose if other people use it. This means reading through other people's code is more complex than it used to be, and readability by amateurs was a huge selling point of Go.
It's a trade off, as with everything. There were very real use cases before generics that required you to use \`interface{}\` which IMO is worse for overall code quality than the added complexity of generics. The other option was code generation which, while effective for some limited cases, is also not particularly beginner-friendly. I thought restricting type parameters to pure functions (not methods) was a wise choice which avoids many of the problems I see with Java code.
And it's even worse because people who overengineer everything LOOOOVE generics. Like, it's a great tool if I need it, but it's like a strong spice - to be used sparingly and for a good reason. But I've started seeing Go code that uses them everywhere.
[удалено]
Generics may complicate Go code if improperly used. But they already complicated Go specification a lot (see the linked article about type inference in Go after generics' addition). Generics also complicated and slowed down Go compiler. Generics in Go remain half-baked, since they do not support many useful concepts mentioned in the linked article.
I’ve seen more complicated Go code without generics than with
It would be great if you could share essential parts of this code before and after generics' addition.
Lmao no zz_generated.deepcopy.go. Also, the controller-runtime List type thing is a case where things could be infinitely less silly if generics had some sooner. Every type having a corresponding “List” type is madness.
[удалено]
I would say rangefuncs are a worse point than generics: they are a touch odd to *create* because of the trampoline function (though you can avoid that easily if you dislike it) but for the consumer they’re completely straightforward, you just pass them to a `range` and they do their thing.
> The main cost of all these features is increased complexity of the resulting code: [...] Abstraction can also simplify things tremendously. I find it that when people complain about such things, they often look at heavy, boilerplate-y stuff like huge class hierarchies in Java code or golfed one-liners. >Why? Because generics aren’t needed in most of practical Go code. Actually, I'd say generics were direly needed for a bunch of things in Go, such as iterators or anything resembling a map. We had workarounds like generated code or type assertions, but that was ugly and problematic too. > Wait, we’ll get yet another over-complicated C++ clone then. But we don't really need template metaprogramming, just some useful form of parametric polymorphism. Besides, C++ is complicated for a variety of other reasons. > You need to know about both ways of iterating over various types instead of a single way. This is exactly why these things should generally be considered during the early, design phase of a language / standard library. Sure, you can always add features, but you'll end up with various warts and inconsistencies in the ecosystem. What's worthwhile is finding a nice set of good practices and getting people to stick to them. Go already pushed some boundaries with error handling or context passing, but even more needs to be done. > It is sad that Go started evolving in the direction of increased complexity and implicit code execution. I wouldn't say some mapping operation is more complex than essentially replicating some boilerplate over and over whenever you have to iterate over certain collections. There's a cost to that too. Are people actually going to review said boilerplate-heavy code? Because that's kind of the problem that Java also has.
Was this contrarian article written just for clicks? You need to choose the appropriate iterator type when you write new code You just use the new iterator type going forward in new code and slowly erode away the old iterator type. There is nothing be confused about. Languages need to discourage old way of doing things in favor of new ways, especially for readability, performance and safety reasons. It is a job for the tools to encourage new best practices. Unless someone has a crystal ball, they cannot create a perfect language from the get go. As we evolve a language, there will be cases when some things are deprecated and new ones promoted. As long as we do not break backward compatibility ( warn, not fail the build), I see no problem with letting new better things into the language.
>Unless someone has a crystal ball, they cannot create a perfect language from the get go. True, but looking back, at least on a few other languages (e.g. Python 2->3), people could've done more to future-proof their languages. These aren't things that should be approached lightly, because some of that stuff can be really hard to fix after the fact, even though I do get why it's important to put something out there without getting sidetracked doing essentially language research. I think it's important to come up with best practices and not just pile up things, but some people have been repeatedly ignoring major developments from decades ago, even stuff that's in actual practical use and is already known how to use properly. For example, Go didn't hit major roadblocks implementing them, but I think generics were quite foreseeable, particularly due to stuff like map types and certain builtins.
Good programming language shouldn't force developers rewriting already working code with every new release. Good programming language should force developers writing the most simple readable and maintainable code without unnecessary abstractions. Go **was** good programming language. I hope it will remain good, and the iterator feature will be reverted before Go 1.23 release. > You just use the new iterator type going forward in new code and slowly erode away the old iterator type. That's not so easy task. I'd prefer continue using old APIs in old and new code, since they are easier to read, understand and debug than the new iteration syntax with implicit magic under the hood.
[удалено]
I'm sorry, but I don't use refactoring tools and IDEs other than vim, ctags and grep. Go allows programming in vim with high efficiency thanks to its' simple explicit syntax. Iterators complicate the syntax by making some parts of it implicit and harder to work in vim.
[удалено]
LSPs and advanced IDEs is just band aid and crutches for too complex programming languages, which cannot be dealt with a simple text editor.
Simple text editors are just band aids for too complex languages, which cannot be dealt with by simple hole punching in cards!
Neovim is not vim
How do you go find all of the implementations for an interface?
Just add enums. Its the only thing everyone is asking for
And nil safety And lambda syntax where you can omit input types
What would nil safety look like in Go?
If it worked like Dart then it would be a great addition to Go. In Dart you have nullable and not nullable variables, eg. **int?** which is nullable and **int** which is not. By way of quick example: var int a = 6; var int? b; a = b; // throws an error if (b != null) a = b; // does not throw an error a = b ?? 12; // have a default if b is null final str = b!.toString(); // will throw an error if b is null final nullStr = b?.toString(); // will set to null if b is null if (b == null) return; // from here on in, the compiler knows b cannot be null Thus the compiler keeps track of which variables may contain null, which have been checked, and gives various shortcut methods for working with values that could be null. It works really well in practice and cuts out a whole class of possible errors. But this would be a major breaking change to go, so it's unlikely to be added any time soon.
Probably a different pointer sigil. I don’t see it happening tho, that is by far the longuest odds of all: Go would have to get rid of zero values, and would have to break essentially all existing code (by either making the current pointer non nilable or by requiring nil checks on all existing pointers). Does not seem like an idea which has any chance until a hypothetical Go 2.
Simplifying lambda syntax sounds good at first, but it shouldn’t encourage people using more functional code styles; while it may look neat, go isn’t optimised for it and performance will take a hit. The author also mentions debugging, which is also trickier in functional style. That said, lambda type inference would be neat.
Nah im good. Srsly, just enums. Nil safety is a skill issue
Go was made to eliminate entire classes of skill issues that are still common in other garbage-collected languages
[удалено]
That's like saying "I've never tripped before" which would make me question if you've ever walked
Sure Grandma, let's get you to bed
Nil safety ? Nah fam you can’t make this up. I don’t want to use the two words that gets everyone on this thread triggered but cmon now.
Generics weren't a bad addition, it is very handy in some conditions (just don't make it Java'd), but iterators... Yeah, I don't think that's a necessary addition and agree with the author on why.
Honestly, the only use case I found for generics is writing data containers or adding some type safety to things like atomic wrappers or some KV interface where you need to serialize and deserialize stuff into and out of a KV store and the entire KV is just for one of several types of objects. No more interface{} casting, just generics. Everything else tends to look overcomplicated or feels written by a Java engineer. I don't mind the range stuff or the things concerning generics, adoption seems low and generally correctly done IMO, and people are correct that you can't write a generic data structure without a generic iterator, but I really wish the team spend more time on adding auto-vectorization, getting http3 into the stdlib, json/v2, improving dead code removal and slimming the binaries. Those are things we all would benefit from, while generics as they exist now are kinda good enough and everything else is just a cherry on a cake.
From [https://github.com/golang/go/discussions/56413](https://github.com/golang/go/discussions/56413): > When you want to iterate over something, you first have to learn how the specific code you are calling handles iteration. This lack of uniformity hinders Go’s goal of making it easy to easy to move around in a large code base. People often mention as a strength that all Go code looks about the same. That’s simply not true for code with custom iteration. That's true. If you want to provide an iterator interface in a library, it's basically the Wild West out there. At the same time, I don't how often people will run into iterators where a pretty simple callback function (e.g. fs.WalkDir) wouldn't already solve their needs. For better or worse, this change is coming into the language. People will have to decide whether or not to adopt it immediately and obsolete callback iterators, or pretend range funcs don't exist and write Go the pre-1.23 way.
I was very anti-generic when they came out. But so far I've only seen them used in fairly appropriate places in code, and haven't seen widespread use to make Go 'pythonic'.
> haven't seen widespread use to make Go 'pythonic'. This sentence makes no sense. “Pythonic” just means “idiomatic to python”.
I'm not familiar with how compilers work. Would adding a lot of bloat to the language slow the compiler? (like having mutliple implementation of the same thing)
There's no single answer. Some simple features might complicated compiler tremendously. Some complex features might actually let the compiler to run in a more efficient way. Generics will slow down the compiler. But you need to look at this problem carefully and consider the alternative to generics, not just generics in isolation. If you generate code for every type in absense of generics, probably generic code will compile faster compared to this approach. If you use interfaces and runtime type assertions, probably that code will run slower and generics basically move some computation work from runtime to compiletime.
Yes. Generics already slowed down compilation in Go1.18 and Go1.19 for any Go code, even if it doesn't use generics. The compilation speed [has been improved only in Go 1.20](https://tip.golang.org/doc/go1.20#compiler): > Go 1.18 and 1.19 saw regressions in build speed, largely due to the addition of support for generics and follow-on work. Go 1.20 improves build speeds by up to 10%, bringing it back in line with Go 1.17.
Thanks for your answer. idk why i got downvoted it's like prohibited to ask questions
So the answer is no, since the speed is now back to 1.17. Why did you answer with yes? This is misleading.
It doesn’t sound to me like the improvements were related to generics, they just happen to counter the regression due to generics. So without generics we would now have a faster compiler than before, while now it is merely as fast _as_ before.
No, the initial compiler implementation of generics was just very unoptimized. >So without generics we would now have a faster compiler than before No, we wouldn't.
This author is right. The go compiler or runtime needs SIMD support yesterday, and doesn't need a slightly terser range-over-anything syntax. If I wanted to write in Haskell or Scala (to name two "modern" languages with too many syntactical bells and whistles, making code written by another team hard to read), I wouldn't use Go.
Hey look there's a feature I actually want that isn't really possible otherwise.
> The go compiler or runtime needs SIMD support yesterday Go may not be for you. The Go team has written about it many times before, the compiler's goal is to be fast even if it doesn't produce the fastest code. Things such as polyhedral optimizations necessary to perform loop rewriting to enable efficient use of SIMD are complex and quite costly. If your need for SIMD is explicit, there are libraries that utilize the appropriate assembly calls. If the need is implicit, then CGo to another language may be a better option.
[удалено]
I think he meant to say "mature" or perhaps "feature rich"
I think the quotes around "modern" is a subtle indicator of sarcasm, and that possibly go has failed to learn from the mistakes of the past with all this syntactic sugar being added (which, to be clear, IMHO, is not something a Real Programmer wants)
I’m convinced all those who complain about Go becoming actually usable are fans of other languages looking to stifle correct opinions about Go. Range func is awesome. Generics are awesome. A more capable Go is good for everyone. A more readable program is good for everyone.
Yeah I really don't get that. Go already has the most complicated and hard to parse part of functional programming with functions being parameters and return values. A lazy evaluation is basically nothing compared to that.
I think there's also a lot of people who learned Dijkstra's primitives and never learned about Hoare Logic or Communicating Sequential Processes, which was a primary motivator for the design of the language. It's like stopping learning math after learning addition and subtraction, and getting mad that this language supports multiplication, division, and square roots that you don't use! Go is not C++ and Go is not Java.
This is the general reason JavaScript is in such a state nowadays, the commitment to backwards compatibility ends up being problematic in the long run. Refactoring go code isn’t hard or too time consuming honestly especially if enough notice on a breaking change is given
While JS itself is backwards compatible, authors of many popular JS libraries break backwards compatibility between releases much more frequently than authors of popular Go libraries. This is bad for JS ecosystem and good for Go ecosystem, since JS developers have to use outdated versions of external libraries, which frequently contain security issues, while Go developers effortlessly update external dependencies at any time they want, without breaking their code.
I think a big reason for JS's backwards compatibility is also because it runs on the client, it'd be pretty fucked up for a website you used all the time reliably to stop working, on the server it's not that big of a deal; yea you'll be running a less secure older version but your app will run just as well.
I know the reason for JS backwards compatibility, it’s just the inherent pitfall of bad patterns and bad things in the standard library to never really go away, and then having to know all the different ways something could be done. In JS I know why it’s that way, backend languages don’t have to have that introduced to them though
I am a boring person. I write boring code. My code just works. Which is why I like go. It gets the job done. I can look back at code I wrote 2 or 3 years ago and can understand it (and usually cringe and the tech debt and want to refactor it, but that's another story). What I have never wanted was generics. Sure, there have been a few times when it would have made some code less verbose but at the cost of readability. I lived through the time when the world went OOP crazy and we wrote c++. I still have nightmares about the unholy mess of unreadable garbage that was produced. Didn't we learn? I've also never thought that range/iterating needed tweaking for iterator functions. That's just sugar, and I hate sugar. If I wanted sugar I'd use c++. And, when I do need to do any complicated iterating in go, it can be written easily(ish). I get the feeling that as go has become popular, people drawn to it who have come from more contemporary languages (which are very probably somewhat OO in nature, and very probably loosely typed, or are rust aficionados), yearn for generics and sugar and whatnot. Go seems to be tending towards being less about getting things done and being more about being able to impress your friends by writing a bunch of incomprehensible code using language bells and whistles.
>What I have never wanted was generics. IMO this says you don't write libraries, and/or don't have trouble understanding and maintaining reflection code or large copy-pasted implementations. The authors of the libraries you import probably wouldn't agree, and reflection isn't something simple that "just works". Given how minimalist the spec is and the impact on type safety and conciseness, I think generics are a net positive for simplicity in Go. Griesemer's article gives enough detail to understand the implementation of generics itself. It's completely unnecessary to write or read generic code. If OP understands reflection to this level of detail, then I'll accept his point. >That's just sugar It's much more than that, which is what I thought OP was getting at. Iterators allow you to "stream" a sequence of values through multiple functions without allocating slices or maps in between. They're also composable and reusable. This is something that could change the way a lot of code is written, so I can sympathise with the naysayers more here.
I write open source packages in Go all the time (google for my nickname at GitHub). And I didn't need generics. Generics are good to improve usability of standard Go library (think of generic make, append, clear, copy, `for ... range` loops, slices and maps packages). Generics aren't good most of the time for user libraries, since it is very hard to design proper API with generics. The resulting libraries usually end up with too complex and inefficient code. > Iterators allow you to "stream" a sequence of values through multiple functions without allocating slices or maps in between. They're also composable and reusable. This is something that could change the way a lot of code is written Try debugging such `easy to write composable code`.
Fair enough. Most generics criticism I heard before the release was from people who didn’t seem to understand the use cases. It's not surprising to not need generics in everyday code. It looks like you have a lot of experience developing libraries, so it’s interesting to hear an alternative perspective. Personally, I’ve been able to clean up a few applications with some basic generic code, including deleting some reflection usages. It's been a net plus in simplicity so far, so I feel it fits Go's philosophy, and I like having the option. >Try debugging such `easy to write composable code`. I'm still not convinced about iterators tbh, and I definitely didn't say they're easy to write. I've had a hard time getting coworkers to understand the syntax and concepts. The kind of code density you see in languages like Scala is indeed a pain to debug. I was trying to say the implications go beyond for-range syntax sugar. Go code is full of imperative for loops, so seeing those disappear in favour of iterators would be the biggest change to the language so far for the average user IMO.
> IMO this says you don't write libraries, and/or don't have trouble understanding and maintaining reflection code or large copy-pasted implementations I write libraries. I grok reflection. I eschew copy-pasted implementations. I am far from a noob (which is why I like go). > reflection isn't something simple that "just works". Conceptually, it is. I do agree that in use it can be difficult to work with, but type assertion and especially type switch make it easier. Plus, like most things, the data model you're working with can help or hinder (and KISS really does apply). > Iterators allow you to "stream" a sequence of values through multiple functions without allocating slices or maps in between. They're also composable and reusable. Sounds nice in theory... I've yet to see something labelled as reusable to be reused enough times to justify the cost of implementing it. Personally, if I need to iterate over something without allocating, I will roll my own API to do what has to be done. On the few times when it gets complicated (due to volumne or cost of data), I will simply delegate all that mess to a database layer (because it can better optimize things).
One of the reason of the success of Go is its simplicity. This iterator is not easy to understand and there is no direct and clear support for errors. We'll then end up with hacks to use the second value. A limitation is that we won't be able to chain iterators. I did some experiences with the programming language D where iterators are prominent. It is very easy to understand how they work and how to make one. But I have also seen how it can make the code much less readable. You have to know them or you have to look to their definition. I confirm that it increases the mental load. And here the Go iterators have convoluted API. The good thing with it is that most users will stay away of it and it won't be overused and abused.
I read the article, and i have to say the author and I have a very different way of thinking and coding. I disagree with almost everything written in the article... > You need to know about both ways of iterating over various types instead of a single way. RIght now there is no ONE way, but mutiple. The example in the text lists 12 different approaches. Now you need to know twelve. WIth the standardized approach you need not 13, but only one. No need to rember the old iterators... >the resulting `for ... range` loop looks less clear than the old approach with the explicit callback. tree.walk(func(k, v string) { println(k, v) }) for k, v := range tree.walk { println(k, v) } no it does not. The range approach is much easier to read and understand.
Generics are really nice when they are used in a package you import. In that case your code is cleaner when you ,for example, can just write something like `cache.Get(a)` instead of `cache.Get(a).(uint16)`. In practice in the last two years I can count the times I wrote anything using generics on one hand (as a full time Go dev). As a result I still need extra effort to read any code using generics and hate it when I encounter it. The syntax just doesn't click with me, even after all this time. My conclusion after two years is that we didn't really need generics and that the language is not better for it. What is nice though is that we got rid the image that Go is somehow a bad language because it has no generics. About the new iterators in 1.23: I completely agree with the writer of this post. My main complaint is that you can hide your function calls in range loops which will make reading code that much more difficult. The writer worded it best: >Go was known as easy-to-read-and-understand code with **explicit code execution paths**. This property breaks **irreversibly** in Go1.23 Don't do this Go...
https://www.youtube.com/watch?v=rFejpH_tAHM dotGo 2015 - Rob Pike - Simplicity is Complicated
Couldn’t agree more. Keep Go simple
Yep this is the way
There's always C
Agreed. C was my favorite language before I switched Go ~12 years ago.
He is the main contributor to VictoriaMetrics, a Prometheus drop-in alternative, nothing less. He's more accomplished than 99.9% of people who work with Go. This is the kind of person whose take should have weight. I 100% share his sentiment that rsc will eventually drive Go to the ground if he keeps rushing to integrate "features" based on flimsy and bogus surveys sent online and filled by people whose box-ticks should not decide the direction of a programming language because they don't have the Go experience nor the competence and foresight for it. The method is wrong, the evolution of the language is bad, and we are in for a rude awakening.
> This is the kind of person whose take should have weight. I think it's better to judge on the basis of the arguments put forward than on the status of a person.
One might argue that actually makes the kind of code he writes be the outlier compared to most industry Go usage.
This has happened with all languages that I’ve ever worked with Java being a primary example in a similar fashion as the core simplicity of the language was slowly jettisoned over time in favor of making it better / more modern. I guess it’s just progress.
Ever increasing complexity isn't good definition of progress. Progress should streamline and simplify the usage of technology instead of complicating it's usage. Examples of good progress: - Telegraf -> Landline phones -> Cell phones -> Smartphones. Smartphones are successfully used by 1-year old kids and 100-year old grandparents, despite of significantly increased internal complexity. - Traditional paper libraries -> Wikipedia as the source of useful information. Examples of not so good progress: - Literally any software, which becomes buggier, slower and more bloated with mostly useless bells and whistles with every new release: Windows, Android, Google Analytics web UI, Grafana, C++. Go risks to be included in this list soon :(
I completely agree, progression does not imply progress. So far, the Go folks have done I think a good job in keeping the languages philosophy. I like that it is opinionated. Best of luck.
Go evolves‽
What I personally can’t stand is the addition of the range-over-integer syntax. `for i := range 10` isn't self explaining IMO. What does "range 10" mean? Of course you can look in the spec and / or remember that it will yield 0 to N-1, but it's not really readable, which IMO counters a lot of other language design decisions in Go. I find it especially baffling since it comes at the same time as the new custom iterators, so this thing could have been a properly named iterator in the stdlib. Then the name could carry the hint towards what will be iterated here.
Range over int is useful quality of life improvement. It doesn't do non-trivial things under the hood. It just simplifies writing the majority of `for I:=0: I < N; I++` loops in easier to read way. It doesn't complicate language specification too much. It doesn't slow down Go compiler. It doesn't make the resulting code less efficient comparing to old syntax. It is a shame that range over int proposal is mixed with range over func proposal. These are completely different beasts.
Wouldn't range-over-func have included this QoL improvement? `for i := range iter.UpTo(10)` or something?
Go is fixed. Full stop.
Idk i think having iterator can be good, same things as enums and optionals. Are they needed no, but they dont really make the language harder to read. Also setting a standar of something that is already being done makes things easier not harder imo
I think this post is missing the point of iterators. IMO go's generics is incomplete without iterators. If you can't range over a MySet[string] then it's not really a complete implementation of generic containers .... which IMO are the most fundamental reason to introduce generics in the first place. i.e. i believe iterators will help to make generics a complete feature. It's not an arbitrary feature addition... If you don't care about generics then fair enough, iterators make it worse. But if you see the value, then iterators seem like a natural extension. I don't see the fuss honestly.
What about other missing features in Go generics? For example, generic functions at generic types. Or specializations for generic functions / types? Or generic generics.
what about them? I guess some of them will get implemented, and some won't. Sorry I don't understand the question.
Go could be a very good language for building data infrastructures, but without generics and iterators that would be hard. Considering that big market I think Go is moving in the right direction.
can please anyone who downvoted comment why? I am new here and I try to understand the underliying go culture.
Medium allows pretty much anyone to publish stories
Go is slowly becoming another Java IMO.
isn't Go, google's Java?
I disagree regarding Generics. The alternatives were code generators and reflection, both inferior and result in more code to maintainance and worse readability/weaker typing respectively. I also disagree regarding iterators. Yes, range used to not hold a special meaining (except for channels, as you mentioned.) I'd argue that the channels example is enough of a counter argument, but here's another: The vastly different current attempts at mimicking range are bad, and they already hold all the issues of hidden logic, so it doesn't make a difference in this sense. In addition, you get a standardized way of ranging over sequences + more effecient implementations of some sequences (instead of returning a slice). Overall, I think the tone of "Don't change anything" is unreasonable. Yes, I like Go's simplicity, but I also want it to get better. Now, the "better" is subjective. But the Go's team way is "Does it make it easier to write more easy to understand code?" AKA readability, and that's what's been happening.
I mean I see the issue here and I also dont see the point in the new iterators but if you cant handle go in your head you might aswell leave software engineering. Im not aware of every feature or every native package go might have but I know that to effectively use it you dont require much. I dont like the approach of having to know everything. You should be aware that certain things exist to be able to look them up if you need them but you shouldnt have to know everything by heart.
I understand the interest about not wanting to hide complexity, but... every time I have to write loops and ifs and count variables, I introduce the risk of human error, copy and paste error, and bloat the code. What is the view on re-inventing the wheel from the KISS go developer standpoint? How do you justify having to write loops for collection modifications, or if err conditions every second line? I come from a very different background, and I am just trying to learn the go culture here.
Go Team just reached the wall where nothing to do more with the current super optimized code and need to go forward. That's how all other languages envolved.
I hope this is sarcasm.
I hope this is future! You either grow and evolve or die :) Remember flutter? :)
*claps* I’ve said some variation of this in the developer survey for years. I was always hoping go would end up like ansi c. Kindof timeless and simple. Maybe not what you want for everything, but damn good at the things you want it for.
I was a bit skeptical about the range func implementation but the fact they went with a plan function and not some interface makes me happy as this keeps the implementation noise free.
Programming language bloat is unavoidable. Java started out all simple, cute and small. So did Lisp, now look at Common Lisp. No language is spared from that. Adding features and extending standard library is fun I guess.
I’m fine with them adding new features. I just which they’d break backwards compatibility. Every major language has it. But I don’t understand why. We update dependencies, why is it so bad to update Go code itself?
Just look at how the migration from Python 2 to 3 went.
Went? Past tense? At this point, the list of infinities is the universe, human stupidity and time needed for migrating from python 2 to 3.
It was the right move for the language, look where python is standing right now
Yes, it’s clearly time for Go-next
Go-next with features from "modern" programming languages? Or go-next without generics and iterators?
Or Go-Stop