Has the Time Finally Come for Generics in Golang? (thenewstack.io) 60
An anonymous reader quotes technology columnist Mike Melanson:
The debate around adding generics to the Go programming language has been going on for years now, often with much resistance, but it's starting to look like one proposal finally has some backing and general acceptance from the greater Go community — much to the surprise of some involved.
Introduced this week in a blog post looking at the next step for generics, penned by Golang team members Ian Lance Taylor and Robert Griesemer, the first update in nearly a year on the topic explains that the generics design draft previously submitted for feedback has been refined, resulting in an updated design draft... For the time being, the team has introduced an experimentation tool that "permits people to type check and run code written using the version of generics described in the design draft" by translating generic code into ordinary Go code. It is meant to give users a feel of how the proposed design would, if accepted work, and they note that it will be implemented differently if so.
As for the proposal itself, it offers several levels of detail, from an abstract, to a high-level overview, to the full level of detail you might expect from such a document. As with everything Go, the design is intended to be fully backward compatible with Go 1, and the authors note that "as the term generic is widely used in the Go community, we will use it below as a shorthand to mean a function or type that takes type parameters.
"Don't confuse the term generic as used in this design with the same term in other languages like C++, C#, Java, or Rust; they have similarities but are not the same."
The article also notes that Go's package repository is now open source.
Introduced this week in a blog post looking at the next step for generics, penned by Golang team members Ian Lance Taylor and Robert Griesemer, the first update in nearly a year on the topic explains that the generics design draft previously submitted for feedback has been refined, resulting in an updated design draft... For the time being, the team has introduced an experimentation tool that "permits people to type check and run code written using the version of generics described in the design draft" by translating generic code into ordinary Go code. It is meant to give users a feel of how the proposed design would, if accepted work, and they note that it will be implemented differently if so.
As for the proposal itself, it offers several levels of detail, from an abstract, to a high-level overview, to the full level of detail you might expect from such a document. As with everything Go, the design is intended to be fully backward compatible with Go 1, and the authors note that "as the term generic is widely used in the Go community, we will use it below as a shorthand to mean a function or type that takes type parameters.
"Don't confuse the term generic as used in this design with the same term in other languages like C++, C#, Java, or Rust; they have similarities but are not the same."
The article also notes that Go's package repository is now open source.
No. (Score:3)
No, the time for generics was way at the beginning.
I also love the comment about generics being different from the ones in C++, Java, C# and Rust. All of those have pretty different models of generics.
Re: (Score:1)
Re: (Score:2)
Between my 27 year job as an IT director and my current job that's strictly software development, I spent about 18 months fixing other people's years old code.
I was pretty self-confident, and was taking projects in a number of languages (C++, C#, Java, even one in Rust). When switching to a different language, there was nothing, and I mean NOTHING, that gave me more grief than generics, inheritance rules, interfaces and obvious, hidden and even deliberately obfuscated macros for dealing with those.
Now, I
Re: (Score:2)
C++ is somewhat different though, in ways that are both powerful, and subtle/tricky. To begin with, C++ generics are Turing Complete, which sprouted a whole new type of programming (Template Metaprogramming).
Re: No. (Score:3)
C# copied Java right at the start, but since then I cannot think of any java feature it has copied.
Re: (Score:2)
C# is a great language, but the community is awful, mainly because of how many people you will meet who are actually proud of their ignorance. Things like, "I don't need to know that, the library maker figured it out for me." True, but that's nothing to be proud of, and the library maker is better than you at programming.
Re: No. (Score:2)
Not only are those not language features, theyâ(TM)re not even official libraries.
Again: what java features has c# copied?
Not much to copy (Score:2)
Java went stagnant for many years.
But Go is just poor man's Java/.Net with third rate garbage collection. Its main appeal is that it is better than C++.
Re: (Score:2)
"stagnant" is one way of saying it..
another is saying that it had a coherent design that people have thrown out the window just to please people that want just a ton of features in the language.
Re: (Score:2)
Not only are those not language features, theyâ(TM)re not even official libraries.
Again: what java features has c# copied?
Well, while its true that C# copied Java.
Java bucled to pressure about generics, autoboxing, and a few other features that probably include Java 14's records.
But autoboxing / unboxing was the big one.
C# from the get go was of the "more features is better" camp. Java used to have a coherent design and shied away from just adding stuff because the other guy has it.
That seems to been lost today. I personally, don't think languages should be like applications where "more features" makes you better.
We don't need
Re: (Score:3)
Java and C# keep copying each other, so it's not surprising they are the same.
Java generics are done with type erasure. Generics in C# don't. I think they're dramatically different in their expressiveness and performance.
Re: (Score:2)
Re: (Score:2)
When I got a C# job after a decade of programming Java, the differences in their generics were responsible for a fairly high percentage of my early bugs.
Re: No. (Score:2)
Can you elaborate?
Re: (Score:2)
It was a long time ago. The thing which I particularly remember catching me out was that in C# Foo<Bar> and Foo<Quux> are different classes, but in Java they type erase to the same class, so if you want to e.g. use a static variable to count instances and assign each instance a sequential ID, in Java you have one counter but in C# you have one counter per value of the type variable and you need to inject an ID generator factory if you want all of the IDs to be distinct.
Re: (Score:2)
To begin with, C++ generics are Turing Complete
So are Java's, apparently.
which sprouted a whole new type of programming (Template Metaprogramming).
Oh, come on. You couldn't have said that with a straight face.
Re: No. (Score:2)
Template metaprogramming is just a really really ugly pure functional version of Haskell or Scheme or Lisp
Re: (Score:2)
Template metaprogramming is just a really really ugly pure functional version of Haskell or Scheme or Lisp
It's much closer to an insanely pure version of Haskell without lazy evaluation than the other two I think. Like the version of Haskell you teach the comp sci fundamentals with where nothing is built in and you construct everything from first principles.
And template partial specialisation is really like Haskell's pattern matching.
Re: (Score:2)
which sprouted a whole new type of programming (Template Metaprogramming).
Oh, come on. You couldn't have said that with a straight face.
What's hard to believe about that? Have you not seen/used template metaprogramming? It is definitely a very different sort of programming, often focused on doing much of the computation at compile time rather than run time.
Re: (Score:2)
Re: (Score:2)
Because it's *not* "a whole new type of programming". This has existed for half a century. But of course, every ten years the programming community reinvents ancient things and claims them for their own with no knowledge of what came before. I don't know if it's anterograde amnesia or just influx of new people, but as Alan Kay said, programming is apparently a pop culture, not a field.
I imagine you're comparing it to LISP macros. It's quite different. I've been a professional programmer for most of the last half century, and I haven't seen anything I'd consider to be similar.
Re: (Score:2)
In fairness, C++ didn't have templates at its beginning either.
Re: (Score:2)
Templates were introduced just six or seven years after C++ was invented, and that was largely for lack of technical expertise at the time of initial creation, according to Stroustrup.
It seems to me that the designers of Go had a bit too much disdain for C++, and so ended up refusing to adopt some of C++'s best / most powerful features (IMO), just because they were associated with C++. For good or ill, in the designers' minds, that meant "no generics". I've even seen the lack of generics touted as a *feat
Re: (Score:2)
I've even seen the lack of generics touted as a *feature*, which has always seemed a bit weird to me.
honestly, the whole complexity of generics (which is quite a bit, specially in c++) is just there to avoid using void pointers as arguments. because apparently programmers can't be trusted to pass correct arguments, and functions supposedly can't check for them. the idea has never convinced me either, and i think they're a bad trade off.
i know, i know, that's heresy, but that's just how weird i am :)
Re: (Score:2)
You're greatly underestimating what C++ templates can do if you're just using them to avoid passing void pointers. Sure, Java generics don't do much more than that, but C++ templates enable so much more, especially now that we have variadic templates.
I don't miss generics in (traditional)Visual Basic (Score:2)
Having static typing is critical, as JavaScript, Python et. al. are belatedly discovering.
But having dynamic casting also does a pretty good job. The problem with Java is that you needed to cast everything explicitly with ()s. That makes sense for C, because there is not run time type checking. But it was always overkill for Java.
Visual Basic actually hits a sweet spot. It keeps the language simple by not having full generics, but you don't miss them because you do not need lots of pointless () casts in
Re: (Score:2)
Yet it is all dynamically typed. And you still get 95% of the benefit of static typing.
A language with an expressive dynamic type system is certainly better than one which is merely unityped or "duck-typed", with implicit conversions everywhere and not even a runtime type check to validate user's expectations. However, given similarly expressive type systems, the benefit of static typing is that it is possible to prove that the types are correct statically—i.e. for all possible inputs, without actually running the program. How does dynamic typing get you even 1% of that benefit, much le
Re: (Score:2)
You miss the point. Visual Basic is not a dynamically typed language like JavaScript. It is mainly statically typed in the sense of Java, but like Java has an Object (and Variant) type which can be abused.
In practice, VB's normally static but sometimes dynamic typing gives you 95% of the benefit of Generics at 5% of the complexity. Particularly as VB arrays are dynamically sized. Most (but not all) generic types are used for collections.
Re: (Score:2)
I admit I haven't worked with Visual Basic much since the pre-VB.Net days. My recollection is of a language where the types of variables can optionally be declared but are not strictly enforced (i.e. almost everything is treated as if it were a plain Object). Perhaps that has changed, but then again you did say "Visual Basic ... is all dynamically typed." Also, I can't help but feel you're moving the goalposts a bit since before you said that dynamic typing gives you "95% of the benefit of static typing" bu
Re: (Score:2)
Nope. If you declare a type in VB that type is enforced.
Generics does give you something that VB cannot do. But what I am saying is that it is not that important. Without generics, you still get statically typed dynamic arrays (aka C++ vectors). But you do lose some other thing that just end up only dynamically typed. But I doubt that the complexity is worth it.
Re: (Score:2)
Off topic, but interesting .sig, and correct. That said, speaking out against cancel culture is also free speech (and free market).
Re: (Score:2)
If he had any integrity he'd *rightfully* fear the free market instead of playing the idiotic "the other team loves it so its ok to (hypocritically) love it to make a point" bullshit game.
Sorry, it's neither interesting nor correct.
Re: (Score:2)
Off topic, but interesting .sig, and correct. That said, speaking out against cancel culture is also free speech (and free market).
Thanks! I mean yes there's more subtlety than I can fit into a pithy signature.
Re: (Score:2)
No, the time for generics was way at the beginning.
I also love the comment about generics being different from the ones in C++, Java, C# and Rust. All of those have pretty different models of generics.
Agree.
Have you tried to recover the type of a complex parameter (anything struct-like) passed over channel in Go after the type has been lost because the channel is handled by Select? Try that. It will show you exactly what an abomination of a language it is without Generics.
We need a more generalized rule (Score:3)
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
— Greenspun's tenth rule of programming
Re: (Score:1)
I was going to say why not just go with a fully developed Lisp-like macro system, but I think you beat me to it. C++'s templates are a big part of what turned me off on that language, aside from the "kitchen sink" thing it has going on. I'd rather have powerful macros, which I'd use judiciously and infrequently... and... there's the problem. A lot of people would probably end up writing mostly macros, and it would be hard to decipher.
Re: (Score:3)
Generics in C++ ruined that language. It was a switch within a few years from an object oriented language into a generics language. They're just smart macros being used by people who don't realize these are smart macros. With Lisp it was much more obvious that all this code is getting expanded, whereas C++ seems designed to hide that underlying complexity and side effects of everything. The irony is that many of its features are intended as a means of rapid prototyping except that the language these days
Re: (Score:2)
Indeed, and if they add generics I'll probably just stick to C for new projects.
It is only bug-ridden and slow if you choose new-ish libraries instead of stable ones.
I really enjoy Golang for implementing network services, but not having generics is one of the advantages. Indirection is not an advantage in this problem space, as Perl proved when it was the popular language in this problem space.
Re: (Score:2)
The moderators have had a humour fail.
Well now (Score:2)
This definitely qualifies as News for Nerds!
Re: (Score:3)
Well it isn't Matt's Script Archive, that's for sure.
The first question to ask in this case (Score:3)
If your feature does not favorably align with either question, it probably won't get implemented.
Inheritance? (Score:2)
How about inheritance?
Re: (Score:2)
No. Learn interfaces. Next question.
Re: (Score:2)
Without inheritance a lot of developers will just stick with Java.
Re: (Score:2)
Anything that would otherwise be in Java should still be in Java. If Java was a good choice before, Golang would be an awful choice anyways.
This is a systems language for network services. The normal choices are C, C++, or a scripting language.
Re: (Score:2)
This concedes an awfully large chunk of developer mind share to Java, just to make some dubious philosophical point. It certainly keeps me from going all in on golang.
Re: (Score:3)
Inheritance?
It's mostly an anti-pattern.
Re: (Score:2)
Explain?
Inheritance is a wonderful thing. It leads to simpler code. It's intrinsic to a big chunk of the Gang of Four book.
I've used it successfully to create maintainable working code on many many occasions. Sorry.
Re: (Score:2)
Re: (Score:2)
When you use inheritance for anything more than trivial example programs, you tend to end up with issues like the "fragile base class problem".
From the Wikipedia article on inheritance:
Reportedly, Java inventor James Gosling has spoken against implementation inheritance, stating that he would not include it if he were to redesign Java.[17] Language designs that decouple inheritance from subtyping (interface inheritance) appeared as early as 1990;[19] a modern example of this is the Go programming language
Re: (Score:2)
Fans explaining away a language defect.
Better type interoperability would be good (Score:2)
While I'm a fan of type safety in general, not considering compatibility between types is taking things to an absurd length. I can understand why e.g. not making a float64 interoperable with a float32 without an explicit cast so that the caller is clear on what they're doing, but there is exactly zero reason why a 32-bit value can not feed into a 64-bit representation of the same exact base type.
Typed languages (Score:2)
If you use a static-typed language, you will eventually feel the draw towards generics. Generics fill a need.
Hopefully any language designer will look at C#'s generics rather than Java's, which is pretty horrible.
I have a theory that Java developers abandoned Java to dynamic languages like Ruby, Javascript & Python, b/c Java generics are so bad.