... and still no generics.
I am always confused by the push to make every language exactly the same by using the same paradigms and features. Some languages try to take a different approach. If you can't figure out how to work within that paradigm, don't use it. Your comment is akin to complaining that Haskell doesn't support an imperative style.
More like: some paradigms and features have been proved useful, and experienced programmers ask for them in a language that lacks them.
And not indiscriminately, but usually only ask for them if that language is of a certain paradigm / family of languages were those things fit well with (e.g. few ask for immutability in Go, or logical programming in Javascript).
>Some languages try to take a different approach.
Yes, the wrong one.
>If you can't figure out how to work within that paradigm, don't use it.
A lack of a feature is not always a "paradigm".
Besides, by the same logic, every language is perfect as is all the time, and users and potential adopters should not ask for anything new.
The lack of closures in Java for ages is a strong counter-argument to that. Or the rejoicing by which people adopted "auto" in C++. And tons of other examples, besides...
>Your comment is akin to complaining that Haskell doesn't support an imperative style.
More like his comment is akin to complaining that Java doesn't have Generics (pre 1.5).
And yes, I've spent plenty of time using languages that do support generics. It can save you time but I've found it also enables "looser" code, which can be more error-prone. In fact one of my favorite things about Go is how restrictive its type system is. I feel a lot more confident about my code doing only what I think it's doing when using Go.
If they find a way to introduce generics while upholding Go's other strong points (fast compilation being another), then great. But it looks like it's not trivial.
If the language is not for you, move on. There are plenty of us who are perfectly happy to write code without generics. Your condescending remarks are entirely unproductive.
When it comes to computer science generics have been an accepted part of PL research for decades. The extra expression power they give and the paradigms they enable are neither controversial, not something that's up to individual tastes to judge.
Someone might not like them subjectively, but that's not different than someone not liking closures, or map or any other established thing. People will always have their preferences.
>I for one have spent the last 2 years using Go to build a very performant system which is used by thousands of Bitcoin day traders every day. It's fast, stable, and easy to modify. I have never felt held back by a lack of generics.
That doesn't prove it's not an objective issue, just that a specific use case, in a specific domain, didn't need it.
Or even more precisely, that a specific programmer didn't feel the need "held back" by their lack. Perhaps others would feel "pushed forward" by their presence.
For example, I mentioned Java above, who only got Generics after 10 years. Tons of far bigger Java programs than the one described have been created with Java-without-Generics (from financial services to automobile controllers).
All those projects weren't any "proof" that Java doesn't need Generics (and/or closures). Just that you can do without them too (which is true -- nobody argues that you can't).
Besides, isn't Paul Grahams whole "Blub" concept based on the idea that people using languages without X features have little means to understand their importance (and what they're missing)?
In any case, there are counter-examples to what you write too: several posts from teams that have used Go in production that say they like it but still lament the lack of generics.
>And yes, I've spent plenty of time using languages that do support generics. It can save you time but I've found it also enables "looser" code, which can be more error-prone. In fact one of my favorite things about Go is how restrictive its type system is. I feel a lot more confident about my code doing only what I think it's doing when using Go.
Generics are not "loose", if anything they're even tighter type-wise than what Go makes you do to overcome their absence. Either you create concrete types for everything, ad nauseum, or you go "loose" and use interface{} and the like, throwing a lot of assurances out of the window.
>If the language is not for you, move on. There are plenty of us who are perfectly happy to write code without generics.
Again, happiness doesn't say much -- that's personal preference and can't be debated.
Java programmers were perfectly happy to write code without Generics and Closures for like 15 years too. Most were even oblivious that those things existed in the PL world at large. Javascript programmers suffered without correct scoping or an import system for 20 years, etc.
The point is, plenty of companies manage to create very good production software with Go, without generics. I didn't mean to rest my argument on my personal anecdote. You can look to Google, CloudFlare, SoundCloud, Dropbox, etc. for reassurance.
If you have a suggestion on how generics would fit into Go, I think the Go team would be happy to read your thoughts: https://groups.google.com/forum/#!forum/golang-nuts.
May I guess you're either some old Lisp/Smalltalk etc veteran, or, much more probably, someone who entered IT after, say 2005?
Because back in the day very few thought of Java as "gross" -- it was greeted as a welcome change from the existing landscape which at its best was something like C++.
I guessed so, because back in the day (1995-early 00's) most devs outside of seasoned functional etc veterans (who were extremely few) or hardcore systems guys, saw Java in mostly positive light, and never considered it "boring" back then.
The change (for new devs to consider Java "boring" and lacking in features) happened sometime after 2005, with Rails entering, Javascript catching up, C# getting more features with 2.0 and 3.0.
(Consider than back then Scala, Go, Clojure et al weren't even started, and AJAX had just been made mainstream).
Programming language "research" and computer "science" research has been irrelevant in the sausage industry for about four decades.
It's just like complaining accounting refuses to use category theory.
It is by design that Go does not have generics as the Go team have not found a design they feel works and they are unwilling to compromise the current design.
They may never.
Why not both?
Good luck; it's an autoantonym. In my experience, your usage is as common as many others, though.