The reasons that Go doesn't have generics are well documented and discussed (continually) on golang-nuts. Basically, the designers feel none of the existing generics implementations are adequate. They claim that if and when a better solution is devised, they're open to using it.
I don't know why you're accusing them of shielding users from generics, unless you think they're being disingenuous.
Yes. The whole "we'll do it when we find the perfect way" is bollocks. Generics are a solved problem and engineering is about compromise.
It's just that the compromise in favour of generics is not the one they wanted to take. But the official excuse is more of a way to shut people up about it, than truthful commitment to finding the best way to add them in Go.
Thought it might be if not proof, maybe indicative: he specifically asked for comments on that blog post. And according to the parent, those comments were well reasoned and by a high expert on the field -- they would at least deserve a reply.
Assuming you are saying that those things are a contradiction I don't agree. It's a perfectly legitimate position to design a language to have fewer 'advanced' features; it makes it easier to learn, there are fewer ways to trip yourself up unexpectedly. Of course on the other hand you may find yourself re-inventing the advanced language features yourself, probably not as well, or committing errors that could have been prevented. I don't think there is a right answer. Go takes a position, and that position is similar to the one taken by the original Java.
Anyway, you took my post in the wrong light. I used insults like those because I was using the language of Java critics[1], which was, you know, the joke. The intelligence one in particular was a riff on an insult by a good friend of yours:
Like the creators of sitcoms or junk food or package tours, Java’s designers were consciously designing a product for people not as smart as them. — Paul Graham
The Go creators definitely enjoy their language themselves. They designed the language that they personally would want to work with.
"For too long to admit to here, C was my language of choice, but I have used many languages through my career. Nowadays almost everything I write is in Go; it is the most productive language I have ever used and has displaced C completely from my toolbox." [0]
https://developers.google.com/events/io/sessions/332768653
You're absolutely right that it's an opinionated language, but having used both for production code, I don't at all see the parallel to Java.
Am I supposed to infer some opinion from you on that? I'm not sure if you were just summarizing or have a fundamental disagreement with the stance, which you thought would be self evident.
He will use the best language for the problem/domain at hand.
Even if OP is right and GO is a "simpler" language than others, if it allows to solve a range of problems without the added mental load required by, say, C++ why should't he use it ?
Since sharing source code with as wide an audience of programmers as possible will almost always bring increased value to your system, then using a language that can be widely understood and modified safely makes it the best language for the problem/domain at hand.
I can agree with that. I also believe that using a simple tool does not presuppose simple outcomes. To me the rewording looked like a fairly neutral assessment of a few language features.
What I was fishing for was if there was some positive of negative opinion behind them and what it was driven by. Without that the comment seemed fairly useless, and I'm fairly sure tptacek's not shy about sharing his opinion. ;)
That is a false dichotomy, and a particularly dishonest one at that. The options are not write complicated code in a modern language vs write boring code in an obsolete language. Go is bad because it gives the programmer poor tools to write any kind of code to solve difficult problems, boring or otherwise. Basic simple functionality that has been established for decades is being ignored because people insist on pretending that having a good language is somehow a problem and makes code complicated.
"I don't mean to boast, but I'm awesome" would be a similar statement. Trying to defeat criticism by deflecting the critique at the root, while actually fulfilling said critique is a common argumentative tactic that, while noble in its attempts to avoid offense, is intellectually dishonest.
The designers are not omniscient, and their desires mean nothing in the real world, beyond how the product of their will is actually used.
All that's just a long winded way of saying that who it's made for and who finds good use out of it are not entirely equivalent. As such the tptacek's statement seemed very neutral to me.
We created Go first and foremost for ourselves. Go is the language we want to be (and are) writing programs in. I haven't had this much fun writing programs in a long time.
It is emphatically NOT true that Go is "created for people less smart than the designers". At no point during any design discussion did we say "well, that will be too difficult for the average programmer".
The part about "large teams of varying abilities" is not true either. What is true is that Go was designed for large-scale programming, though, and the things that work in a 100-line Haskell pearl don't necessarily scale to million-line programs. Rob Pike gave a talk about this at SPLASH titled "Go at Google: Language Design in the Service of Software Engineering" [1]. I highly recommend it if you want to see where we're coming from with some of the design.
Your third point is certainly true, but I can't think of a decent language that doesn't attempt to make certain types of errors harder than the languages it replaces.
I don't see how Go is more "systems-ey" than say, Java; other than allowing you to pack struct members together by separating pointer and value types in a certain way. C# already allows you to do something similar.
Furthermore, the main arguments I've seen for "programming at scale", are that unused vars get treated as errors, interfaces, and the way dependencies are managed (mainly to speed up compile times).
The latter has been solved by probably any modern language post-C++. Warnings as errors is a preference. Interface types aren't that special when looking at languages like Scala and Rust, which provide very nice and powerful type and trait systems that go really well together; while maintaining the ability to extend types by other traits, not that much unlike Go to begin with.
I am not a language designer, but I can't help but feel that the language was somehow designed into a corner, with the way interfaces and composition work together. All this is making adding generics much harder.
However, this talk does not mention some questionable decisions, such as keeping null references in the language. Why would you do that, instead of using option types?
Can you comment on generics in ML-derived languages?
The language designers have not ruled out generics, and are fully open to providing them at some point. The issue is that they have yet to find an implementation that fits within the language design goals.
Yes, if you jump on the mailing list, and propose that they somehow "use" .NETs generics, and you actually have no idea how that would be implemented, or impact the compiler and runtime, you're not going to be greeted cordially. This happens fairly frequently, and is probably why people think the community is totally against generics.
The Go team wants generics, when they find the right way to handle them within the language. In the meantime, most heavy users seem to agree that lack of generics is better than poor generics.
This statement, part of the standard Go talking points, seems to be designed to persuade the unsure to give the language a chance, "and generics will be around later once we figure it out." Not likely.
I think the designers know that no perfect shining implementation of generics--compatible with all of Go's existing design decisions--is going to arise deus ex machina after eluding researchers for all these years.
There has been some talk, but it's mixed in with a lot of noise too.
I don't think that anyone is expecting a PL research breakthrough to provide some generics panacea. I think this is more along the lines of how can we pragmatically introduce generics without messing up too bad. From what I've seen, I personally think some form of templating has the most promise (though I am far from qualified to actually comment on its viability).
That already happened. In 1976. There is simply no excuse for this disingenuous "oh but go is magic and special and can't do it the same way everyone else can" nonsense. If people want that argument to be taken seriously, then they need to start offering actual specific problems with parametric polymorphism as it would apply to go. Not just saying "we're special".
Implementing generics requires tradeoffs of some sort -- compile-time and size, runtime efficiency, or language-complexity. The creators didn't want to accept any of these compromises, at least for the initial release of go.
Really, if you have a language, compiler, and operating systems designer of the caliber of Rob Pike saying that generics introduce a lot of issues, I'm going to need some damned good evidence to the contrary.
"He also co-developed the Blit graphical terminal for Unix; before that he wrote the first window system for Unix in 1981. Pike is the sole inventor named in AT&T's US patent 4,555,775 or "backing store patent" that is part of the X graphic system protocol and one of the first software patents. [1]
Over the years Pike has written many text editors; sam and acme are the most well known and are still in active use and development.
Pike, with Brian Kernighan, is the co-author of The Practice of Programming and The Unix Programming Environment. With Ken Thompson he is the co-creator of UTF-8. Pike also developed lesser systems such as the vismon program for displaying images of faces of email authors."
Yeah, some amateur engineering right there. My point still stands; heuristically I have every reason to believe an extremely competent arquitect and designer who is involved in good faith on this project over a random commententer who can't be bothered to assess the evidence.
No one is denying that C and C++ have many problems. At the same time though, many of those problems have been solved in other languages (both older and newer than C++).
You don't need to believe anyone, that is the whole point. You are trying to turn it into "some guy's opinion vs the glorious and all-knowing rob's opinion". It is not a question of opinion, it is one of fact. Again, this problem was solved in 1976. ML is very old. Go read the papers on parametric polymorphism.
As I mentioned in another comment in this thread, I have a feeling that the issue with generics in Go is how some language features interact with each other (and not in a good way). Mainly interfaces and object composition. I think this is a good indication that the authors were not aware of several developments in language design at the time of making Go. Not everything is a tradeoff all the time. Certain problems have been solved.
Where? I can find nothing of the sort. And given that we have proof otherwise (compare D to go for example) it seems likely that you are choosing to interpret "some languages made their compilers slower" with "parametric polymorphism must make a compiler slower".
most heavy users are self selected.
Outsiders may have suggestions for improvements, they may even be outsiders because they would like to see those suggestions realized, but when is that ever not the case?
Plus, something of this magnitude may need to be in a theoretical go2, so they can break whatever needs to be broken.
That's the party line. And I, for one, don't believe that.
Go has been going for what, 3 years? And a couple more internally IIRC. And not only they came up with nothing with regard to generics as of now, there's also no research or initiative has been started that anybody knows of.
So how exactly are they supposed to "find an implementation that fits within the language design goals"? By some kind of satori?
What I find amusing lately is the exodus from Ruby over to Javascript. What's the thought there - maybe there weren't enough braces? Maybe THIS time, this scripting language will work! What valiant hope.
I'm not one of these developers, but I believe the appeal is largely the ability to work with one language in the "full stack": Node.js on the server, JS in the browser obviously, and maybe MongoDB or Postgres.
The web has become our operating system, and Javascript is its language.
Nodejs? Solving stuff that erlang have solved.
The only approach I like is use a backend language to create a RESTful server to server data. And let clientside javascript mvc handle the layout and looks.
Don't let me get started on those javascript people that think MongoDB and noSQL is going to replace SQL.
JavaScript made sense because web devs already knew it. Also, and more importantly, there was no blocking io library.
So the developer is forced to write code in a way that makes Node perform well.
IIRC Rob Pike was hacking away in C++ and the some guys from C++1x comite came to google to show C++'s new features. And he thought to himself: "Really you really think the problem with C++ is not enough features?"
I think the advocates of Go who say "it is supposed to be boring" are giving a mistaken impression. Java was "talking down" to replaceable cog programmers, by having "one way to do it" that fronts the then-popular inheritance based OO, and syntax that spells everything out. Go is "talking up" to a programmer who is expected to want to see the algorithm in stark brush strokes against an uncluttered page, by having "one way to do it" that fronts the imperative algorithm and very light very regular syntax that doesn't obtrude. Go is not for people who want to program the language (try Haskell or a lisp). Go is for people who want to program the program.
Reducing the mental load of a programming language has nothing to do with how "smart" anyone is, it's about making everyone more productive. Otherwise, the smartest programmers would all be clamoring to use C++.
Now flexibility certainly comes with a cost: there's just that much more you need to understand about theory and architecture to be able to account for all the different code permutations. That said, it also allows for those who dedicate themselves to programming as a science to write exceptionally and more productively.
I would say Go raises the average productivity compared to more complex languages but dramatically caps the upper bound as well. Whether that's good or bad is as much philosophical as practical.
Productivity during creation isn't worth the cost of maintenance later. At least, not the psychological cost.
I would like to know exactly what the established programming language research is. My strong impression is that if there was ever anything that was not established it was 'how to build the best programming language'. Not trolling, just asking for clarification on that point.
I believe I heard that Gosling did want to have first-class functions initially in Java, but they just ran out of time.
Go, of course, does have closures like almost all modern languages. The lack of generics does stymy what you can express statically with higher-order functions, but it does have them.
[1] http://commandcenter.blogspot.com.au/2012/06/less-is-exponen...
I don't think anybody (that is, more than a few outliers) said anything about Java being "boring" back then. It's in the last 5-7 years, after J2EE came out of favour, that is in vogue to say these kind of things. And I know that, because I was around back then. Java was supposed to be safer, yes, but nobody said it was supposed to be boring or targeted to enterprise drones. On the contrary, it was deemed "revolutionary" and the language of the rich web (because of applets).
>1) created for people less smart than the designers
Well, most programmers are indeed less smart than Ken Thompson or Rob Pike, so that would be a good call IF it was true.
But from what I have read, it was created to be the perfect language FOR it's designers, scratching THEIR pain points -- not targeted to some inferior programmers. And it's designers were and are are very fond of the language and heavy users of it.
So, I don't see where you got your (1) point.
>2) designed to be easy to use in a corporate environment with large teams of varying abilities (the 'simplicity', which is really more familiarity: most people can write boilerplate filled imperative C-family language style code already).
Who said Go is about 'boilerplate'? One of the design goals was to reduce boilerplate, and in practice it's very succint, eg. to get the same thing going, compared to Python code.
>3) attempts to make certain types of errors harder than the languages it replaces (in Java thats memory errors, in Go it's concurrency errors), but by ignoring established PL research still gives you a big gun that is loaded and aimed at your foot (doing concurrency in Java with threads and locks, NULL and deadlocks in Go, etc). i.e. very conservative when it comes to adopting PL ideas, but perhaps bringing one old idea to the mainstream, and being prepared to make a lot of sacrifices (to ensure an 'easy' language) to get people on board with that one idea.
So, in essence, it's not a hodgepodge of newfangled PL research like Haskell. Sounds good to me.
>The amusing thing is that the creators of Go are some of the fiercest critics of Java, but they have created something that seems to follow a very similar philosophy to the original Java.
Well, they are not critics of the original Java. Matter of fact, some of them have also programmed lots of in Java in the past.
>I don't mean this as a slight against Go (or Java!). I just find the comparison illuminating.
Well, you sure sound like you do.
What is the relevance of Dunning-Kruger? I've always taken the practical meaning of Dunning-Kruger to be that there's always room for self-doubt, though certainty may be increased the more external validation you get. The GP's comment does not seem any more certain than the average comment here.
While a valiant effort of you to meta-snark (couldn't help it, could you?), there's nothing much to "understand" about it. It's a well known experimental study. And it wasn't quoted here as a scientific citation -- just as a well known metaphor for "don't overestimate your smarts, kid".
>The fact that it was used in earnest without presenting any justification just makes it all the more hilarious, unintentionally so.
"Without presenting any justification"? What exactly do you thing this is? Some academic forum on psychology where we study cognitive issues?
He have, here, an exchange on programming languages, where the parent put down whole classes of programmers as inferior (to some unmentioned higher standard) with rigorous hand waving and a few invalid arguments -- several of which I refuted.
The reference to a cognitive superiority bias was given in this context, as a token "and who do you think you are" gesture. Nobody said that this was a clinically verified case of the Dunning-Kruger effect in action -- or that it was the core of the conversation anyway (it's a single link at the very bottom of a 450 word reply).
I know some people on HN tend to be pedantic, but you should not let pedantry ruin your ability to hold a conversation (AKA, the "well, actually" effect: http://tirania.org/blog/archive/2011/Feb-17.html ).
Either way, I didn't get that the OP wanted to put down other developers, rather that the language designers did, by "simplifying" their languages by sticking to tradition and leaving crucial features out, and needless features in.
In that it's not wise to put people using other languages (such as Java etc) as "lesser programmers", just because you think you're so much better for using something else.
People tend to overestimate their smarts -- and those kind of inane comments about whole language ecosystems are not exactly signs of brightness.
> So, in essence, it's not a hodgepodge of newfangled PL research like Haskell.
Pretty sure repeating Hoare's 1965 mistake should not be glossed over this way.
But let's step back and explore "boring" here. When I talk about Go being boring, I mean the specs of the language are boring. In contrast, Java has a pretty exciting spec while the code itself is boring.These two are worlds apart. Go promotes a "boring" spec to write smarter code[1]. Like Python, the focus is on expressiveness rather than on features(standard library features).It reduces the cognitive overhead so that you can "program" more. 3) Neither Go's concurrency patterns nor the avoidance of concurrency errors(or non-determinism of code execution)is anything new. It's based on more than 30 years of research including Unix pipes, Hoare's CSP. The patterns Go follows is not conservative at all! It still follows the same PL ideas you are talking about(or not talking about). If you are looking for the gun it's still there[2]. The wrapper around concurrency is not a protection but an enhancement so that the code can focus more on project logic. And still the wrapper is sometimes not enough to avoid mutilating your foot. I don't think Go inventors had that in mind while designing the patterns. Also Go too handles memory management(yes, just like Java).
Your comparison is based on incorrect hypothesis. I can hardly see the illumination. Let's just say Go is a fresh new programming paradigm and it would be hasty to jump to conclusions without exploring it a bit more.
[1]http://commandcenter.blogspot.in/2012/06/less-is-exponential... [2]http://golang.org/pkg/sync/
P.S: I don't program in Java by choice. Android Developer. Edit: language
Funny you should say that, because IIRC they also have stated that one of the reasons they are so skeptical of adding features to the language is that Java started out as nice and simple language that was a great alternative to what was available at the time, and that they don't want to repeat the mistakes of what happened after that.
This one doesn't hold up to inspection. The indications are that Google intended to use it in house. If nothing else can be said about Google, they do believe they are smart.
Golang also differs from Java in some obvious low level ways.
Remember "Node.js is cancer"? Remember how the Node.js fanboys would bully programmers on social media who critiqued it? At no point have I seen Go programmers hype up the language and attack others.
I sincerely hope the "brogrammers" and "hackers" who beat their chest about Rails and Node.js and whatever framework was/is flavor of the day, do not start using Go.
They will be a negative force in the community and it will be sickening to see them pump up the hype and declare themselves as champions of Go.
Perhaps not "attack", but Go advocates tend to be very defensive about any criticism.
1) created for people less smart than the designers (even if not intentionally: maybe Gosling and Pike really do believe that generics and HOF are too difficult for the average programmer)
2) designed to be easy to use in a corporate environment with large teams of varying abilities (the 'simplicity', which is really more familiarity: most people can write boilerplate filled imperative C-family language style code already).
3) attempts to make certain types of errors harder than the languages it replaces (in Java thats memory errors, in Go it's concurrency errors), but by ignoring established PL research still gives you a big gun that is loaded and aimed at your foot (doing concurrency in Java with threads and locks, NULL and deadlocks in Go, etc). i.e. very conservative when it comes to adopting PL ideas, but perhaps bringing one old idea to the mainstream, and being prepared to make a lot of sacrifices (to ensure an 'easy' language) to get people on board with that one idea.
The amusing thing is that the creators of Go are some of the fiercest critics of Java, but they have created something that seems to follow a very similar philosophy to the original Java. I guess it remains to be seen if Go will have added as many features in 15 years time as Java has in the last 15.
I don't mean this as a slight against Go (or Java!). I just find the comparison illuminating.
[1] http://news.ycombinator.com/item?id=5750256