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.
> 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.
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.
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.
>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.
I'll give you that what you say about the Go team's motivations is entirely possible (though I don't believe it to be the case), but not responding to blog post comments shouldn't be indicative of anything.
Yes, I agree with your disclaimer re: blog post comments in general.
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.
Personally, I think that generics, in whatever form, are never going to happen in Go. The designers are smart enough that if they were really interested in them, they would've studied different approaches and come up with a reasonable design. I just think that having maps, slices and channels be polymorphic is enough for the designers and they have no use for something more complex.
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.
"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."
I'm going to have to infer what you mean by that snark.
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
> Java’s designers were consciously designing a product for people not as smart as them
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]
It's worth watching the Advanced Go Concurrency talk from I/O before judging whether Go is designed for below-average developers. They throw up a plausible code sample near the beginning that has multiple tricky bugs. It's not a very forgiving language if you aren't meticulous about how you use it, which I've also found to be true of Ruby (perhaps this is true of expressive languages in general).
Of all pg's essays I just put the Java one down to a bad day at the office. He's obviously a. very smart guy (cf On Lisp) but some of his statements in that essay seem to be made out of genuine ignorance. Its fine to criticise the language but to criticise the users who at the time were mainly ex c++ many of whom built systems in their time that were elegant, reliable, scalable etc, was a mistake - I think.
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.
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.
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 ?
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 think his fundamental disagreement is with the idea that embracing simplicity makes one a simpleton.
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. ;)
>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.
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 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.
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.
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.
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.
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?
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.
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.
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).
>I don't think that anyone is expecting a PL research breakthrough to provide some generics panacea
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".
No one is saying generics can't be implemented in go, or that go is "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.
No, it does not require a trade off. That is exactly what I just pointed out. There is no such problem. Parametric polymorphism was solved in 1976. None of the things you mentioned are actual problems, they simply do not exist. Those are invented excuses. If Rob seriously still hasn't bothered to read CS papers from 30+ years ago, that is very unfortunate. But it does not mean the problem wasn't solved, it just means he is unaware of the solution.
I'm more willing to trust Rob Pike on his assesment than a random Internet comment from someone who has neither knowledge of Go nor has read the comments on their mailing list.
Appeal to authority. You don't have to trust some random comment on the Internet. Read a little about how generics are implemented in other languages today, and you will be able to see the points the commenter is making.
An appeal to authority is not an argumentative fallacy if the authority is, umm, actually qualified to talk about whatever they're saying. There are at most a couple dozen people more qualified and able to talk about the upsides and downsides of programming languages who, moreover, have seen them in action in the course of several decades of computing history (much of which was directly due to this man's actions).
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.
Yes, it is still a fallacy. If you have an argument, you can make it without trying to rely on "famous person X agrees". And you seem to be confused about who Rob Pike is. He simply worked at bell labs. After everything important had already happened. He had nothing to do with the creation of unix or C, he just gets lumped in with them because he was at bell labs after the fact.
"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.
It seems to me that Pike and gang are mainly coming from a C background. They loathe C++ and Java. Take a look at the SPLASH talk linked in another comment here, and see how the "pain points" mentioned either apply mainly to C and C++ (dependency issues, build times in the case of the latter), or are independent of the language in general (like poor documentation). Then at least 4 sections on that page are just related to dependencies and build times (about 1/3rd of the entire article).
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++).
Did you seriously not notice how nothing in your list of accomplishments is even remotely relevant? We're talking about programming language research, and Pike's experience in that area is seriously lacking.
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.
Quick searches turn up slow compile times as a definite issue with generics. Which means papsosouid's premise is wrong: there IS an issue, and it's one of the ones the Go team considers important. EDIT: read name wrong.
It has been claimed by the D people that D compiles faster than Go. D has a very powerful generic/template system -- even more powerful than C++. Yet, they seem to have solved the compile speed problem, while preserving runtime types (it is a systems language after all).
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.
>Quick searches turn up slow compile times as a definite issue with generics
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".
Is there a problem with that? I expect you would find that most baseball players don't find baseball boring, and most nascar drivers don't think that their sport is low-tech to a fault.
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?
Well then it would already be too late, since the std lib has been frozen since go1. As long as things are added in a backwards compatible way, there's no problem though.
Plus, something of this magnitude may need to be in a theoretical go2, so they can break whatever needs to be broken.
>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.
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?
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.
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...
> 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.
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.
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.
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?"
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.
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.
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++.
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.
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.
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'.
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.
> 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.
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.
>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.
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.
None. It's something which is, ironically, used by people who overestimate their own understanding of pop-psychology to put down others. The fact that it was used in earnest without presenting any justification just makes it all the more hilarious, unintentionally so.
>It's something which is, ironically, used by people who overestimate their own understanding of pop-psychology to put down others.
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 ).
And yet you keep handing out these passive-aggressive put downs to everyone left and right. Maybe you should just not invoke the blog versions of scientific results into everyday conversation, much less to denigrate others. And maybe you shouldn't go around imparting your perceived wisdom on others so liberally. I think it's rather pretentious, and it's all part of an unfortunate ailment of geeks who feel the need to appear cultured, to pop random facts and factoids into conversation, and the Dunning Kruger effect has to be one of the most abused of these. I should know, I suffer it too.
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.
I think meta-conversations can quickly go downhill, but that they can also be constructive. I'll just say that there's always room for doubt, including in our presumptions about the intent of others, and that linking to an article about a particular cognitive bias doesn't necessarily strengthen an argument, nor does it put someone above that bias. For whatever it's worth, I've found that when I encounter apparent (possibly offensive) disagreement, I'm less constructive when I act on presumptions, and more constructive when I engage a Socractic dialog.
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.
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.
> 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.
"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.
> "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.
The main reason I love Go is because it makes me feel like the more I use it, the more I'm able to do and get it done faster. When I solve a given problem, it's solved for all my current and future projects written in Go.
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.
I'm still a little confused as to why Haunts keeps getting used as an example of Go "failing". As discussed in other Go-related comment threads, the project would have likely failed with any language, not just because Go doesn't have a version pinning package manager.
It's confusing why anyone would seek to blame a project's failure on the choice of programming language.
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.
It's confusing why anyone would seek to blame a project's failure on the choice of programming language.
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.
What baffles me isn't the lack of a version pinning package manager, but that a significant portion of the Go community actively criticizes projects trying to implement them, like http://gonuts.io or https://github.com/GPMGo/gopm
Yeah, I saw the post about gonuts.io on the mailing list and wished the creator would have gotten a warmer welcome. Some valid points were brought up, but everyone seemed to be annoyed at him.
Go has always looked interesting to me, but I don't understand why Google hasn't put go on Android yet. It seems like a better long term solution for Google than Java is for just about everything, but maybe it's not.
I've asked this question of a number of core Go contributors.
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.
It doesn't sound like that whatsoever. Here's what I interpreted:
"If Google were pushing Go and it were on Android, it may feel as though Go's goal was political, ie another way for Google to assert control over the development process and bring people under their umbrella.
"Given that Go isn't on Android, it feels more like Google is trying to contribute a useful tool than push an agenda."
If Google offers official support for a second language on Android, it will almost certainly be another JVM based language like Scala or (my personal dream) Clojure. They can already be used to write native apps, and would allow Google to continue to use Dalvik and the all the tooling surrounding it, which they've invested a tremendous amount of resources in.
I believe Dalvik's interpreter is very fast compared to Java interpreters. But its JIT is optimized for low startup cost and low memory usage, and as a result it's relatively slow. Though it might have improved in recent releases.
The only things that really bothers me about Go is how difficult is to contribute a patch (even when I'm listed as a contributor). First, you have to sign an agreement to give an unlimited license to Google to use your code as they see fit, then you have to use a special HG extension to get your patches uploaded to codereview.google.com (which disables branches/commits/etc, and doesn't let you submit multiple patches affecting the same files) and, finally, the patches may sit in review for a few weeks until someone from the core dev team takes a look at them.
Thanks for your contributions. I apologize that you've found it difficult. Just to respond to your points:
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.
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.
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.
Yes. Not sure how much I feel like talking about generics and error handling again, but those are the first two reasons. I can respect them wanting error conditions to be explicit, but then they give you no acceptable way of dealing with them -- perhaps because proven techniques from the functional world would require parametric polymorphism, or yet more built-ins from the language designers.
Absolutely.
Each time I try to move away from Scala, I always notice the lack of functional features in most other languages + a type system that's as strong as Scala's.
Most importantly, with Akka([1]) you have an awesome concurrency framework that comes with lots of features out of the box.
However, for many client-side applications, Go's lack of the JVM is a huge plus...
Go is awesome, and I'd love an excuse to use it in production. The problem is that being a young language, there aren't many libraries, and the ones that do exist are often at very early stages at best too. That means when you need a library to solve problems like printing a PDF, you are out of luck.
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 problem is that being a young language, there aren't many libraries.
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.
You can pry the super powerful type system, functional programming support, monad comprehensions, library ecosystem, IDE support from my cold dead hands :D
There is some support via a plugin [0] for JetBrains Idea. I also wouldn't be surprised to see JetBrains put some internal effort into supporting Go, from what I've heard Idea is pretty popular within Google and they just switched their Android Studio over to an Idea base.
I am not familiar with C#, but what Go does have is gofmt.
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.
Refactoring is not reformatting, nor are text replacement systems comparable. Refactoring allows you to keep program behavior the same while safely making structural changes to your code. Renaming is one simple example of this (where true refactoring tools are superior to textual find-and-replace because they understand which occurrences of an identifier are semantically identical). But there are many other useful refactoring operations, such as extracting a bit of logic into its own method, etc.
If you want a language which requires an IDE, I doubt very much you'd like Go - it is intentionally pared down to a minimum of what the creators consider essential features.
Having an IDE is almost required in a language where you have things like header files, namespacing, verbose function names, type hierarchies, a vast and complex standard library, etc. I've used a few IDEs, and prefer to go without where I can, though with some languages they're almost necessary - that's a personal judgement though, not a criticism of those who like IDEs or languages which require them. In Go, I can't imagine what I'd even use one for, save to organise the files in a project and do global searches, and perhaps trigger compiles/runs (I use a text editor for that), it's far closer to a scripting language in that sense. As to refactoring, it's really very simple and tools like gofix are there if you want to do something complex - to be honest that's really unnecessary for 99% of the refactoring I do, a search, check and replace does it very quickly.
So you might not like the language for the same reasons it doesn't require an IDE, but not having a decent IDE is not a valid criticism on its own.
I don't see how you make the jump from "Is there even a decent IDE for Go?" to "If you want a language which requires an IDE ...". For many people IDEs make the experience of programming more pleasant, even if the language is perfectly usable without an IDE. It hardly requires "a vast and complex standard library" for documentation tooltips or auto-completion to be useful, for instance.
> I didn't ask for a language which "requires" an IDE. I simply want to find a decent IDE for use when coding Go.
Depends what you mean by "IDE". There's LiteIDE[1], which fits the more "traditional" idea of an IDE.
I use Sublime Text 2 + GoSublime[2] myself; auto-completes from packages—inc. third party ones installed via `go get`—as well as error detection and integrated `go fmt`.
The thread started with refactoring, and then moved on to IDEs - what I was trying to say was that if you expect to require an IDE to help you with tasks like that, you might not enjoy using Go very much, because usually IDEs tailored for an ecosystem with built in autocomplete, docs, refactoring etc are useful for languages where refactoring means changing header files, the inheritance hierarchy is complex, the std lib or API is really large, etc. (like Java, ObjC, C# perhaps). None of that applies to Go so I don't really see what an IDE would add above a text editor (I use TextMate for example), combined with a browser open at the excellent package docs here - http://golang.org/pkg/.
I haven't seen any yet (though I would probably not be one to use them), but the language lends itself to the creation of such tools very well. Between the basics like fmt, and easy assess to the AST, I don't think it will be too long before more advanced tooling comes out from some of the larger organizations using go.
I wonder if Go will be similar to Scala where it arrives to solve issues with Java (or C++). I found that although Scala is a nice language in many ways, the smallness of the community prevented me from adopting it big time for most work. The same holds true for languages like F#. They're fine for special cases (likely what Google intended with Go), but won't be a general purpose replacement for more mainstream languages without some huge advance in support (like what the Rails team did for the Ruby language).
I guess it's how you look at it, but Indeed still shows very little movement over the last years with interest in Scala developers by businesses. Even compared to Go, it's very small.
Feed that to "go run". It'll work fine. Those two imports, by the way, are morally the same imports you gave .NET.
It might be reasonable to argue that most files will need to import "fmt" (although the Damnable Use Requirement means you won't be importing it anywhere you don't need it), but I'm lost as to why you imported "strings", "bytes" ("strings" for raw arrays of bytes) or "bufio" (in all my Golang code only two files I have import "bufio").
Why is that? Compared to? Is it worse than exceptions?
f, err := os.Open("/etc/ttys")
if err != nil {
// handle `err` "f not found"
}
try:
f = open("/etc/ttys")
except IOError as err:
// handle `err` "f not found"
I hate having to sometimes reindent a block of code, not changing any part of the block, because I need to wrap it in a try/except. It really drives me crazy with my obsession to have a clean, revision history.
Yeah, but arguably not as non-idiomatic as letting panics cross package boundaries. So long as you keep it all in your package I don't imagine very many people will mind if you use them a tad liberally (use them for things that are not truly exceptional).
I think most people who are bothered by Go's error handling are really just bothered by cross-package panics not being idiomatic (and thank god they aren't).
Define "fatal". Go-the-language and the standard library sometimes panic in situations that are bad but non-fatal for a long-running server process.
I have no issue with an argument that a panic making it out of a library meant for general external use is usually a bad thing -- that's not a "reasonable use of exceptions".
But my own applications are deliberately structured so that most of the outer layers can safely assume most operations will just work, as inner layers, to which interaction with external libraries is largely confined, will log.Panic() if they don't. It's the right choice 90% or more of the time, and leaves us with shorter, cleaner code.
In any case, I severely dislike arguments based on whether something is "idiomatic" or not. It's one thing when you're talking about loops and switches, and something else entirely when you hit someone over the head with it on architectural matters, especially in a language this young.
Well, it's non-obvious what we're comparing it to, so I assumed the most oft compared exceptions.
In this case, when opening a file, you can go ahead and use the value and "ignore" the error. Go ahead a run either of the above examples. Notice tptacek explicitly ignores the error.
This argument comes up a lot in lieu of or during talk of Generics, so it'd be best for me to defer to those discussions. Unless you or the OP have examples of hating `err` handling not yet described here, opening / reading a file in Go doesn't strike me as a place to take jabs at how errors are handled in Go.
I have no idea what you are talking about. The fact that you can ignore the error, including doing so by accident, is the problem. Sum types solved this problem a very long time ago, and there is simply no reason for a language created in the last decade not to have them. It is very simple conceptually, the function should not return a value and an error, because only one of those actually is valid. So it should return a value or an error.
It is very explicit and C-like. If, like me, your favorite language is C, it's OK (I agree it's not optimal). If your favorite language has exceptions, it'll annoy you a lot.
OK, it looks like you simply copied the import block from the first StackOverflow result for "golang read file" (the giveaway is that the order of imports is in the same non-formatted order as the top answer). That question, and its answer are covering more than simply reading in a file into a buffer.
Apologies, but I don't think you can accuse the golang authors of not putting enough thought into the project. Especially the package structure.
This is actually one of the major boons of go. They are solving problems you haven't considered. They set out to first solve the dependency problem. Someone commented that for every byte of C++ code being compiled in their large framework, the compiler was processing many kilobytes. This lead to many-hour compile times on large compute clusters.
In go, when a package is compiled it only needs to consider the contents of its imports (and not the imports of those imports, if you follow). It's very beneficial to only pull in what you need, since that will be one of the factors which heavily affects your compile time.
Lastly, as a personal preference, I really don't like "using namespace"-like directives. Go has a really nice property that for any given symbol you can find where it was defined by looking in the current file. This makes it great when working on unfamiliar projects or for people learning go.
I see that as a strength of Go, that it lets you cherry-pick the packages you want to import and make available, so you only get what you want/need. This is good for many reasons.
99% of my projects don't use "fmt" nor "strings", but they may use packages that use "fmt" internally.
Reading the contents of a file into a string is this easy for me:
package main
import . "gist.github.com/5571468.git" // [1]
func main() {
s := MustReadFile("foo.txt")
print(s)
}
Finally, canonical Go code typically has function names like ReadLine [2] rather than rdLn. Where are you getting that from?
I know no .NET, and very little go. But from a layperson and Python programmer's perspective, since you asked which is more intuitive --
When I look at the .NET statement, I'm a bit confused. Does that mean you are using some classes defined in the toplevel "System" package or module, and some that are defined in the "System.IO" package or module or whatever it is called? (I would actually like to know this.)
On the other hand, looking at the Go statement, I can see that it is importing six modules/packages, all of which more or less say what they do. That is more intuitive for me.
Critics of Go (and other languages, I imagine, but I've noticed it a lot with Go) tend to ignore anybody who points out that their argument is invalid. This might be because their real argument is:
"The language I'm familiar with does it this way, Go does it another way, and I don't like that."
Go is alright, but I don't understand their naming convention for packages. Why "fmt" instead of "format"?
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".
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