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.
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.
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
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.
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.
most heavy users are self selected.
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.
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.
> 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.
Go is the right language for the right time: easy enough for the Python people (like me) to pick up quickly, but with a concurrency model that makes taking advantage of multi-core very easy.
Anyone prefer Scala to Go?
Yes, very much so. I love being able to keep so much of the state in the type system, freeing my attention for more important things; it also (ironically?) lets me write much more dynamic-feeling code by using "typeclasses" to supply varying implementations for an operation. I don't realise how much I depend on it until I try to go back to other languages. Go has some useful standard types and a good story in place for some other generic type use cases, but if you need a (generic) type that the language designers didn't think of (and e.g. even Option is missing), you're stuffed.
[1] http://akka.io
The other thing that makes me a bit nervous about using it in production is the idea of linking to the latest/head version of a dependency. Maybe I just don't properly understand the paradigm though.
Those nits aside, I believe Go has bright future and within 2 years will be mainstream. Meanwhile, Scala is better suited for projects that need lots of libraries and mature tooling.
The Go standard library is large, there are many libraries on code.google and github. I feel like this statement would have been more accurate a year ago. My job is almost 100% Go based development and at this point, I have no issues finding libraries when I need them.
I'd choose Ada or Rust over Go.
For concurrency I'd choose Erlang or Rust over Go.
If it's Node.js or Go. I guess I'll choose Go.
You can pry the super powerful type system, functional programming support, monad comprehensions, library ecosystem, IDE support from my cold dead hands :D
Yes, by a huge margin. I rank my preferences like so:
derp languages (go lives here) < scala < ocaml/F# < haskell
But that doesn't make it clear how huge the distance is between the derps and scala.
but, I'm giving you the benefit of the doubt that there's an intelligent comment here
First, I should point out that you CAN currently run Go programs on an Android device. You just can't take advantage of the SDK and make GUI-based applications, etc.[0]
Basically, the answer is that nothing's preventing anybody (including you and me) from doing so, except the fact that we would have to wrap the entire NDK and make it available/usable through Go.
That's not any more difficult to do in Go than it is to do in Java, but it's a massive amount of work which has already been solved for Java, so there's little incentive to recreate it in Go.
(I'm paraphrasing, so my answer may be slightly wrong, but hopefully you get the idea - perhaps @enneff can give a more complete answer).
[0] You can, however, bundle them as hybrid applications, because Android applications apparently allow bundling of arbitrary binaries, from what I've been told.
I think it will happen eventually. The language is new, but it's having a lot of success and spreading both within Google and outside.
When I was working with C++ earlier, that was not really the case. After spending many years with it, I couldn't write a simple web server in under 5 minutes. Making something into a library had too much overhead. In Go, once I've done something [1], the next time it's one line to import it.
Also, working with the language programmatically is a pleasure. There's a full parser in the standard library.
[1] e.g. https://gist.github.com/shurcooL/5571468, https://gist.github.com/shurcooL/5504644
"for _, "
range in the for loop return 2 values (index, value). If you don't want the index, you can assign it to "_" to ignore it.
This forces all Go code to be formatted and styled in a consisten manner. This not only solves readability issues, but makes all code consistent for machine reading and replacing.
gofmt also supplies a pattern replace method, which is a bit more sophisticated than a regex search and replace.
For interactive refactoring experience, then, it's basically up to the IDE how to integrate that.
The presence of this anecdote in the article seems to fulfill some sort of journalistic requirement to balance any positive stories with criticism as well, to be in the center. It doesn't make a lot of sense when writing about programming languages.
The choice of language does have the potential to deep six a project; however, it's rarely something that can be blamed on the language itself.
I've seen projects fail because of the language the chose for at least two reasons, but I think these two are the most obviously harmful:
1. Choosing a language that isn't just unsuitable, its design goals and tradeoffs should make it an obviously poor choice in terms of your requirements.
2. Choosing a language for use by a team that has no experience with it, no time to learn it, and/or lacks the discipline to learn it in sufficient depth to use it efficiently for the project's purposes.
Again, these are not failures of any given language. They are, however, potential project-killers that are only possible based on the choice of programming language.
Some examples are AppEngine, Angular.js, Go, GWT, and Chrome Developer tools.
I don't get where he'sshe's going with his/her post though...
Just my humble opinion..
1. CLAs are a fact of life in open source to keep the lawyers happy (http://en.wikipedia.org/wiki/Contributor_License_Agreement). We've tried to make it as simple as possible: you fill out one web form, we do the rest. And it's just once, not every time. So if you're already listed as a contributor, you're done with this forever.
2. You're free of course to prepare the code any way you want. We insist on the hg extension to manage the review of the patch, mainly because it makes our lives easier: there are a LOT more contributors than there are core Go team members doing code reviews. (And we don't just review; sometimes we even like to write our own code.) I hope using the tool isn't really too burdensome. Many people work with other things, like git in the same dir or hg in another dir, and then they copy the changes into their "review" tree.
3. This is a real problem. We don't have a good system for tracking these: so far we've just been letting everyone watch the same stream and deal with what needs dealing with. But the volume has gotten high enough that we are dropping too many incoming changes or bug reports on the floor. We're working on a new system to track incoming changes and bug reports and assign them to a clear owner so that everyone knows who is responsible for what. I hope this will go live soon.
So, like:
var SomeFunc = RequireAuth(func(...) {
...
});
OK, I guess they think abbreviations are useful...but then they went with "database" instead of "db", "encoding" instead of "enc" and "image" instead of "img".
At least be consistent.