14 ms·

“Go’s design is a disservice to intelligent programmers”

131 points by apta 12y ago

smt88 12y ago
I'd be really curious to know what this guy thinks of Rust.
- davecheney 12y ago
  I can confidently predict the author will decide that Rust has some nice attributes, but pales in comparison to D.
- nemo44x 12y ago
  I'm a bit curious too - he seems to hate the idea a programming language thinks the developer is an idiot. Rust, for how perfect it really is, treats developers as humans. You must be smart if you can use it - but it doesn't trust you to have any idea what's really going on when a program gets large. This is a good thing IMO. Honestly, anyone who thinks Rust is trash is just wrong. I can get the argument that there just will never be enough people who can use Rust but having learned Go and then Rust - I have to say Rust is the most well designed programming language ever. I can't believe what's in it and it's far and away the most advanced programming language ever. It's hard to compile but when it does you have a good chance it's right.
  - smt88 12y ago
    Haven't seen anyone trash Rust yet. However, one thing I'll say is that it's a big problem for people like me if a language requires you to be smart to use it. It's really, really hard to hire only smart/experienced developers. What I need, and what I hope Rust can be, is a language that is opinionated (in the right ways) and won't compile if an inexperienced dev tries to do something dumb. In Rust, the fact that variables are immutable by default (but can be explicitly declared mutable) is the kind of thing I'm talking about.
  - MetaCosm 12y ago
    Woah, I can't tell if that was a brilliant troll or you honestly believe these things -- either way +1 hilarious.
    - smt88 12y ago
      What do you dislike about Rust?
  - kibwen 12y ago
    I heartily disagree that you have to be smart to use Rust. I'm a ho-hum CRUD web programmer with enterprise credentials and versed in dynamic languages, and I was able to pick up Rust quite easily as my first systems programming language ever. The hardest part isn't even learning the language, the hardest part is figuring out the essential differences that separate the systems programming domains and the high-level dynamic domains.
    - smt88 12y ago
      That's a great endorsement. I was going to do my next experimental app in Go, but this really makes me want to use Rust.
carbocation 12y ago
My summary of the author's points: no generics, inexpressive, no good package manager, procedural. Of these, caring about the fact that it is procedural seems pure opinion. Lacking a package manager is not really a language issue (PHP's package manager, for example, is not coupled to the core language). So, we are left with the lack of generics and the lack of expressivity. I'm not deep enough in the weeds to be able to argue pro/con for generics intelligently right now, so I will concede that as a concern that has been raised by many. The lack of expressivity seems to be an inexorable consequence of the goal of simplicity, so I'm sympathetic. That said, it seems to be a tradeoff acknowledged by Go's authors, not an oversight. Overall, these points don't convince me of the author's thesis (or, at least, they don't seem to justify the title's degree of inflammation).
- sethetter 12y ago
  "Expressiveness" seems like a subjective measurement to me. Also, from what I've gathered, Go attempts to be more convention oriented and is centered around doing things the "one true way". The Go formatter is an example of this. Perhaps this is just a result of that philosophy.
- AlexandrB 12y ago
  I thought the "sum" example was pretty damning. Bug count scales with code length so writing tons of boilerplate code to work around language limitations means you're introducing bugs.
  - carbocation 12y ago
    I believe that the purpose of `go generate` is to lessen the risk of this type of thing by handling the repetitive code generation for you, but I do agree that it's a limitation. If done by `go generate`, it's an additional procedure that you have to learn; if done by hand, it's a bug risk.
    - meowface 12y ago
      Code generation is a giant spiked mallet for a nail which can easily be screwed with a small screwdriver. It has its uses, especially for generating schemas (like what Protobuf and Capnproto do), but for generating actual function implementations it's kind of absurd. `go generate` is a nice tool but it's not even remotely a solution to the no-generics problem. Of course, the problem is that for the compiler implementation, those traits are completely reversed (adding generics at this point is like hitting the compiler with a mallet); and that happens to be Go's primary excuse for lack of generics/templating/macros/anything sane. I think dev ease-of-use matters a lot more than core dev ease-of-use though. Even if the compiler must grow in complexity and average compile time, the benefits to devs are worth it.
staunch 12y ago
You shouldn't be offended that Rob Pike thinks he's a much more advanced programmer than your average programmer. He is. Whatever his motivations, he created a very productive language. As it turns out, even advanced programmers benefit from having a simple language when it comes to getting practical work done.
- Someone1234 12y ago
  > As it turns out, even advanced programmers benefit from having a simple language when it comes to getting practical work done. I'm making this point quite tongue in cheek however... By that logic why do programmers hate Visual Basic so much? At least VB6 was very much a "simple language" relative to other things around at the time (less so with VB.net/C#). A lot of the arguments people are making here (less is more essentially, and clear syntax wins over complexity even at the cost of efficiency) then VB6 should be something we're modelling modern languages off of, but it is not... PS - Remember I am not being literal here. VB6 had some issues both then and now. I am not really comparing Go to VB6, I am comparing the arguments made in support of Go to arguments that could be made in support of VB6.
  - PopsiclePete 12y ago
    There's a difference between being "simple" and "brain-dead". C, for example, is very simple, simpler than Go, even, but you can't compare it to VB6 either. Your comparison is disingenuous at best. Simplicity is a good thing. It's a virtue. It's part of what made UNIX a success. It's not something to shun or avoid. Adding features adds complexity and complexity is not free. Notice how the industry still has't jumped ship whole-sale to Haskell?
    - waps 12y ago
      > Simplicity is a good thing. It's a virtue. It's part of what made UNIX a success. It's not something to shun or avoid. It seriously depends what you're doing. As someone put Haskell recently "all the possibilities of advanced algebra combined with all the clarity of advanced algebra". Simplicity is only a real success if it doesn't throw out the baby with the bathwater. > Adding features adds complexity and complexity is not free. And taking away features is free ? Why aren't you programming in LISP then ?
keithba 12y ago
"So Rob Pike is basically saying that the developers at Google aren’t very good so they’ve developed a dumbed down language so they can get things done." I read the Pike quote very differently. When Pike says: "The key point here is our programmers are Googlers, they’re not researchers." I thought he meant programmers today use google to assist them in programming.
- jalfresi 12y ago
  "The key point here is our programmers are Googlers, they’re not researchers." I took that to mean "Our programmers are building products, not thinking about building programming languages"
  - AnimalMuppet 12y ago
    It may go even further than that. Google has to produce multi-million line programs and maintain them for a decade or two. That's not a problem that most programming language researchers face. If researchers think about that, they usually do so in the abstract, rather than from a position of personal experience. One place this shows up: Build times. Turning a 45-minute build into a 10-second build, times 30 programmers, times several builds a day for 10 years... that adds up to a really big difference.
    - MetaCosm 12y ago
      It always astounds me when (inexperienced) developers play down build times as if they simply aren't that big an issue. They are hellish, creativity crushing monsters. Also, static binaries -- so the DevOps guys don't hit you with sticks. I still remember the first go program README.md I shipped. "Umm, get foo to box, ./foo in a way so that it runs persistently and at startup." Easy way to get your apps to the front of the line in the deploy queue -- all the time.
- robbrit 12y ago
  "Googler" means "someone who works at Google". He's saying the language is designed for people who are in large, transient teams building large-scale production systems, not people who want to explore advanced programming language concepts.
deedubaya 12y ago
The author is basically saying that you'll be better off banging your head against a wall trying to figure out a more complicated language than to pick up golang quickly an start building something. News flash! Not everyone is a brilliant developer. And that's okay! News flash! Not ever developer has extensive programming experience and can pick up new concepts quickly. And that's okay! Go is too simple for you? Drink a big glass of shut the hell up and go write a program in brainfuck or something. Intelligent programmers aren't dependent on the language they use to become better developers. There is no disservice in being able to build something quickly.
- sheepmullet 12y ago
  Most of the negative reactions to Go aren't really to do with the language itself. They are more general feelings of frustration with our industry. Part of the reason Go is so popular is because we place such a low value on education, training, and long term productivity, and a high value on getting things done quickly. In general our industry is focused on the short term, is fad driven, and is more than willing to turn on our own. Go is a language created to win in this kind of environment. And because people hate the environment... they focus their animosity on the tools that are successful in our environment.
  - 15155 12y ago
    > more than willing to turn on our own This "it's so simple!" nonsense is an exemplification of that. By reducing everyone (even good programmers) to the lowest common denominator, talent is far more commoditized and pluggable. You can throw away Programmer A because Programmer B is "as good as it can get for
- moron4hire 12y ago
  Syntactically simple language actually tend to be harder for new/less-skilled programmers, as they require the programmer to figure out how to do more things that more complex languages handle as simple expressions.
sheepmullet 12y ago
It's the difference between simple and easy. Go is very easy for existing developers to learn because it is basically a cut down subset of what they already know. Which makes Go a great option.... if you use it properly. It means you don't need to worry about a programmers language history when you hire even if you need them to be productive right away. It means you can hire the smartest developers, regardless of whether they have been doing embedded work, or spas in js, or large enterprise application dev in java, etc.
- 15155 12y ago
  In other words: reduce everyone to the lowest common denominator.
  - Gigablah 12y ago
    But I'm a special snowflake! This won't do!
    - sheepmullet 12y ago
      Of course a lot of good developers won't like it because it is a change that makes them worse off. If you are a good Haskell/D/Lisp developer then switching to Go will probably halve your productivity over the long term. There are a lot of benefits to using Go but lets not pretend there aren't any downsides.
intortus 12y ago
Just because you're intelligent doesn't mean you should spend all that intelligence trying to figure out other people's messes. Simplicity and explicitness are paramount when collaborating.
- AlexandrB 12y ago
  > Simplicity and explicitness are paramount when collaborating. So is succinctness (most people can't speed read code). The examples he gives make Go look anything but succinct.
  - jff 12y ago
    That's because he's not a very good Go programmer, which is not surprising since he's clearly far too intelligent to use Go.
  - intortus 12y ago
    At a certain point succinctness does more harm than good. Go captures nearly all of the sense of python's early values (https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/), without requiring all that much more in the way of boilerplate. So you have to if-check an error value here and there, no big deal. You should be handling errors anyway. If Haskell's succinctness level is 1, then I would rate python's at 2, go's at 4, and java's at 20.
    - dragonwriter 12y ago
      Presumably, that rating scales has higher numbers meaning less succinctness? Because otherwise the order of the numbers (much less there relative values) doesn't make any sense, even though that's kind of the opposite of what you'd expect of a "succinctness level".
      - intortus 12y ago
        It's a linear scaling factor for how many lines of code I tend to take to express the same medium-sized program across these languages.
barsonme 12y ago
His Go is a little disingenuous. This (https://gist.github.com/EricLagerg/105431503d32f18d239b https://gist.github.com/EricLagerg/105431503d32f18d239b) is almost as short as his D code, and functions the same.
- jff 12y ago
  It's almost as if, like most people who write articles complaining about Go's lack of "expressiveness" and generics, he took a cursory look at the language, wrote some naive examples that supported his point, and squeezed out a blog post.
  - waps 12y ago
    If the code was equivalent you might have a point. Unfortunately it is not (tokenizing/line scanning vs. copying). One has a shortcut in Go, the other does not. Would you say that Go is not excessively verbose in non-trivial use cases ? I recently had to sort a struct list in a program. Added lines of code for sorting a single list once : 30. What the ...
    - okbake 12y ago
      I'm curious about the specifics of your problem. I couldn't imagine sorting a list of structs (by one of the fields I presume) would be too terribly different in Go than in other langauges. Heres an example of insertion sort on a basic type: https://play.golang.org/p/SPoiNRVl2B https://play.golang.org/p/SPoiNRVl2B You can use the standard library sort methods by making your type implement the sort interface. Heres an example taken from the example in the sort docs: https://play.golang.org/p/oeRIhHi1Ei https://play.golang.org/p/oeRIhHi1Ei
      - waps 12y ago
        This post contains a comparison : https://news.ycombinator.com/item?id=9267578 https://news.ycombinator.com/item?id=9267578
      - he_the_great 12y ago
nemo1618 12y ago
IMO, the author's "copy data to stdout" example betrays a lack of language understanding. Here's a more idiomatic version: http://play.golang.org/p/ZWatRuj3Q_ http://play.golang.org/p/ZWatRuj3Q_
- QuercusMax 12y ago
  Thanks! I'm just learning go (started last night), but I couldn't believe there wasn't a better way. It felt like a straw man example.
- Cthulhu_ 12y ago
  Plus given Go's focus on external dependencies, a common task like reading commandline parameters can (and should) be done with a library that solved that problem for you already - don't reinvent the wheel, and such.
- zoips 12y ago
  Kind of code golfing it: http://play.golang.org/p/s53zQrE0ei http://play.golang.org/p/s53zQrE0ei
  - sounds 12y ago
    That's definitely shorter, but I would hope that isn't considered the most shining example of non-obfuscated code. :) (For code golf, though, it's just fine.)
    - NateDad 12y ago
      It's actually very simple code, if you're at all familiar with go. That's probably what I would have written just by sitting down at the computer to do so for work.
- NateDad 12y ago
  Yep, that's what I would have written.
- deleted 12y ago
  [deleted]
farresito 12y ago
Man, I've lately seen so many posts criticizing Go. They must have done something pretty well with it. It's sad that I see more posts criticizing Go than posts talking positively about it.
- QuercusMax 12y ago
  Sort of like my feeling about politics - if the far left and far right hate you, you're probably on the right track.
  - icebraining 12y ago
    Knowing its history, if you're really hated by the far left, you're probably part of it too :D
- nothrabannosir 12y ago
  To be fair, it feels like survivor's bias. People are more vocal about criticism. When you agree, well, what is there to say? Nothing, you just use it, instead. In that light, the actual usage statistics are probably a better metric of the language's success than the +/- ratio on hacker news.
- nemo44x 12y ago
  I hear you and I have been a fan of Go for awhile. But, it hasn't really done anything new, especially in regards to programming language theory over the last 30 odd years. It feels like another "developers, developers, developers" play and when you see ultra modern languages like Rust, you sort of get the feeling Go is half baked and without purpose.
  - MetaCosm 12y ago
    Its purpose is to help ship products. It isn't sexy, it isn't fancy, it isn't interesting, it isn't groundbreaking. If it doesn't help you ship products, don't use it. Go will continue to grow at the insane pace it has because it hit a sweet spot and cared about standard library and documentation. You will continue to see high profile successes because it doesn't try to be fancy, it tries to get out of your way so you can do that job of actually transforming data. So you can be a programmer and it can be a language, not a hobby. I am a language geek, I write DSLs on a regular basis for fun -- and I love any language that is DSL friendly -- but for actually getting my day to day "must ship", "must work", "must scale" work done -- Go to the rescue. Great docs, easy to train people on, ultra-simple spec, multiple compilers, easy enough to integrate C code, and a really great vibrant community.
fiber 12y ago
The most important point the author is missing is code readability - being forced to write opinionated code is one thing. Having a chance to read somebody elses code (or your own code 3 months later) and avoiding eternal debate on code formatting is priceless. Programming is not about being able to outsmart others, in particular not in a large-scale project.
- sheepmullet 12y ago
  ...every large scale project I've worked on has had a set coding standard and supplied auto-format tools either as IDE plugins or as part of the checkin procedure to make it easy to adhere to the standard.
bsaul 12y ago
I've had a hard time making up my mind with generics vs interface in go, but i think now that any compelling argument should be made using real world problem from a real world project. Nobody is coding the sum of a list of integers for all the various integer types. People more likely use custom types anyway, and only have to create operations on those custom types ( except maybe for go language designers themselves). So there's always a suspicion that somehow there should be a way to code something clean using interfaces only.
- kd0amg 12y ago
  People more likely use custom types anyway, and only have to create operations on those custom types ( except maybe for go language designers themselves). People developing whole applications use custom types. People developing libraries meant for general use seem to prefer not limiting their stuff to working with their language's comparatively few built-in types (at least, that's how things seem to go in languages with generics -- Guava's BloomFilter should work with any type, even if that type was created well after Guava was written).
  - bsaul 12y ago
    You're right, librairies developers are probably the one that should complain, and yet go is also famous for having a really extremely convenient standard lib (such as http), which means it should be possible. They are often built on top of a tiny set of orthogonal interfaces rather than generic types (see sort.Interface as an example of something quite low-level). So that's why i'd like to see real-world problems that illustrate some concrete examples.
    - kd0amg 12y ago
      It's no surprise that an HTTP library doesn't have issues with the lack of generics -- it shuffles text around. Reusable data structures are the obvious case for genericity, and I don't see many in the docs. Once you have a higher-order language (whether via objects or first-class functions), some control structures become data you might want to use generically. Looking over Java's stuff also shows some interfaces one might want to parameterize over a type (e.g., Comparable -- what can you compare this to?, Future -- what type will we get from it?). Haskell also offers a lot of examples of really exercising polymorphism (like lenses, but those maybe aren't appropriate for Go).
NateDad 12y ago
On my phone, but his examples just show that he's new to Go. He's using like 5x add much code as he needs to.
- wwweston 12y ago
  Possible explanations: * the author (and everyone else who complains about Go) simply hasn't made any appreciable investment in learning Go * the language itself doesn't naturally lend itself to most programmers easily finding the most succinct/powerful expressions available, instead providing a grain that favors clarity over other values * the documentation and tutorials available don't teach programmers how to write succinct and expressive Go
  - djhworld 12y ago
    > the language itself doesn't naturally lend itself to most programmers easily finding the most succinct/powerful expressions available, instead providing a grain that favors clarity over other values I think that can be said of pretty much all programming languages.
  - NateDad 12y ago
    It's not about the language or expressions. He just isn't very familiar with the standard library. His code was not unclear or overly verbose... it just didn't use libraries to replace most of his code. So, yes, it was exceedingly obvious that the author had not made any appreciable investment in learning the language.
transfire 12y ago
I have to agree about the generics, and agree a bit about error handling too. Also, I wasn't impressed by the speed. I wrote a program in Ruby, Go and Elixir and expected Go to win, but is was 1x, 5x, 20x respectively, and I could never figure out why there was such a discrepancy. Even so, if they added generics and improved performance, I would be very inclined to use it. It is surprisingly comfortable to code in.
- EugeneOZ 12y ago
  1 program in Ruby to measure the speed of whole language is not enough. https://xkcd.com/605/ https://xkcd.com/605/
- isaiahg 12y ago
  I would wager it was human error.
evmar 12y ago
It's pretty funny how this post is on the front page adjacent to a post profiling one of the Go authors that opens with mentioning his masters/PhD from Harvard/MIT.
- deleted 12y ago
  [deleted]
- EugeneOZ 12y ago
  And for more contrast, author of critique article can only brag "past few months I’ve been using Go to implement a proof of concept program in my spare time". I really hate articles from noobs who thinks they have a right to criticize something without being proficient in it. And not only about Go. At least HN comments are interesting.
PopsiclePete 12y ago
Ahhhh, he's a D programmer. That explains most of it. D programmers are only slightly behind C++ programmers in their universal hatred for Go. Rubyists can learn to love Go, Pythonistas can learn to love Go, NodeJs people even, but D programmers, man, it's like just the mere existence of Go is an assault on their very souls. If D and C++ programmers hate Go, it's doing something right.
- EugeneOZ 12y ago
  Go was built for C++ programmers, so your point is not valid.
- nothrabannosir 12y ago
  Awful ad-hominem. Who cares if all D programmers hate Go? Maybe for good reason. Or maybe they're just being erratic. Who knows? Not the readers of this comment, because it doesn't contain any constructive argument.
- saurik 12y ago
  I hate to have to refer to something so stereotypically "Hacker News" (as it was witten by Paul Graham), but this seems like a great example of the Blub Paradox playing out: C++ and D offer some really key features that all those other languages don't, so the reason you are more willing to tolerate Go is because you don't find yourself thinking "how could someone seriously have designed a language without these key features". Now, you might try to argue that it is somehow C++/D that are missing out, but FWIW: I have been programming in Python for seven years, and have probably at this point written as much if not more Python than I ever did C++, and the only reason I do it is because there are some "trivial" (and yet key) tooling and library advantages... the language itself honestly just feels "dumb".
- Grue3 12y ago
  No, it just means there is nothing in Go that would cause a D or C++ programmer to switch to it. The feature set of D and C++ is a superset of Go feature set. This "they laughed at Einstein, so I must be right too" mentality is pure fanboyism.
oh_sigh 12y ago
The odds of a single individual being an "intelligent" programmer is much lower than the odds of a team of all present and future programmers for a project being intelligent.
- oh_sigh 12y ago
  Uh..yes, I meant much higher, not much lower :(
zzzcpan 12y ago
Author's examples are really exaggerated, but there is definitely some truth. Bufio and flag packages are not that good. And "idiomatic" Go is full of poor abstractions. More often than not it feels like some things are written by OO programmers and are unnecessary hard. Like people don't know there are function literals in Go and they are free to abstract away state changes, instead of creating objects and spreading them all over the place.
- rogpeppe1 12y ago
  I'd like to hear more details of your issues here. What's not good about the bufio package? What do you mean by "poor abstractions"? What's wrong with creating a single purpose local type rather than using a function literal?
- natebrennand 12y ago
  The flag package might not be perfect but the author wasn't even using it properly so it's hard to judge it based off of this example.
djhworld 12y ago
The author is trolling or has some weird superiority complex, don't rise to it.
jacquesm 12y ago
Languages should be criticized by those that have spent sufficient time in them to be able to really see their shortcomings. Having a little bit of experience in a language is not an automatic qualification for writing blog posts about what's amiss, for that you need more than just surface familiarity.
- he_the_great 12y ago
  Seems to me the replies made to the "fake" problems are very telling about what is a problem. For example, Go is praised for being a simple language that everyone can learn quickly, yet when someone shows what they picked up "that isn't how you do it." I get that it is one thing to get something done, and another to learn an idiomatic approach. But when the sort package is hailed as the example for both why Go doesn't need generics and Go does need generics, I think it is safe to say that even the language creators don't know how to use Go.
east2west 12y ago
T
leonatan 12y ago
Good article, but the "would of" ruined it for me. Did you not proof read it even once to let such a horror through?
ereyes01 12y ago
If I wasn't already a Go programmer, reading this would make me more interested in Go than not. Simplicity is deceivingly challenging, and quite different from simple-mindedness, which seems to be what the author is accusing Go of being. Keeping code simple, elegant, and consistent is IMHO one of the most valuable principles a team can adhere to. Simple is not necessarily shorter, as short can often be subtle and sneaky rather than simple. Complex power tools can be fun to the inquiring mind, but the ultimate consumers of your product almost never appreciate how you built it, but almost always appreciate the final outcome. A wise man once said: “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian Kernighan
- meowface 12y ago
  There's also the argument that your chance of writing buggy code increases with each additional line you write. Highly readable code helps reduce bugs. But if that code is also so simplistic that it necessitates a lot of verbosity, you definitely increase the chance of introducing some stupid bug. Thankfully, as a compiled language, Go can find a decent portion of the silly stupid bugs where in a more expressive language like Python they might go hidden for longer, but it's still a big tradeoff you're making.
  - NateDad 12y ago
    Go is not significantly more verbose than python except in a couple trivial cases (list comprehensions become a 3 line loop). Across even a moderately sized program, this will most likely not even amount for a statistically significant difference.
    - meowface 12y ago
      As a professional Python developer and amateur Go dabbler, I very vehemently disagree. Without access to list/dict/set comprehensions, or libraries like itertools, or a lightweight lambda syntax or something like Ruby's blocks, transformations on collections will always be considerably more tedious and verbose. Various functions have "bring-your-own-buffer" calling conventions, which will often double or triple the number of lines required for those function calls. No tuple unpacking, no ability for functional programming (Python's isn't that amazing but with functools and some of the builtins, you can get pretty far), no operators for string formatting or anything but absolute barebones operations. Combine that with what Go lacks even compared to languages like Java (no inheritance [which is usually an anti-pattern but does decrease verbosity when used properly], no generics, no deep type/class reflection) and it's hard to say that Go isn't a verbose language. No statically typed language is going to be as terse or expressive as Python can be.
ukigumo 12y ago
hey man, don't say anything negative about the G. It goes on your permanent record! /s edit: apparently sarcasm does not go unpunished. ah well.
Corporate_Shill 12y ago
The irony of "Boiler-Plate Hell" is you're never too sure what anything does until you've memorized all the boiler-plate.
east2west 12y ago
This topic periodically flares and provokes so much emotion it is almost unseemly. The two camps are so diametrically opposed that I think other factors are at play here. Programmers who cannot or don't want to understand some of more advanced/esoteric features of expressive languages like C++ or Rust insist on the virtue of simple languages because it guarantees job opportunities for them. Their slogan is group power; quantity has a quality of its own. Interestingly, communists have similar slogans, who are mainly intellectuals self assured to govern/manage the mass and be handsomely compensated. I never realized the common interest between the top and middle, or how corporate the communism is. The other camp is equally vehement because their livelihood is at stake. If all their time and effort will not make them better/more productive programmers, the upper limit to their compensation is drastically lowered, not to speak of damage to their self-image and statue among peers. They are the liberal individualists who insist that there is no limit to what one individual can achieve or make. There is no need to debate this further. Everybody WILL not change their mind. Go will go far, just look at Java.
- robwilliams 12y ago
  >Go will go far, just look at Java. How did you reach this conclusion? I also don't understand the odd comparison to communism. Who's the communist in this scenario?
10098 12y ago
I tried Go. It didn't really impress me, to be honest. I get that they're trying to build a nice, coherent language and, but they do that by simply avoiding doing all the things that are hard. I don't see any compelling reasons to choose Go over, for example, Java.
- NateDad 12y ago
  Go uses a lot less memory than java in general (generally due to having real value types and usable pointers). Go has clean multi-threaded code baked into the language. Go requires no external runtime, so you never have to worry about what version of the runtime is on a machine. The implicit interfaces make it easier to keep separation of concerns, and prevent your code from turning into spaghetti.
ithkuil 12y ago
> In my opinion Go has been designed by people who have been using C all their lives and don’t want to try anything new. [..] > Another grating issue is that because Go is procedural (just like C ‘shock horror’) you start writing code in a procedural way which feels archaic and old hat. Ok, Go is not object oriented, but it has a few features that make it possible to do some stuff that are very cumbersome if not impossible in C. - first class functions and closures - you can safely take an address of a local variable and use it after the function's scope exits (the compiler takes care about promoting variables to the heap) - interfaces allow you write modular code: e.g. you can create your own Reader and Writer interfaces and the standard library can operate on it. People are focusing much about generics/templates but it's not that Go completely lack any way of creating modular and reusable code. - pointer/value distinction but having safe pointers by disallowing pointer arithmetics and instead providing runtime bound checking (slices) - garbage collection (this topic actually opens a can of worms of it's own, regarding the placement of the language on the spectrum) If you take C and add those features (instead of starting from another language and removing the features, see Blub Paradox) it's more apparent that it adds some value. One could argue that the comparison with C misses the point, given that one of the main reasons C is still alive and kicking is because of it's ubiquity and the fact that its calling convention is the de facto standard of modern operating systems, all of which is defeated by introducing a new language (with a non-C calling convention!) that doesn't even aim at the level of control (especially over memory allocation) that C gives. However that's where Go's cultural roots are. Well, except for the concurrency parts and other bits that were inspired from other languages, but when talking about sorting or reducing arrays, that part stems from the C culture. I have the feeling that one of the reasons Go is so successful, is that there are many people who would actually like C but recognise what a giant time sink can be to become proficient and write good quality software in it.

131 points by apta 12y ago

smt88 12y ago

I'd be really curious to know what this guy thinks of Rust.

davecheney 12y ago
I can confidently predict the author will decide that Rust has some nice attributes, but pales in comparison to D.
nemo44x 12y ago
I'm a bit curious too - he seems to hate the idea a programming language thinks the developer is an idiot. Rust, for how perfect it really is, treats developers as humans. You must be smart if you can use it - but it doesn't trust you to have any idea what's really going on when a program gets large. This is a good thing IMO. Honestly, anyone who thinks Rust is trash is just wrong. I can get the argument that there just will never be enough people who can use Rust but having learned Go and then Rust - I have to say Rust is the most well designed programming language ever. I can't believe what's in it and it's far and away the most advanced programming language ever. It's hard to compile but when it does you have a good chance it's right.
- smt88 12y ago
  Haven't seen anyone trash Rust yet. However, one thing I'll say is that it's a big problem for people like me if a language requires you to be smart to use it. It's really, really hard to hire only smart/experienced developers. What I need, and what I hope Rust can be, is a language that is opinionated (in the right ways) and won't compile if an inexperienced dev tries to do something dumb. In Rust, the fact that variables are immutable by default (but can be explicitly declared mutable) is the kind of thing I'm talking about.
- MetaCosm 12y ago
  Woah, I can't tell if that was a brilliant troll or you honestly believe these things -- either way +1 hilarious.
  - smt88 12y ago
    What do you dislike about Rust?
- kibwen 12y ago
  I heartily disagree that you have to be smart to use Rust. I'm a ho-hum CRUD web programmer with enterprise credentials and versed in dynamic languages, and I was able to pick up Rust quite easily as my first systems programming language ever. The hardest part isn't even learning the language, the hardest part is figuring out the essential differences that separate the systems programming domains and the high-level dynamic domains.
  - smt88 12y ago
    That's a great endorsement. I was going to do my next experimental app in Go, but this really makes me want to use Rust.

carbocation 12y ago

My summary of the author's points: no generics, inexpressive, no good package manager, procedural. Of these, caring about the fact that it is procedural seems pure opinion. Lacking a package manager is not really a language issue (PHP's package manager, for example, is not coupled to the core language). So, we are left with the lack of generics and the lack of expressivity. I'm not deep enough in the weeds to be able to argue pro/con for generics intelligently right now, so I will concede that as a concern that has been raised by many. The lack of expressivity seems to be an inexorable consequence of the goal of simplicity, so I'm sympathetic. That said, it seems to be a tradeoff acknowledged by Go's authors, not an oversight. Overall, these points don't convince me of the author's thesis (or, at least, they don't seem to justify the title's degree of inflammation).

sethetter 12y ago
"Expressiveness" seems like a subjective measurement to me. Also, from what I've gathered, Go attempts to be more convention oriented and is centered around doing things the "one true way". The Go formatter is an example of this. Perhaps this is just a result of that philosophy.
AlexandrB 12y ago
I thought the "sum" example was pretty damning. Bug count scales with code length so writing tons of boilerplate code to work around language limitations means you're introducing bugs.
- carbocation 12y ago
  I believe that the purpose of `go generate` is to lessen the risk of this type of thing by handling the repetitive code generation for you, but I do agree that it's a limitation. If done by `go generate`, it's an additional procedure that you have to learn; if done by hand, it's a bug risk.
  - meowface 12y ago
    Code generation is a giant spiked mallet for a nail which can easily be screwed with a small screwdriver. It has its uses, especially for generating schemas (like what Protobuf and Capnproto do), but for generating actual function implementations it's kind of absurd. `go generate` is a nice tool but it's not even remotely a solution to the no-generics problem. Of course, the problem is that for the compiler implementation, those traits are completely reversed (adding generics at this point is like hitting the compiler with a mallet); and that happens to be Go's primary excuse for lack of generics/templating/macros/anything sane. I think dev ease-of-use matters a lot more than core dev ease-of-use though. Even if the compiler must grow in complexity and average compile time, the benefits to devs are worth it.

staunch 12y ago

You shouldn't be offended that Rob Pike thinks he's a much more advanced programmer than your average programmer. He is. Whatever his motivations, he created a very productive language. As it turns out, even advanced programmers benefit from having a simple language when it comes to getting practical work done.

Someone1234 12y ago
> As it turns out, even advanced programmers benefit from having a simple language when it comes to getting practical work done. I'm making this point quite tongue in cheek however... By that logic why do programmers hate Visual Basic so much? At least VB6 was very much a "simple language" relative to other things around at the time (less so with VB.net/C#). A lot of the arguments people are making here (less is more essentially, and clear syntax wins over complexity even at the cost of efficiency) then VB6 should be something we're modelling modern languages off of, but it is not... PS - Remember I am not being literal here. VB6 had some issues both then and now. I am not really comparing Go to VB6, I am comparing the arguments made in support of Go to arguments that could be made in support of VB6.
- PopsiclePete 12y ago
  There's a difference between being "simple" and "brain-dead". C, for example, is very simple, simpler than Go, even, but you can't compare it to VB6 either. Your comparison is disingenuous at best. Simplicity is a good thing. It's a virtue. It's part of what made UNIX a success. It's not something to shun or avoid. Adding features adds complexity and complexity is not free. Notice how the industry still has't jumped ship whole-sale to Haskell?
  - waps 12y ago
    > Simplicity is a good thing. It's a virtue. It's part of what made UNIX a success. It's not something to shun or avoid. It seriously depends what you're doing. As someone put Haskell recently "all the possibilities of advanced algebra combined with all the clarity of advanced algebra". Simplicity is only a real success if it doesn't throw out the baby with the bathwater. > Adding features adds complexity and complexity is not free. And taking away features is free ? Why aren't you programming in LISP then ?

keithba 12y ago

"So Rob Pike is basically saying that the developers at Google aren’t very good so they’ve developed a dumbed down language so they can get things done." I read the Pike quote very differently. When Pike says: "The key point here is our programmers are Googlers, they’re not researchers." I thought he meant programmers today use google to assist them in programming.

jalfresi 12y ago
"The key point here is our programmers are Googlers, they’re not researchers." I took that to mean "Our programmers are building products, not thinking about building programming languages"
- AnimalMuppet 12y ago
  It may go even further than that. Google has to produce multi-million line programs and maintain them for a decade or two. That's not a problem that most programming language researchers face. If researchers think about that, they usually do so in the abstract, rather than from a position of personal experience. One place this shows up: Build times. Turning a 45-minute build into a 10-second build, times 30 programmers, times several builds a day for 10 years... that adds up to a really big difference.
  - MetaCosm 12y ago
    It always astounds me when (inexperienced) developers play down build times as if they simply aren't that big an issue. They are hellish, creativity crushing monsters. Also, static binaries -- so the DevOps guys don't hit you with sticks. I still remember the first go program README.md I shipped. "Umm, get foo to box, ./foo in a way so that it runs persistently and at startup." Easy way to get your apps to the front of the line in the deploy queue -- all the time.
robbrit 12y ago
"Googler" means "someone who works at Google". He's saying the language is designed for people who are in large, transient teams building large-scale production systems, not people who want to explore advanced programming language concepts.

deedubaya 12y ago

The author is basically saying that you'll be better off banging your head against a wall trying to figure out a more complicated language than to pick up golang quickly an start building something. News flash! Not everyone is a brilliant developer. And that's okay! News flash! Not ever developer has extensive programming experience and can pick up new concepts quickly. And that's okay! Go is too simple for you? Drink a big glass of shut the hell up and go write a program in brainfuck or something. Intelligent programmers aren't dependent on the language they use to become better developers. There is no disservice in being able to build something quickly.

sheepmullet 12y ago
Most of the negative reactions to Go aren't really to do with the language itself. They are more general feelings of frustration with our industry. Part of the reason Go is so popular is because we place such a low value on education, training, and long term productivity, and a high value on getting things done quickly. In general our industry is focused on the short term, is fad driven, and is more than willing to turn on our own. Go is a language created to win in this kind of environment. And because people hate the environment... they focus their animosity on the tools that are successful in our environment.
- 15155 12y ago
  > more than willing to turn on our own This "it's so simple!" nonsense is an exemplification of that. By reducing everyone (even good programmers) to the lowest common denominator, talent is far more commoditized and pluggable. You can throw away Programmer A because Programmer B is "as good as it can get for
moron4hire 12y ago
Syntactically simple language actually tend to be harder for new/less-skilled programmers, as they require the programmer to figure out how to do more things that more complex languages handle as simple expressions.

sheepmullet 12y ago

It's the difference between simple and easy. Go is very easy for existing developers to learn because it is basically a cut down subset of what they already know. Which makes Go a great option.... if you use it properly. It means you don't need to worry about a programmers language history when you hire even if you need them to be productive right away. It means you can hire the smartest developers, regardless of whether they have been doing embedded work, or spas in js, or large enterprise application dev in java, etc.

15155 12y ago
In other words: reduce everyone to the lowest common denominator.
- Gigablah 12y ago
  But I'm a special snowflake! This won't do!
  - sheepmullet 12y ago
    Of course a lot of good developers won't like it because it is a change that makes them worse off. If you are a good Haskell/D/Lisp developer then switching to Go will probably halve your productivity over the long term. There are a lot of benefits to using Go but lets not pretend there aren't any downsides.

intortus 12y ago

Just because you're intelligent doesn't mean you should spend all that intelligence trying to figure out other people's messes. Simplicity and explicitness are paramount when collaborating.

AlexandrB 12y ago
> Simplicity and explicitness are paramount when collaborating. So is succinctness (most people can't speed read code). The examples he gives make Go look anything but succinct.
- jff 12y ago
  That's because he's not a very good Go programmer, which is not surprising since he's clearly far too intelligent to use Go.
- intortus 12y ago
  At a certain point succinctness does more harm than good. Go captures nearly all of the sense of python's early values (https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/), without requiring all that much more in the way of boilerplate. So you have to if-check an error value here and there, no big deal. You should be handling errors anyway. If Haskell's succinctness level is 1, then I would rate python's at 2, go's at 4, and java's at 20.
  - dragonwriter 12y ago
    Presumably, that rating scales has higher numbers meaning less succinctness? Because otherwise the order of the numbers (much less there relative values) doesn't make any sense, even though that's kind of the opposite of what you'd expect of a "succinctness level".
    - intortus 12y ago
      It's a linear scaling factor for how many lines of code I tend to take to express the same medium-sized program across these languages.

barsonme 12y ago

His Go is a little disingenuous. This (https://gist.github.com/EricLagerg/105431503d32f18d239b https://gist.github.com/EricLagerg/105431503d32f18d239b) is almost as short as his D code, and functions the same.

jff 12y ago
It's almost as if, like most people who write articles complaining about Go's lack of "expressiveness" and generics, he took a cursory look at the language, wrote some naive examples that supported his point, and squeezed out a blog post.
- waps 12y ago
  If the code was equivalent you might have a point. Unfortunately it is not (tokenizing/line scanning vs. copying). One has a shortcut in Go, the other does not. Would you say that Go is not excessively verbose in non-trivial use cases ? I recently had to sort a struct list in a program. Added lines of code for sorting a single list once : 30. What the ...
  - okbake 12y ago
    I'm curious about the specifics of your problem. I couldn't imagine sorting a list of structs (by one of the fields I presume) would be too terribly different in Go than in other langauges. Heres an example of insertion sort on a basic type: https://play.golang.org/p/SPoiNRVl2B https://play.golang.org/p/SPoiNRVl2B You can use the standard library sort methods by making your type implement the sort interface. Heres an example taken from the example in the sort docs: https://play.golang.org/p/oeRIhHi1Ei https://play.golang.org/p/oeRIhHi1Ei
    - waps 12y ago
      This post contains a comparison : https://news.ycombinator.com/item?id=9267578 https://news.ycombinator.com/item?id=9267578
    - he_the_great 12y ago

nemo1618 12y ago

IMO, the author's "copy data to stdout" example betrays a lack of language understanding. Here's a more idiomatic version: http://play.golang.org/p/ZWatRuj3Q_ http://play.golang.org/p/ZWatRuj3Q_

QuercusMax 12y ago
Thanks! I'm just learning go (started last night), but I couldn't believe there wasn't a better way. It felt like a straw man example.
Cthulhu_ 12y ago
Plus given Go's focus on external dependencies, a common task like reading commandline parameters can (and should) be done with a library that solved that problem for you already - don't reinvent the wheel, and such.
zoips 12y ago
Kind of code golfing it: http://play.golang.org/p/s53zQrE0ei http://play.golang.org/p/s53zQrE0ei
- sounds 12y ago
  That's definitely shorter, but I would hope that isn't considered the most shining example of non-obfuscated code. :) (For code golf, though, it's just fine.)
  - NateDad 12y ago
    It's actually very simple code, if you're at all familiar with go. That's probably what I would have written just by sitting down at the computer to do so for work.
NateDad 12y ago
Yep, that's what I would have written.
deleted 12y ago
[deleted]

farresito 12y ago

Man, I've lately seen so many posts criticizing Go. They must have done something pretty well with it. It's sad that I see more posts criticizing Go than posts talking positively about it.

QuercusMax 12y ago
Sort of like my feeling about politics - if the far left and far right hate you, you're probably on the right track.
- icebraining 12y ago
  Knowing its history, if you're really hated by the far left, you're probably part of it too :D
nothrabannosir 12y ago
To be fair, it feels like survivor's bias. People are more vocal about criticism. When you agree, well, what is there to say? Nothing, you just use it, instead. In that light, the actual usage statistics are probably a better metric of the language's success than the +/- ratio on hacker news.
nemo44x 12y ago
I hear you and I have been a fan of Go for awhile. But, it hasn't really done anything new, especially in regards to programming language theory over the last 30 odd years. It feels like another "developers, developers, developers" play and when you see ultra modern languages like Rust, you sort of get the feeling Go is half baked and without purpose.
- MetaCosm 12y ago
  Its purpose is to help ship products. It isn't sexy, it isn't fancy, it isn't interesting, it isn't groundbreaking. If it doesn't help you ship products, don't use it. Go will continue to grow at the insane pace it has because it hit a sweet spot and cared about standard library and documentation. You will continue to see high profile successes because it doesn't try to be fancy, it tries to get out of your way so you can do that job of actually transforming data. So you can be a programmer and it can be a language, not a hobby. I am a language geek, I write DSLs on a regular basis for fun -- and I love any language that is DSL friendly -- but for actually getting my day to day "must ship", "must work", "must scale" work done -- Go to the rescue. Great docs, easy to train people on, ultra-simple spec, multiple compilers, easy enough to integrate C code, and a really great vibrant community.

fiber 12y ago

The most important point the author is missing is code readability - being forced to write opinionated code is one thing. Having a chance to read somebody elses code (or your own code 3 months later) and avoiding eternal debate on code formatting is priceless. Programming is not about being able to outsmart others, in particular not in a large-scale project.

sheepmullet 12y ago
...every large scale project I've worked on has had a set coding standard and supplied auto-format tools either as IDE plugins or as part of the checkin procedure to make it easy to adhere to the standard.

bsaul 12y ago

I've had a hard time making up my mind with generics vs interface in go, but i think now that any compelling argument should be made using real world problem from a real world project. Nobody is coding the sum of a list of integers for all the various integer types. People more likely use custom types anyway, and only have to create operations on those custom types ( except maybe for go language designers themselves). So there's always a suspicion that somehow there should be a way to code something clean using interfaces only.

kd0amg 12y ago
People more likely use custom types anyway, and only have to create operations on those custom types ( except maybe for go language designers themselves). People developing whole applications use custom types. People developing libraries meant for general use seem to prefer not limiting their stuff to working with their language's comparatively few built-in types (at least, that's how things seem to go in languages with generics -- Guava's BloomFilter should work with any type, even if that type was created well after Guava was written).
- bsaul 12y ago
  You're right, librairies developers are probably the one that should complain, and yet go is also famous for having a really extremely convenient standard lib (such as http), which means it should be possible. They are often built on top of a tiny set of orthogonal interfaces rather than generic types (see sort.Interface as an example of something quite low-level). So that's why i'd like to see real-world problems that illustrate some concrete examples.
  - kd0amg 12y ago
    It's no surprise that an HTTP library doesn't have issues with the lack of generics -- it shuffles text around. Reusable data structures are the obvious case for genericity, and I don't see many in the docs. Once you have a higher-order language (whether via objects or first-class functions), some control structures become data you might want to use generically. Looking over Java's stuff also shows some interfaces one might want to parameterize over a type (e.g., Comparable -- what can you compare this to?, Future -- what type will we get from it?). Haskell also offers a lot of examples of really exercising polymorphism (like lenses, but those maybe aren't appropriate for Go).

NateDad 12y ago

On my phone, but his examples just show that he's new to Go. He's using like 5x add much code as he needs to.

wwweston 12y ago
Possible explanations: * the author (and everyone else who complains about Go) simply hasn't made any appreciable investment in learning Go * the language itself doesn't naturally lend itself to most programmers easily finding the most succinct/powerful expressions available, instead providing a grain that favors clarity over other values * the documentation and tutorials available don't teach programmers how to write succinct and expressive Go
- djhworld 12y ago
  > the language itself doesn't naturally lend itself to most programmers easily finding the most succinct/powerful expressions available, instead providing a grain that favors clarity over other values I think that can be said of pretty much all programming languages.
- NateDad 12y ago
  It's not about the language or expressions. He just isn't very familiar with the standard library. His code was not unclear or overly verbose... it just didn't use libraries to replace most of his code. So, yes, it was exceedingly obvious that the author had not made any appreciable investment in learning the language.

transfire 12y ago

I have to agree about the generics, and agree a bit about error handling too. Also, I wasn't impressed by the speed. I wrote a program in Ruby, Go and Elixir and expected Go to win, but is was 1x, 5x, 20x respectively, and I could never figure out why there was such a discrepancy. Even so, if they added generics and improved performance, I would be very inclined to use it. It is surprisingly comfortable to code in.

EugeneOZ 12y ago
1 program in Ruby to measure the speed of whole language is not enough. https://xkcd.com/605/ https://xkcd.com/605/
isaiahg 12y ago
I would wager it was human error.

evmar 12y ago

It's pretty funny how this post is on the front page adjacent to a post profiling one of the Go authors that opens with mentioning his masters/PhD from Harvard/MIT.

deleted 12y ago
[deleted]
EugeneOZ 12y ago
And for more contrast, author of critique article can only brag "past few months I’ve been using Go to implement a proof of concept program in my spare time". I really hate articles from noobs who thinks they have a right to criticize something without being proficient in it. And not only about Go. At least HN comments are interesting.

PopsiclePete 12y ago

Ahhhh, he's a D programmer. That explains most of it. D programmers are only slightly behind C++ programmers in their universal hatred for Go. Rubyists can learn to love Go, Pythonistas can learn to love Go, NodeJs people even, but D programmers, man, it's like just the mere existence of Go is an assault on their very souls. If D and C++ programmers hate Go, it's doing something right.

EugeneOZ 12y ago
Go was built for C++ programmers, so your point is not valid.
nothrabannosir 12y ago
Awful ad-hominem. Who cares if all D programmers hate Go? Maybe for good reason. Or maybe they're just being erratic. Who knows? Not the readers of this comment, because it doesn't contain any constructive argument.
saurik 12y ago
I hate to have to refer to something so stereotypically "Hacker News" (as it was witten by Paul Graham), but this seems like a great example of the Blub Paradox playing out: C++ and D offer some really key features that all those other languages don't, so the reason you are more willing to tolerate Go is because you don't find yourself thinking "how could someone seriously have designed a language without these key features". Now, you might try to argue that it is somehow C++/D that are missing out, but FWIW: I have been programming in Python for seven years, and have probably at this point written as much if not more Python than I ever did C++, and the only reason I do it is because there are some "trivial" (and yet key) tooling and library advantages... the language itself honestly just feels "dumb".
Grue3 12y ago
No, it just means there is nothing in Go that would cause a D or C++ programmer to switch to it. The feature set of D and C++ is a superset of Go feature set. This "they laughed at Einstein, so I must be right too" mentality is pure fanboyism.

oh_sigh 12y ago

The odds of a single individual being an "intelligent" programmer is much lower than the odds of a team of all present and future programmers for a project being intelligent.

oh_sigh 12y ago
Uh..yes, I meant much higher, not much lower :(

zzzcpan 12y ago

Author's examples are really exaggerated, but there is definitely some truth. Bufio and flag packages are not that good. And "idiomatic" Go is full of poor abstractions. More often than not it feels like some things are written by OO programmers and are unnecessary hard. Like people don't know there are function literals in Go and they are free to abstract away state changes, instead of creating objects and spreading them all over the place.

rogpeppe1 12y ago
I'd like to hear more details of your issues here. What's not good about the bufio package? What do you mean by "poor abstractions"? What's wrong with creating a single purpose local type rather than using a function literal?
natebrennand 12y ago
The flag package might not be perfect but the author wasn't even using it properly so it's hard to judge it based off of this example.

djhworld 12y ago

The author is trolling or has some weird superiority complex, don't rise to it.

jacquesm 12y ago

Languages should be criticized by those that have spent sufficient time in them to be able to really see their shortcomings. Having a little bit of experience in a language is not an automatic qualification for writing blog posts about what's amiss, for that you need more than just surface familiarity.

he_the_great 12y ago
Seems to me the replies made to the "fake" problems are very telling about what is a problem. For example, Go is praised for being a simple language that everyone can learn quickly, yet when someone shows what they picked up "that isn't how you do it." I get that it is one thing to get something done, and another to learn an idiomatic approach. But when the sort package is hailed as the example for both why Go doesn't need generics and Go does need generics, I think it is safe to say that even the language creators don't know how to use Go.

east2west 12y ago

leonatan 12y ago

Good article, but the "would of" ruined it for me. Did you not proof read it even once to let such a horror through?

ereyes01 12y ago

If I wasn't already a Go programmer, reading this would make me more interested in Go than not. Simplicity is deceivingly challenging, and quite different from simple-mindedness, which seems to be what the author is accusing Go of being. Keeping code simple, elegant, and consistent is IMHO one of the most valuable principles a team can adhere to. Simple is not necessarily shorter, as short can often be subtle and sneaky rather than simple. Complex power tools can be fun to the inquiring mind, but the ultimate consumers of your product almost never appreciate how you built it, but almost always appreciate the final outcome. A wise man once said: “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian Kernighan

meowface 12y ago
There's also the argument that your chance of writing buggy code increases with each additional line you write. Highly readable code helps reduce bugs. But if that code is also so simplistic that it necessitates a lot of verbosity, you definitely increase the chance of introducing some stupid bug. Thankfully, as a compiled language, Go can find a decent portion of the silly stupid bugs where in a more expressive language like Python they might go hidden for longer, but it's still a big tradeoff you're making.
- NateDad 12y ago
  Go is not significantly more verbose than python except in a couple trivial cases (list comprehensions become a 3 line loop). Across even a moderately sized program, this will most likely not even amount for a statistically significant difference.
  - meowface 12y ago
    As a professional Python developer and amateur Go dabbler, I very vehemently disagree. Without access to list/dict/set comprehensions, or libraries like itertools, or a lightweight lambda syntax or something like Ruby's blocks, transformations on collections will always be considerably more tedious and verbose. Various functions have "bring-your-own-buffer" calling conventions, which will often double or triple the number of lines required for those function calls. No tuple unpacking, no ability for functional programming (Python's isn't that amazing but with functools and some of the builtins, you can get pretty far), no operators for string formatting or anything but absolute barebones operations. Combine that with what Go lacks even compared to languages like Java (no inheritance [which is usually an anti-pattern but does decrease verbosity when used properly], no generics, no deep type/class reflection) and it's hard to say that Go isn't a verbose language. No statically typed language is going to be as terse or expressive as Python can be.

ukigumo 12y ago

hey man, don't say anything negative about the G. It goes on your permanent record! /s edit: apparently sarcasm does not go unpunished. ah well.

Corporate_Shill 12y ago

The irony of "Boiler-Plate Hell" is you're never too sure what anything does until you've memorized all the boiler-plate.

east2west 12y ago

This topic periodically flares and provokes so much emotion it is almost unseemly. The two camps are so diametrically opposed that I think other factors are at play here. Programmers who cannot or don't want to understand some of more advanced/esoteric features of expressive languages like C++ or Rust insist on the virtue of simple languages because it guarantees job opportunities for them. Their slogan is group power; quantity has a quality of its own. Interestingly, communists have similar slogans, who are mainly intellectuals self assured to govern/manage the mass and be handsomely compensated. I never realized the common interest between the top and middle, or how corporate the communism is. The other camp is equally vehement because their livelihood is at stake. If all their time and effort will not make them better/more productive programmers, the upper limit to their compensation is drastically lowered, not to speak of damage to their self-image and statue among peers. They are the liberal individualists who insist that there is no limit to what one individual can achieve or make. There is no need to debate this further. Everybody WILL not change their mind. Go will go far, just look at Java.

robwilliams 12y ago
>Go will go far, just look at Java. How did you reach this conclusion? I also don't understand the odd comparison to communism. Who's the communist in this scenario?

10098 12y ago

I tried Go. It didn't really impress me, to be honest. I get that they're trying to build a nice, coherent language and, but they do that by simply avoiding doing all the things that are hard. I don't see any compelling reasons to choose Go over, for example, Java.

NateDad 12y ago
Go uses a lot less memory than java in general (generally due to having real value types and usable pointers). Go has clean multi-threaded code baked into the language. Go requires no external runtime, so you never have to worry about what version of the runtime is on a machine. The implicit interfaces make it easier to keep separation of concerns, and prevent your code from turning into spaghetti.

ithkuil 12y ago

> In my opinion Go has been designed by people who have been using C all their lives and don’t want to try anything new. [..] > Another grating issue is that because Go is procedural (just like C ‘shock horror’) you start writing code in a procedural way which feels archaic and old hat. Ok, Go is not object oriented, but it has a few features that make it possible to do some stuff that are very cumbersome if not impossible in C. - first class functions and closures - you can safely take an address of a local variable and use it after the function's scope exits (the compiler takes care about promoting variables to the heap) - interfaces allow you write modular code: e.g. you can create your own Reader and Writer interfaces and the standard library can operate on it. People are focusing much about generics/templates but it's not that Go completely lack any way of creating modular and reusable code. - pointer/value distinction but having safe pointers by disallowing pointer arithmetics and instead providing runtime bound checking (slices) - garbage collection (this topic actually opens a can of worms of it's own, regarding the placement of the language on the spectrum) If you take C and add those features (instead of starting from another language and removing the features, see Blub Paradox) it's more apparent that it adds some value. One could argue that the comparison with C misses the point, given that one of the main reasons C is still alive and kicking is because of it's ubiquity and the fact that its calling convention is the de facto standard of modern operating systems, all of which is defeated by introducing a new language (with a non-C calling convention!) that doesn't even aim at the level of control (especially over memory allocation) that C gives. However that's where Go's cultural roots are. Well, except for the concurrency parts and other bits that were inspired from other languages, but when talking about sorting or reducing arrays, that part stems from the C culture. I have the feeling that one of the reasons Go is so successful, is that there are many people who would actually like C but recognise what a giant time sink can be to become proficient and write good quality software in it.