10 ms·

I think the thing that amuses me most about the current Go hype is when people defend the language with statements along the lines of "it is supposed to be bori

I think the thing that amuses me most about the current Go hype is when people defend the language with statements along the lines of "it is supposed to be boring"[1]. Go is the new (old) Java and the arguments echo those of 15 years ago. 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 http://news.ycombinator.com/item?id=5750256

fmstephe 13y ago
I think a much better comparison is with C. C, similarly, has a paucity of features. It is also relatively easy to grasp its core. However, this has never prevented C from being used to build very powerful applications. 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.
tptacek 13y ago
"I don't mean this as a slight against Go, or Java. I'm just saying it's made for people of a certain level of intelligence and designed for use at giant corporations."
- kbenson 13y ago
  I think that's an accurate distillation of what was said. 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.
  - randall 13y ago
    I think he's saying the OP is being contradictory. "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.
    - kbenson 13y ago
      That only follows if you think that a language being made for "people of a certain level of intelligence" is a negative assessment (even if I find the wording crude). I don't think that, because I don't think it precludes "more intelligent" people from getting good use out of it. 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.
  - jbooth 13y ago
    I think his fundamental disagreement is with the idea that embracing simplicity makes one a simpleton. I'm primarily a Java and Go coder and think that writing boring code to solve difficult problems requires much more intelligence and artistry than writing complicated code.
    - Kurtz79 13y ago
      Yes. IMHO a smart programmer does not use a complex or a language "by smart people for smart people" because "he can". 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 ?
nknighthb 13y ago
I fail to recognize the world from which your comment seemingly comes. 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++.
- Refefer 13y ago
  One of the big issues I have with its simplicity is that it seriously constrains expressibility; there are many designs that are simply off the table since they cannot be adequately defined. 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.
  - nknighthb 13y ago
    I'm afraid that more than a decade of picking through legacy code (both other people's and my own) has irrevocably convinced me that "expressive" is newspeak for "unmaintainable". Productivity during creation isn't worth the cost of maintenance later. At least, not the psychological cost.
    - gtrak 13y ago
      even with productive languages, there is such a thing as 'idiomatic'.. (I say to myself as I munge some legacy clojure)... I still prefer to work on old clojure code than new java code after a year and a half with it, even java written by 'experts'.
ominous_prime 13y ago
my rant re: generics, I wish people would read through the documentation (FAQ) and discussion of this first. 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.
- quatrevingts 13y ago
  I am highly skeptical that they are actively investigating ways to support generics, or that they are willing to change anything else about the language to support them better. 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.
  - ominous_prime 13y ago
    I would like to believe that the go team members aren't being disingenuous when they say this. 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).
    - papsosouid 13y ago
freyr 13y ago
> maybe Gosling and Pike really do believe that generics and HOF are too difficult for the average programmer 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.
- anon1385 13y ago
  Heh, I should probably have known better than to mention generics in relation to Go. Replace it with option types if you like, I don't think it changes the argument.
- KaeseEs 13y ago
  I don't think that's an entirely fair take on the situation. There was a great series of comments on Russ Cox's blog in late 2009[1] by longtime Boost contributor and general brainiac Rivorous about the benefits of generic programming a la Stepanov and pervasive value semantics, which were noted but not engaged in any meaningful way. [1]http://research.swtch.com/generic http://research.swtch.com/generic
  - mdwrigh2 13y ago
    So because Russ Cox didn't respond to some comments on his blog, the Go team is trying to shield users from generics because they think they're too complicated? I don't buy that. If you follow the go-nuts mailing list, the pros and cons of various generics implementations have been argued back and forth, and they have yet to find one that meets their criteria. I don't think they disagree that it would be helpful, they just don't think that the trade-offs current implementations provide aren't worth the convenience they add.
    - coldtea 13y ago
      >So because Russ Cox didn't respond to some comments on his blog, the Go team is trying to shield users from generics because they think they're too complicated? 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.
kyllo 13y ago
I agree, Go seems designed to solve a lot of the same problems with C/C++ that Java was designed to solve. That's probably why the creators of Go are fierce critics of Java, because Go is meant to replace Java (which was meant to replace C/C++). They operate in the same problem space, so they're going to be competitors.
- ExpiredLink 13y ago
  Go was meant to replace C++ as 'systems programming language'.
  - trailfox 13y ago
    In practice it's better suited to apps typically written in Java.
    - kyllo 13y ago
      Yeah, I get that feeling too, and I think it's because of the garbage collection. You use C++ when you want to manage memory allocation manually.
JulianMorrison 13y ago
Go and Java are both opinionated languages, and the first release of Java was a small language, but the opinions they embody are quite different. 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.
smrtinsert 13y ago
Gosling himself said that scripting projects were always fun and fast, but when the job got large only static languages made sense (paraphrasing). This definitely echos my experience. The only way I've been able to manage large scripting projects is by building a quasi static type system - the strictest conventions allow you to decrease cognitive wait substantially. 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.
- spamizbad 13y ago
  > 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.
  - papsosouid 13y ago
    I find the other approach much better. Use a good language on both the server and the client, using one of the many language_x to javascript compilers.
- pkroll 13y ago
  Well, one reason to move from Ruby to JavaScript is speed: there are very fast JavaScript implementations, compared to the fastest Ruby. And since you need to know JavaScript ANYWAY for the client side, it makes a certain amount of sense to just use it everywhere. So I guess that'd be two reasons, if I can go all Spanish Inquisition here...
- ef4 13y ago
  The prevalence of Javascript has nothing to do with the language itself and everything to do with the ecosystem. The web has become our operating system, and Javascript is its language.
- 13y ago
shurcooL 13y ago
Have you read Rob Pike's post here [1]? I wonder if your post is made with that knowledge in mind or without, and whether it'd change your perception in any way. [1] http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com.au/2012/06/less-is-exponen...
PuercoPop 13y ago
According to Rob Pike the lack of features is a feature (less is more) not a way to appease to the fictional 'average programmer' in the PL designers imagination. So I don't know where do you get the idea that go is meant to be used by 'lesser minds'. 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?"
bangkoknights 13y ago
> "The issue for PHP and even Node.js is obviously you're trapped in a single-threaded situation and what I really wanted was to be able to do a lot of things concurrently," 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.
- trailfox 13y ago
  > At no point have I seen Go programmers hype up the language and attack others. Perhaps not "attack", but Go advocates tend to be very defensive about any criticism.
  - suite16 13y ago
    Seriously, say something critical about Go on HN and you better have some karma built up or it's instant hellban.
    - pekk 13y ago
      Can the same not be said for, say, Haskell?
    - codygman 13y ago
      I remember when everyone was annoyed at Go stuff getting posted on hackernews. /hipster
columbus1492 13y ago
Go creators are some of the fiercest critics of Java because Java is better, thus they have to tear it down to feel good about themselves. Java has better error handling, documentation, readability, and yes concurrency. Concurrency is Go is so basic and limited it's only solving the easiest of easy concurrency (message passing, no shared memory) and that is trivially easy in any language. Concurrency in Go has no priorities, no limits, can't be aborted, and is not even preemptive. Start an endless loop coroutine and nothing else ever runs, start coroutines doing lots of computation and your server is unresponsive/chunky. When you get anything complicated then you're back to manually doing locking, with no help from the language (not even synchronized). In most ways it's worse than Java -- but that doesn't matter because it's "new" and "fun" and "from Google". And hype.
vanderZwan 13y ago
> 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. 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.
coldtea 13y ago
>Go is the new (old) Java and the arguments echo those of 15 years ago. 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. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
- mcgwiz 13y ago
  Hmm, metacomment: 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.
munificent 13y ago
> maybe Gosling and Pike really do believe that generics and HOF are too difficult for the average programmer 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.
0xdeadbeefbabe 13y ago
Is anything really established in PL research? Is goto really considered harmful? Golang also differs from Java in some obvious low level ways.
realrocker 13y ago
1&2: Since you are using my comment as a reference, let me first declare that Java (not Go, though I have been using it for a while now) is my everyday language. You seem to point out that "a boring language" is designed for lesser programmers. And Java started out as one(just like Go has). 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-exponentially-more.html http://commandcenter.blogspot.in/2012/06/less-is-exponential... [2]http://golang.org/pkg/sync/ http://golang.org/pkg/sync/ P.S: I don't program in Java by choice. Android Developer. Edit: language
rsc 13y ago
Go designer here. 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. [1] http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article
- azth 13y ago
  What's peculiar is the way certain words are used by the authors, like "systems" programming, or "programming at scale", etc. 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.
- mietek 13y ago
  This is a brilliant talk, and it gives excellent reasons for most design decisions — except making error handling "intentionally clumsy". Why not borrow what is arguably the most important Erlang feature, process linking and supervision? 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?
mtdewcmu 13y ago
"1) created for people less smart than the designers..." 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.

fmstephe 13y ago

I think a much better comparison is with C. C, similarly, has a paucity of features. It is also relatively easy to grasp its core. However, this has never prevented C from being used to build very powerful applications. 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.

tptacek 13y ago

"I don't mean this as a slight against Go, or Java. I'm just saying it's made for people of a certain level of intelligence and designed for use at giant corporations."

kbenson 13y ago
I think that's an accurate distillation of what was said. 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.
- randall 13y ago
  I think he's saying the OP is being contradictory. "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.
  - kbenson 13y ago
    That only follows if you think that a language being made for "people of a certain level of intelligence" is a negative assessment (even if I find the wording crude). I don't think that, because I don't think it precludes "more intelligent" people from getting good use out of it. 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.
- jbooth 13y ago
  I think his fundamental disagreement is with the idea that embracing simplicity makes one a simpleton. I'm primarily a Java and Go coder and think that writing boring code to solve difficult problems requires much more intelligence and artistry than writing complicated code.
  - Kurtz79 13y ago
    Yes. IMHO a smart programmer does not use a complex or a language "by smart people for smart people" because "he can". 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 ?

nknighthb 13y ago

I fail to recognize the world from which your comment seemingly comes. 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++.

Refefer 13y ago
One of the big issues I have with its simplicity is that it seriously constrains expressibility; there are many designs that are simply off the table since they cannot be adequately defined. 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.
- nknighthb 13y ago
  I'm afraid that more than a decade of picking through legacy code (both other people's and my own) has irrevocably convinced me that "expressive" is newspeak for "unmaintainable". Productivity during creation isn't worth the cost of maintenance later. At least, not the psychological cost.
  - gtrak 13y ago
    even with productive languages, there is such a thing as 'idiomatic'.. (I say to myself as I munge some legacy clojure)... I still prefer to work on old clojure code than new java code after a year and a half with it, even java written by 'experts'.

ominous_prime 13y ago

my rant re: generics, I wish people would read through the documentation (FAQ) and discussion of this first. 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.

quatrevingts 13y ago
I am highly skeptical that they are actively investigating ways to support generics, or that they are willing to change anything else about the language to support them better. 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.
- ominous_prime 13y ago
  I would like to believe that the go team members aren't being disingenuous when they say this. 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).
  - papsosouid 13y ago

freyr 13y ago

> maybe Gosling and Pike really do believe that generics and HOF are too difficult for the average programmer 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.

anon1385 13y ago
Heh, I should probably have known better than to mention generics in relation to Go. Replace it with option types if you like, I don't think it changes the argument.
KaeseEs 13y ago
I don't think that's an entirely fair take on the situation. There was a great series of comments on Russ Cox's blog in late 2009[1] by longtime Boost contributor and general brainiac Rivorous about the benefits of generic programming a la Stepanov and pervasive value semantics, which were noted but not engaged in any meaningful way. [1]http://research.swtch.com/generic http://research.swtch.com/generic
- mdwrigh2 13y ago
  So because Russ Cox didn't respond to some comments on his blog, the Go team is trying to shield users from generics because they think they're too complicated? I don't buy that. If you follow the go-nuts mailing list, the pros and cons of various generics implementations have been argued back and forth, and they have yet to find one that meets their criteria. I don't think they disagree that it would be helpful, they just don't think that the trade-offs current implementations provide aren't worth the convenience they add.
  - coldtea 13y ago
    >So because Russ Cox didn't respond to some comments on his blog, the Go team is trying to shield users from generics because they think they're too complicated? 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.

kyllo 13y ago

I agree, Go seems designed to solve a lot of the same problems with C/C++ that Java was designed to solve. That's probably why the creators of Go are fierce critics of Java, because Go is meant to replace Java (which was meant to replace C/C++). They operate in the same problem space, so they're going to be competitors.

ExpiredLink 13y ago
Go was meant to replace C++ as 'systems programming language'.
- trailfox 13y ago
  In practice it's better suited to apps typically written in Java.
  - kyllo 13y ago
    Yeah, I get that feeling too, and I think it's because of the garbage collection. You use C++ when you want to manage memory allocation manually.

JulianMorrison 13y ago

Go and Java are both opinionated languages, and the first release of Java was a small language, but the opinions they embody are quite different. 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.

smrtinsert 13y ago

Gosling himself said that scripting projects were always fun and fast, but when the job got large only static languages made sense (paraphrasing). This definitely echos my experience. The only way I've been able to manage large scripting projects is by building a quasi static type system - the strictest conventions allow you to decrease cognitive wait substantially. 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.

spamizbad 13y ago
> 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.
- papsosouid 13y ago
  I find the other approach much better. Use a good language on both the server and the client, using one of the many language_x to javascript compilers.
pkroll 13y ago
Well, one reason to move from Ruby to JavaScript is speed: there are very fast JavaScript implementations, compared to the fastest Ruby. And since you need to know JavaScript ANYWAY for the client side, it makes a certain amount of sense to just use it everywhere. So I guess that'd be two reasons, if I can go all Spanish Inquisition here...
ef4 13y ago
The prevalence of Javascript has nothing to do with the language itself and everything to do with the ecosystem. The web has become our operating system, and Javascript is its language.
13y ago

shurcooL 13y ago

Have you read Rob Pike's post here [1]? I wonder if your post is made with that knowledge in mind or without, and whether it'd change your perception in any way. [1] http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com.au/2012/06/less-is-exponen...

PuercoPop 13y ago

According to Rob Pike the lack of features is a feature (less is more) not a way to appease to the fictional 'average programmer' in the PL designers imagination. So I don't know where do you get the idea that go is meant to be used by 'lesser minds'. 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?"

bangkoknights 13y ago

> "The issue for PHP and even Node.js is obviously you're trapped in a single-threaded situation and what I really wanted was to be able to do a lot of things concurrently," 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.

trailfox 13y ago
> At no point have I seen Go programmers hype up the language and attack others. Perhaps not "attack", but Go advocates tend to be very defensive about any criticism.
- suite16 13y ago
  Seriously, say something critical about Go on HN and you better have some karma built up or it's instant hellban.
  - pekk 13y ago
    Can the same not be said for, say, Haskell?
  - codygman 13y ago
    I remember when everyone was annoyed at Go stuff getting posted on hackernews. /hipster

columbus1492 13y ago

Go creators are some of the fiercest critics of Java because Java is better, thus they have to tear it down to feel good about themselves. Java has better error handling, documentation, readability, and yes concurrency. Concurrency is Go is so basic and limited it's only solving the easiest of easy concurrency (message passing, no shared memory) and that is trivially easy in any language. Concurrency in Go has no priorities, no limits, can't be aborted, and is not even preemptive. Start an endless loop coroutine and nothing else ever runs, start coroutines doing lots of computation and your server is unresponsive/chunky. When you get anything complicated then you're back to manually doing locking, with no help from the language (not even synchronized). In most ways it's worse than Java -- but that doesn't matter because it's "new" and "fun" and "from Google". And hype.

vanderZwan 13y ago

> 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. 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.

coldtea 13y ago

>Go is the new (old) Java and the arguments echo those of 15 years ago. 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. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

mcgwiz 13y ago
Hmm, metacomment: 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.

munificent 13y ago

> maybe Gosling and Pike really do believe that generics and HOF are too difficult for the average programmer 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.

0xdeadbeefbabe 13y ago

Is anything really established in PL research? Is goto really considered harmful? Golang also differs from Java in some obvious low level ways.

realrocker 13y ago

1&2: Since you are using my comment as a reference, let me first declare that Java (not Go, though I have been using it for a while now) is my everyday language. You seem to point out that "a boring language" is designed for lesser programmers. And Java started out as one(just like Go has). 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-exponentially-more.html http://commandcenter.blogspot.in/2012/06/less-is-exponential... [2]http://golang.org/pkg/sync/ http://golang.org/pkg/sync/ P.S: I don't program in Java by choice. Android Developer. Edit: language

rsc 13y ago

Go designer here. 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. [1] http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article

azth 13y ago
What's peculiar is the way certain words are used by the authors, like "systems" programming, or "programming at scale", etc. 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.
mietek 13y ago
This is a brilliant talk, and it gives excellent reasons for most design decisions — except making error handling "intentionally clumsy". Why not borrow what is arguably the most important Erlang feature, process linking and supervision? 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?

mtdewcmu 13y ago

"1) created for people less smart than the designers..." 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.