HN's reaction to Go reminds me of Stroustrup quote about C++:
..."There are only two kinds of languages: the ones people complain about and the ones nobody uses"
So much complaining about how Go lacks this and that features of shiny new (and sometimes unfinished) language X. In the meantime, as time goes by it seems that more and more real companies use Go code in real production and are quite happy with it, despite all the shortcomings frequently listed here.
And to your last sentence, use in production is not a good measure of language quality (except in a tautological sense), because many non-technical factors strongly affect popularity.
Sure, that's really useful - you guarantee that you can never access the unset half of the value. But it adds a lot of complexity, too. You need a way to declare values of this type - this means more keywords and/or more special syntax. You need a way to then access both halves of the values, so now you have to add pattern matching... that's actually a lot of complexity to add to a language that only has 25 keywords.
All that, instead of just doing what Go already does, which is to return two values and just have a convention of checking the error before the value... which works really well 99% of the time, and doesn't require all the rest of that complexity.
Clearly that was a very deliberate choice on the part of the Go creators, not the result of oversight or ignorance. I suspect they simply didn't want to reflect the state of the art 30 years ago, 20 years ago, or today. I don't find that at all surprising, because people who want to get things done often like very simple tools which stay out of the way. To each their own though, and I'm sure the go creators would be very happy to see other languages used instead of go by those who prefer more features, more complexity, state of the art from 30 years ago, etc. I do find myself puzzled by the hostility it generates though - it is just a language, one of many, and about which some very ordinary claims are being made (easy to learn etc).
I cannot return a loop.
I cannot see a single way in which that is objectively "better".
Does the functional style of maps and composition cause problems at scale? I don't have any data. However, I would not begin by assuming that Go's designers were either stupid or ignorant of functional programming idioms.
And to your last sentence, use in production is not a good measure of language quality
It is actually a great indicator of the gap between abstract language tourism, and practical day to day development.
I will say again that Haskell is held as the perfect language and set of choices on here constantly (particularly when used to denigrate Go). Yet it is used for perilously few actual solutions (despite being around for decades).
Sometimes the things that seem incredibly important and of great value just aren't such a great value in the real world. Similarly, things that seem minor end up being very important.
As for use in production, I agree that it can be a fair barometer for "utility", but I strongly disagree that it's a good measure of "quality" (as in, technical design choices). We live in a path-dependent world rife with network effects, so quality per se just doesn't matter all that much, and non-technical factors like "being backed by a major corporation" can matter a lot. I'm sure there's more Visual Basic in the wild than Go, but I'd hardly use that to argue that it's a superior language, or that Go proponents are "abstract language tourists".
i hope you're just not aware whom you're talking about http://en.wikipedia.org/wiki/Go_%28programming_language%29:
"Go, ..., is a programming language initially developed at Google[6] in 2007 by Robert Griesemer, Rob Pike, and Ken Thompson."
Suggesting application of Blub paradox to the people who invented Unix ...
On the other hand, unless you spend a lot of time using a feature in earnest, it's hard to know that the feature is actually not necessary because it's an enormous workaround for something else.
no offense, man, yet this your statement is an example of the blub paradox.
"But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub ..."
it is like you looking up at Thompson and not realizing that you're looking up. You probably consider Thompson equivalent to you and everyone. (Again, no offense intended, though i can see how it can sound kind of offensive).
Who mean the same people that disregarded memory safe system programming languages and decided to create their own "unsafe by default" one?
The same people that created a text based operating system, while at Xerox PARC GUI based workstations were being developed in memory safe system programming languages?
it sounds a bit oxymoronic, at least on practice. I'm yet to see a normally functioning system written using "safe system programming language".
>The same people that created a text based operating system, while at Xerox PARC GUI based workstations were being developed in memory safe system programming languages?
i hope you don't mean Unix here because Unix has nothing to do with either "text based" or "GUI based" - it is completely orthogonal to that.
Just some examples of operating systems that worked for several years in certain circles.
Xerox Star systems coded in Mesa.
Lilith coded in Modula-2.
Spin coded in Modula-3.
Oberon coded in Oberon.
AOS coded in Active Oberon.
Ethos coded in Oberon.
Original version of OS/400 coded in Modula-2.
Mac Lisa and initial versions of Mac OS coded in Object Pascal.
VME in Algol 68
The real time systems driving lots of trains, planes, helicopters and medical devices running Ada code deployed directly to firmware.
> i hope you don't mean Unix here because Unix has nothing to do with either "text based" or "GUI based" - it is completely orthogonal to that.
I sure do.
UNIX System V does not offer any GUI interface.
POSIX does not offer GUI support.
I'm pretty sure Ken Thompson &co were fully aware of generics and sum types (to use your own example). It trades the implicit complication of implementing and using those (and other) features for strong concurrency. For a lot of people, that's a good tradeoff to make.
It has been pointed out multiple times that the page you refer to, only focus on C++ and Java, while forgeting about all the other languages.
The languages and compilers I'm familiar with (Scala, Haskell, MLton) all pay a cost, usually in compile time.
[1] http://research.microsoft.com/en-us/um/people/akenn/generics...
In F#, you can use hat types via inlining to get even more power. Like creating a map function that works directly on List, Array, and Set - but without using any common interface. Pretty neat, but it emits the function's IL into every callsite so it can get out of hand.
I recall there being a mailing list thread on Go where the designers addressed this. I've no idea how Go is implemented so perhaps the multiple-copies problem is actually significant.
Also addressed by Ada generics for example. There are many others.
Strong typed languages with generics go back to CLU (1974), so there are lots of research material, as well as, real languages if one steps outside Java/C++ implementation mindset.
Edit: Removed stupid comment.
I find some philosophy of C and Go similar, BTW. Minimalism is an art.
:.:.:
Go lacks a lot of basic functionality a lot of other languages take for granted. I.E.:
In Rust you can type
fn id<T> ( item:T) -> T
{
return item;
}
:.:.:
Lets say you want to iterate over a array in say java.
for(byte a: bytes[]
{
x += a;
}
:.:.:
Lets say I'm adding vectors and dark magic has told me to use '-' for the dot product. In most languages (Rust, C, C++, Haskell) this is completely possible, as - is just a function. __subtract__() in rust.
You can't in Go.
:.:.:
Now lets talk about pointers. When you want to signify data doesn't exist in Go you pass a null pointer (nil, 0x0). This is wrong on almost every single level. Your not only creating a back door, but your by passing your entire type system.
The only thing that stops this from being common practice is that Go has such good message handling, but it still exists! Why?!
:.:.:
Immutable variables, data structures, etc. are a thing of beauty. In Rust and Haskell all values are immutable by default, but most languages (C, C++, Java) let you delcare variables, data structures, etc. as immutable.... Go doesn't.
:.:.:
Go has no support for turning off compiler safety features. Much like Rust offers the
unsafe{ ... }
:.:.:
TL;DR
Go doesn't do anything new.
Actually it takes a step back.
for _, a := bytes {
x += a
}
No there's no operator overloading, and thank god. + is numeric add, I never have to wonder if + might be some crazy O(n^2) function. Yes, that makes go bad for Matt and science code. That's ok, go is not for every application.
Go has unsafe and reflection, it is just discouraged strongly.
Yes, nil exists. Big deal. You know how often I've seen nil pine exceptions in a year of writing go full time? Once. Because go has multiple returns and you never look at the pointer before checking the error.
No there's no immutable data structures.... And I've never missed them. You can approximate them with interfaces with only getter methods, but it's rarely worth the effort.
Often times in large code bases you'll have short mathematical expressions used in multiple places.
fn error<T:num>(real:<T>, test:<T>)-> <T>
{
return ((real-test)/real)*100;
}
>no operator overloading, and thank god. + is numeric add, I never have to wonder if + might be some crazy O(n^2) function.
Overloading is normally done a per-data type basis to avoid exactly what you state. But yes, it is a big mathematical/scientific point. It can really simplify your life working with some data structures.
>Yes, nil exists. Big deal.
No that's the problem. Its existence is a bug. And has no use existing, as you said yourself its rare, you never see it, you hardly use it... So why even include it?!
>[...] immutable
Immutability is more of a programmer hack, not a language hack. Rust and Haskell make me ask myself 'will I actually change this value' when declaring a new variable. And addes an extra mental step and self check of your own code when programming.
He said he rarely sees code fail because of nil dereferences, not that he rarely sees it. "if err != nil {" is probably the most commonly written line of Go code by a large margin. Nil fits well with the language's zero defaultness of values. It may not be theoretically sound, but in practice it fits within Go very well and rarely causes the problems it tends to in other languages with null.
http://www.infoq.com/presentations/Null-References-The-Billi...
To say Go doesn't do anything new is wrong however. The language specification doesn't include new material, sure, but the language tools are incredibly engineered. Go get just works (but don't use it for long term dependency management, that's not what it's designed for.) The documentation is stellar, and it's really easy to make good documentation. The compile times are lightning fast. Go fmt is by far my favorite feature; All Go code looks the same, and it even saves time trying to format code to look nice.
As for your specific complains:
:.:.:
No, Go doesn't have generics, but for most cases that's ok. The saying goes when you have a hammer, everything looks like a nail. However Go does give you a screwdriver (interfaces), and it turns out a lot of things work well as screws. Generics aren't easy, they complicate the language (which goes against one of their language goals), and increase compile time or run time (which go against other goals.) They haven't said generics will never be in the language, just that they haven't found a solution they like and that it won't be in the language any time soon.
:.:.:
You can iterate in Go. Otherwise for loops are a tried and true method.
:.:.:
This complicates some code, but makes the language a lot simpler. Yes it's a trade off, and the language author's choices may differ from your preferences.
:.:.:
Yuck, nil pointers, I agree. However sometimes an ugly feature makes the whole language look a lot better. Nil usage aligns very well with the design of the rest of the language. Gross? Yes. The wrong design decision for Go? Definitely not.
:.:.:
Immutable values complicate the type system and require that those features occupy some brain power. They may be nice in other languages, they have no place in Go.
:.:.:
Go has unsafe operations.
If all business decisions were based on pure computer science we might very well have much better software, but im inclined to believe we wouldn't have so many different and great products out in the world.
(It isn't of course)