24 ms·

Why Go Is Not Good (2014)

• pmilot 11y ago
  I like this article and I agree with most of what was said there. Against that type of point-by-point criticism, fans of a language will usually use the argument: "but that language was not designed for that!". Then the question becomes: What was that language designed for? My impression was that Go was meant to be a slightly higher-level systems language with better constructs for concurrent programming. With that in mind, it seems to me that Rust is just a "better Go".
  • masklinn 11y ago
    Rust's target of being a better C++ means it tends to be more verbose than Go, and less convenient in the short run (no built-in — let alone syntactic — support for evented IO and CSP)
    • steveklabnik 11y ago
      > (no built-in — let alone syntactic — support for evented IO and CSP) Channels are in the standard library[1], while async io is in an external package, almost everything is in Rust, and it is one of the packages that will end up making that jump to be in the standard library fairly quickly. [1]: and, isn't as big of a deal in Rust since we make shared memory significantly safer in the first place.
  • Veedrac 11y ago
    I can't really see a world in which Rust is a "better Go". Rust is one of the more complex languages in existence, largely because it competes with C++ and thus can't afford to lose many features nor do many things the easy way. Go is one of the simplest languages in existence. It's on the other side of the charts.
    • masklinn 11y ago
      > Go is one of the simplest languages in existence. No, not even close.
    • vvanders 11y ago
      Rust has many things that C++ doesn't have, and that's a good thing. I think you might want to spend a bit more time with Rust before considering it just another C++.
      • Veedrac 11y ago
        I know Rust has things C++ doesn't have, and vice-versa. I don't see how that changes my argument that it's competing, though. Consider inheritance vs. traits. Rust isn't able to stick with just traits because there are some things, though few, that are slightly faster with inheritance. So Rust is going to get some form of inheritance (in whatever form it might take). For every bit of functionality in C++, there is or will be some alternative in Rust, and that's by design. The same is not at all true for Go.
    • wyager 11y ago
      > Go is one of the simplest languages in existence. By what metric? I can think of a lot of simpler languages. Lua, C, Forth, all the theoretical dead-simple combinator languages you don't want to use (Lambda Calculus, SKI calculus, etc.), etc...
      • Veedrac 11y ago
        > Lua, C, Forth Are all simple, yes. That C is on your list is kind'a the point - Go is explicitly a spiritual derivative of C. But go down on the TIOBE index[1] and tell me what fraction of languages there are as simple as Go. It's not a large fraction. [1]: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
    • jbeja 11y ago
      > Go is one of the simplest languages in existence Are you saying that is simple because: 1) Is so anemic and have a relatively small specification? 2) Let you solve problems in the most simple ways? I could (maybe) kinda agree if you refer to 1...kinda.
  • tomekowal 11y ago
    Argument "that language was not designed for that!" is valid almost anytime anyone tries to criticize a programming language. Go was designed within Google for Google. Where your system has millions of lines of code and thousands of developers work on them constantly. So they thought about three things: compilation speed, memory management and concurrency. Go compiles fast, so you can iterate quickly. This requires giving up most of the compilation safety checks. They can be done by static analysis tools in parallel. Explicit memory management means, you can sometimes optimize this 0.05% memory on your program. This means a lot, when you run your code on million machines. Concurrency isn't hard in Go, but explicit memory management makes it harder than in Erlang for example (in Erlang, you have "share nothing" policy). Go is also very simple, so one developer won't be surprised by other developer using some obscure feature. That being said. I wouldn't recommend using Go outside of Google, Facebook or Microsoft. It solves problems, that companies and developers usually don't have. If you need always running and quickly evolving software - there is Erlang and Elixir. If you need guarantees on correctness, use static typing from Haskell. If you can resign from some guarantees to have grater control on memory, there is Rust. If you are writing in browser, there is Elm. If you want to easily transition from OO to functional programming - try Scala. If you need to prototype app for your startup quickly - there is Ruby. Every popular language has its purpose and its trade-offs. Rust isn't strictly better than Go, but with high probability, it is better than Go for your problem.
    • pmilot 11y ago
      Compilation speed is a very good argument for Go, yeah. That often seems disregarded in a lot of these sorts of comparisons, but it's a really important factor since it directly affects the level of complexity your language can have.
• grabcocque 11y ago
  My essential issue with Go is how much it feels like cargo cult language design. Compared to other emerging languages [Rust, Clojure, Elixir, Julia...], it feels inconsistent, half-baked, uncertain what it's for or where it's going.
  • cmrdporcupine 11y ago
    200% agree. I didn't feel consistency in what was included or excluded. It's too bad because a language with its general tone really should replace much of the use of Java and Python (and at Google, C++, which is still used in places where many other companies would use Java)
  • gohrt 11y ago
    Cargo cult, copying what? Go is the evolution of a design that was started before any of those other languages were dreamed up.
• joshbaptiste 11y ago
  https://news.ycombinator.com/item?id=7962345 https://news.ycombinator.com/item?id=7962345 << 527 days ago, 356 comments
  • bargl 11y ago
    Thanks for the link. I'm kinda happy this resurfaced because I missed it on it's first go around (pun intended) and I am happy I read the article. Its nice to see some of these language features that I want to see in my language as well.
• pbnjay 11y ago
  Go's biggest strengths for me around the tools and ecosystem, and code readability. I very rarely find myself wanting generic code, and when I do using empty interfaces make the code difficult to read. I don't want to start an imperative-vs-functional war or anything, but I've noticed many of the people complaining about Go seem to be functional programming aficionados. Is this because of how much they like embedding and abstractions, or is it because they're trying to put the square Go peg into the round FP hole?
  • dradtke 11y ago
    The things I tend to miss most in Go are the functional operations, so I'm inclinced to agree. On the flipside, when I'm programming in Rust or Haskell, I can spend a couple hours optimizing a particular expression until it feels "right", which sometimes never happens. It's incredibly fun, but it's not as much of a problem in Go, since it's not as fun to tweak.
  • TuringTest 11y ago
    I believe the imperative-vs-functional war is coming to an end. Now that structures based on Category Theory (generic types, lambdas, monads, futures/promises...) are being adopted by most mainstream programming languages, side effects can be described in a declarative way that is thread-safe and thus amenable to parallelism, will still allowing developers to write in a mostly imperative style. It's a rare instance where we can really get the best of both worlds. I'm optimist about future developments of PLs.
  • scribu 11y ago
    > I very rarely find myself wanting generic code, and when I do using empty interfaces make the code difficult to read. But is that unreadability due to the nature of generic code, or due to the empty interface hack that Go forces you to use?
• fideloper 11y ago
  Most of these arguments seem to be arguments between the pragmatism vs purity camps. I've switched between these camps before, and the lesson I've taken away is to use each when needed. (Altho I personally err on the pragmatic).
  • wyager 11y ago
    I believe you are incorrectly conflating pragmatism with monotony. I've found Haskell to be very pragmatic, once I learned how to apply it. I haven't re-visited Rust in a while, but I expect to use it very pragmatically once it matures and people start developing Rust tooling for embedded work.
• aikah 11y ago
  > I like Go Me too, and that's precisely why I kept complaining for a time about these exact stuff until I moved on to something else. People don't complain about the stuff they do not use, they actually complain about the stuff they have/want to use everyday. But that's a good thing for the remaining users on go-nuts, most people that complained moved on, which means that a good chunk of them stopped using Go. I really really wanted to use that language, the "you don't need that in Go" patronizing tone on the mailing list made not want to use it anymore.
• teps 11y ago
  The author list features, shows you can't solve them easily with go and then conclude that go is not good. With similar argument, I could list every feature of xml, show that they are not easily solvable with json and conclude that json is not good.
  • aikah 11y ago
    > that json is not good Json became the defacto serialization format, but in my opinion, Json isn't good for everything. Json and all its tools around it keeps trying to be like XML.
    • fooster 11y ago
      Exactly the point surely? Just because json isn't good for everything doesn't mean its not good. Just because you wish json had xslt support (for example), doesn't mean its not good either.
  • wyager 11y ago
    See the very end of the article :)
  • parenthephobia 11y ago
    I think JSON is a pretty terrible markup language.
• mydpy 11y ago
  When I first learned Python and Scala, they 'hooked' me practically instantly. As my ability with these languages matured, I learned their strengths and weaknesses, and (try) use the tools where their strengths are complimented. Trying Go had practically the opposite emotional response: It didn't take long to get a bad taste in my mouth while using the language (a lot of, where is feature X from my favorite language, and why does the Go approach feel so jagged by comparison?), and as I read blogs like this that emphasize the weaknesses of the language, I don't feel compelled to write anything using Go. With so many options, why bother with Go? Am I missing something?
  • ashark 11y ago
    The Good: Goroutines, the tools, the standard library, YAGNI to the bone, less testing needed compared with Ruby, Python et c, if you'd otherwise be using one of those. The Bad: Hard to keep DRY, writing testable code can require a bit more planning that one may be used to, frustrating newbie experience[1] [1] go command errors if run after installing if you don't configure it (set proper env vars) first, tools that are basically essential to having a good experience with the language aren't packaged with it and have to be tracked down individually (probably someone's written a nice shell script that takes care of that, but it's silly that that was necessary)
  • TeeWEE 11y ago
    Ever wrote a big program in python? Then you know it works at runtime. Not at compile time. Go comes with more typesafety while being a bit more verbose. Its a tradeoff.
    • Filligree 11y ago
      And yet Rust has more type safety, while being more concise, more expressive and faster. Which is the article's point.
      • oscargrouch 11y ago
        Yes, but is less productive than go. You need more to express te same. Rust is like a phone with a lot of buttons and commands, give you more options and freedom of choice. Go is like a simple phone with very few buttons which has enough to enable you the real purpose of the phone, to make phone calls. Its just more pragmatic, and that doesnt make it a sin. Particularly, i like to have options.. its good we have them all, and we can choose the right tool for the job.
• iand 11y ago
  Subtitle: "Go is not what I want it to be"
• tuyguntn 11y ago
  If there were GOOD language then all other languages will be dropped. Every language has its own disadvantage, but it doesn't mean its not good, thats just trade-off. For me main selling point of golang is small lightweight threads with event loop. You write sequential blocking code and you get concurrency built in.
  • quadrangle 11y ago
    That sort of total relativism is not a helpful perspective. There are definitely better and worse designs in the world, and the reason people do not drop the worse ones has to do with the network effects of adoption. Betamax was superior to VHS but adoption rates and support by movie publishers made VHS win.
    • quadrangle 11y ago
      Are people downvoting this because I didn't use a convincing enough example? Or because they think this is part of the anti-Go sentiment here? Or because they actually believe in total relativism? Sincerely curious. Maybe people aren't relativists but actually believe that markets are magic and always make the most deserving things win??
    • tuyguntn 11y ago
      Semi-joke: If we consider type system of Rust superior to Go, then adoption rates in Go world should increase. I love both languages, both has their advantages, but Rust lost community while changing syntax and versions were not stable until v1. Its not about total relativism, its about trade-offs.
• Kapura 11y ago
  I've used Go for a few projects and I think that people who point out all of the things that Go doesn't have and Go doesn't support misunderstand the language. The problem is that most big languages today are hammers, and they can are used to hit all sorts of nails to fasten all sorts of unholy planks together. Go is a screwdriver. Still good for construction, but you need to be using it in the correct way and you can't wail away at the problem the same way you're used to. Hammer people try to pound the screw in and get frustrated at the resistance they encounter. Perhaps they should instead ask themselves why the choices have been made, what possible benefits come from using a different tool. And you know what, maybe they just prefer hammers. Nothing wrong with that.
  • danieldk 11y ago
    I've used Go for a few projects and I think that people who point out all of the things that Go doesn't have and Go doesn't support misunderstand the language. This is the standard Go defense. 'It's not Go, it's you.' I have written some larger projects in Go, and I am in full agreement with the article - Go is a relatively weak and repetitive language, similar to pre-generics Java. So, why does Go gain so much traction? While it may be a weak programming language, this is often compensated by excellent tooling and easy deployability. Plus dyed-in-the-wool Unix users (me inclusive) never liked the JVM baggage that comes with JVM languages.
    • Kapura 11y ago
      Certainly Go lacks some features (generics) which are more-or-less standard in other large languages, but I think that's a sacrifice to the code quality gods (not that you can't write shit code in Go). To use another metaphor: if C++ and Java are motorcycles, Go is more like a bicycle. Smaller, easier to maintain, and more portable, but there are times when you might really wish you had a motor.
      • trimbo 11y ago
        > easier to maintain How do we know this? Has anyone written enough Go in an environment with a lot of engineers to make that determination?
• AYBABTME 11y ago
  Can we get over "it doesn't have feature XYZ"? Everybody knows it doesn't have generics and that it would be convenient. Doesn't make the language intrinsically bad. There should be a point where a problem has been talked about ad-nauseum. I think people saying this will fall on deaf ears misunderstand that the Go community has been there, done that. We all know it, we'd like to have it and the Go team knows about that, and they stated why it's not there yet (because the tradeoffs available to them aren't interesting enough to make a decision with either implementation). Until this changes, I think we can all just get over it.
• the-tomster 11y ago
  The author says that "all the problems listed here have already been solved" by Rust and Haskell. Great, so let's stop complaining about Go and use those languages instead. Go has specifically rejected the complexity that these features introduce, both in the implementation of the language and the writing of programs in it. If you want those features, just use a language that has them. Some other people might not care about those features, and prefer the simplicity of Go, and that's fine too.
  • dchesterton 11y ago
    Precisely. Just because a language lacks certain features available in other languages doesn't mean it's not 'good'. Things that are 'good' for me: Good concurrency primitives, single binary deployment with no dependencies, a language that can be picked up in a matter of days and a consistent coding style (gofmt). If another language suits you better than use it, but to call Go "a regression from other modern programming languages" ignores the many reasons developers are using it.
  • wyager 11y ago
    > Great, so let's stop complaining about Go and use those languages instead. That's not a very good attitude. Some people have to use Go (for work), so it doesn't make sense to just ignore them. If every language had the attitude "It's fine as it is, stop complaining", then languages would never improve!
    • geodel 11y ago
      I think this attitude is just fine because it does not make assumption about what is improvement for a particular language users which you seem to be making. Some user wants improvement ,ok fine, but then what about users whose experience deteriorate after those alleged improvements.
  • wwweston 11y ago
    > The author says that "all the problems listed here have already been solved" by Rust and Haskell. Great, so let's stop complaining about Go and use those languages instead. I applaud your advocacy. Using other languages is pretty much my personal plan. The problem, though, is that like everybody else in the industry, I don't work in a vacuum. Other people may be making platform decisions for projects I work on. Complaining about Go's limits seems like a good additional strategy to minimize the chance that I'll have to work around them again in the future.
• andrew_wc_brown 11y ago
  Go is good enough when you're switching from Ruby to Go and all you do is build web-applications. * Its forced syntax stops syntax wars. * Compiling down to one binary makes deployment easy. * Its has concurrency out of the box. * Its insanely fast. * A strong community to hire developers easily enough. Does Haskel/Rust have the same criteria? Shurgs
  • orvado 11y ago
    I believe all of these are good points. The keywords are simple and concise and I believe the language constructs such as interface{} and sub-typing were designed to ensure compilation and running are insanely fast. Google is famous for optimizing their server applications and Go appears to be their "go-to" language of choice for all future web application development.
    • codygman 11y ago
      Interface{} (not interfaces as a whole) and subtyping would make compiling slower. I think sum types and pattern matching would compile faster and be more sensible.
  • 15155 11y ago
    > * Its forced syntax stops syntax wars. Okay, but so does any in-company linter. > * Compiling down to one binary makes deployment easy. Rust and Haskell are both compiled to a single binary, typically, and both can be statically linked (with some work.. this is getting better) > * Its has concurrency out of the box. Rust is actually a systems language and does not have a decent semblance of concurrency (beyond OS threads, which it does very well) because it is very difficult to actually introduce/keep consistent at that level. (AKA: Why green threads were removed) Haskell has one of the most advanced runtime systems of any modern language, and it does support Go-esque concurrency/parallelism (along with every other concurrency style you might want - as libraries). As a bonus: in Haskell, you don't typically need to worry about the dangers of multiple concurrent or parallel routines manipulating state in unsafe ways, etc. STM is pretty great, too. > * A strong community to hire developers easily enough. If you want a "Go developer" - there are plenty of them. If you want a strong generalist who can learn the technologies you are working with (be it Rust, Haskell, whatever), there are plenty of those, too. Go does seem like it reduces developers of all skill levels to some common denominator, allowing easy termination/hiring. Whether or not this is a good thing is debatable.
• jkaptur 11y ago
  Using the author's standards, adding features to a language is always a good idea. > All well-written code is easy to read, and most poorly-written code is hard to read. Obviously Go can't change that. I completely disagree. Languages with lots of features can make poorly-written code vastly more difficult to read.
• tomasien 11y ago
  This is the most HN headline of all time
  • harryh 11y ago
    "Why Go Is Not My Favorite Programming Language" would have been even better given the historical nod.
• cmrdporcupine 11y ago
  While many of these points (on generics especially) are completely legitimate, this article will fall on deaf ears. My impression of the Go community (both within Google and outside of it) is that there is a very ... moralistic? .... sense of "You don't really need that, we know best" going on. It aims to be a pragmatic language. But IMHO the anemic nature of the type system is a practical handicap that they have made a point of pride out of not addressing. It leads to boilerplate code and fragile code. I am no academic language snob -- I like Rust, and have been known to like me some C++ templating, sure, but I can understand a critique of complicated type systems that laypeople cannot understand. But after my brief exposure to Go, I was very very frustrated. I don't think it really solves the problems it says it's solves.
  • grabcocque 11y ago
    Any critique of Go seems to be met with angry pitchforks in this place. As you say, the Go developers seem to have developed a kind of bunker mentality where they interpret legitimate criticisms of the language design as personal attacks, and respond by wearing Go's shortcomings as a badge of honour. It's not, I think, entirely healthy.
    • hitekker 11y ago
      Is the bunker-mentality a recurring pattern for all Google OSS? I've heard people talking about it in Dart, Angular, and V8/Chrome, and I'm not sure if it's true or not.
      • lmm 11y ago
        I don't think it's Google specific. I'm quite a Scala fan but there was a time when many of us, probably myself included, had an unhealthy bunker-mentality.
    • bndr 11y ago
      > Any critique of Go seems to be met with angry pitchforks in this place. You can say that about any language. The people that like the language will always defend it. e.g. PHP, C, Ruby. They all have flaws and yet when one talks about their shortcomings, the people get defensive.
• gendoikari 11y ago
  We'll see in the next few years... We'll see...
  • innocentoldguy 11y ago
    I don't think a language's popularity has anything to do with it being a good, well-thought-out language. Just look at Javascript.
    • kentor 11y ago
      Javascript is pretty good.
      • parenthephobia 11y ago
        Counterpoint: Javascript is pretty bad. There is a brilliant language that looks like Javascript that is the language you might be thinking of when you say "Javascript is pretty good". Unfortunately, that language only exists in people's heads. In practice, Javascript is full of crazy weird edge cases where it is required to behave in an insane manner because the browser vendors have all been juggling the idiot ball amongst themselves when implementing it. e.g. https://medium.com/@daffl/javascript-the-weird-parts-8ff3da55798e https://medium.com/@daffl/javascript-the-weird-parts-8ff3da5...
        • gendoikari 11y ago
          I like Javascript. I don't see any problem with the language itself. I see problems with the browser ecosystem as a whole, but that's another story. I understand the argument "popular != good", but I think that if in the long term a tool raises in popularity this is not random. There should be reasons for that.
    • thegeekpirate 11y ago
      Javascript is a very poor analogy since it's been grandfathered into our workflow, and has coincidentally been shoehorned into being workable, at the very least.
• fixermark 11y ago
  "Go does not support operator overloading or keyword extensibility." Very much working as intended, I believe. Experience from languages that support those features has shown that what we gain in the very few situations where those extensions make sense (such as defining mathematical operations on vectors using the same symbols that are used in vector mathematics), we lose in too many developers thinking they have a clever shortcut that an existing operator would be perfect for, to the detriment of readability and comprehensibility. This is also the era of code-analysis-by-search-engine, and operator overloading harms that feature significantly. If I need to find all instances of vector addition in my code and I'm searching for '+', I'm going to have a bad time.
  • cmrdporcupine 11y ago
    I agree that operator overloading is probably a feature not wanted in a language with this target problem domain. However "working as intended" I think is also the response of Go to their lack-of-generics, which I think is kind of crap.
    • gendoikari 11y ago
      About generics, this is highly debatable. This is a design choice, it's not a decision made by accident. You'll surely gonna have boilerplate code in some cases, but all the language will be a lot more readable, and simple. Simplicity it's the most wanted feature of Go, from the designers perspective, I think. In the long term it's preferable to have explicit and simple code, instead of complex magic. This is a correct view? We'll see. Honestly I'm starting to appreciate that. They may have a good point.
      • moultano 11y ago
        Without generics, you can never write a type safe datastructure. I can't imagine the hubris that thinks the language already contains all of the datastructures it needs.
        • 11y ago
• joined 11y ago
  If anyone is looking for the article publishing date (no indication on the site), archive.org made the first snapshot on June 2014.
  • tvon 11y ago
    Thanks, I found "<!-- 2014-06 -->" in the source as well, but it drives me nuts when web pages have no publishing or last-modified date.
  • carols10cents 11y ago
    Yeah, I suspected it was old when the Rust version used was 0.11...
    • hatsunearu 11y ago
      The most often encountered thing that I find Rust frustrating is how much the language changed over time--lots of random answers and posts that are outdated floating around somewhere that I have to throw out because the language changed.
      • krisdol 11y ago
        It's just incredibly young at this point, and still in a phase where making breaking changes for the sake of the language vision is acceptable. Swift has been in the same boat. I'm sure that will change in the near future. Luckily both languages have great compilers that catch backwards-incompatible issues.
  • SuperKlaus 11y ago
    Previous discussion: https://news.ycombinator.com/item?id=7962345 https://news.ycombinator.com/item?id=7962345
  • insulanian 11y ago
    I love your user id :D
• Zikes 11y ago
  I like Go. It's fun, it's fast, and it's introduced me to a lot of programming concepts I had never used before. The one thing that seems to be missing from these discussions is that Go fits in an unexpected niche. I come from a web development background. I grew up on Perl, ASP, PHP, and Javascript. I dabbled a bit in C in college, but I always felt like I was fighting to avoid shooting myself in the foot with it. For me, Go was a huge step up, with an extremely friendly and approachable syntax, comprehensive standard library, and great toolsets. On the flip side, we've got a bunch of C/C++/Java developers who would rather compare it to what they've been using for decades. I've no doubt it's missing a slew of very important features from that perspective. Go does seem to be capable of many of the same things as those languages, so those criticisms are likely valid, but for those of us that aren't trying to use it as a low-level systems language it's still pretty great. Go could probably be improved in a lot of ways, but at the moment it serves my needs really well. For me, Go is good.
  • mike_hearn 11y ago
    I think the main question then is, why don't you take a look at more modern languages than Go and see if you have the same experience (fun, fast, introduces to new programming concepts)? You could start by checking out https://kotlinlang.org/ https://kotlinlang.org/ - it targets the JVM so the tools are much better than what Go has and the library ecosystem is much larger. The language is a straightforward imperative style language that will remind you of Go. It also will take just a few days to learn, at most. But it has a slew of features Go does not have which have been proven in many of the world's biggest and most popular languages.
    • Zikes 11y ago
      That's a bit of a slippery slope, though, isn't it? I'm already doing everything I want to do with Go, so all of the things it's "missing" don't really matter to me. If we had to learn and switch languages every time something implemented a feature the other did not have, we'd be refactoring our code every other week, wouldn't we? That's not to say those other languages don't interest me, or that I would eschew learning for the sake of learning. I've been eyeballing Rust for a while, and I do think it may someday fill the role Go currently fills for me, but for the type of coding I currently do Go is more than sufficient.
• evmar 11y ago
  This sort of gratuitous takedown is unfortunately crack for HN -- pages and pages of "here's how this popular thing is not like this other thing I like", without any thought given to why things are they way they are. Go is missing a lot of my pet features too but I know its authors are smart so I don't just immediately jump to assuming they don't know what they're doing. Thought experiment: write a proposal that works through adding algebraic data types (or even just special-case the error handling as option types, if that is easier) to Go. I've tried it; I found that doing so brings up a bunch of other problems that don't make it an obvious solution. (E.g. you'll want a "match" operator. And then that means you need all statements work as expressions. And you'll have to change how zero values work, which are pervasive throughout the language.) And I really like algebraic data types in Haskell. At some point if you really want Haskell you should just use Haskell. Or Rust. And then you will find out that those languages have problems too, and you will understand that engineering is a question of tradeoffs, not of feature checklists like this blog post.
  • moultano 11y ago
    While a proposal would be better than a takedown certainly, I do think this kind of language advocacy has value. People don't generally get to choose the languages they work in, the industry chooses for them. So if you don't want to work in a language you dislike, writing things like this is necessary. I tried a project in Go and really disliked it. For my personal projects, I will not start another one using it. But there are already situations where I have to write Go if I want to do my job. If I don't want that set of situations to grow I have to speak up.
  • zippoxer 11y ago
    This article looks to me like a list of personal preferences presented as facts. There's much more depth to language design than what the author presents - a checklist of must-have features that are "obviously better".
  • pcwalton 11y ago
    > E.g. you'll want a "match" operator. And then that means you need all statements work as expressions. And you'll have to change how zero values work, which are pervasive throughout the language. You don't need to make everything an expression for pattern matching to work. See Bjarne's C++ proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3449.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n344... You might have to change zero values, although you could make algebraic data types all be nullable if you wanted to avoid doing that.
• skybrian 11y ago
  I think the answer for people who want this sort of thing is to write a Go++ that compiles to Go. If it's a good enough solution then it will convince the community to move forward, at least on some features.
  • nanodano 11y ago
    Go is still young and I think it will expand over time. I think they wanted to start with a simple language and grow it carefully. One of the biggest complaints is generics and they compare it to Java but even Java didn't have generics at first.
    • skybrian 11y ago
      And how do you think Java got generics? There were experimental offshoots of Java (for example, Pizza and GJ) before Java 5. The authors went on to help design the generics in Java 5. I don't see a similar effort to improve Go, at least not yet.
  • dvirsky 11y ago
    There were a few attempts to do this with generics, some seem decent. But I've always found myself preferring to write a few extra lines than using such a language extension. It boils down to tool support for me. If you can't have code completion and things like gofmt, no one (well, at least not me) is going to use such a thing.
• fixermark 11y ago
  For me personally, it's not what the language offers syntax-wise but what I can do with it. I was excited about Ruby because of Rails; only after working with it did I pick up a book on Ruby itself and come to appreciate the cleverness of block arguments (Ruby's insight, that functions that accept another function as an argument almost always accept at most one, so special-casing the syntax for that to make it clear, was really quite clever). And then I migrated away from using Ruby when I started to care about execution speed and couldn't escape the feeling that I was investing more time keeping up with the framework changes than I was writing my program. For Go, I can write fast web servers in it. That's what I want, and it shines for that use case. I haven't looked at Haskell for that use case yet. Rust is still figuring itself out in that space (http://arewewebyet.com/ http://arewewebyet.com/). Go, in contrast, has a very solid commitment to backwards compatibility until the major version number changes. So my general take on Rust and Haskell, specifically, is "Wake me when it's cooked."
  • quadrangle 11y ago
    Haskell can do fast web servers. See Warp
    • HelloNurse 11y ago
      I don't care about fast web servers if a language doesn't have a decent design (rather than tolerable hacks and bolted-on libraries) for records, arrays, hierarchical namespaces, mutable data structures, strings, exception handling, compile-time dependencies, the standard library in general, system calls, etc.
      • innocentoldguy 11y ago
        Personally, I would say that immutable data structures and pure functional programming ARE a decent design; especially in web programming.
  • steveklabnik 11y ago
    Are We Web Yet has pull requests outstanding for 11 months, it has not been accurate in a long time.
• 72deluxe 11y ago
  Very informative, thanks! Looks like I'll be sticking with C++11 onwards from now on, despite its flaws and the ability to do dangerous stupid things. Even better, it is backwards compatible so there is an abundance of usable existing libraries for it. (On reflection, it can do dangerous stupid things but in truth it would be entirely my fault for doing dangerous stupid things, so best not blame the language for my stupidity). A very informative article though, thanks!
• insulanian 11y ago
  When one mentions Go, I imagine the crowd. When one mentions Haskel/OCaml/F#, I imagine an artist.
  • oscargrouch 11y ago
    Whats the problem in enabling more people to program computers like Python, Go and Javascript does? And the most funny thing about this arrogant attitude for some languages, is that the greatest popular tools, and the "killer apps" tend to occur in those languages.. as a indication that there is actually pretty smart people using the language contrary to common believe. So is more likely that the "artist" might actually end using Go than Haskell
• poorman 11y ago
  The blogger has completely missed the entire purpose of Go. I suggest anyone who actually wants info one way or the other to read the Preface in Alan Donovan and Brian Kernighan's "The Go Programming Language". You will then understand why Go is the way it is and why all the negative points (in his mind) this blogger listed, are not in the language.
  • wyager 11y ago
    > read the Preface in Alan Donovan and Brian Kernighan's "The Go Programming Language" I have read it :) I think it's both misguided and misleading. It's misguided because they have the wrong idea about simplicity, and it's misleading because they claim that Go is "radically simple". Go isn't really that simple; it's just inconveniently incapable.
    • SneakerXZ 11y ago
      Well said!
    • AnimalMuppet 11y ago
      > It's misguided because they have the wrong idea about simplicity... No, it's not your idea of simplicity. It's not wrong, it's different. That's all. You're falling into the "my way is the right way" arrogance that so many here are accusing the Go advocates of.
      • wyager 11y ago
        >No, it's not your idea of simplicity. It's not wrong, it's different. What is your point? That words have no objective meaning and no one can ever be wrong ever? I'm operating under the assumption that most people have a definition of simplicity that's similar to mine. Go is not simple under a very broad definition of "not simple". I'm not saying using Go is the wrong way to do things; I'm saying this classification is misleading.
        • AnimalMuppet 11y ago
• iffycan 11y ago
  As feedback on the article itself, I kept getting confused. The author describes a wish: > If I write a function to sum a list of numbers, it would be nice if I could use it on lists of floats, lists of ints, and lists of anything else that can be summed. I agree with the author and continue reading, expecting to see an implementation of that function in each language. I keep reading and re-reading to try to figure out how the first two code samples (Rust and Haskell) are summing a list. I feel like an idiot, because I can't figure out how that code is possibly summing a list. Thankfully, the next paragraph explains it, but a heads up would have made it more clear. The article continues with pairs of Rust and Haskell -- as a reader, I'm thinking, "Yes, yes, but show me how this compares to Go." Finally, when I get to `Go's Solution: interface{}` I feel like I'll be able to compare the languages... but instead of implementing an already-mentioned problem, a new problem is introduced: > Let's say you wanted to write a function that printed a hash code for objects that could be hashed. As a reader, I have too many things in my head now. I think the author probably has valid points to make, and I will now finish reading the article. Hopefully some of this feedback is helpful (I'm not trying to be a jerk).
  • wyager 11y ago
    Thanks for the feedback! I did that in an effort to be fair to Go. You can write a generic Hashable interface in Go, so I started with that. The very next example is why you can't make a generic sum over a list in Go. I didn't want people to get the idea that Go didn't support any sort of genericism at all.
• amelius 11y ago
  The ugliest part of Go, imho, is that in some situations it may appear as if nil != nil. See for example the confusion in [1], and for an explanation, [2] [1] http://stackoverflow.com/questions/21460787/nil-slice-when-passed-as-interface-is-not-nil-why-golang http://stackoverflow.com/questions/21460787/nil-slice-when-p... [2] https://golang.org/doc/faq#nil_error https://golang.org/doc/faq#nil_error
  • tjholowaychuk 11y ago
    I'd have to agree! Some little quirks like this sort of make sense after they're explained but they're certainly not intuitive. Assignability is another that I find awkward, I had to dig around to find the reasoning behind named/unnamed types being handled the way they are.
• issaria 11y ago
  This post seems to rising from ash. Definitely saw it on HN year ago. I don't want to say the word "perfect language", but there is no such language that can meet the demands of every nerd on the planet, the goal of the Go programming language is stated clearly, compiling speed overweight the needs for generics, that's why LLVM is not considered for the go compiler. Also the language is considered feature complete, if one doesn't want to met with "angry pitchforks", do the homework, e.g. the generics topic has been picked up over and over, that it's not funny anymore, if you are interested, the amount of debate online can take days to read.
  • wyager 11y ago
    >This post seems to rising from ash. Definitely saw it on HN year ago. Looks like I wrote it in June 2014. Someone posted it here after I asked for feedback on /r/rust, so it's been almost a year and a half! It pops up every once in a while :)
  • doodpants 11y ago
    One of my big peeves is when a blog does not have a date stamp at the top of each post. Some have the date at the bottom of the post, which is less convenient, but at least it's there. Others don't have a date stamp at all, but you can guess when the post was written by looking at the date of the earliest comment, or the date is included as part of the permalink URL. Will Yager's blog seems to have no possible way of determining when a post was written. Which is especially frustrating since the very first paragraph of the post in question includes the phrase "at the time of writing". Well, when was that!?
• erjjones 11y ago
  Go is "trendy" and will fall right in line with Ruby on the trendy block. They'll have block parties together and "Go" swing dancing. Wait, that was a fad too and a pun.
  • innocentoldguy 11y ago
    Not in my mind. I'd invite Ruby to a party. Go is who I would go to for a colonoscopy or prostate exam.
• frik 11y ago
  Go is pretty good for various use cases. Before that, one coded web services and server tools in C, C++, Java, etc. - nowadays Go is ideal for the task. It has the advantages of Java (JIT, strings, higher level concepts, inbuilt concurrency, etc), is fast and shares the simplicity of the C syntax.
  • deleted 11y ago
    [deleted]
• jmquigs 11y ago
  There are some things I like about Go: 1) really fast compilation speed 2) goroutines 3) gofmt But I learned F# after learning Go, and it felt like I was walking out of Plato's cave. Its hard to use a Go-like language after using the ML-style features described in this post. Most modern static languages shift the debugging from run-time to compile-time, which is a huge win in my opinion, but Go does not do this. You don't even need to go "pure functional" to get the benefits (as in Haskell), Rust/F#/OCaml are fine.
• poofyleek 11y ago
  These points are valid but miss the point of Go. To judge Go, as any language or tool, one must program in it for a while -- say a year or two -- and build substantial programs that serve specific needs. The outcome of such experience is clear indication of a tool's usefulness. I started as a very skeptical user of Go. Now I cannot live without it.
• tjholowaychuk 11y ago
  I think this post neglects the fact that one of Go's biggest strengths has almost nothing to do with the language. A huge portion of every-day logic is implemented very well, and very consistently in the stdlib. Personally I don't want to go pick through half-baked third-party packages, mix and match concurrency models or GC. I have experienced enough of that in Node and it's not pretty. Having it all consistently implemented in the stdlib is a great feature. Go not being cute was also something I found attractive, I'm not particularly worried about how much I type, because typing has never been a bottleneck. I prefer that code is easy to comprehend. My biggest problem with Go as a language is the arbitrary nature of some aspects when it comes to assignability etc. When Rust or Haskell can say the same I'll definitely invest in them but until then it's just not a problem. I don't think it's about one language being academically better than the other, it's what is best right now for the job you're doing. I want those languages to do well of course, more options the better, but for now Go ticks the right boxes for a lot of people.
  • x1024 11y ago
    But... Python already exists? Sorry to go all old-school on you, but the quality of Python's stdlib has literally been a part of pop culture for more than half a decade: https://xkcd.com/353/ https://xkcd.com/353/
    • deleted 11y ago
      [deleted]
    • thegeekpirate 11y ago
      > But... Python already exists? He never said Go was the only language which had a wonderful standard library, only that it's > one of Go's biggest strengths
• bluepill 11y ago
  there we Go again. why spend time writing about something you don't like? Is it a therapy for programmers with strong opinions?
  • 15155 11y ago
    > something you don't like? Because you may be forced to use it at work.
  • parenthephobia 11y ago
    It is possible to like things but not think they are perfect. Every time Go has ever gotten better was because somebody who liked it thought it could be improved.
• bfrog 11y ago
  After having been the primary author on a large go program, I'd personally never choose it again. It fails to help solve several major issues where other language like swift and rust seem to solve them wonderfully. Just looking at the Option<> type in Rust alone makes you wonder just how many places have you really forgotten to check or write tests to verify you check for nil values. Probably too many. That one thing is enough of a win over most languages today that I'm sold on the concept entirely. Can we all agree to raise our pitchforks and torches in the general direction of the terribleness that is null? And how would someone implement Option<> if not for type generics. Because of the lack of type generics in Go your stuck writting run time tests for things like type conversions and nil value checks. A complete waste of precious developer time. Thats the real loss. Time.
• tmaly 11y ago
  I was not sure about Go, but I tried it out, and I like the language. It was easy to learn, has a good tool chain, it has a good standard library, and the community produces code for things not available in the standard library. I have traditionally used Perl for most things, but Go fills a nice spot for small servers on the backend. I think if you need generics for your project, C++ and Rust are waiting for you to pickup and start using. If you want embedded programming, C is there for you to pick up. If you want fancy type systems, Haskell is there for you to pick up. No one language can be everything to everyone. Choose the tool with the features you need.
• pinn4242 11y ago
  Serious here--what is the color between black and white?
• karmakaze 11y ago
  > I like Go. I use it for a number of things (including this blog, at the time of writing). Go is useful. With that said, Go is not a good language. It's not bad; it's just not good. It's all right there. Go has good uses. But it's not good for some things including as an example for a 'good' (for some definition of good) typed language. Also Go has generics: array/slice, map, channel. You just can't create others.
• DubiousPusher 11y ago
  I'm not switching to a language without a mechanism for type safe generic programming any time soon. But I will say, the simplicity of Go probably makes it much easier to keep the compiler fast and reliable.
• platz 11y ago
  > no runtime overhead from generic programming. Not really the full truth, since the monomorphic version in haskell can possibly be unboxed reducing a level of pointer indirection.
• lohengramm 11y ago
  I like the article. It is well written and very informative. However, one could just omit the word "Not" in the title, becoming "Why Go Is Good", and it would still be a valid article. In short, the author just points out features that Go could have but doesn't, which is not a good argument for saying that Go is "unconditionally" bad. All those missing features are missing on purpose, they are not bugs nor there is some kind of inherent defect in the language. To me, the only two things that really bother me in Go are: 1) sometimes, the lack of generics, particularly when dealing with data structures and 2) the lack of a proper and official dependency manager. (The go tool has so many officially supported auxiliary tools, why not also a dep manager supporting versions etc.?)
• sesteel 11y ago
  High level programming languages exist, first, to help us instruct computers on how to process data and second, to allow us to communicate with humans on how we intended to have the computer process data. For the most part, Go works well in both of these cases. I appreciate the fact that I can read other people's code and understand what is going on.
• deleted 11y ago
  [deleted]
• steven2012 11y ago
  I hate blog posts like this. It sounds like the author wants to turn Go into Java or Haskell. If that's what the author's preference is, then just use Java or Haskell. I don't even use Go, but to me this post is simply just whining, but the author doesn't appear to understand the fundamental reason of how or why Go was designed. The creators of Go made opinionated decisions on how the language would behave. Generics weren't left out because of oversight or accident, that was a conscious decision. Everything in his list was a conscious decision. Go is one of the most opinionated languages out there, and it's definitely not flexible to do whatever everyone wants. If you don't like it, then use another language. It's pretty simple.
  • masklinn 11y ago
    > It sounds like the author wants to turn Go into Java Go is already a Java. It's just that by and large it's an old Java, 1.0~1.1 style. Slightly better in some ways (local type inference), slightly worse in others (more magical builtins). > Generics weren't left out because of oversight or accident, that was a conscious decision. So were they in Java 1.0. Or C# 1.0 for that matter. Though for the latter it was because of time constraints, they were never under any illusion that they should do without.
• crimsonalucard 11y ago
  Imagine a flawless gemstone with a permanent stain on one of the edges. This is go, and this is why people complain endlessly. The creators of go only look at the gemstone from a single angle. So they never see the stain and they really don't care. When people complain to them, they just tell the complainers that they're looking at the gemstone from the wrong angle.
  • thegeekpirate 11y ago
    > The creators of go only look at the gemstone from a single angle. So they never see the stain and they really don't care. When people complain to them, they just tell the complainers that they're looking at the gemstone from the wrong angle. This isn't true at all, and is incredibly naive. Here's the reasoning behind not having generics, for example: https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417 https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics
• brianolson 11y ago
  Another "Go isn't Haskell/Rust" rant. I agree Go lacks macros/templates/generics and should fix at least one of those, but mostly this is a bunch of whining wishing that Go was Haskell or Rust.
• aftabh 11y ago
  I might have taken the content of this article more seriously if it had been titled something like "Why Go Is Not Good for Embedded System Programming" since the original author of the article seems to have more experience in embedded system's domain[1]. Also, the article say "Go is a regression from other modern programming languages" and I find it amusing that a significant numbers of people here taking the article and its claim seriously when it is coming from a student[1] who just finished his 'Computer Programming' university course in Fall 2014[1] (one of the reason, other reason is mentioned in the next paragraph). Don't get me wrong here: I'm not saying that you can't say anything significant when you're a student; what I mean here is that one needs to come up with more detailed explanations and with many more examples which are valid for a wide range of scenarios and use-cases when you make a general statement about a programming language which has been created by some of the highly-respected experts in the field of programming language. The list of problems mentioned in the article are important but they're not very critical for the kind of the system development that Go language has been designed/developed for[2]. Since Go language has been developed for system programming, the term 'system programming' is not restricted to embedded system only (as few people have already mentioned it in different threads here) which are mostly limited to one component (or small number of related components working together). With the advent of internet and IoT, we are forced to develop very large software systems (read, software systems as infrastructures) in order to make next generation of internet and IoT applications possible and usable (talking from business perspective). Development of these new large scale systems bring different kinds of theoretical and practical problems like complexity, concurrency and inefficiencies in system development process (for example; code compilation of large codebase and running regression test suits). And, Go has been specifically build for this new kind of large scale system softwares[2] (competing/working along with some other programming languages in this area). Here, I would read the initial set of high-level problems which forced Rob Pike and his team to create a whole new language[2], instead of only considering issues/problems which one face while developing a single machine software/hardware program (as I've already said that they're important but they're also not everything). Once I know the strength and weakness of a programming language, I know when I should (or should not) use it, under what circumstances it's the right tool and what advantages/dis-advantages I've to trade off when I use it. --- [1]- http://yager.io/resume.pdf http://yager.io/resume.pdf [2]- http://commandcenter.blogspot.de/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.de/2012/06/less-is-exponential...
• talles 11y ago
  > Go has the null pointer (nil). I consider it a shame whenever a new language, tabula rasa, chooses to re-implement this unnecessary bug-inducing feature. I agree that all points in the article are very debatable. But this one I'm yet to see the counter-argument.
• Merovius 11y ago
  TIL that go is not good, because it's not rust. Also, yes, go has the ability for isolated unsafe code. Namely importing the unsafe package and using that.
• jwatte 11y ago
  Go is a perfectly fine incremental refinement on the Perl model. What the Go cheerleaders lack is actual experience of most of the alternatives over significant time. I have code in production based on Go, and C++, and Haskell, and PHP, and Erlang, and Python, and JavaScript, and probably others. Go doesn't really stand out, at all. If I had to pick one, I'd pick C++. If I had to add another, it would be Haskell, unless I needed front end which forces JavaScript. Go is probably ahead of PHP, though, so that's something.
• anotherevan 11y ago
  If I was of a more petulant nature, I'd be tempted to register the domain doesgohavegenericsyet.com and just put up a web-site with a big "NO".
• bribri 11y ago
  A language that someone could learn in a few days and can immediately start being productive writing fast concurrent code is interesting. And it is good.
• polymathist 11y ago
  There is a small discrepancy in the article: > Go supports the := assignment operator, which works like this ... All this does is look at the return type of bar(), and set the type of foo to that. This is a misunderstanding of the := operator and how type inference works in Go. If you look at the language spec (https://golang.org/ref/spec#Short_variable_declarations https://golang.org/ref/spec#Short_variable_declarations), you can see that the := operator is nothing more than a shorthand variable declaration. x := "foo" is shorthand for (and functionally equivalent to) var x = "foo" Type inference is orthogonal to the := operator and is a little more powerful than the author implies. For example, Go is able to infer the type of literals, including inferring the type of a numeric literal based on the presence of a decimal point or the symbol for the imaginary number, i (complex and imaginary numbers have native support). It can also infer the type when you assign a variable to an element in array, slice, or map or when you receive from a channel. Of course it can also infer types for values inside of a struct, map, slice, or array and for keys in maps. The only obvious difference I see between type inference in Go and Rust or Haskell is that in Go you must always define the return types for functions, but there may be more differences I am unaware of. See this playground example for a demo of a few different ways that types can be inferred in Go: http://play.golang.org/p/8ep340vLky http://play.golang.org/p/8ep340vLky. (edit: formatting)
• Depado 11y ago
  Maybe we should stop fighting over languages and focus on the things you can create with them ? I honestly see no point in creating blog posts about "Why this language sucks". It's quite always a subjective point of view, and the whole goal of this kind of article is generally to drag people away from a language. People are using Go. They create content with Go, they create amazing stuff, sometimes they realize that Go isn't the best language to create this or that and so they switch to something else. What's the point there ? If a language doesn't fit your exact use cases, then it's a bad language ? Stop the impossible standards of the perfect language. Real languages have flaws !
• romanovcode 11y ago
  I tried Go, didn't really impressed me. I don't see any reason why now one should choose Go over C#, for example.