Generics aren't ready for Go
drewdevault.com
drewdevault.com
Basically, this is trying to spin "Popular language missing essential feature" into "But what if it's because they're braintstorming something EVEN BETTER???"
Well, if they're brainstorming something better, then I'll wait to use your language until you solve all the basic problems first.
Plus I think the language-obsession is usually cargo-culting and signaling. All good engineers I know use and enjoy several languages. The hipster/all-talk/buzzword engineers are the ones who insist on prototyping garbage in a new language every 6 weeks and dropping it entirely thereafter.
Yet people can write distributed databases, monitoring tools, dns/DHCP servers in go. ANd they deliver stable and performant solutions with thousands of institutional users.
How come, if the basics are not solved?
So does C, C++, Java, etc. That statement is meaningless. It just means that with enough contortion, you can write some code in golang that works. But that doesn't mean mean there aren't better, safer ways to write code. As others said, you can write large systems in C, but we still see the fallouts of using a very limited and unsafe language.
And the funny things is, how do some of these larger projects get around golang's limititions? They write code generators to emulate mocking and generics, ending up with a weird mix of code that is difficult to manage. I saw this at my current employer, where they use golang for most of their backend. It's funny that I always think that even writing in Java would make the code base a lot more maintainable and even shorter and less verbose.
Indeed it's as capable as those languages in this domain. The productivity is higher though, thanks to the stdlib.
Naturally turning into name calling is easier when running out of arguments.
They happen to sell an IDE for Go.
If Java's standard library is reasonably sized, what is your idea of a bloated standard library? How often do you use SOAP? Applets? Open MBean? CORBA? Relation?
> Naturally turning into name calling is easier when running out of arguments.
I like many of your posts. This one is just gratuitous ad hominem.
You're not following the conversation. The question is "Does Go solve 'the basics'?", not "Is Go better than C, C++, Java, etc?". I noted that Go solves 'the basics' for any meaningful definition of the term, as evidenced by regularly shipping useful software; I didn't claim that "regularly shipping useful software" makes it better than other languages.
> And the funny things is, how do some of these larger projects get around golang's limititions? They write code generators to emulate mocking and generics, ending up with a weird mix of code that is difficult to manage. I saw this at my current employer, where they use golang for most of their backend. It's funny that I always think that even writing in Java would make the code base a lot more maintainable and even shorter and less verbose.
This is a fallacy. A code generator is a pain in the ass to work around generics, but it's entirely possible and likely that the efficiencies gained by Go (versus Java or other candidate languages) more than justify the losses due to a code generator compared.
It's also entirely possible and likely that people are throwing code generators at problems (like mocking) that don't require or benefit from code generators.
Ravendb...
Better get those numbers straight.
But is it an essential feature? I've written a lot of Go code and I'm perfectly fine without generics. It makes my code a lot simpler, no need to abstract everything into Thing<OtherThing implementing Stuff, YetOtherThing<Thingie implementing This or That>>. By the way, C doesn't have generics.
If you really need generics that badly for your use-case, nothing stops you from using another language.
"If you're not happy go look elsewhere" doesn't move the needle on the question "Should Go have generic" at all. It's not an argument at all.
As the author explains in the article, I don't think all languages should try to solve all problems perfectly.
Note that this leaves the possibility that a feature should not be in the language, even if it does solve a real problem.
Both arguments do not address whether the language should have a feature or not.
"Not essential" might be recast as a valid argument, but must be rephrased in terms of cost vs benefits of the feature examined wrt the goals of the language.
C doesn't have generics. Java has extremely limited generics. In both cases, it means that it's annoying and difficult for me to write a decent math library. I have to choose among making it support only one numeric type, implementing many copies by hand (one for each numeric type), or using some sort of ugly code generation tool - who knows what in Java, the preprocessor in C - to implement all those copies.
Which might not be a problem for everyone, but, for my use case, it's annoying.
(Deliberately avoiding the "generic library of data structures" use case because, while generics are what brought that to most of us (edit - in the world of static typing), it would appear that Go's handling that case just fine without them.)
Maybe I'm missing something, though. On the rare occasion that I write C code, I stick to C99, so I haven't had much occasion to use it.
It's perfectly fine for Go's answer to be, "Go doesn't have generics because generics aren't needed to solve the kinds of problems Go is designed for solving, and we are not trying to be a kitchen sink language here. If generics are something you need, please pick a language that's designed to solve the problems that you're trying to solve."
But that's a far cry from what TFA said. TFA read more to me as, "Go doesn't have generics because generic programming is a half-baked idea that isn't ready for prime time."
For example, it's why F# continues not to have ad-hoc polymorphism, despite many users clamoring for it. I'm inclined to agree with the project's maintainers on the subject. As useful a thing as it is, and as glaring as it is for a modern descendant of ML not to have it, it's hard to see how it could be added without creating all sorts of language warts.
[1] https://github.com/louthy/language-ext#ad-hoc-polymorphism
is a quote from the article, and seems to say exactly what you're saying?
By the way, C has minimal generics support since C11.
This article is wrong in many ways, but I thought I'd point out this particular one. There are many really weird warts in Go, in fact its about average in "wartiness". Here is one example https://dave.cheney.net/2017/08/09/typed-nils-in-go-2
Go biggest advantage isn't the language, its the decent documentation and standard library design. The language is a bit mediocre. I wish the Go community accepted this and moved on - a mediocre language with good documentation and well done standard library is still an acceptable contender since so many other languages get those two wrong.
The language already uses them for Arrays, Maps and Slices, plus a lot of code relies on runtime-typed ad-hoc generics with interface{}.
It's not as if Go is a language without warts... there's a lot of ugly stuff, like Iota, Reflection, the error handling, interface{} itself.
This is a legitimate question, btw. Legitimately looking for other points of view
They hear the golang authors complain about Java, that it's the only way to do things, so they think that the only other solution is to go the extreme opposite way, not even looking at real modern languages (which golang isn't) like Kotlin or even C# for instance.
It's very evident that the golang authors have no experience designing language, and didn't look in depth at what other languages did.
It is evident that Go is a better language than most thanks to the creators having deep experience in that domain.
Maybe F# would be a better choice. .NET Core and its tooling are pretty well done. C# and NET Core would be another nice alternative.
I do think you're on the right track that go's designers are pushing back hard on what they see as feature abuse in C++ and Java. C++ abuses templates and has dozens of ways to do anything that also don't interact with each other well. Java abuses inheritance, abstractions, and OOP.
go uses generics under the hood, probably the designers fear that generic's will also get abused if released into the wild. On the other hand I've never heard anyone bitch about well designed generics in other languages. Which is a tell since people will bitch about anything and everything.
Now that you mention it, I can't really blame them!
> On the other hand I've never heard anyone bitch about well designed generics in other languages. Which is a tell since people will bitch about anything and everything.
That's my opinion as well. Generics are quite pleasant, simple and a great tool to have when they're well designed.
Language abuse happens when the feature is the only available feature to implemented a particular and no other language feature allows for a better implementation.
in C++ most abuses of template are related to the missing feature "concepts". which took quite a while to get their.
If language switching is not an option, and your application requires generics and you are also required to use Go, you do have a problem. You need abuse the language and work around re-implement generics for Go.
Which can result in a very ugly development process, difficult to maintain code etc.
And nobody is advocating C++ style template metaprogramming. There are much better implementations of generics, as acknowledged by Russ Cox himself.
I think we need to be real about what are the strengths and weaknesses of each platform instead of drinking the coolaid. Otherwise we don't learn anything and the bad parts are going to find their way in the next one.
Which, ironically, Java is just superior in every way when it comes to documentation of the standard library. Large open source Java projects are well designed and very well documented, unlike golang projects.
The Go documentation as well as standard interfaces are tastefully and minimally done (for an imperative language): https://golang.org/doc/ - e.g. https://golang.org/pkg/io/ ... To my knowledge there is no equivalent of this for Java that comes close.
Compare https://golang.org/pkg/io/#Reader to this mess https://docs.oracle.com/javase/7/docs/api/java/io/Reader.htm...
Java has pretty nice generics. With Java 10 the language is now decent too.
Green threads are not the be-all-end-all solution for concurrency. They have their place, but so do event based async io.
That being said, Java is getting green threads in the form of Fibers.
> Compare https://golang.org/pkg/io/#Reader to this mess https://docs.oracle.com/javase/7/docs/api/java/io/Reader.htm....
Obviously Java's Reader interface does more work, and has a `close()` method, which golang lacks. Golang is forced to go with this way to write interfaces due to how they are implemented (sacrificing usability to get nominal typing, which is a very questionable design decision). Languages like Kotlin, Rust, Scala among others have superior solutions.
Async IO is also fine. The question is, what is your current ecosystem built on top of. AFAIK the answer with Java is definitely not async IO or fibers.
Yes, structural interfaces in Go are implemented poorly. But the standard library uses them very tastefully, putting most standard libraries to shame :) Go also has Closer, and its a separate interface - interfaces are minimal which makes them much easier to implement and more generally applicable.
So weird. Java used to only have green threads. The very name, "green threads", comes from the fact that's what the JVM called them. Literally invented the name.
The HN community is too focused on OpenJDK/Oracle when talking about Java, when there are as several JDKs toolchains across the industry, some with very specialized deployment scenarios.
Rob Pike didn’t bother to look into any of the research into type theory and programming language technology. Hence his understanding of types were restricted to Java and C++ and similar (whose type systems are an abomination), and he could not separate subclass polymorhism with inhertance from parametric polymorhism.
But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types.
That's the detail that sticks with me.
Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive.
My late friend Alain Fournier once told me that he considered the lowest form of academic work to be taxonomy. And you know what? Type hierarchies are just that.
I mean he’s openly contemptous of the academics who do research in his field, while wildly mistepresenting their work. But people eat that shit up, because ”OMG it’s Rob Pike” instead of actually discussing the underlying issues.
Yes Rob, you are a philistine when it comes to types.. (or at least were)
Maybe Mr. Pike actually has some well-deserved reputation when it comes to real-world software and engineering projects that are about handling large scale data in real time?
What are the credentials to back this up? Otherwise, the languages he makes fun of actually are used to deliver large scale systems in real time. Google is built on C++ and Java, so are most of the other top tech companies, not to mention banks and HFT firms.
Compare to Leslie Lamport for instance, and the tremendous effect he had on large scale systems and software engineering correctness.
Or are you just being disrespectful?
When it comes to complexity, large systems tend to be complex, so you either push some of that complexity into your language, to give you expressiveness and modeling capability, or you simplify your language so much (golang) such that the code base becomes complex and verbose due to repetition, not to mention error prone.
Readability? Compare:
var a int
if foo() {
a = bar()
} else {
a = baz()
}
final int a = foo() ? bar() : baz()
val a = if foo() { bar() } else { baz() }
The funny thing is, the golang code bases I worked with would be quite a bit shorter in a supposedly verbose language like Java, not to mention something like Kotlin.
Do you want a practical reason why golang is popular? Because it has Google behind its name. The language that he worked on before he was at Google, which were similar to golang, went nowhere.
Let it be said that I'm not actually a Go but a C programmer, and there might be about 1 legitimate use of this syntactic construct per few thousand lines in my code (you are free to checkout my language project from github and verify my claim). It's not that I don't know the construct, but more that most experiments with it end up being reverted again to the longer form, to preserve the rhyme and rhythm of my code.
I won't take sides, but I guess their idea was that like so many other features, this little syntactic sugar construct does not carry its own weight.
> I read the slides, but didn't hear the talk
You absolutely should hear it! The slides probably do not contain actual experience reports, opinions, and arguments.
> the golang code bases I worked with would be quite a bit shorter in a supposedly verbose language like Java
that's hard to believe. Any code samples for illustration? (I invite you to cherry pick!).
There's also something called "argument from fallacy". Either refute the points I raised, otherwise there's no point bringing up fallacies :)
> Let it be said that I'm not actually a Go but a C programmer,
I have been using golang at my current employer for several months now. That being said, that's your experience, and it doesn't necessarily mean that everyone else has your use case.
The shorter form is (1) more readable, and (2) less error prone - fact. Less code also means less room to make errors. It was pretty laughable on the golang mailing list when someone asked why there wasn't a max/min implementation for all number types in golang, someone replied why do you need it? You can just implement it yourself like so, and proceeded to write a max implementation where the comparison operator was flipped. It's quite ironic really.
> but I guess their idea was that like so many other features, this little syntactic sugar construct does not carry its own weight.
It does, it reduces the probability of error by making sure that assignment happens only once. They weigh things very arbitrarily, like how one of the golang authors doesn't think compile checked enums are worth it because hey, they're just enums checked by the compiler to ensure coverage. It shows they don't have experience with other languages, or with features that reduce error rates.
> that's hard to believe. Any code samples for illustration? (I invite you to cherry pick!).
I already listed the lack of a ternary operator or its equivalent, and this extends to other constructs which can be expressions. Java is getting switch expressions in the upcoming release, and in Kotlin, try/catch is an expression, it's quite nice. The most obvious other one is error handling, "if err != nil" checks everywhere, which makes the code base much longer.
Others include the lack of map/fold/etc functions. The code base I work with is littered all over the place with functions to do what effectively are maps or maps+filters. Those functions end up being 8 lines or so, whereas they could be fit in 1-2 lines, inline at the call site, without the reader having to jump to the function implementation. This gets tiring very quickly, and makes it take longer to understand the code at hand.
Another example is needing to explicitly assign to a temporary variable if you need to take its address to pass it as an argument.
a := foo()
b := bar()
c := baz()
qux(&a, &b, &c)
qux(&foo(), &bar(), &baz());
qux(foo(), bar(), baz()); 1. Rob Pike doesn't have a strong grasp of type theory.
2. Rob Pike is an accomplished programmer.
1. That shape over there is a square.
2. That shape over there is blue.
1. Go doesn't have generics because the authors didn't have strong grasp of type theory.
2. Go doesn't have generics, not from a lack of knowledge, but because the authors' real world software engineering experience had shown to them it wasn't important.
Though, in that case, I think the argument is more like:
1. That shape is equilateral
2. That shape is equiangular
So, even with the alternative statement, I still see no argument here.
I have used Go extensively and would disagree with the idea that the lack of generics in go was ill-informed (and therefore a mistake). I find that Go's limited number of features leads to simpler libraries that are much easier to comprehend and use effectively. And in situations where I previously would have reached for generics I am forced to find a different approach and the end result is often better. Yes it does have its drawbacks and is not a perfect solution, but as far as engineering decisions go, I feel it was a successful one.
What do you mean by "real world software engineering experience", Acme or Plan9? These are silly academic projects with tens of installations at best.
I think there is a tendency to create an unneccessary barrier between ”real-world” software and ”useless” academic theory. I’ve spent most of my career working with java, php, python and js, and I absolutely agree with Rob that class hierarchies and inheritance is a bad way to program, but there’s a lot more to types than oop type systems with limited type inference.
It’s of course always a trade off, which is why I build frontends in Elm, backends in Haskell and play with proofs in Agda, but why throw away types altogether?
Software that runs the world utilizes parametric polymorphysm in C++, Java, Ada, D, Swift, OCaml, Haskell etc, hell, even C [1].
I also tend to consider some mission critical Ada/C++ software a real engineering, not some webshit.
[1] https://github.com/jiixyj/libebur128/blob/master/ebur128/ebu...
For example, in the absence of any practical exposition demonstrating that the module system solves problems that other systems don't, you can quite comfortably (and cynically, sure, but please let me have my fun) choose to interpret the analogy along these lines: General relativity is well-established, reasonably well-understood, and is essential to making a sizable chunk of the modern world (e.g., GPS) work. Whereas nobody's been able to demonstrate a working GUT yet, so currently its main practical use is as fodder for books and TV specials.
But to answer your question go has really mediocre support for a wide variety of problems. Some that burn me a lot is support for future/promises and support for modern lock free algorithms.
So you end up either writing non-optimal replacements, losing type safety or in some case code generation is used.
This doesn't make sense in Go. Nothing is asynchronous in Go, everything is blocking. You use goroutines to execute multiple tasks at the same time. That's a big part of what makes Go simple: it's a lot easier to understand sequential code than spaghetti callbacks and promises (it's somewhat similar to async/await in the JavaScript world).
Go’s unsophisticated type system makes it difficult to write a good standard generic data structure library such as a future/promise library.
That leads to people either writing a poor replacement, not using that style, or losing type safety. This is precisely what you would predict upon learning golang doesn’t have user defined genetics & ive had it bite me more than once in real projects.
I think people are used to futures etc, that's why the new concept feels strange.
I think the goroutines and channels are the biggest features which compensates for generics.
Goroutinue are very light weight. Zero size channel works like promise
If you really want high performance with many different types of a function, its a case of copy-paste-modifying your code.
Its a language that is straight-forward, its the antitheisis of tmtowtdi.
Golang use duck typing. It is very flexible and very simple. (Some times too simple)
Whereas all the other kinds of generics, I believe, can't offer this quality. They require a lot of machine code instanciations (like C++'s template system). Or at least, in the case of virtual functions ("dynamic polymorphism" with VTables), they cause more brittle abstraction boundaries. Think how in C++, when definining a class, you need to expose a lot of internal details in the header file -- list all the private member functions and fields, etc. This has lead to the so-called PIMPL idiom which is exactly what you do in Go or C.
Even on C++ this is be eventually a thing of the past, after modules get finally adopted.
Using how C++ currently does as argument against generics is a pretty weak argument, given the various ways to implemente them since CLU and ML introduced generic programming into the world.
> Using how C++ currently does as argument against generics is a pretty weak argument, given the various ways to implemente them since CLU and ML introduced generic programming into the world.
I would be interested to know how you think the problem of tighter coupling (a.k.a dependencies) is solveable, because I don't see a solution. For example, I'm pretty sure that typeclasses in Haskell are implemented with either of those two approaches I've mentioned depending on the situation.
(Maybe it's possible if we require more information for the linker? I haven't thought through this.)
It is solvable by not sitting in an ivory tower using C++ and Java as the typical examples why Go won't get generics, and instead engage with generics friendly communities.
Personally I care about true, hard dependencies much more than that "exposed for everyone else to see" fluff (the latter being only a subset of the former). Probably that is because I don't do business software, don't work in big teams etc.
What really matters to me is reducing hard technical dependencies, and recompile times and ABI compatibility may only be the two biggest reasons.
You're probably aware that I program predominantly in C, and "sitting in an ivory tower" is not a word that I would apply to typical C programmers. I wouldn't apply it to Java programmers, either. It's normally a term for the academic world, the world from which languages that focus on type theory originate.
C does provide minimal support for generics since C11, with improvments planned for later standard revisions, as anyone that works predominantly in C should be aware.
And yes I am aware that I kind of reversed the meaning of the term, but that is how it feels all the Luddite arguments against generics.
Just because there are plenty of old tech languages, which many in the generics crowd have a large experience using, doesn't mean we should keep using such approach at expense of productivity.
They are actively looking for something that doesn't suck. Aren't they?
> C does provide minimal support for generics since C11, with improvments planned for later standard revisions, as anyone that works predominantly in C should be aware.
Not sure what was your intention behind that statement. But of course I'm aware of C11 Generics. And they might be nice for a generic min() and max() and similar but other than that honestly I have little use because types are not values and in C, types are not elevated to be much more than simply physical layout. Whenever I've tried to encode meaning in types in any language I've failed spectacularly. Feel free to make Oddintegers and Evenintegers all day long if that's what makes you happy.
> And yes I am aware that I kind of reversed the meaning of the term, but that is how it feels all the Luddite arguments against generics.
Let's get a life and not spend all of our time raging against people doing different things differently. At Google, I'm sure Go does solve real headaches they have with C++ ((re)compilation issues being only the worst offenders) and Python (performance...). And probably it does so better than any other language can. Because, Google is still primarily an engineering company, not a hipster company, nor a language-obsession company.
It looks more of "we are working on it excuse" to keep people at bay.
Rob Pike has done a presentation last year where he stated that he doesn't have anything to do with it and is very sceptical of it being ever added.
So WIP is kind of euphemism.
> Not sure what was your intention behind that statement.
That even languages born before generics are willing to move forward.
Google is majorly a Java, Python, C++ shop. Go is usually more outside than internal Google projects.
If we reduce Go lack of features to stuff that C doesn't provide, maybe bounds checking, modules and GC aren't required as well.
As for complaining, projects like Docker and K8s ensure that those of us that rather not use Go, have to deal with it in some form anyway.
Well that was the initial basic design frame: A systems programming language that removes some of the headaches of writing distributed systems software with the use of a GC and Channels/CSP.
It was intended from the start to have more features and tradeoffs than C has, and it even backed up pretty quickly from trying to be a competitor in the (not-distributed) systems programming space, didn't it?
> That even languages born before generics are willing to move forward.
C11 Generics are a pretty limited feature, basically a central switch on types instead of values. They are not a big deal. And maybe Go decided against them because Go has RTTI. In any case, C11 Generics are decidedly different from what many people expect from a Generics in Go.
> As for complaining, projects like Docker and K8s ensure that those of us that rather not use Go, have to deal with it in some form anyway.
Dude... 1) They are not Go. 2) If you don't like them don't deal with them. 3) Don't make an elephant from a mosquito. 4) Show us some of your beautiful systems software written in perfect OOP style in languages from 1975 already! We need real world proof that there is a supreme super-typesafe OOP way with functional bells that solves all of our problems!
Also some would say that Go is actually from 1968.
Generics specifically refer to the parameterization of types using types. Go doesn't have user defined generics.
The only reason in C++ why you need to define all the "internal details" in the header file is because the compiler needs to know the size of things. You can write completely template free code that requires all your classes to be defined in headers or you can litter your code with templates, put pointers everywhere and place all your classes outside of headers. It has nothing to do with generics and everything to do with how the rest of C++ is designed.
Other than that, I don't think we're in disagreement here.
That said, there are still cases where generics would be useful; however, a lot of the people who complain about generics missing from Go tend to exaggerate the extent to which this is a problem, "You can't ship software in a language without generics!". In the case of Go, you have something like 97% type safe code compared to the many, many successful Python and JavaScript programs that ship with 0% type safety. And lastly, one thing that you can't really appreciate without trying Go--the lack of generics/expressiveness and general simplicity of the language largely means everyone writes the same boring, predictable code, which means you can pretty much pick up any project on GitHub or your own code from years ago and understand it almost immediately. This isn't to say that generics aren't worth it; only that the debate kind of sucks because one side is ignoring that rather significant point.
Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code...
As you said, you can already have generics using unsafe solutions. Some built-in types have generics. Most people just want this type safety.
interface{} does feel like a temporary and clunky solution for people used to generics.
> And lastly, one thing that you can't really appreciate without trying Go--the lack of generics/expressiveness and general simplicity of the language largely means everyone writes the same boring, predictable code, which means you can pretty much pick up any project on GitHub or your own code from years ago and understand it almost immediately.
I don't get this argument. Why are generics more complicated than other features? Has this hypothesis been tested?
I personally find that using generics is way easier and faster than interface{}, Reflection or code generation. Also simpler and less error-prone than features from other languages like inheritance, operator overloading and unbounded coroutines.
As a C programmer (which doesn't have generics either) I can't recall the last time where that additional safety was being missed. Whenever I fed the wrong argument in for a void* parameter (which is rare enough), the program crashed on the first try and the problem is obvious. Plus, Go even has runtime type checking to catch this sort of problem with 100% probability at runtime (I think - I'm not a Go programmer).
So I don't think there's a valid problem here.
Maybe the more serious problem is that people want to be able to quickly say "I want a Fibonacci-Tree<K,V> for types K and V"?
Except when it isn't. Except when it crashes in production. I believe this is the kind of situation people are trying to avoid with type safety...
> Maybe the more serious problem is that people want to be able to quickly say "I want a Fibonacci-Tree<K,V> for types K and V"?
That's uncalled for, isn't it? There's a lot of non-toy problems solved elegantly and pragmatically using generics. I personally enjoy how Entity Framework uses it.
Yes, but by far more important are bounds checks. Go has bounds checks. As a C programmer I don't get to enjoy them (I get to write simpler, non-GCed, object-cruft-free software in exchange). Out of bounds reads and writes consume far far more of my time compared to void pointers. (And even OOB are not that time consuming).
> That's uncalled for, isn't it? There's a lot of non-toy problems...
Yes, the Fibonacci was a bad example (couldn't use Map because Go has that). It wasn't meant in a mean way.
Sure, but I'm failing to see why having other checks isn't important. I mean, generics aren't hard to use... They're way easier to grasp than Channels (a great feature), and easier to use daily than go generate. I dunno.
Generics are abstract. They lead to bad error messages. They make the language more complex. They require syntactical support as well as special magic under the hood. Look for various resources by Russ Cox and Rob Pike (and maybe other Go designers). For example https://go.googlesource.com/proposal/+/master/design/go2draf...
About your other points: nope, generics wouldn't remove simplicity in the language itself. They would mostly legitimize with type-safety certain idioms that are already present in current Golang code. And the terrible error messages of C++ templates are not really a good example. There are much better languages now when it comes to generics.
I suggest that maybe you try looking into other legitimate uses of generics? The Fibonacci-Tree<K,V> example you gave earlier is unrealistic, and the other example being thrown around here, STL, is too complex... There are lots of legitimate reasons for someone wanting generics in a language, and nobody is advocating for them out of bad faith, or wishing to kill a nice language with feature bloat :(
For the rest... Yes, it is very ugly. But the standard generic does not fit very well with go type system, so....
Luckily, go is very simple. Even ugly bit are not hard to understand.
Why not? Generics in Arrays/Maps/Slices fit perfectly in the language, and don't feel weird at all in Go.
They are widely used data structures and so, in the opinion of the Go creators, justified separate specialized implementations in the Go compiler. In other words, there isn't actually a Generics system in the language (I don't actually know this, correct me if I'm wrong). For various reasons. There are quite a few talks and design docs from Rob Pike and Russ Cox if you look for them.
And generics aren't just for abstract data structures, there are other uses as well.
func (p *parser) tryIdentOrType() ast.Expr {
....
case token.MAP:
return p.parseMapType()
Yes, you can use any type as keys and values. But that's a far cry from an abstract system that lets the user define any parameterizable data type. And that's for good reason: By hardcoding just the most important parameterizable data types, the problems that an abstract system would bring can be avoided.
It's not a strawman; I run into this tired argument too often, so I wanted to call it out to avoid the predictable digression. There is a strong case for generics and I empathize with "`interface{}` is clunky..."; I just want a debate that recognizes the tradeoffs.
> I don't get this argument. Why are generics more complicated than other features? Has this hypothesis been tested?
I don't think I made the argument that "generics are more complicated than other features". My argument was that Go code is boring and predictable (consistent). It stands to reason that boring, consistent code is easier to read and understand than novel and/or mixed-paradigm code. Generics increase expressiveness, which pretty much by definition means fewer rails to keep code consistent. I'm not arguing that Go's current feature set strikes an optimal balance between expressiveness and consistency for all problems; however, it does do a pretty good job and we should count the costs as well as the gains when considering a new feature.
I agree that C++ template meta programming might be a bit too much for Go (or for any language, for that matter), but generics as they are implemented in C# and Java are pretty cool and simple.
IMO, if generics were to be ever added in Go they should just be a simple replacement for some uses of interface{} and code generation. I mean, the complexity is already there... why wouldn't generics simplify those use cases?
For example, in Go, there is no functional-vs-imperative conundrum; it's only imperative. And I appreciate that there are multi-paradigm languages like C# and Java that allow for both (better for experimenting with new patterns and paradigms); however, I also appreciate that there are languages like Go that take a more conservative opinion, and I think this is more practical for software development.
But why? There's nothing in generics that would make Go non-consistent. In fact, there's already generics in Go in Array/Map/Slice, and they're not inconsistent with the rest of the language at all.
> For example, in Go, there is no functional-vs-imperative conundrum; it's only imperative
Why would generics break that? Funcional programming and type-safety/polymorphism are orthogonal concepts. IIRC, generics were introduced in Barbara Liskov's CLU language, which is imperative.
It sounds to me that most people advocating generics in Go are having a pragmatic/utilitarian approach, while people against it are opposing it from a purely ideological standpoint not grounded in either theory or pragmatism.
And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :)
Even if I were making a positive assertion like "generics costs more than it gains", that would be a pragmatic viewpoint even if it's incorrect. But I'm not even making that assertion, I'm merely unsure and would like to be persuaded otherwise (and I find people with experience on both sides of the fence to be more credible than those without that experience).
> Why would generics break that?
Because "generics" as a feature suffices to support multi-paradigm programming. It explodes the solution space, creating many solutions for problems that Go's type system is perfectly capable of dealing with (~97% of the problem space in practice according to my experience) while permitting new solutions that Go's type system must currently punt on (~3%). We should be able to roughly agree on this even if we disagree about the degree to which multiple solutions is a problem relative to the advantage of the additional type safety.
That's fair! I'm really sorry I typed that, it was completely uncalled for and I wasn't referring to you specifically!
> Because "generics" as a feature suffices to support multi-paradigm programming.
I don't really agree with that. Despite being widely used in functional languages, they aren't really a "functional" thing, as much as static typing is.
In fact, I'd argue that Go already has a feature that is much more important and representative of funcional programming than anything else: higher order functions. [1] With higher order functions (and recursion!) you can implement pretty much anything functional.
Generics don't really allow for much more than something like interface{} can already give. The problem is that interface{} comes with both runtime performance and type-safety penalties. Generics could fix that and help programmers arrive at better/safer practices, IMO.
My point is: with generics the language could be much simpler and we'd have to rely less on (IMO) complicated/unsafe features like Reflection and interface{}.
[1] http://aquaraga.github.io/functional-programming/golang/2016...
Yes, there's a class of programs for which this is not the case, and for which I might want some sort of fancier guarantees. But those don't tend to be the sort of programs I write. My hobby projects are in Common Lisp; I used to professionally program in Python and JavaScript (for my sins) — Go is strictly better than those in the static-typing department.
Would I like generics? Sure, I can see how they'd be nice. But I remember how templates in C++ turned into something nasty, and I've written Java professionally too: I like how clean & simple Go is. I can write code, then be done with it, and come back a year or two later and not be mystified. It's a decent little language for getting stuff done.
- container/list.List which uses its own Element with internal pointers and interface{} for values
- write a type-specific implementation (not generic, but no runtime type assertion)
- write your own implementation using your own node / element interface type (maybe your list is generic to types that support io.Writer - generic for some use, but if you need access to specific types, you're back to runtime type assertions)
- write your own interface{} implementation (constantly needs runtime type assertions)
- use code generation (maintenance is harder, potentially non-standard tooling / build steps, but hey - no runtime type assertions)
- use a slice instead of a list (Go's version of vectors / dynamic arrays) - still requires some implementation, but the language has a lot of built-ins that make this easier. Depends on use. If you are doing a lot of insertions in the middle, this may suck, FIFO may suck and you need to be careful about not doing append()-shift and effectively leaking memory, LIFO this is dynamic and gives you good cache locality. Up shot is no-runtime type stuff and at least the slices themselves and the built-ins are generic.
Uhg such programming language Stockholm syndrome. You could apply this fallacy to any feature. The lack of modules and a performant garbage collector also bred creative solutions in previous Go releases, but that doesn't mean that adding those was a bad idea.
Until we find an elegant solution for the generics issue, it's better not to have them.
This is the sort non-adhominem adhominem attack that makes these debates so tedious.
Obviously, someone deciding not to use Go for lack of generics after giving it a serious try would end up not being a Go user. Does that invalidate their opinion?
The logic of this argument is strikingly cult-like. Any criticism coming from non-adherents is automatically disregarded on the basis of it coming from non-adherents.
The task that lead to my decision to quit was to write a data serialization systems for datastructure that I didn't know in which version of junk they were expressed, by interfacing with the broken standard library. The serialization system was to replace another serialization system that somehow didn't quite work. No wonder, it was broken code, and I couldn't see a way to write non-broken code to solve an unsolveable problem.
What's nice about Delphi is that the compiler is quick and it has a beginner-friendly IDE with a visual GUI creator (no selling point for me). That's about it, AFAICT.
interface{} is already promoted to heap, they are pointers, all you need is to swap interface with type parameter and add a couple of hundreds lines of code to the type checker. The theory is all in the books and there are dozens of compilers implementing it in practice.
It seems crazy to me that language designers of modern statically typed languages wouldn't go for the state-of-the-art. I see the comments about simpilicty, but generics makes [working with abstract types] simpler (in my humble opinion, of course).
The generics one, I've seen plenty of pixels spilled on, and I've come to accept that I won't really grok the debate unless I spend some serious time programming in Go. What about the module system, though? Can anyone explain or share an article on what's so great about its module system?
Go puts it's head in the sand and and handles the problem like it's 1970 with the "void pointer" way of thinking. That's fine if you're using a dynamic language (ie python, lisp) and firmly decided your trade offs with regards to types and performance. But if you elect to use a statically typed language, it would be nice to reap the benefits.
Modern C++ is still the only way to go for serious software. Rust maybe in the future as the compilers improve. Go is a no no-go.
Please define serious software.
Most people are totally confused by generics, i personally don't have a problem using them or not. At the end of the day, its just template metaprogramming.
Generics aren't a cure-all, they merely duplicate code and change the type. Its not much better than copy-paste and replace the type names.
Nobody ever said that.
> . Its not much better than copy-paste and replace the type names.
Yes it is. You let the compiler do the job, instead of doing it manually.
There is no difference whatsoever between the same function duplicated with different types.
Don't be obtuse, nobody ever said "Generics are a cure-all".
> There is no difference whatsoever between the same function duplicated with different types.
Yes there is, it's called polymorphism.
Yep. Go is a hipster language, even if you don't like it.
I don't feel like arguing over a word that has become essentially meaningless over time, but I think you have seriously misunderstood what hipster means or was once supposed to mean. Either that, or you don't really know about Go and are just judging it by its marketing's design aesthetics (Gopher, fonts etc. following a trendy googley style).
I think you're just upset about the choice of the word hipster but as with all words it's a shortcut to actual meaning. It was intended with a hint of playfulness and not intended to make you feel bad, even if you don't agree with the choice of word.
I can't even understand how you can be constructing such a statement. "In fashion" and "mainstream" are pretty synonymous to me. In consequence, the statement is contradictory. Hence, No, I am clearly not trying to say that.
> I think you're just upset about the choice of the word hipster
No I'm saying that the team behind Go is just really considerate and principled. They don't follow all the latest fads, simply because those fads are the reason why so many other languages suck and projects written in them become giant unmaintainable hairballs.
They are engineers (label them conservative if you like). Not hipsters.
I don't miss them - it's just a different way of programming but I've not ran into a problem that I couldn't overcome because they are missing.
OTOH, I've shot myself in the foot quite a few times with Generics.
Honestly, just _try_ it for longer than an exploratory session. Try to build something big with it, and see if you still miss it.
But basically lodash is my bread-and-butter. Could such a library even exist in a language without generics?
Program into a language, don't program in a language.
The functional approach is just one way to solve the problem. Also, as a side-note, when I program at home I'll often take a functional language. It's just a different way of programming and I do like FP (Haskell mainly). But Go is different, not worse or better.
Because hybrid is objectively better than only supporting one.
(We had something similar happen).
Or that it's ludicrous for any statically typed language to not have generics.
> It’s small and simple, and every detail is carefully thought out > Nearly all of Go’s features are bulletproof > my opinion are among the best implementations of their concepts in our entire industry
Uh huh.
> You could write a book called “C++: the good parts”, but consider that such a book about Go would just be a book about Go
Or it could be one-liner: "easy concurrency".
> simplicity and elegance are now the principles I optimize for
Doesn't everyone who cares? The problem is that elegance and simplicity, like beauty, are in the eye of the beholder.
To me, generics increase elegance and simplicity.
> If you’re fighting Go’s lack of generics trying to do something Your Way, you might want to step back and consider a solution to the problem which embraces the limitations of Go instead
So pretend it's the 70s and use void* (interface{})?
If Go had a least unions, it would be a bit less painful to describe a range of finite types while keeping things strictly typed in functions and methods. Unions are a limited form of type polymorphism in a garbage collected language.
Any example where you have a better solution than using generics?
But it's very easy to spread that Go code into tens of Kloc.
The amount of error handling and if constructs make me feel as if I am readying assembly: predictable AF, but it doesn't help because the volume of the code is huge.
var a = n1;
if a < n2 {
a = n2
}
var a = max(n1, n2)
I still want something more powerful for error handling like a type that if it is ever assigned non-nil the method returns immediately.
var err autoreturn error
rslt, err = pkg.MaybeError()Design choice. You can't have both.