16 ms·

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch ont

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the language design, but I suspect that doesn't account for all of it. It seems to me that the intensity with which some people fixated on the absence of generics cannot be explained just by frustration with writing non-generic code, which by all accounts was annoying but not overwhelmingly so. So, for those of you who are willing to explore the part of this that goes beyond a simple rational analysis and criticism of language design, whats bugging you? Sometimes I think the core irritation with Go is its simplicity. The suggestion that easy to learn languages can be effective too is somewhat humiliating, as we get attached to the pride of mastering more complex languages, and the suggestion is that some of the struggling we went through was unnecessary, and that folks who wont struggle as much might be able to be effective too, in fact the suggestion is that maybe our pride was misplaced. Theres also a suggestion, in the fact that Go has opinions, that other opinions might be "wrong". I think this may bug people, who would take up those other opinions or see merit in them, a lot. There's also a bit of an anti-expertise "who are you, Go creators, to say you know better than me how to design this program/engage in software development?" In any case, it's something I've been trying to figure out for a while and I don't think I have a complete explanation still. Curious to see what others think.

deleted 5y ago
[deleted]
icholy 5y ago
People are upset that their favourite language didn't get as popular as Go.
- echelon 5y ago
  Counter point: Generics make me far more inclined to use Go regularly. If error handling is improved to be safer and more ergonomic, it'll be incredibly compelling for me. Generics were the biggest feature keeping me from using the language, and now that's a done deal. I'm excited.
  - icholy 5y ago
    If you consider the adoption rate, it's pretty clear that the people who avoid Go because of <insert missing feature> are a vocal minority.
    - echelon 5y ago
      Well, I can only speak for myself :)
    - mcronce 5y ago
      While true, that doesn't really change the situation for the individuals who require <missing feature>
      - throwaway894345 5y ago
        No one meaningfully "requires generics", people are just reluctant to set their ego aside and learn a different approach. Some use cases may benefit from generics, but even then "require" is too strong.
        mcronce 5y ago
        Considering the alternative is often either "copy and paste a bunch of code with a type changed in a bunch of places and commit the result" or "vtable dynamic dispatch", it's perfectly fair for a person to say that they require that feature. Generics also aren't the only useful feature that Go lacks (or, as of today, lacked).
        throwaway894345 5y ago
        You still don't "require generics", you might require more performance than idiomatic Go offers, but in this case you're also excluding everything slower than C/C++/Rust irrespective of whether or not the language supports generics. > Generics also aren't the only useful feature that Go lacks (or, as of today, lacked). Agreed, but it's foolish to frame language debates purely around the presence or absence of useful features. Many languages have too many features including a great many misfeatures which degrades the overall experience, and your analysis doesn't account for that. Further, there are costs associated with things like generics which your analysis similarly ignores. Further still, it ignores things like tooling, ecosystem, learning curve, etc. This is how you end up with C++.
- pjmlp 5y ago
  Go needs to catch up with 25 years of Java, 20 of C#, and 40 of C++ regarding industry adoption. Not worried, just pleased it is finally catching up with modern times.
ainar-g 5y ago
> It seems to me the next object of hatred is the lack of sum types. Sum types may be coming in a close future release, since the notation type T interface { int | string } that can currently only be used for constraints on type parameters can be “easily” made to be a runtime thing as well. I cannot find the GitHub issue right now (perhaps, it wasn't an issue, but a comment in a very long thread, and GitHub is being annoying with those), but it seems like nobody is currently opposed to that, and the only reason it didn't make it into 1.18 is that it's already a pretty big language change.
- earthboundkid 5y ago
  Yes, the only downside I see is that if you do: type Number interface { int | int64 | int32 } var n Number The default value for n has to be nil, rather than 0, because Go can't choose between the types (int 0, int64 0, etc.). And of course, you can't do n + x (assuming x is also a Number) because x might be a different kind of number. Still, it's a pretty good simplification from the current restrictions, and it builds well on existing concepts.
throwaway894345 5y ago
> Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I'm a big Go proponent, and I'm pretty "meh" on generics. They'll make some code easier to read and write, but they'll make a lot of code a lot harder to read (because contrary to popular belief, "readability" doesn't always increase with abstraction or terseness). That said, sum types would genuinely be helpful--the workarounds are error prone (making sure all cases are handled by code) and inefficient (unnecessary allocations if the implementation is backed by interfaces or wasted memory if it's struct with a field per variant). Note that simply supporting sum types doesn't guarantee that they'll be implemented efficiently--I'm afraid of the possibility that the Go community might settle for an interface-based implementation rather than a union-based implementation. On balance, however, Go is still the most productive language I've ever used (and by a healthy margin). People make way too big a deal about type system minutia (having a basic type system is important, but going too far beyond that can be counterproductive) and they are far too forgiving for things like bad tooling, poor performance, or impoverished standard libaries.
- djbusby 5y ago
  What do you build where you see that "healthy margin"? I build mostly webApp, and API services (boring business stuff). Reaching for Go or PHP is about the same (read JSON, business rules, database). For this stuff PHP was hardly better than CGI-Perl - except for application performance - where PHP was better than CGI and Go is better than both. What am I missing in using the tools that I don't see that margin? Maybe I'm measuring the wrong thing?
  - rob74 5y ago
    Comparing Go and PHP, as a compiled language Go's performance is undeniably better. Plus it has a cleaner design without all the cruft that accumulated in PHP over the decades (in PHP's favor however, you have utility functions that make it really easy to accomplish basic tasks, such as `json_decode` and `file_get_contents`, which are not so straightforward in Go). One example I'm currently confronted with: I'm writing a long-running backend task in PHP, and since the rest of the backend is based on Laravel, it's using Laravel too. The script doesn't really do much, and as far as I can see there should be no memory leaks, but unfortunately it can still only run for ~ 3 hours before it quits because of running out of memory. I'm sure it will be real fun debugging that. Makes me want to switch to Go...
bcrosby95 5y ago
For some, generics will be enough. For others, it won't. It's the nature of people rather than a person - there's lots of us and we all have our own preferences. Personally, lack of generics never kept me out of Go. I did a lot of programming in it for about a year when 1.0 first dropped. I think it is a fine language, both with and without generics. I do prefer simpler languages though - those that give me broad tools to accomplish many tasks rather than many tools to accomplish specific tasks.
andrewf 5y ago
I work at a Go shop that was a Python + RoR shop when I joined. I don't dispute Go's benefits at our scale. As a matter of personal preference, I don't enjoy Go. Go is Blub (http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html). I think the industry is in a place where Blub makes sense! Lots of VC money is floating around, and schools are training a lot of people to hire with that money. Commercially relevant ideas most often succeed by raising a ton of money, then hiring a ton of people to realize the vision. In the Blub essay's terms, a modern company doesn't want to beat the average, they want to reliably hit the average with the 10s or 100s of people they're hiring. This resembles the conditions at Google when Golang was conceived, a lot more than the "4 people want to max their individual leverages, whilst eating rice and beans to extend their runway" world the Blub essay was inspired by.
- throwaway894345 5y ago
  Go wins because it's generally simple and consistent. People like simplicity rather than kitchen-sink languages. And this doesn't only apply to the grammar and type system, but also to the tooling--Go doesn't require you to: * Pick a testing framework / runner * Learn a DSL to manage dependencies * Learn how to configure the build system to ship static binaries * Debate code formatting rules * Build a CI pipeline to build and publish source code packages * Build a CI pipeline to build and publish documentation packages * Tune a GC for low-latency + low-memory
  - jimbob45 5y ago
    I don't know if it's that people like simplicity as much as simple things should be done simply. If I'm in C and I want some user input and I want to concatenate that input to another string, I have four hours minimum research ahead of me to not add a terrible vulnerability to my application right off the bat. User input should be simple in the simple case with complexity hidden behind weird toggles. Git is great with this. You can get by just fine in 99% of cases with git add, commit, and push and those three could be explained even to a child. However, you can also fine-tune your pipeline just the way you like with Git's endless tweaks.
  - 5y ago
apazzolini 5y ago
Here's a blog series that you'll likely find enlightening: https://jesseduffield.com/Gos-Shortcomings-1/ https://jesseduffield.com/Gos-Shortcomings-1/
- philosopher1234 5y ago
  I did not find this enlightening (and I’ve read it before). This criticism is fixated on what I would consider minor annoyances in using Go, and doesn’t explain why they’re such a big deal.
gerbilly 5y ago
> I would like to understand a bit more about where a lot of the Go criticism comes from. Go is really s souped up version of C. It's a design rooted in the 70s with some fixes to make it a good language for writing small networked apps. Insofar as that goes¹, the language is fine. However the creators of Go responded to critiques of the language in a patronizing manner and talked down to their own programming community at Google as being unable to handle complex languages. Basically the Go community got the exchange off on the wrong foot. Personally, I sense egos were at stake. They created a language which is simple by design, but then still wanted to claim a sort of opinionated superiority for it. If they'd said, "oh go is just a simple little language we enjoy using for such and such, perhaps you will too" then people who don't like Go wouldn't have felt provoked. 1: Pun not intended.
- ainar-g 5y ago
  > However the creators of Go responded to critiques of the language in a patronizing manner and talked down to their own programming community at Google as being unable to handle complex languages. Can you provide examples of that? Because the closest thing I can remember is Go creators saying that C++ had too many features interacting in weird ways, and that they wanted to avoid that. Which is a perfectly normal design goal.
  - ______-_-______ 5y ago
    Here's the original Rob Pike quote: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. The source seems to be MSDN, but the link has bit-rotted. https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/From-Parallel-to-Concurrent https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr... This attitude I think is the reason most experienced deveploers I've worked with are put off by the language. You don't have to be a "researcher" to understand sum types or generics. There's a large part of the industry that thinks we should limit ourselves to concepts that can be understood by a beginner, and I think it's holding the industry back. I can't think of another industry where people think this way.
Zababa 5y ago
> I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the language design, but I suspect that doesn't account for all of it. It seems to me that the intensity with which some people fixated on the absence of generics cannot be explained just by frustration with writing non-generic code, which by all accounts was annoying but not overwhelmingly so. > In any case, it's something I've been trying to figure out for a while and I don't think I have a complete explanation still. Curious to see what others think. Couldn't the same be said for every programming language, ever? People often spend more energy complaining relative to the pain that they went through, I don't think there is anything specific about to Go about this. Just look at every discussion about C, C++, Java, JavaScript, Python, Ruby or even better, PHP.
freedomben 5y ago
I'm not the target market for your question, but I stopped using Go mainly because I felt constrained. I prefer functional programming style and that was very difficult in Go. More than that, I hated having the language dictate to me where my code had to live (this has since been fixed). I also disliked the lack of a package manager (also since fixed). I do dislike the verbosity of Go programs (some of which is forced by the language, other of which is self-inflicted by devs writing very long functions), although this is more of a style choice, and style is something that you can get used to. I don't dislike Go though, and I still use it occasionally. I love the go formatter, and I like the built in channels (although now that I've experienced Elixir/Erlang I think the actor model is pretty great). I think of it as a flavor of ice cream: some people will like it, others won't. Even if I hated Go, I still believe that the diversity in languages is a good thing and I have yet to see a language that didn't contribute to overall progress.
- throwaway894345 5y ago
  > I'm not the target market for your question, but I stopped using Go mainly because I felt constrained. I prefer functional programming style and that was very difficult in Go. Yeah, Go is opinionated. I like functional programming style too (because I like being abstract), but it's hard for me to deny that it's easier for people to read code which is more concrete and standardized (fewer ways to express the same idea) even if there is more boilerplate. > More than that, I hated having the language dictate to me where my code had to live (this has since been fixed). I also disliked the lack of a package manager (also since fixed). These things have been fixed for a long time. It sounds like you tried Go when it was quite young. > I think of it as a flavor of ice cream: some people will like it, others won't. I agree. To expound on that, I'll also posit that people have different goals in choosing a programming language. Some people want a language that makes them feel clever / express themselves aesthetically and others want a ruggedly practical language / Get Shit Done (I definitely fall into both camps). Go is squarely in the latter camp.
  - freedomben 5y ago
    Yes absolutely, I did most of my Go programming in the 1.5 days, so (as I mentioned) some of my dislikes have been fixed. > but it's hard for me to deny that it's easier for people to read code which is more concrete and standardized (fewer ways to express the same idea) even if there is more boilerplate. Yes, absolutely agree. When working on a team, especially a big team, that's a huge benefit that shouldn't be overlooked.
tacotacotaco 5y ago
I like the simplicity of the language. What I did not like was the complete denial of functional patterns for problem solving. The language has first class functions but language's "best practices" and the core library are imperative and all 3rd party libraries (rightly) follow suit. I appreciate that the language designers had a specific vision for their language. I have much respect for them. They have a lot of experience and expertise. I prefer functional patterns so I decided to discontinue go and learn a different language.
- synergy20 5y ago
  'discontinue go and learn a different language', which is what? there are not many 'better' languages to pick these days, all languages have pros and cons, even Rust won't save the world.
mcronce 5y ago
> So, for those of you who are willing to explore the part of this that goes beyond a simple rational analysis and criticism of language design, whats bugging you? Error handling is a big one for me. This could be generalized to lack of expressivity; it takes an unreasonably large amount of code to accomplish anything. Generics will help with the general case, but they don't do anything for error handling. Lack of sum types, as you already mention, are another. Go really likes forcing you to either write a ton of tests or discover your errors in production. More expressive features (sum types, etc) effectively mean that compiler provides those tests to me for free. _Can_ I write them myself? Yes, obviously, but that brings us right back to having to write way too much code to accomplish anything. Farther down the list is escape analysis. Rather than just giving me control over whether allocation happens inline or indirect, if I have some performance critical submodule, I have to sit there and box with escape analysis; this is not only time consuming, but extremely brittle. https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... is a good read for fairly specific issues that _mostly_ haven't directly impacted me, but on the rare occasion they have, they've been infuriating.
- jatone 5y ago
  > Error handling is a big one for me. This could be generalized to lack of expressivity; this has been shown over and over to be incorrect. go programs are within the ballpark of other languages in terms of LOC. usually the examples given are niche use cases that impact an extremely small amount of code. golang is looking for ways to make it more ergonomic just hasnt found a decent path forward yet. interestingly your sum types complaint might allow for it eventually. > Go really likes forcing you to either write a ton of tests or discover your errors in production this is just not true compared to most languages. evidence please. given the prevalence of dynamic languages in the wild today its most likely the opposite. i know my golang tests tend to be less in number than java or any dynamic language. >Farther down the list is escape analysis. Rather than just giving me control over whether allocation happens inline or indirect also not true, golang absolutely gives you the ability to control this. but its guarded by rules. rules that prevent you from screwing up and causing memory issues. this is a good thing.
nicoburns 5y ago
I would suggest that the core complaint is with the lack of ability to create abstractions, which leads to writing a lot of boilerplate. Which in turn makes Go code quite hard to read for anyone who thinks about programming from a top-down perspective doesn't for example want to have to decipher loop indexes to determine that the code is doing a .filter().map() operation.
- Thaxll 5y ago
  I disagree, Go is easier to read than most modern languages, it's easier because it has a few keyword and did not add major features in the last 15 years. I can't say the same for Java / C#, Rust / C++ etc ...
  - nicoburns 5y ago
    I think that's a valid perspective. But there are many of us who don't find Go harder to read than those languages (well, maybe not C++). I think we must recognise that to some extent simplicity is subjective. What is easy to one person isn't necessarily easy to another and vice-versa. Personally, I think in abstractions. So a language that represents those directly is much easier for me to reason about than one that makes me constantly translate those low-level procedural code and back again.
    - philosopher1234 5y ago
      Perhaps the trouble is when you encounter other peoples abstractions, or when you return to abstractions you’ve long since discarded :)
      - nicoburns 5y ago
        The key abstractions that I want access to are standard ones like "map", "filter", "reduce", and data structures like "Option", "Result", "Future, "ConcurrentHashMap".
  - kaba0 5y ago
rat9988 5y ago
> I would like to understand a bit more about where a lot of the Go criticism comes from Because I loved the language so much but I feel like it decided to be on the wrong level of abstraction, making many things, uselessly frustrating and verbose. What can be a very readable code in other languages can be hard to read in go because of its verbosity. And the lack of generic has been very limiting of a while, and many discussions with the main team turned to "what are your usecases that really need generic". So I felt like the language won't evolve the way I wanted it, the despite its redeeming qualities.
- throwaway894345 5y ago
  > What can be a very readable code in other languages can be hard to read in go because of its verbosity I suspect that a lot of people conflate "readable" and "terse" or "abstract". For example, beyond one or two chained methods, a foos.map(...).reduce(...) style quickly becomes unreadable while the equivalent for loop is still easily understood (this is a large part of the reason why complicated list comprehensions are discouraged in many parts of the Python world). It's also why it's often easier to understand error paths in Go than in a language which makes heavy use of exceptions despite differences in boilerplate.
  - rat9988 5y ago
    I see where you come from with those super smart one liners (guilty of it when I started programming). But sometimes, you can do something nicely in one line instead of three or four, and it makes it easier to parse.
    - throwaway894345 5y ago
      I agree, but those one-liners win by only a little bit when they do win (e.g., it's only a little easier to read foos.map(...) than it is to read the equivalent for loop) but they lose by a lot when they lose (it's a lot harder to read .map(...).filter(...).flat_map(...).reduce(...) than the equivalent for loop). Generics tend to win by a lot in very specific, rare cases--so I appreciate that Go will have better support for those cases, but there's no way the community will restrain themselves outside of those cases (no language community has succeeded in this capacity to date).
candiddevmike 5y ago
I think Go's criticisms come from elitism more than anything--folks can't flex their algebraic programming muscles and instead have to do error checking inline or do some WET things due to lack of generics like some amateur. To me, Go is never the wrong choice, but it may not be the best choice for some projects.
- quaunaut 5y ago
  I'm not sure it's elitism to be looking for type-system features that are well-over a decade old and generally non-controversial and considered vast positives. I don't think they necessarily need to go crazy in this regard(as simplicity is one of Go's best strengths), but I don't think it's elitism.
  - scns 5y ago
    > Algebraic data types were introduced in Hope, a small functional programming language developed in the 1970s at the University of Edinburgh. [0] It predates Miranda and Haskell and is contemporaneous with ML, also developed at the University. [1] ML had them too [2] [0] https://en.wikipedia.org/wiki/Algebraic_data_type#Programming_languages_with_algebraic_data_types https://en.wikipedia.org/wiki/Algebraic_data_type#Programmin... [1] https://en.wikipedia.org/wiki/Hope_(programming_language) https://en.wikipedia.org/wiki/Hope_(programming_language) [2] https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language) edit: add ML
- throwaway894345 5y ago
  I'm a Go proponent, but I also feel this. Sometimes I want to be very abstract and clever. I've written a static site generator in Rust, not because a Go version would be too slow or error prone, but because I liked the idea of being gratuitously abstract and efficient. I feel clever and I like the aesthetic of very abstract programs. But this is almost always at-odds with the objectives of software development--very abstract/terse code is often much harder to understand than concrete/verbose code. There are significant material advantages to being able to onboard a developer with zero language experience to a project in a matter of hours rather than weeks or months.
s3graham 5y ago
The silly things that bothered me the last time I tried to use it: 1) lame un-opininated formatter (no line wrapping); 2) obtuse-but-mandatory directory structure for modules once you move beyond a single file (maybe this has improved?); 3) embarrassingly large binaries.
didibus 5y ago
> So, for those of you who are willing to explore the part of this that goes beyond a simple rational analysis and criticism of language design, whats bugging you? I think the reason Go gets a lot of criticism is that at a language level it misses a lot of constructs and features. So for everything it doesn't have, you'll find someone who is really used to leverage those constructs or features when they program and who favor that style, thus they will be bothered that Go doesn't have them, as it makes it less enjoyable for them to use Go. Now normally this wouldn't be an issue, you'd say, just don't use Go. But here's the thing, the best part about Go isn't the language, but the compiler and runtime. That's the combination which attracts a lot of criticism, because everyone would like to be able to use the Go compiler and runtime since it creates beautifully efficient, small and low memory binaries with cross-compilation, and it has a good set of libraries. I'd say on that front Go is unparalleled honestly, I can't think of any other compiler that can produce binaries for various targets that easily. Its cross-compilation is simply excellent. That means everyone would want to use Go, but not because of the language, but because of the compiler and runtime. As all these people come to Go, they're forced to use the language, and very quickly realize this doesn't have the features or constructs that they'd want to program with, and there goes the criticism. The trade-off is just hard to swallow, if you come from a more expressive and powerful language, with more features or styles, the Go language will be a harsh reality of how minimal it all is, so much so that they decide not to use Go. So what's happening is a bunch of people are waiting for Go to have feature X,Y,Z before they jump back to Go, and that creates loud voices, and the reason is that they want to use Go the same way they currently program, but have access to its awesome compiler and runtime.
- jhgb 5y ago
  > I'd say on that front Go is unparalleled honestly, I can't think of any other compiler that can produce binaries for various targets that easily. Its cross-compilation is simply excellent. Zig, perhaps? My impression is that it's similarly capable.
- andyfleming 5y ago
  This is spot on, for me. The compiler and runtime are attractive, but the missing language niceties are an annoyance.
beltsazar 5y ago
> Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. Lacking generics is not in the same league as lacking sum types or other features. Only a few major static languages have sum types, whereas most major static languages have generics.
kansface 5y ago
> It seems to me that the intensity with which some people fixated on the absence of generics cannot be explained just by frustration with writing non-generic code, which by all accounts was annoying but not overwhelmingly so. You speak for yourself here! Miles of copy pasted code, slightly altered who knows how, impossible to refactor without either using code generation or eschewing type safety altogether was my experience. Its impossible to write entire classes of general purpose libraries with type safety! Its just beyond belief to me that "copy paste" is an actual, bona fide best practice in the community, or that a 'map' function is unexpressible! > There's also a bit of an anti-expertise "who are you, Go creators, to say you know better than me how to design this program/engage in software development?" Go the compiler/runtime is super impressive! Cross compiling small, binaries with a switch is awesome, so kudos! Go, the language, on the other hand, sucks; it actually sucks so much, that historically, we couldn't even write libraries to work around the things that suck. That is frustrating!
goodoldneon 5y ago
A more robust type system can help you deal with coordination between various nooks of a codebase. For example, let's say our platform supports multiple authentication methods. If we need to add a new auth method, how do we know all the spots we need to update? TypeScript can handle this using a sum type: type AuthMethods = "push" | "sms" | "fancy_new_thing" // No errors const authMethodHandlers: {[key in AuthMethods]: CallableFunction} = { push: () => {}, sms: () => {}, fancy_new_thing: () => {}, } // Error: Property 'fancy_new_thing' is missing const authMethodTitles: {[key in AuthMethods]: string} = { push: "Push", sms: "SMS", } With the above approach, static analysis tells us when we missed a spot. That adds a ton of safety and expedites feature work (since engineers don't need to manually find all the spots that need updating).
keybored 5y ago
This comment has the tone of being genuinely inquisitive, yet it mostly comes up with negative and depraved reasons for as to why someone one might dislike $lang. - Rational reasons (frustrations with the language design) are briefly acknowledged but then some reason left by the wayside - It is suggested that people don't have principled objections to $lang; they will "latch onto" something else if $misfeature is fixed - Simplicity, a universally praised quality, might be the problem - ... Because it can "humiliate" someone who has wasted time on needless complexity - "$lang has opinions", which all languages have whether they acknowledge them or not. Why should this bug people especially when it comes to $lang? - "Anti-expertise" for some reason, even though creating any "enterprise-ready" language takes expertise and many years of effort. (This also seems to be at odds with the "anti-simplicity" point?) - ... But aren't then people who argue for $lang also anti-expertise? They are after all taking a stance on something that they are not experts at; they should take a neutral stance and defer to the experts I would say that it is rude to suggest that someone might not really be arguing against X and instead ask what they are really upset about, since the follow-up questions and implications are absolutely never flattering. They inevitably just dive into the gutter with suggestions like "maybe simplicity humiliates you".
- stouset 5y ago
  This needs to be higher up, and summarizes my main cultural oppositions to golang. I'll also add: - Extensive laundry lists of frustrations, sharp edges, antipatterns, and ways the language makes it trivial to write incorrect code are dismissed as nits or minor annoyances. - Missing features that have no way of being worked around are dismissed off-hand as unnecessary complexity. - The language authors repeatedly ignore mistakes learned from other language projects and rush headlong right back into them, with predictable consequences. - Verbosity is mistaken for "simplicity" while bugs scaling roughly linearly with lines of code is quite literally one of the few reliable bits of data we actually have in this industry.
  - int_19h 5y ago
    > Missing features that have no way of being worked around are dismissed off-hand as unnecessary complexity. You forgot to add the part where, once the features are added after all, they stop being "unnecessary" complexity :)
deleted 5y ago
[deleted]
- deleted 5y ago
  [deleted]
marwatk 5y ago
I have an irrational dislike of go because for every X it's missing the community's answer is "you don't need X" (until they decide you do). Package management, generics, sum types, decent error handling, etc. It's an arrogant approach that rubs me the wrong way. It reminds me of "You're holding it wrong" and seems ingrained in the go ethos. That's not to say I'm not productive in go, but I could be vastly more productive.
- twsted 5y ago
  If I rethink about how long I was kept away from go by its error handling and then I fell in love with it...
oconnor663 5y ago
> So, for those of you who are willing to explore the part of this that goes beyond a simple rational analysis and criticism of language design, whats bugging you? I coded primarily in Go at work for several years, although that was several years ago. I understand that package management and now generics have changed in major ways since then. But at the risk of being out of date, here are some language-level complaints I had at the time, focusing less on convenience/taste and more on things that I felt made it harder to write correct code: - Nil pointers. Go doesn't have any built-in way of distinguishing between pointers that can be nil and pointers that can't. - Two kinds of nil. Go distinguishes between typed and untyped nil pointers. - Automatic zero-initialization of omitted fields. Adding a new field to a struct has a tendency to make existing callsites incorrect without producing any compiler errors. - Mixing declaration and assignment on the left side of the := operator. Copy-pasting a line from an outer scope to an inner one silently changes assignments into shadowing declarations. - Calling append() without capturing its return value is always wrong. This mistake is easy for linters to catch in simple cases, but aliasing creates more complicated cases. - It's easy to make an implicit temporary copiy of an object without realizing it, like by using a value method receiver or by looping over a slice of values. These are examples of things that made me feel like I was "fighting the language" to try to write correct code. I'd appreciate feedback about any of these that might have changed in the last few years.
- kaba0 5y ago
  And the stupidest of all: defer is function-scoped, not block.
  - oconnor663 5y ago
    I don't like calling any of these things stupid. They're tradeoffs, and I can respect why they were made.
    - kaba0 5y ago
      I would agree with you in the general case, but I yet to hear any sort of sane explanation for why it is the way - and it is not like a typical tradeoff where something arguably worse would have been chosen otherwise, it is just a small semantic change to a keyword. But its effect is huge, e.g. the prototypical usage of the keyword would be to unlock mutexes, but it is simply a huge footgun, see: https://news.ycombinator.com/item?id=30253426 https://news.ycombinator.com/item?id=30253426
matthewmacleod 5y ago
I think my biggest non-specific, slightly silly irritation when using Go is just how annoying I find it to write clear code in it, because the focus on simplicity feels like it too often comes at the expense of clarity, correctness, and expressiveness. I don't like that I'm not able to express simple constraints that I find a really important for improving code quality in other environments – things like "this field cannot be nil and it's a programming error if it is", or "all possible values of this field must be handled". There are lots of other bits, but I'd say the general pattern is being quite frustrated about having to do and remember things that the computer should be handling for me – such that working in Go always feels like having a small rock in my shoe. It's a shame, because as a language—and wider ecosystem—it gets so much stuff really right.
- stouset 5y ago
  This is my critique of go too. It's really easy to write code that works well for all of the cases I can think to test. But it is strictly impossible to write code where I can make guarantees of robustness. These little warts that prevent that are everywhere: lack of sum types (no Option / Result), half-assed enums, no real ability to make things const, inability to express exhaustive switch statements, having to downcast to `interface{}/any`, nil, typed nil, and on and on and on. The longer I develop software, the less I care about being able to write software that works and the more I care about being able to write software that doesn't fail. The former is table stakes, and I can throw together something that works in virtually any language. The latter is what not only prevents me from spending nights and weekends fixing problems, but also allows me to finish software and truly move on to new projects without having to constantly play whack-a-mole fixing new issues that keep coming up.
kevinmgranger 5y ago
I like parts of Go. It's refreshing. I'm excited for this release. What I don't like is how its weak parts are consistently defended instead of having its shortcomings be acknowledged. Before any rational analysis and criticism can begin, we need to look at the context of these arguments. I'll do that through some of the comments on this post. - Issues people bring up are dismissed as non-issues or as personal preference / opinionated, regardless of their impact. - Critics are asked for rational analysis, but proponents are allowed to use something as airy as "simplicity", a word that has essentially lost all meaning in programming. - Missteps by representatives / stewards of Go are given the most charitable interpretation, critics less so. - Finally, in so many cases, counterarguments to critics are dripping in condescension. I don't think folks are going to get rational analysis. I also don't think they actually want it, whether they realize it or not.
- kevinmgranger 5y ago
  In case anyone is interested, here are my technical critiques of Go: - Boilerplate increases the surface area that a bug can hide in. The fact that most of the boilerplate is around error handling is especially worrying. Yes, the flexibility of "Errors are values"[1] is nice. But I also don't know any languages where errors _aren't_ values, so the main value add seems to be reduced boilerplate compared to individual try/catches around each function call. - Go manages to repeat the Billion Dollar Mistake[2]. Things like methods working on nil receivers is cool, but not worth the danger or messiness. - Even worse, for a language that claims to value simplicity, the fact that nil sometimes doesn't equal nil[3] is... honestly, I can only consider that a bug. [1]: https://go.dev/blog/errors-are-values https://go.dev/blog/errors-are-values [2]: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/ https://www.infoq.com/presentations/Null-References-The-Bill... [3]: https://go.dev/doc/faq#nil_error https://go.dev/doc/faq#nil_error
  - uryga 5y ago
    > But I also don't know any languages where errors _aren't_ values (look, i know you understand how exceptions work, please bear with me) yes, Exception objects are technically values, but you don't return them to the caller; you throw them to the, uh, catcher. basically, you get a special, second way of returning something that bypasses the normal one! but in the EaV approach, errors just are returned like every other thing. the uniformity of EaV comes in handy when doing generic things like mapping a function over a collection - don't have to worry if something will throw, because it's just a value! and that lets you go to some pretty powerful places w.r.t abstraction: see e.g. haskells `traverse`. but yeah, EaV needs some syntactic sugar to reach ergonomic par with exceptions, otherwise you get if-err-not-nil soup :P
stouset 5y ago
> I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. This is a needlessly dismissive perspective. Put another way, now that one of golang's most prominent deficiencies has been addressed, people will switch their focus to other areas of frustration. > Sometimes I think the core irritation with Go is its simplicity. The core irritation (well, my core irritation) around Go is that this simplicity just kicks the cans of complexity and verbosity downstream onto its users, and—in the worst cases—hides the fact that this complexity exists, so encourages writing simple, obvious, and subtly incorrect solutions. Subtly incorrect is by far the worst kind of incorrect, as it results in code that works for all the obvious test cases but breaks at 2AM in production. Go doesn't feel simple to me. It feels half-assed. Let's take a recent example I had to work with: truncating a string to the first 63 characters. Easy, right? s = s[:63] Simple, obvious, and subtly incorrect. Why? UTF-8. Strings in go are just a microscopic wrapper around immutable byte arrays. I could almost consider this okay if there was some type in the language that wrapped a byte array and an encoding to provide a real string type. But not only isn't one included, a reliable one can't even exist. The range keyword iterates over bytes for byte arrays and over UTF-8 code points for strings and there's no way to express anything different. String straddles this uncomfortable middle where it's both a byte array and a UTF-8 string and which one it is depends implicitly on which operators you use on it. Strings are "just" a byte array, except they're supposed to contain UTF-8, but not only is there no way to enforce that they do, the language makes it trivial to accidentally corrupt any UTF-8 string you do have (e.g., through indexing). If you're writing a function and somebody passes you a string you have no way to know or enforce that it's intended to bytes or ASCII or UTF-8 or any encoding whatsoever without iterating through to check. There is no type that actually encodes an enforced requirement of a valid UTF-8 string, nor can one even be written as a library. So the way you're "supposed" to truncate a string is: s = string([]rune(s)[:63]) At least I think that's the magical incantation. Do you do this everywhere? Do your coworkers? Yeah, I didn't think so. Compare this to Rust and Ruby, which take two diametrically opposite (but both IMO reasonable) approaches. In Rust, strings are UTF-8. You cannot construct a String that does not contain a valid UTF-8 byte sequence (at least not without unsafe). You cannot perform safe operations on a string that result in an invalid byte sequence. If you are handed a string, you know that it contains valid UTF-8 bytes. You can iterate over either the bytes or the characters, but you have to explicitly decide which. In Ruby, strings are byte array / encoding pairs. It could be UTF-8, UTF-16, Shift-JIS, EBCDIC, or any other encoding you want it to be. When you're handed a string you can generally assume it's been parsed and validated under that character set. Indexing, iteration, and other operations are all encoding-aware. If you want the bytes, you can choose to access them. The string equivalent in golang is, to put it bluntly, half-assed. It's mostly just a byte array but some keywords assume it's UTF-8. If you're given a string you generally assume it's UTF-8 but there's no reasonable expectation that it's valid since the language makes it ridiculously easy to violate the encoding rules. Go strings aren't even a decent building block for an encoding-aware type since range can't be made to work on other encodings. For a language written by none other than Rob Pike himself, I simply cannot fathom how golang arrived at this design. Keep in mind this is just one of a myriad places where the language punts complexity to the user but, at best, doesn't give them the tools to actually reliably handle it and, at worst, pretends like the complexity doesn't even exist so it's not even obvious something needed special care in the first place. Simple, obvious, and subtly incorrect.
zemo 5y ago
people hate Go because Go is unapologetically designed from the framing of programmers being members of a labor class having differing levels of expertise. It's not the design itself; it's the design goals themselves that people are opposed to. This Rob Pike quote gets bandied around in these discussions: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. Ten years ago when I learned Go at the Recurse Center, I was early in my career and I picked Go as my language of study because I believed it was a good bet for my career prospects. I said to myself "I bet this is the next Java, and I bet that people who learned Java very early did very well for themselves". This bet proved correct; Go has been enormously useful to me in my career. Many people who go to RC pick languages like Haskell or a Lisp instead; things that are more interesting and challenging. While Haskell is well known for being mentally stimulating and very enriching, it is also well known for not seeing much industry adoption. You can sub a handful of other languages here, but basically just think of any very beautiful cutting edge experimental language that doesn't have a lot of industry jobs. I'm stick to Haskell for consistency in this post but you could just as easily say Lisp or Scala or arguably Rust these days; it's not about a specific language, it's about a specific grouping of languages that prioritize the beauty of the language and the effectiveness of the solo developer. People get upset at Pike's framing that Go should be learnable by people with less-than-expert experience. As a person sees technology's ability to serve as a vehicle of class mobility, I see this as a great and noble design goal, because I think class mobility is fundamentally good. Ask yourself this: why do people consider it bad that a language acknowledge that it should help not only people with lots of experience, but also people with very little experience, and teams with mixed levels of experience? My experience of programming Go for ten years and for being in these spaces for that time frame is that criticism of Go almost uniformly comes from people who can afford to invest heavily in things that have a low expected ROI; great and beautiful languages that don't have a lot of job prospects. Most people on Earth cannot afford the time commitment it takes to learn programming at all, let alone learning aspects of programming that they can't monetize. I have never met a Go programmer that is bothered by the existence of Haskell. I have met many, many Haskell programmers that are bothered by the existence of Go. Ask yourself why that is. Ask yourself why someone would be so angry about something so wildly successful and useful to people. It's not even remotely a two-way street; the hatred goes one way. This leaves us with the final problem: why can't people acknowledge that different people have different goals, and that those people's goals are just as legitimate as their own? Why are other people's goals threatening? It's because the existence of Go and the massive success of Go causes people to confront some aspect of class consciousness. It is impossible to witness the enormous success of Go and not confront the idea that programmers are laborers, and for some people, the idea of being a member of the labor class is simply not acceptable; criticizing Go thus becomes not merely an act of design criticism, but also as vehicle through which the critic can express something about their own socioeconomic class. There are many valid criticisms of Go, but there is also a category of Go criticism that exists more as a form of class signaling than anything else, and in these public forums, those two forms of criticism often get entangled in complex and opaque ways.
int_19h 5y ago
I doubt that sum types are going to be a big target, given the lack of support for them in many other mainstream languages. The lack of generics was standing out so much precisely because Go was the only mainstream statically typed PL without them by choice.

deleted 5y ago

[deleted]

icholy 5y ago

People are upset that their favourite language didn't get as popular as Go.

echelon 5y ago
Counter point: Generics make me far more inclined to use Go regularly. If error handling is improved to be safer and more ergonomic, it'll be incredibly compelling for me. Generics were the biggest feature keeping me from using the language, and now that's a done deal. I'm excited.
- icholy 5y ago
  If you consider the adoption rate, it's pretty clear that the people who avoid Go because of <insert missing feature> are a vocal minority.
  - echelon 5y ago
    Well, I can only speak for myself :)
  - mcronce 5y ago
    While true, that doesn't really change the situation for the individuals who require <missing feature>
    - throwaway894345 5y ago
      No one meaningfully "requires generics", people are just reluctant to set their ego aside and learn a different approach. Some use cases may benefit from generics, but even then "require" is too strong.
      - mcronce 5y ago
        Considering the alternative is often either "copy and paste a bunch of code with a type changed in a bunch of places and commit the result" or "vtable dynamic dispatch", it's perfectly fair for a person to say that they require that feature. Generics also aren't the only useful feature that Go lacks (or, as of today, lacked).
        throwaway894345 5y ago
        You still don't "require generics", you might require more performance than idiomatic Go offers, but in this case you're also excluding everything slower than C/C++/Rust irrespective of whether or not the language supports generics. > Generics also aren't the only useful feature that Go lacks (or, as of today, lacked). Agreed, but it's foolish to frame language debates purely around the presence or absence of useful features. Many languages have too many features including a great many misfeatures which degrades the overall experience, and your analysis doesn't account for that. Further, there are costs associated with things like generics which your analysis similarly ignores. Further still, it ignores things like tooling, ecosystem, learning curve, etc. This is how you end up with C++.
pjmlp 5y ago
Go needs to catch up with 25 years of Java, 20 of C#, and 40 of C++ regarding industry adoption. Not worried, just pleased it is finally catching up with modern times.

ainar-g 5y ago

> It seems to me the next object of hatred is the lack of sum types. Sum types may be coming in a close future release, since the notation type T interface { int | string } that can currently only be used for constraints on type parameters can be “easily” made to be a runtime thing as well. I cannot find the GitHub issue right now (perhaps, it wasn't an issue, but a comment in a very long thread, and GitHub is being annoying with those), but it seems like nobody is currently opposed to that, and the only reason it didn't make it into 1.18 is that it's already a pretty big language change.

earthboundkid 5y ago
Yes, the only downside I see is that if you do: type Number interface { int | int64 | int32 } var n Number The default value for n has to be nil, rather than 0, because Go can't choose between the types (int 0, int64 0, etc.). And of course, you can't do n + x (assuming x is also a Number) because x might be a different kind of number. Still, it's a pretty good simplification from the current restrictions, and it builds well on existing concepts.

throwaway894345 5y ago

> Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I'm a big Go proponent, and I'm pretty "meh" on generics. They'll make some code easier to read and write, but they'll make a lot of code a lot harder to read (because contrary to popular belief, "readability" doesn't always increase with abstraction or terseness). That said, sum types would genuinely be helpful--the workarounds are error prone (making sure all cases are handled by code) and inefficient (unnecessary allocations if the implementation is backed by interfaces or wasted memory if it's struct with a field per variant). Note that simply supporting sum types doesn't guarantee that they'll be implemented efficiently--I'm afraid of the possibility that the Go community might settle for an interface-based implementation rather than a union-based implementation. On balance, however, Go is still the most productive language I've ever used (and by a healthy margin). People make way too big a deal about type system minutia (having a basic type system is important, but going too far beyond that can be counterproductive) and they are far too forgiving for things like bad tooling, poor performance, or impoverished standard libaries.

djbusby 5y ago
What do you build where you see that "healthy margin"? I build mostly webApp, and API services (boring business stuff). Reaching for Go or PHP is about the same (read JSON, business rules, database). For this stuff PHP was hardly better than CGI-Perl - except for application performance - where PHP was better than CGI and Go is better than both. What am I missing in using the tools that I don't see that margin? Maybe I'm measuring the wrong thing?
- rob74 5y ago
  Comparing Go and PHP, as a compiled language Go's performance is undeniably better. Plus it has a cleaner design without all the cruft that accumulated in PHP over the decades (in PHP's favor however, you have utility functions that make it really easy to accomplish basic tasks, such as `json_decode` and `file_get_contents`, which are not so straightforward in Go). One example I'm currently confronted with: I'm writing a long-running backend task in PHP, and since the rest of the backend is based on Laravel, it's using Laravel too. The script doesn't really do much, and as far as I can see there should be no memory leaks, but unfortunately it can still only run for ~ 3 hours before it quits because of running out of memory. I'm sure it will be real fun debugging that. Makes me want to switch to Go...

bcrosby95 5y ago

For some, generics will be enough. For others, it won't. It's the nature of people rather than a person - there's lots of us and we all have our own preferences. Personally, lack of generics never kept me out of Go. I did a lot of programming in it for about a year when 1.0 first dropped. I think it is a fine language, both with and without generics. I do prefer simpler languages though - those that give me broad tools to accomplish many tasks rather than many tools to accomplish specific tasks.

andrewf 5y ago

I work at a Go shop that was a Python + RoR shop when I joined. I don't dispute Go's benefits at our scale. As a matter of personal preference, I don't enjoy Go. Go is Blub (http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html). I think the industry is in a place where Blub makes sense! Lots of VC money is floating around, and schools are training a lot of people to hire with that money. Commercially relevant ideas most often succeed by raising a ton of money, then hiring a ton of people to realize the vision. In the Blub essay's terms, a modern company doesn't want to beat the average, they want to reliably hit the average with the 10s or 100s of people they're hiring. This resembles the conditions at Google when Golang was conceived, a lot more than the "4 people want to max their individual leverages, whilst eating rice and beans to extend their runway" world the Blub essay was inspired by.

throwaway894345 5y ago
Go wins because it's generally simple and consistent. People like simplicity rather than kitchen-sink languages. And this doesn't only apply to the grammar and type system, but also to the tooling--Go doesn't require you to: * Pick a testing framework / runner * Learn a DSL to manage dependencies * Learn how to configure the build system to ship static binaries * Debate code formatting rules * Build a CI pipeline to build and publish source code packages * Build a CI pipeline to build and publish documentation packages * Tune a GC for low-latency + low-memory
- jimbob45 5y ago
  I don't know if it's that people like simplicity as much as simple things should be done simply. If I'm in C and I want some user input and I want to concatenate that input to another string, I have four hours minimum research ahead of me to not add a terrible vulnerability to my application right off the bat. User input should be simple in the simple case with complexity hidden behind weird toggles. Git is great with this. You can get by just fine in 99% of cases with git add, commit, and push and those three could be explained even to a child. However, you can also fine-tune your pipeline just the way you like with Git's endless tweaks.
- 5y ago

apazzolini 5y ago

Here's a blog series that you'll likely find enlightening: https://jesseduffield.com/Gos-Shortcomings-1/ https://jesseduffield.com/Gos-Shortcomings-1/

philosopher1234 5y ago
I did not find this enlightening (and I’ve read it before). This criticism is fixated on what I would consider minor annoyances in using Go, and doesn’t explain why they’re such a big deal.

gerbilly 5y ago

> I would like to understand a bit more about where a lot of the Go criticism comes from. Go is really s souped up version of C. It's a design rooted in the 70s with some fixes to make it a good language for writing small networked apps. Insofar as that goes¹, the language is fine. However the creators of Go responded to critiques of the language in a patronizing manner and talked down to their own programming community at Google as being unable to handle complex languages. Basically the Go community got the exchange off on the wrong foot. Personally, I sense egos were at stake. They created a language which is simple by design, but then still wanted to claim a sort of opinionated superiority for it. If they'd said, "oh go is just a simple little language we enjoy using for such and such, perhaps you will too" then people who don't like Go wouldn't have felt provoked. 1: Pun not intended.

ainar-g 5y ago
> However the creators of Go responded to critiques of the language in a patronizing manner and talked down to their own programming community at Google as being unable to handle complex languages. Can you provide examples of that? Because the closest thing I can remember is Go creators saying that C++ had too many features interacting in weird ways, and that they wanted to avoid that. Which is a perfectly normal design goal.
- ______-_-______ 5y ago
  Here's the original Rob Pike quote: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. The source seems to be MSDN, but the link has bit-rotted. https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/From-Parallel-to-Concurrent https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr... This attitude I think is the reason most experienced deveploers I've worked with are put off by the language. You don't have to be a "researcher" to understand sum types or generics. There's a large part of the industry that thinks we should limit ourselves to concepts that can be understood by a beginner, and I think it's holding the industry back. I can't think of another industry where people think this way.

Zababa 5y ago

> I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the language design, but I suspect that doesn't account for all of it. It seems to me that the intensity with which some people fixated on the absence of generics cannot be explained just by frustration with writing non-generic code, which by all accounts was annoying but not overwhelmingly so. > In any case, it's something I've been trying to figure out for a while and I don't think I have a complete explanation still. Curious to see what others think. Couldn't the same be said for every programming language, ever? People often spend more energy complaining relative to the pain that they went through, I don't think there is anything specific about to Go about this. Just look at every discussion about C, C++, Java, JavaScript, Python, Ruby or even better, PHP.

freedomben 5y ago

I'm not the target market for your question, but I stopped using Go mainly because I felt constrained. I prefer functional programming style and that was very difficult in Go. More than that, I hated having the language dictate to me where my code had to live (this has since been fixed). I also disliked the lack of a package manager (also since fixed). I do dislike the verbosity of Go programs (some of which is forced by the language, other of which is self-inflicted by devs writing very long functions), although this is more of a style choice, and style is something that you can get used to. I don't dislike Go though, and I still use it occasionally. I love the go formatter, and I like the built in channels (although now that I've experienced Elixir/Erlang I think the actor model is pretty great). I think of it as a flavor of ice cream: some people will like it, others won't. Even if I hated Go, I still believe that the diversity in languages is a good thing and I have yet to see a language that didn't contribute to overall progress.

throwaway894345 5y ago
> I'm not the target market for your question, but I stopped using Go mainly because I felt constrained. I prefer functional programming style and that was very difficult in Go. Yeah, Go is opinionated. I like functional programming style too (because I like being abstract), but it's hard for me to deny that it's easier for people to read code which is more concrete and standardized (fewer ways to express the same idea) even if there is more boilerplate. > More than that, I hated having the language dictate to me where my code had to live (this has since been fixed). I also disliked the lack of a package manager (also since fixed). These things have been fixed for a long time. It sounds like you tried Go when it was quite young. > I think of it as a flavor of ice cream: some people will like it, others won't. I agree. To expound on that, I'll also posit that people have different goals in choosing a programming language. Some people want a language that makes them feel clever / express themselves aesthetically and others want a ruggedly practical language / Get Shit Done (I definitely fall into both camps). Go is squarely in the latter camp.
- freedomben 5y ago
  Yes absolutely, I did most of my Go programming in the 1.5 days, so (as I mentioned) some of my dislikes have been fixed. > but it's hard for me to deny that it's easier for people to read code which is more concrete and standardized (fewer ways to express the same idea) even if there is more boilerplate. Yes, absolutely agree. When working on a team, especially a big team, that's a huge benefit that shouldn't be overlooked.

tacotacotaco 5y ago

I like the simplicity of the language. What I did not like was the complete denial of functional patterns for problem solving. The language has first class functions but language's "best practices" and the core library are imperative and all 3rd party libraries (rightly) follow suit. I appreciate that the language designers had a specific vision for their language. I have much respect for them. They have a lot of experience and expertise. I prefer functional patterns so I decided to discontinue go and learn a different language.

synergy20 5y ago
'discontinue go and learn a different language', which is what? there are not many 'better' languages to pick these days, all languages have pros and cons, even Rust won't save the world.

mcronce 5y ago

> So, for those of you who are willing to explore the part of this that goes beyond a simple rational analysis and criticism of language design, whats bugging you? Error handling is a big one for me. This could be generalized to lack of expressivity; it takes an unreasonably large amount of code to accomplish anything. Generics will help with the general case, but they don't do anything for error handling. Lack of sum types, as you already mention, are another. Go really likes forcing you to either write a ton of tests or discover your errors in production. More expressive features (sum types, etc) effectively mean that compiler provides those tests to me for free. _Can_ I write them myself? Yes, obviously, but that brings us right back to having to write way too much code to accomplish anything. Farther down the list is escape analysis. Rather than just giving me control over whether allocation happens inline or indirect, if I have some performance critical submodule, I have to sit there and box with escape analysis; this is not only time consuming, but extremely brittle. https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... is a good read for fairly specific issues that _mostly_ haven't directly impacted me, but on the rare occasion they have, they've been infuriating.

jatone 5y ago
> Error handling is a big one for me. This could be generalized to lack of expressivity; this has been shown over and over to be incorrect. go programs are within the ballpark of other languages in terms of LOC. usually the examples given are niche use cases that impact an extremely small amount of code. golang is looking for ways to make it more ergonomic just hasnt found a decent path forward yet. interestingly your sum types complaint might allow for it eventually. > Go really likes forcing you to either write a ton of tests or discover your errors in production this is just not true compared to most languages. evidence please. given the prevalence of dynamic languages in the wild today its most likely the opposite. i know my golang tests tend to be less in number than java or any dynamic language. >Farther down the list is escape analysis. Rather than just giving me control over whether allocation happens inline or indirect also not true, golang absolutely gives you the ability to control this. but its guarded by rules. rules that prevent you from screwing up and causing memory issues. this is a good thing.

nicoburns 5y ago

I would suggest that the core complaint is with the lack of ability to create abstractions, which leads to writing a lot of boilerplate. Which in turn makes Go code quite hard to read for anyone who thinks about programming from a top-down perspective doesn't for example want to have to decipher loop indexes to determine that the code is doing a .filter().map() operation.

Thaxll 5y ago
I disagree, Go is easier to read than most modern languages, it's easier because it has a few keyword and did not add major features in the last 15 years. I can't say the same for Java / C#, Rust / C++ etc ...
- nicoburns 5y ago
  I think that's a valid perspective. But there are many of us who don't find Go harder to read than those languages (well, maybe not C++). I think we must recognise that to some extent simplicity is subjective. What is easy to one person isn't necessarily easy to another and vice-versa. Personally, I think in abstractions. So a language that represents those directly is much easier for me to reason about than one that makes me constantly translate those low-level procedural code and back again.
  - philosopher1234 5y ago
    Perhaps the trouble is when you encounter other peoples abstractions, or when you return to abstractions you’ve long since discarded :)
    - nicoburns 5y ago
      The key abstractions that I want access to are standard ones like "map", "filter", "reduce", and data structures like "Option", "Result", "Future, "ConcurrentHashMap".
- kaba0 5y ago

rat9988 5y ago

> I would like to understand a bit more about where a lot of the Go criticism comes from Because I loved the language so much but I feel like it decided to be on the wrong level of abstraction, making many things, uselessly frustrating and verbose. What can be a very readable code in other languages can be hard to read in go because of its verbosity. And the lack of generic has been very limiting of a while, and many discussions with the main team turned to "what are your usecases that really need generic". So I felt like the language won't evolve the way I wanted it, the despite its redeeming qualities.

throwaway894345 5y ago
> What can be a very readable code in other languages can be hard to read in go because of its verbosity I suspect that a lot of people conflate "readable" and "terse" or "abstract". For example, beyond one or two chained methods, a foos.map(...).reduce(...) style quickly becomes unreadable while the equivalent for loop is still easily understood (this is a large part of the reason why complicated list comprehensions are discouraged in many parts of the Python world). It's also why it's often easier to understand error paths in Go than in a language which makes heavy use of exceptions despite differences in boilerplate.
- rat9988 5y ago
  I see where you come from with those super smart one liners (guilty of it when I started programming). But sometimes, you can do something nicely in one line instead of three or four, and it makes it easier to parse.
  - throwaway894345 5y ago
    I agree, but those one-liners win by only a little bit when they do win (e.g., it's only a little easier to read foos.map(...) than it is to read the equivalent for loop) but they lose by a lot when they lose (it's a lot harder to read .map(...).filter(...).flat_map(...).reduce(...) than the equivalent for loop). Generics tend to win by a lot in very specific, rare cases--so I appreciate that Go will have better support for those cases, but there's no way the community will restrain themselves outside of those cases (no language community has succeeded in this capacity to date).

candiddevmike 5y ago

I think Go's criticisms come from elitism more than anything--folks can't flex their algebraic programming muscles and instead have to do error checking inline or do some WET things due to lack of generics like some amateur. To me, Go is never the wrong choice, but it may not be the best choice for some projects.

quaunaut 5y ago
I'm not sure it's elitism to be looking for type-system features that are well-over a decade old and generally non-controversial and considered vast positives. I don't think they necessarily need to go crazy in this regard(as simplicity is one of Go's best strengths), but I don't think it's elitism.
- scns 5y ago
  > Algebraic data types were introduced in Hope, a small functional programming language developed in the 1970s at the University of Edinburgh. [0] It predates Miranda and Haskell and is contemporaneous with ML, also developed at the University. [1] ML had them too [2] [0] https://en.wikipedia.org/wiki/Algebraic_data_type#Programming_languages_with_algebraic_data_types https://en.wikipedia.org/wiki/Algebraic_data_type#Programmin... [1] https://en.wikipedia.org/wiki/Hope_(programming_language) https://en.wikipedia.org/wiki/Hope_(programming_language) [2] https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language) edit: add ML
throwaway894345 5y ago
I'm a Go proponent, but I also feel this. Sometimes I want to be very abstract and clever. I've written a static site generator in Rust, not because a Go version would be too slow or error prone, but because I liked the idea of being gratuitously abstract and efficient. I feel clever and I like the aesthetic of very abstract programs. But this is almost always at-odds with the objectives of software development--very abstract/terse code is often much harder to understand than concrete/verbose code. There are significant material advantages to being able to onboard a developer with zero language experience to a project in a matter of hours rather than weeks or months.

s3graham 5y ago

The silly things that bothered me the last time I tried to use it: 1) lame un-opininated formatter (no line wrapping); 2) obtuse-but-mandatory directory structure for modules once you move beyond a single file (maybe this has improved?); 3) embarrassingly large binaries.

didibus 5y ago

> So, for those of you who are willing to explore the part of this that goes beyond a simple rational analysis and criticism of language design, whats bugging you? I think the reason Go gets a lot of criticism is that at a language level it misses a lot of constructs and features. So for everything it doesn't have, you'll find someone who is really used to leverage those constructs or features when they program and who favor that style, thus they will be bothered that Go doesn't have them, as it makes it less enjoyable for them to use Go. Now normally this wouldn't be an issue, you'd say, just don't use Go. But here's the thing, the best part about Go isn't the language, but the compiler and runtime. That's the combination which attracts a lot of criticism, because everyone would like to be able to use the Go compiler and runtime since it creates beautifully efficient, small and low memory binaries with cross-compilation, and it has a good set of libraries. I'd say on that front Go is unparalleled honestly, I can't think of any other compiler that can produce binaries for various targets that easily. Its cross-compilation is simply excellent. That means everyone would want to use Go, but not because of the language, but because of the compiler and runtime. As all these people come to Go, they're forced to use the language, and very quickly realize this doesn't have the features or constructs that they'd want to program with, and there goes the criticism. The trade-off is just hard to swallow, if you come from a more expressive and powerful language, with more features or styles, the Go language will be a harsh reality of how minimal it all is, so much so that they decide not to use Go. So what's happening is a bunch of people are waiting for Go to have feature X,Y,Z before they jump back to Go, and that creates loud voices, and the reason is that they want to use Go the same way they currently program, but have access to its awesome compiler and runtime.

jhgb 5y ago
> I'd say on that front Go is unparalleled honestly, I can't think of any other compiler that can produce binaries for various targets that easily. Its cross-compilation is simply excellent. Zig, perhaps? My impression is that it's similarly capable.
andyfleming 5y ago
This is spot on, for me. The compiler and runtime are attractive, but the missing language niceties are an annoyance.

beltsazar 5y ago

> Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. Lacking generics is not in the same league as lacking sum types or other features. Only a few major static languages have sum types, whereas most major static languages have generics.

kansface 5y ago

> It seems to me that the intensity with which some people fixated on the absence of generics cannot be explained just by frustration with writing non-generic code, which by all accounts was annoying but not overwhelmingly so. You speak for yourself here! Miles of copy pasted code, slightly altered who knows how, impossible to refactor without either using code generation or eschewing type safety altogether was my experience. Its impossible to write entire classes of general purpose libraries with type safety! Its just beyond belief to me that "copy paste" is an actual, bona fide best practice in the community, or that a 'map' function is unexpressible! > There's also a bit of an anti-expertise "who are you, Go creators, to say you know better than me how to design this program/engage in software development?" Go the compiler/runtime is super impressive! Cross compiling small, binaries with a switch is awesome, so kudos! Go, the language, on the other hand, sucks; it actually sucks so much, that historically, we couldn't even write libraries to work around the things that suck. That is frustrating!

goodoldneon 5y ago

A more robust type system can help you deal with coordination between various nooks of a codebase. For example, let's say our platform supports multiple authentication methods. If we need to add a new auth method, how do we know all the spots we need to update? TypeScript can handle this using a sum type: type AuthMethods = "push" | "sms" | "fancy_new_thing" // No errors const authMethodHandlers: {[key in AuthMethods]: CallableFunction} = { push: () => {}, sms: () => {}, fancy_new_thing: () => {}, } // Error: Property 'fancy_new_thing' is missing const authMethodTitles: {[key in AuthMethods]: string} = { push: "Push", sms: "SMS", } With the above approach, static analysis tells us when we missed a spot. That adds a ton of safety and expedites feature work (since engineers don't need to manually find all the spots that need updating).

keybored 5y ago

This comment has the tone of being genuinely inquisitive, yet it mostly comes up with negative and depraved reasons for as to why someone one might dislike $lang. - Rational reasons (frustrations with the language design) are briefly acknowledged but then some reason left by the wayside - It is suggested that people don't have principled objections to $lang; they will "latch onto" something else if $misfeature is fixed - Simplicity, a universally praised quality, might be the problem - ... Because it can "humiliate" someone who has wasted time on needless complexity - "$lang has opinions", which all languages have whether they acknowledge them or not. Why should this bug people especially when it comes to $lang? - "Anti-expertise" for some reason, even though creating any "enterprise-ready" language takes expertise and many years of effort. (This also seems to be at odds with the "anti-simplicity" point?) - ... But aren't then people who argue for $lang also anti-expertise? They are after all taking a stance on something that they are not experts at; they should take a neutral stance and defer to the experts I would say that it is rude to suggest that someone might not really be arguing against X and instead ask what they are really upset about, since the follow-up questions and implications are absolutely never flattering. They inevitably just dive into the gutter with suggestions like "maybe simplicity humiliates you".

stouset 5y ago
This needs to be higher up, and summarizes my main cultural oppositions to golang. I'll also add: - Extensive laundry lists of frustrations, sharp edges, antipatterns, and ways the language makes it trivial to write incorrect code are dismissed as nits or minor annoyances. - Missing features that have no way of being worked around are dismissed off-hand as unnecessary complexity. - The language authors repeatedly ignore mistakes learned from other language projects and rush headlong right back into them, with predictable consequences. - Verbosity is mistaken for "simplicity" while bugs scaling roughly linearly with lines of code is quite literally one of the few reliable bits of data we actually have in this industry.
- int_19h 5y ago
  > Missing features that have no way of being worked around are dismissed off-hand as unnecessary complexity. You forgot to add the part where, once the features are added after all, they stop being "unnecessary" complexity :)

deleted 5y ago

[deleted]

deleted 5y ago
[deleted]

marwatk 5y ago

I have an irrational dislike of go because for every X it's missing the community's answer is "you don't need X" (until they decide you do). Package management, generics, sum types, decent error handling, etc. It's an arrogant approach that rubs me the wrong way. It reminds me of "You're holding it wrong" and seems ingrained in the go ethos. That's not to say I'm not productive in go, but I could be vastly more productive.

twsted 5y ago
If I rethink about how long I was kept away from go by its error handling and then I fell in love with it...

oconnor663 5y ago

> So, for those of you who are willing to explore the part of this that goes beyond a simple rational analysis and criticism of language design, whats bugging you? I coded primarily in Go at work for several years, although that was several years ago. I understand that package management and now generics have changed in major ways since then. But at the risk of being out of date, here are some language-level complaints I had at the time, focusing less on convenience/taste and more on things that I felt made it harder to write correct code: - Nil pointers. Go doesn't have any built-in way of distinguishing between pointers that can be nil and pointers that can't. - Two kinds of nil. Go distinguishes between typed and untyped nil pointers. - Automatic zero-initialization of omitted fields. Adding a new field to a struct has a tendency to make existing callsites incorrect without producing any compiler errors. - Mixing declaration and assignment on the left side of the := operator. Copy-pasting a line from an outer scope to an inner one silently changes assignments into shadowing declarations. - Calling append() without capturing its return value is always wrong. This mistake is easy for linters to catch in simple cases, but aliasing creates more complicated cases. - It's easy to make an implicit temporary copiy of an object without realizing it, like by using a value method receiver or by looping over a slice of values. These are examples of things that made me feel like I was "fighting the language" to try to write correct code. I'd appreciate feedback about any of these that might have changed in the last few years.

kaba0 5y ago
And the stupidest of all: defer is function-scoped, not block.
- oconnor663 5y ago
  I don't like calling any of these things stupid. They're tradeoffs, and I can respect why they were made.
  - kaba0 5y ago
    I would agree with you in the general case, but I yet to hear any sort of sane explanation for why it is the way - and it is not like a typical tradeoff where something arguably worse would have been chosen otherwise, it is just a small semantic change to a keyword. But its effect is huge, e.g. the prototypical usage of the keyword would be to unlock mutexes, but it is simply a huge footgun, see: https://news.ycombinator.com/item?id=30253426 https://news.ycombinator.com/item?id=30253426

matthewmacleod 5y ago

I think my biggest non-specific, slightly silly irritation when using Go is just how annoying I find it to write clear code in it, because the focus on simplicity feels like it too often comes at the expense of clarity, correctness, and expressiveness. I don't like that I'm not able to express simple constraints that I find a really important for improving code quality in other environments – things like "this field cannot be nil and it's a programming error if it is", or "all possible values of this field must be handled". There are lots of other bits, but I'd say the general pattern is being quite frustrated about having to do and remember things that the computer should be handling for me – such that working in Go always feels like having a small rock in my shoe. It's a shame, because as a language—and wider ecosystem—it gets so much stuff really right.

stouset 5y ago
This is my critique of go too. It's really easy to write code that works well for all of the cases I can think to test. But it is strictly impossible to write code where I can make guarantees of robustness. These little warts that prevent that are everywhere: lack of sum types (no Option / Result), half-assed enums, no real ability to make things const, inability to express exhaustive switch statements, having to downcast to `interface{}/any`, nil, typed nil, and on and on and on. The longer I develop software, the less I care about being able to write software that works and the more I care about being able to write software that doesn't fail. The former is table stakes, and I can throw together something that works in virtually any language. The latter is what not only prevents me from spending nights and weekends fixing problems, but also allows me to finish software and truly move on to new projects without having to constantly play whack-a-mole fixing new issues that keep coming up.

kevinmgranger 5y ago

I like parts of Go. It's refreshing. I'm excited for this release. What I don't like is how its weak parts are consistently defended instead of having its shortcomings be acknowledged. Before any rational analysis and criticism can begin, we need to look at the context of these arguments. I'll do that through some of the comments on this post. - Issues people bring up are dismissed as non-issues or as personal preference / opinionated, regardless of their impact. - Critics are asked for rational analysis, but proponents are allowed to use something as airy as "simplicity", a word that has essentially lost all meaning in programming. - Missteps by representatives / stewards of Go are given the most charitable interpretation, critics less so. - Finally, in so many cases, counterarguments to critics are dripping in condescension. I don't think folks are going to get rational analysis. I also don't think they actually want it, whether they realize it or not.

kevinmgranger 5y ago
In case anyone is interested, here are my technical critiques of Go: - Boilerplate increases the surface area that a bug can hide in. The fact that most of the boilerplate is around error handling is especially worrying. Yes, the flexibility of "Errors are values"[1] is nice. But I also don't know any languages where errors _aren't_ values, so the main value add seems to be reduced boilerplate compared to individual try/catches around each function call. - Go manages to repeat the Billion Dollar Mistake[2]. Things like methods working on nil receivers is cool, but not worth the danger or messiness. - Even worse, for a language that claims to value simplicity, the fact that nil sometimes doesn't equal nil[3] is... honestly, I can only consider that a bug. [1]: https://go.dev/blog/errors-are-values https://go.dev/blog/errors-are-values [2]: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/ https://www.infoq.com/presentations/Null-References-The-Bill... [3]: https://go.dev/doc/faq#nil_error https://go.dev/doc/faq#nil_error
- uryga 5y ago
  > But I also don't know any languages where errors _aren't_ values (look, i know you understand how exceptions work, please bear with me) yes, Exception objects are technically values, but you don't return them to the caller; you throw them to the, uh, catcher. basically, you get a special, second way of returning something that bypasses the normal one! but in the EaV approach, errors just are returned like every other thing. the uniformity of EaV comes in handy when doing generic things like mapping a function over a collection - don't have to worry if something will throw, because it's just a value! and that lets you go to some pretty powerful places w.r.t abstraction: see e.g. haskells `traverse`. but yeah, EaV needs some syntactic sugar to reach ergonomic par with exceptions, otherwise you get if-err-not-nil soup :P

stouset 5y ago

> I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. This is a needlessly dismissive perspective. Put another way, now that one of golang's most prominent deficiencies has been addressed, people will switch their focus to other areas of frustration. > Sometimes I think the core irritation with Go is its simplicity. The core irritation (well, my core irritation) around Go is that this simplicity just kicks the cans of complexity and verbosity downstream onto its users, and—in the worst cases—hides the fact that this complexity exists, so encourages writing simple, obvious, and subtly incorrect solutions. Subtly incorrect is by far the worst kind of incorrect, as it results in code that works for all the obvious test cases but breaks at 2AM in production. Go doesn't feel simple to me. It feels half-assed. Let's take a recent example I had to work with: truncating a string to the first 63 characters. Easy, right? s = s[:63] Simple, obvious, and subtly incorrect. Why? UTF-8. Strings in go are just a microscopic wrapper around immutable byte arrays. I could almost consider this okay if there was some type in the language that wrapped a byte array and an encoding to provide a real string type. But not only isn't one included, a reliable one can't even exist. The range keyword iterates over bytes for byte arrays and over UTF-8 code points for strings and there's no way to express anything different. String straddles this uncomfortable middle where it's both a byte array and a UTF-8 string and which one it is depends implicitly on which operators you use on it. Strings are "just" a byte array, except they're supposed to contain UTF-8, but not only is there no way to enforce that they do, the language makes it trivial to accidentally corrupt any UTF-8 string you do have (e.g., through indexing). If you're writing a function and somebody passes you a string you have no way to know or enforce that it's intended to bytes or ASCII or UTF-8 or any encoding whatsoever without iterating through to check. There is no type that actually encodes an enforced requirement of a valid UTF-8 string, nor can one even be written as a library. So the way you're "supposed" to truncate a string is: s = string([]rune(s)[:63]) At least I think that's the magical incantation. Do you do this everywhere? Do your coworkers? Yeah, I didn't think so. Compare this to Rust and Ruby, which take two diametrically opposite (but both IMO reasonable) approaches. In Rust, strings are UTF-8. You cannot construct a String that does not contain a valid UTF-8 byte sequence (at least not without unsafe). You cannot perform safe operations on a string that result in an invalid byte sequence. If you are handed a string, you know that it contains valid UTF-8 bytes. You can iterate over either the bytes or the characters, but you have to explicitly decide which. In Ruby, strings are byte array / encoding pairs. It could be UTF-8, UTF-16, Shift-JIS, EBCDIC, or any other encoding you want it to be. When you're handed a string you can generally assume it's been parsed and validated under that character set. Indexing, iteration, and other operations are all encoding-aware. If you want the bytes, you can choose to access them. The string equivalent in golang is, to put it bluntly, half-assed. It's mostly just a byte array but some keywords assume it's UTF-8. If you're given a string you generally assume it's UTF-8 but there's no reasonable expectation that it's valid since the language makes it ridiculously easy to violate the encoding rules. Go strings aren't even a decent building block for an encoding-aware type since range can't be made to work on other encodings. For a language written by none other than Rob Pike himself, I simply cannot fathom how golang arrived at this design. Keep in mind this is just one of a myriad places where the language punts complexity to the user but, at best, doesn't give them the tools to actually reliably handle it and, at worst, pretends like the complexity doesn't even exist so it's not even obvious something needed special care in the first place. Simple, obvious, and subtly incorrect.

zemo 5y ago

people hate Go because Go is unapologetically designed from the framing of programmers being members of a labor class having differing levels of expertise. It's not the design itself; it's the design goals themselves that people are opposed to. This Rob Pike quote gets bandied around in these discussions: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. Ten years ago when I learned Go at the Recurse Center, I was early in my career and I picked Go as my language of study because I believed it was a good bet for my career prospects. I said to myself "I bet this is the next Java, and I bet that people who learned Java very early did very well for themselves". This bet proved correct; Go has been enormously useful to me in my career. Many people who go to RC pick languages like Haskell or a Lisp instead; things that are more interesting and challenging. While Haskell is well known for being mentally stimulating and very enriching, it is also well known for not seeing much industry adoption. You can sub a handful of other languages here, but basically just think of any very beautiful cutting edge experimental language that doesn't have a lot of industry jobs. I'm stick to Haskell for consistency in this post but you could just as easily say Lisp or Scala or arguably Rust these days; it's not about a specific language, it's about a specific grouping of languages that prioritize the beauty of the language and the effectiveness of the solo developer. People get upset at Pike's framing that Go should be learnable by people with less-than-expert experience. As a person sees technology's ability to serve as a vehicle of class mobility, I see this as a great and noble design goal, because I think class mobility is fundamentally good. Ask yourself this: why do people consider it bad that a language acknowledge that it should help not only people with lots of experience, but also people with very little experience, and teams with mixed levels of experience? My experience of programming Go for ten years and for being in these spaces for that time frame is that criticism of Go almost uniformly comes from people who can afford to invest heavily in things that have a low expected ROI; great and beautiful languages that don't have a lot of job prospects. Most people on Earth cannot afford the time commitment it takes to learn programming at all, let alone learning aspects of programming that they can't monetize. I have never met a Go programmer that is bothered by the existence of Haskell. I have met many, many Haskell programmers that are bothered by the existence of Go. Ask yourself why that is. Ask yourself why someone would be so angry about something so wildly successful and useful to people. It's not even remotely a two-way street; the hatred goes one way. This leaves us with the final problem: why can't people acknowledge that different people have different goals, and that those people's goals are just as legitimate as their own? Why are other people's goals threatening? It's because the existence of Go and the massive success of Go causes people to confront some aspect of class consciousness. It is impossible to witness the enormous success of Go and not confront the idea that programmers are laborers, and for some people, the idea of being a member of the labor class is simply not acceptable; criticizing Go thus becomes not merely an act of design criticism, but also as vehicle through which the critic can express something about their own socioeconomic class. There are many valid criticisms of Go, but there is also a category of Go criticism that exists more as a form of class signaling than anything else, and in these public forums, those two forms of criticism often get entangled in complex and opaque ways.

int_19h 5y ago

I doubt that sum types are going to be a big target, given the lack of support for them in many other mainstream languages. The lack of generics was standing out so much precisely because Go was the only mainstream statically typed PL without them by choice.