7 ms·
Lack of generics != lack of abstractions. The Go community freely acknowledges that generics are a nice feature, and that lacking them is a pain point of Go so
by eloff 12y ago
Lack of generics != lack of abstractions.
The Go community freely acknowledges that generics are a nice feature, and that lacking them is a pain point of Go sometimes. Although many Go developers will tell you that sometimes turns out to be not that often in reality, which has also been my experience.
Rob Pike has outlined the tradeoffs inherent with generics here: http://research.swtch.com/2009/12/generic-dilemma.html http://research.swtch.com/2009/12/generic-dilemma.html
The bottom line is it's not a feature that comes for free, and if most of the time you don't really need it, maybe the costs aren't worth it. That's a bold statement for a programming language these days, since generics is a central feature of every popular, modern, statically typed language. Whether they are right or wrong I won't attempt to say. The language may well get generics one day, but it's early days still and the team is rightly focusing on more important features for the moment.
- spion 12y agoThat really depends on what you mean by "most of the time". After all, you only write a generics based library once, and you reuse it many times - therefore on the outside it appears that you don't really use generics all that much. In my opinion, depriving a "normal" language user of generics is like depriving a Lisp user of macros. Whatever it is, its definitely not just "bold".
- eloff 12y agoI've done most of my Go programming on library code. A sync library for relational databases to sqlite (for mobile devices) and an embedded database. Lack of generics has bothered me a little, but copy and paste with a multiple-cursor editor really makes short work of it. I think the worst part is really our natural aversion to code duplication and the ugliness of it. e.g. having to write min/max for integers is pretty ugly (although not as ugly as converting your ints to float64 and using the stdlib min/max.) However, I spent more time thinking that it was ugly than writing min and max. Sure it's ugly, but programming is not art, it's engineering, and Go is a language for engineers.
- echaozh 12y agoI never thought people will actually come up and defend code duplication. It's definitely more than ugliness. The need to fix all the copies when they need to be updated is a bigger problem.
- apta 12y agoOr the fact that I actually saw someone on the mailing list also implement min() incorrectly due to copy-paste :) > I never thought people will actually come up and defend code duplication. Indeed. Some of the responses by some Go fans really leave me surprised to say the least.
- pjmlp 12y agoIt was the community attitude towards generics and code distribution that eventually made me focus on Rust and D. At least those communities embrace modern computing abstractions and code distribution practices.
- nknighthb 12y agoIt's fine that you don't agree with our tastes, but it would be nice if you could stop coming into every Go thread and being condescending about it. Like PostgreSQL and OpenBSD, I've been permanently turned off Rust because I never want to be left at the mercy of a community that invests so much time in harassing and insulting others.
- pjmlp 12y agoExcept, I also talk good about Go in what concerns using it to replace C, specially in possible uses for real systems programming in a GC enabled language. After all, when compared with the first Oberon version, Go only needs a few more primitives in runtime and unsafe, Kernel and SYSTEM in Oberon respectively. This is what attracted me to the language in first place.
- 12y ago
- ufo 12y agoCorrect me if I'm wrong but doesn't the current state of affairs (using Interface{}) have all the downsides of Java's boxing but without any of the type safety?
- NateDad 12y agoThe answer is not that you should use an empty interface, the answer is not to write generic functions.
- eropple 12y agoWhich leads to writing the same code repeatedly--because trying to wedge in reusability via insufficiently expressive structural typing is entertaining but often fruitless--and making the user wonder why they didn't just use something modern (setting aside stuff like Scala, even C++ can do channels, and past that the reasons for Go start vanishing real quick).
- NateDad 12y agoI write go 40 hours a week and have been for over a year. There's been only a couple times I wanted generics and those are structures I haven't actually needed to reuse yet. I'm not guessing about not being generics much. Edit That being said, go is not for all projects. Some projects need a lot of generics. Don't use go for that.
- EpicEng 12y agoWell it obviously depends on what kind of code you write. People writing certain types of libraries may benefit far more from generics than you would.
- eropple 12y agoUm, I've written Go. Nontrivial amounts, as it happens. In doing so, I recognized that I was regularly forced to write worse code in the pursuit of doing things idiomatically because I lacked the semantic richness of C++, let alone Scala. And this worse-is-better attitude of the Go community gives me a dim view of its future--and between its junk GC and its completely pedestrian semantic and syntactic propositions I already had a dim view of its present. If you write reusable, future-facing code, generic types without the erasure of interface upcasting is required. There are no two ways around it.
- kansface 12y agoThe problem is that the code that needs generics is reusable abstractions in libraries. Thats probably 1-3% of code but it is also critically important and there is no convincing workaround.
- jesstaa 12y agoThat is Russ' blog post, not Rob's.
- pjmlp 12y ago> Rob Pike has outlined the tradeoffs inherent with generics here: http://research.swtch.com/2009/12/generic-dilemma.html http://research.swtch.com/2009/12/generic-dilemma.html First of all that post was written by Russ Cox. Second, it already has been discussed multiple times that it only focus on C++, C#, Java approaches while cleverly forgetting generics implementations exist in multiple forms since CLU (1974) introduced them. But Go advocates take that page as dogma and toss it around every time a generics discussion comes up.