9 ms·

Lies we tell ourselves to keep using Golang

130 points by danslo 4y ago

synergy20 4y ago
On and off with Golang and now stay with c++17/c++20(a subset of it that is to make it good enough and simpler for daily coding). I need c++ no matter what, adding Golang did not gain much so far plus it is a very different programming paradigm.
- ilyt 4y ago
  Rust seems closer to C++ than Go
jarbus 4y ago
What's with all the Go hate on HN all of a sudden?
- deleted 4y ago
  [deleted]
- somekyle2 4y ago
  It is not all the sudden as far as I can tell. There's a long history of Go hate, and it makes sense to me. Go is a new(ish) and fairly popular language, which already guarantees some level of hate. More substantially, it is an implicit argument against most things language enthusiasts like about programming languages; it's lack of static features and dynamic capability, it's non-focus on optimality in any domain, there's no attempt at uniform elegance or a motivating theory, it's just a kinda mundane procedural language that tries to solve some problems C enthusiasts had while avoiding the things that bugged them about Java and C++ (to oversimplify). A language such as that succeeding socially and practically is borderline offensive to folks who love clever language and runtime design, who love things that can push the boundaries of performance or verifiability. Something so apparently mundane and poorly thought getting traction is a regression in the world of software engineering, supported by a Big Evil Corp that many folks dislike. I've also personally seen a social meta-effect of this, where in a particular space all of the language aficionados would make a point of dumping on Go whenever Go was discussed (or even when a dig at Go could be shoe-horned into another discussion), and at a certain point there are only negative discussions of it, and the snobbery (justified or not) is a form of social bonding. Of course, there are loads of legitimate criticism to be applied to the language design, the runtime, the rollout, the marketing, the framings of the authors, but there's a persistence, a snarl, to some of the critics that seems to me to go beyond an observation of the real issues. For reasons listed above, some people seem to take hating Go quite personally.
  - erik_seaberg 4y ago
    The HN audience started out with fans of essays like http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html and http://www.paulgraham.com/hundred.html http://www.paulgraham.com/hundred.html, and now a language arose that seems to intentionally embrace the blub paradox.
    - kaba0 4y ago
      What exactly is novel about Go? The only thing that comes to mind is go routines, but it is not integrated well in the language for several reasons, and concurrency is just a very hard problem. Otherwise it is the exact same thing as the litany of basic managed languages.
      - tgv 4y ago
        Why should a language be novel? If you have to hang something on the wall, are you going to discard screws and plugs because they've been around for quite some time? Go is good enough. It has some short-comings. I'd like to see non-nullable types, even though I haven't had a memfault in ages. But it's easy to write it, runs fast, is memory efficient, and runs practically everywhere without a fuss. For normal software, that's such a big plus. I'd hate to have to go back to Java.
        kaba0 4y ago
        Well, the screws and plugs are Java and the litany of older managed languages we have with almost the exact same guarantees. Why should I throw it away and buy a new set which will give me the same thing?
        tgv 4y ago
        Languages have advantages and disadvantages, aside from being novel. Java is a memory hog in comparison to Go; Go is probably a bit faster in execution. The "eco system" for Go is pretty good, tooling too; I'm sure Java has a larger set of libraries and frameworks to choose from, but less easy to integrate. Idk about the current state, but Eclipse and Netbeans were so unpleasant when I did Java. The choice is yours, novelty or not.
- housingisaright 4y ago
  wouldnt say its all sudden, this article has been linked multiple times before and there is probably 2-4 go hate threads per months on HN.
- josephg 4y ago
  Go has never been particularly popular on HN. It’s a bit on the nose, but lots of people here like to think of ourselves as clever (whether it’s true or not). Go, philosophically, is a terrible language to show off in. It’s intentionally designed for every line to require as little brainpower to understand as possible. It’s not an aspirational language - unless you aspire to be able to hire lots of junior programmers and make sure they don’t cause too much trouble. The lukewarm support go had here was because it was still new and trendy. Rust will lose its lustre in a decade or so too, and the tone will inevitably turn more negative. You can see the pattern slowly play itself out at the moment with docker.
  - worik 4y ago
    Mēh! > The lukewarm support go had here was because it was still new and trendy. Rust will lose its lustre in a decade or so too, and the tone will inevitably turn more negative.... Are Rust and Go not the same age?
    - josephg 4y ago
      > Are Rust and Go not the same age? Rust only really started to get traction after 1.0 landed in 2015. Even then, writing web services and things like that in rust has only really been ergonomic in the last few years as async/await has stabilized. Rust is still a pretty niche language, and its much easier to admire something from a distance. Go hit 1.0 in 2012, but people started using it in production before even then.
      - zozbot234 4y ago
        I'd say the 2018 edition was even more relevant (and that was late 2018, in fact). Rust was very hard to use prior to non-lexical lifetimes. So the real mass popularity of Rust is very recent. Also why it's a bit silly to compare Rust to any other language (just pick your favorite: Go, C++, Java/C#, Python/Ruby, Haskell/Elixir, Javascript/TypeScript etc. and expect it to be just as popular. There's a whole lot of legacy projects written in older languages and they have to be maintained, even though some stuff does get ported to Rust in the meantime.)
- guilhas 4y ago
  Rust fans trying to convince everyone it's the next big thing
- bsg75 4y ago
  People seem to get really upset about a language that does not do what they want, or how they want it to be done, so they write articles about the language nobody is forcing them to use. I get that Rust or C++ has more power or expressiveness, but neither of those come without additional cognitive effort for us non-CS types. But if I don’t _need_ to work in Rust to get my work done, why bother ? Go is good enough for me, Rust for others, etc. Hating a technology that you can choose not to use seems futile.
  - erik_seaberg 4y ago
    > language nobody is forcing them to use Only if I were adamant enough to quit each time it happens (I say this having joined a team that was explicitly Java/Scala-focused, and yet.)
jstx1 4y ago
That's a lot of words for a language you don't like and don't want to use.
- richbell 4y ago
  > That's a lot of words for a language you don't like and don't want to use. I agree, I'm glad the author wrote up such thoughtful constructive criticism. They clearly care about software development and want everyone to improve. :)
  - ctvo 4y ago
    They didn't though. It's ... familiar quibbles surrounded by noise. I'd love it if you could summarize the thoughtful constructive criticism you saw for the rest of us.
    - worik 4y ago
      > It's ... familiar quibbles surrounded by noise. I found it helpful. It did confirm my priors (Go is useful for a big class of problems) and educate me a bit (uninitialised values set to zero??) I have compiled some Go (so fast) but written zero Go. I do not like garbage collected languages, but rather a garbage collector than reference counting (I have done a lot of Swift - Why? For money - there could be no other reason) > I'd love it if you could summarize the thoughtful constructive criticism you saw for the rest of us. The lack of protections for using uninitialised data structures. I learnt about that from this article. Makes me nostalgic for C
- samtho 4y ago
  I seriously cannot tell if you are trying to be ironic here.
  - jstx1 4y ago
    My point is that they're putting a lot of unnecessary effort and attention into being negative about something that they don't have to use anyway. The author is making a living out of being a full time Rust online personality - https://fasterthanli.me/articles/becoming-fasterthanlime-full-time https://fasterthanli.me/articles/becoming-fasterthanlime-ful... - maybe these unnecessarily controversial takes help them attract more attention and make a bit more money.
convolvatron 4y ago
I find the opposite to be true about junior/senior. junior programmers accepts all kinds of awful things because they assume there is a good reason. senior programmers are pretty deeply aware that the whole jenga pile is suspect.
- b3morales 4y ago
  Agree, and the inverse problem is also prevalent, as we all know: someone without experience looks at a system, declares it to be shit while ignoring all the edge cases and design constraints that went into it, and insists they can do better by starting from scratch.
  - richbell 4y ago
    At a company I worked at, one of the VPs secured his son a "Senior Developer" role fresh out of a boot camp. His son was assigned to a high-visibility project that had been in development for several months and immediately started trashing it for using SQL instead of NoSQL, amongst many other reasons. He drew up some fancy diagrams and managed to convince people that the only way for the project to 'scale' was to do a rewrite from scratch with a new shiny tech stack. Several months later and they were still struggling to deliver a "Hello World".
  - Ygg2 4y ago
    Those who don't understand system's history/structure/constraints are doomed to re-implement it... Badly. See: C++/Java OOP implementation.
- rxhernandez 4y ago
  I was lucky to learn this a decade ago when I was an intern; except it came from the electrical engineering side of the department (a department who produced products that were seen as the gold standard for that part of the medical device industry) Manager (who was a world class electrical engineer): "why did you reuse this?" Friend (who was also an intern): "I assumed ${staffEngineer} knew what they were doing and it would be fine to just place it in this design" Manager: "never assume that anyone knows what they're doing here or at any other organization."
dochtman 4y ago
Previously: https://news.ycombinator.com/item?id=31205072 https://news.ycombinator.com/item?id=31205072 (Edited to point to page 1.)
- metadat 4y ago
  Why link to page 2? If you want to begin at page one, try this: https://news.ycombinator.com/item?id=31205072 https://news.ycombinator.com/item?id=31205072 Edit: thanks for the follow-up @dochtman, it was just a little confusing. Cheers!
  - dochtman 4y ago
    Googled the link, posted a little too quickly. Fixed it up.
freecodyx 4y ago
You can’t have a perfect language. Go is good enough for what is good at. Plus advanced IDE will help make the experience even better
- explodingcamera 4y ago
  That doesn't mean there nothing to be learned from mistakes previous languages made and striving to create iteratively better languages
- ilyt 4y ago
  Sure, no language is perfect but some things in Go were apparently "to make it simpler", but by lack of them it made the code in the end more complex and/or verbose. Lack of generics made a lot of code less type-safe than it should, and just more complexity and/or duplication. Lack of sum types made some types ugly (like mentioned IP type), and other ways of control flow harder. Rust-like Result<T> would be massive improvement to verboseness of error handling in Go for example, without really any drawbacks.
firloop 4y ago
Little bit of a nit on the title if the author is reading this. Go is called Go, not Golang. https://go.dev/doc/faq#go_or_golang https://go.dev/doc/faq#go_or_golang
- seneca 4y ago
  It is extremely common to use "Golang" for Go to disambiguation the extremely common word. Not necessary on HN due to context, but it helps with SEO for blog posts.
- nequo 4y ago
  To me, "Golang" is a good compromise to make material about it searchable. For example, Lean is notoriously hard to find stuff about. Try entering "lean" into HN's search engine: https://hn.algolia.com/?q=lean https://hn.algolia.com/?q=lean I wish there was a convention to call it "Leanlang" or "leanprover" or something.
- jmainguy 4y ago
  I always list it as Go/Golang on resume. Don't want people thinking I'm good at that board game
  - richbell 4y ago
    From what I've heard about its difficulty, I'd be far more impressed if you were proficient at Go.
  - WJW 4y ago
    When people write phrases like "Proficient in C, C++, Go and Malbolge" on their resume it's always a pain to figure out if they mean the programming language or the board game.
    - aflag 4y ago
      I once interviewed someone who was "proficient in dart, go and nim", but I was puzzled when they said they never wrote a computer program in their life.
jasonhansel 4y ago
Something that annoys me: - Go's approach to normal error handling assumes that correctness and proper error handling are paramount: every error must be handled explicitly, and every control flow path must be made obvious, no matter how much verbosity this creates. - Go's approach to panic handling assumes that correctness and proper error handling don't matter: a function can halt at any given point, panics are easy to trigger by accident (e.g. methods with nil receivers), handling them explicitly is usually discouraged, and they tend to leave values in intermediate and unexpected states (unless you use "defer" very carefully and consistently). Rust partially resolves this issue by preventing many causes of panics, by using methods like "lock poisoning" to avoid leaving shared values in unexpected states, and by having proper destructors. Go's approach (just crash everything) makes it easy for one error to completely bring down an application. Handling panics leads to values being left in inconsistent states with operations half-completed.
- tapirl 4y ago
  > panics are easy to trigger (e.g. methods with nil receivers) No, methods nil receivers in Go don't trigger panics (if they are not dereferenced). > every error must be handled explicitly, and every control flow path must be made obvious, no matter how much verbosity this creates. Is this, bad? It is just the recommended way. You are not required to implement your code in this way.
  - Cyph0n 4y ago
    Why would you have a method that doesn’t touch the receiver? Refactor it into a function.
    - assbuttbuttass 4y ago
      Dereferencing isn't the only way to touch a pointer: func (o *myObject) isNil() bool { return o == nil }
      - Cyph0n 4y ago
aetherson 4y ago
The author fundamentally misunderstands poor weather. Portland's weather is pretty nice! Definitely better than, say, Chicago, or St Louis, or Minneapolis, or Buffalo. I'd argue also better than Austin or Dallas, though people are free to disagree about the merits of unbearably hot weather vs rainy cold weather.
- d1str0 4y ago
  Absolutely! I’d much prefer a mild temp with constant rain vs. wildly changing temps at extremes and crazy wind or storms.
  - aussiesnack 4y ago
    Clearly a matter of taste then. I much prefer the extremes, and find mild weather boring. Maybe it's having grown up in England. Much happier where I live now and I'm at frequent risk of fires and floods!
- LikeAnElephant 4y ago
  Amen. Mild weather + usually gray > extreme weather + usually sunny. Though I'd never fault someone for making different decisions. The fire season of the past few years are changing the equation for me though...
aeturnum 4y ago
Having shipped a little golang code (back in ~2017) and having watched things evolve, my sense is this: - Golang doesn't fit comfortably into the spectrum of "low level & fast v.s. high level and easy" languages, largely because it does go in different directions in many ways (see: critiques on their garbage collector, type system, etc). - Smart people are happy with Golang, but the fact that it makes different choices means that people regularly discover to their sorrow that the language isn't quite what they expected. - In general, most of the "go was wrong for us" stories seem to come from companies that use it as a side language. Teams where Golang is their main workhorse generally seem at peace with its choices. To me, it means I have no doubt you can build a company on Go - but maybe build that experimental high-performance replacement for a python service in Rust.
- zozbot234 4y ago
  "Teams where Golang is their workhorse" probably made that choice a long time ago and have a lot of legacy code in the language. Staying with Go for the most part is just the sensible thing to do in that situation.
foldr 4y ago
I fail to see the point of this. Buried in this post are one or two reasonable (but familiar) criticisms of Go. As for the rest of it, the author appears to be upset that everyone in the world didn't immediately stop using Go after reading his blog post of two years ago.
- aidenn0 4y ago
  The author does not think everyone in the world should immediately stop using Go. TFA even mentions that tailscale's use of Go could very well be the correct choice. TFA is about dismissive comments about the article and people burying their head in the sand rather than engaging with the criticisms.
  - ilyt 4y ago
    Or they are just fine with the drawbacks and are annoyed by another non-user whining about it. Yet another whiner complaining about well-known problems that advanced users are aware of doesn't add anything and nothing in this article is new thing to any advanced user. Especially if the asshole behind article makes the title extra confrontational and aggressive just to piss off people.
    - richbell 4y ago
      > Yet another whiner complaining about well-known problems that advanced users are aware of doesn't add anything and nothing in this article is new thing to any advanced user. "Well-known problems that advanced users are aware of", in other words problems that you can and will shoot yourself in the foot with unless you've already shot yourself in the foot and know to avoid them? Why is it contentious to say that things should and could be better? > Especially if the asshole behind article makes the title extra confrontational and aggressive just to piss off people. Why do you feel the need to reproach constructive criticism as being from assholes and "whiners"? You can like Go, or anything else, while acknowledging its flaws and believing it should be better. I thoroughly enjoy Kotlin, TypeScript, and a handful of other technologies but I will be the first to admit and lament their failings. (I'll admit the title is cheeky/provocative, but I think calling the author an asshole and ascribing intent that they want to piss people off says more about you than them.)
tapirl 4y ago
The author doesn't use Go any more, but cares about Go so much. ;D
- gefriertrockner 4y ago
  Definitely gets attention on HN for it.
camdenlock 4y ago
[dead]
_cenw 4y ago
The article spends an inordinate amount of time to delve into meta arguments about groupthink and elitism and juniors vs. seniors which is interesting enough, but I find the meat of the argument a bit lacking. Go has some warts, but they're all things that make sense if you know some basic concepts about go (as in you can derive them from knowing how go ticks), versus thousands of random caveats in the core library of other languages. They seem to be most upset about allocation, but it is in fact pretty simple. Types that can be nil are nil upon initialisation, and everything else is a zero value (by virtue of not being a pointer). C isn't actually different here. The only thing I'd expect to surprise a C programmer here is that strings aren't pointers by default, despite being variable length. And I'm not sure what their point about CGO is. People always say to avoid it because you leave the Go world behind and because performance could be better, but it is still a legitimate way to achieve FFI. The SQLite package uses it and nobody recommends against using that either. It just comes with a "more complexity if you add this" disclaimer.
- kelnos 4y ago
  > Go has some warts, but they're all things that make sense if you know some basic concepts about go That's exactly the problem. I don't want to spend my time learning the myriad quirks of a language. I want to spend my time building my program. As someone who is an "advanced beginner" at Go, I assure you that just knowing "some basic concepts" is not enough to avoid Go's pitfalls and footguns. I don't want to work in a language where the solution to all these things is "just be careful when writing code". I'm fallible. Compilers, less so. The compiler should be doing this work for me.
  - loosescrews 4y ago
    > I don't want to spend my time learning the myriad quirks of a language. That is just it. Go's quirks are mostly a result of its consistency, not a result of a lack of consistency. > I assure you that just knowing "some basic concepts" is not enough to avoid Go's pitfalls and footguns. It seems that Go has two somewhat contradictory goals: consistency and similarity to popular yet inconsistent languages. This seems to result in a lot of people who can generally use the language, but haven't learned the language model because the language doesn't require that in order to get started. This seems to frustrate a lot of people and prevent them from ever learning the language model. Languages which appear completely different from popular languages don't seem to suffer this issue because people tend to learn the language model up front. Go really only has one major source of inconsistency and that is the late addition of type parameterization. The built-in parameterized types are special, but still generally follow the same rules as other types with a few exceptions. The main thing you need to know about slices, maps, and interfaces is what they actually are. Once you know that, the normal rules apply. Channels are a different beast though.
candrewlee14 4y ago
I agree that structs should enforce using all fields or have provided some defaults at declaration, a result type would be nice, FFI is much harder than most other PLs I’ve worked with, and if your use case is a bad case for the GC, you’re in trouble. At the same time, I really like go. No other AOT-compiled language I know of makes concurrency so easy: `go foo()`. It’s wonderfully simple and I love that using the language doesn’t cram my working memory. It feels like all the space is there for my problem. It isn’t the right tool for some jobs, and of course, you’re perfectly entitled to your opinion. But I think it’s a welcome tool in the toolbox. I recently had to implement Raft in Go, and I don’t know of a better language for that. Feel free to inform me otherwise. The race condition checker, RPC libs, and simple concurrency let me focus on the algorithm implementation. The iteration speeds for me were super fast too since Go keeps compile times snappy. These are all useful tradeoffs for me to keep in mind when deciding the right tool for the job. I wouldn’t consider these “lies” personally, but maybe I do have the wool pulled over my eyes :)
- ilyt 4y ago
  > I agree that structs should enforce using all fields Nah, enforcement would be a problem if you're just say making a protocol decoder, you might "just" write struct as defined by API but not need to use all of its fields, or not use it inside the package (say package that decodes some JSON then just returns a struct with it) I'd like go vet option for that tho as in some cases that would be useful. > or have provided some defaults at declaration Outright initializers would be nice vs New*() for any type that needs it and having developer to remember to call that
aidenn0 4y ago
HN comment mentioned in TFA appears to be https://news.ycombinator.com/item?id=31194152 https://news.ycombinator.com/item?id=31194152
lvl102 4y ago
Go is OK. I think early adoption was mostly among Chinese startups due to the language being tied to Google and Pike.
eikenberry 4y ago
Programming languages are subjective mediums, with no real objective measures, and that the negatives of the language are part of what gives it its character is is why people like it, not why they dislike it. Reminds me of a diatribe by an oil painter on why people shouldn't use acrylic paints. Probably mostly a cathartic thing after the author took a job that needed it before trying it out.
cjk 4y ago
I've written a heaping pile of Go code over the last few years. I consider myself a fan, but not a fanatic. I tend to believe that Go's failings aren't any worse than the failings of most other languages, and for me, the drop-dead-simple cross-compiling and batteries-included standard library is well worth its warts. That said, I found myself vehemently agreeing with the author re: how hostile Go is to FFI/etc. IMO, a network boundary is indeed the sanest way for most other things to communicate with Go code. Re: Go on Windows: anecdotally, things seem a lot better than even a couple years ago, but there's still room for improvement for sure. It's baffling that the semantics of e.g. os.Rename() are so different between POSIX-y platforms and Windows when they don't have to be (Windows supports POSIX-style renaming semantics if you ask nicely). I ended up having to reimplement os.Rename() on Windows in terms of SetFileInformationByHandle() with the FILE_RENAME_POSIX_SEMANTICS and FILE_RENAME_REPLACE_IF_EXISTS flags set to get the behavior I was looking for. Re: mutable state, I think these concerns are mostly overblown. These are problems we've been dealing with in the vast majority of mainstream languages for many years now, and there are plenty of strategies for dealing with it. For example, if I want to pass an "object" by reference in Go but do not want it to be mutated, I'll wrap it in an interface with getter methods for its fields, but no setters or anything that can cause side effects. Sure, it's a bit more involved than tagging something with the `const` keyword in e.g. C++, but it's plenty effective.
- worik 4y ago
  > Re: mutable state, I think these concerns are mostly overblown. These are problems we've been dealing with in the vast majority of mainstream languages for many years now.... Yes. Do not minimise this. For very large complex systems immutable state is very helpful. > pass an "object" by reference in Go but do not want it to be mutated, I'll wrap it in an interface Making the point. Horses for courses, but this is picking the course for this nag.
  - cjk 4y ago
    100% agreed -- if it wasn't clear, I wasn't trying to downplay the importance of immutable state. Just saying that it's perfectly achievable in Go with a small bit of effort.
alphazard 4y ago
Go criticism is always focused on the language itself, which is admittedly non-optimal. But it's non-optimal in the direction of missing features. Contrast that with most languages which are non-optimal in the direction of having too many features which are poorly designed. Go's position on the simplicity vs feature set continuum is perhaps the least interesting reason it's popular. There are a myriad of other reasons for its success: - It spits out static binaries with minimal fuss. - The import statement maps strings to symbols. No complicated module system to learn. The strings are resolved to something like URLs, but that's not part of the language. It's very easy to see code on GitHub and import it. - Packages are just directories. - No new package namespace with squatters and poor infrastructure. Go packages, in practice, are named with DNS. You know, the namespace that already exists and everything else has standardized on. - Rejection of complicated version selection. Go almost went down the npm route, there was even an "official experiment" that looked much like other package managers. Then the Go leadership stepped in and sorted things out. https://research.swtch.com/vgo-mvs https://research.swtch.com/vgo-mvs Go is set up to be the language of an ecosystem in a way that most other languages are not. If you are a language designer: take Go's import statement, packages, and modules, and just copy them. You aren't going to do better, and you probably weren't trying to innovate in that area anyway.
- worik 4y ago
  Plus very fast compile times.
- mdaniel 4y ago
  > The import statement maps strings to symbols. No complicated module system to learn. The strings are resolved to something like URLs, but that's not part of the language. It's very easy to see code on GitHub and import it. This is for sure untrue, unless one is already steeped in the golang ecosystem. $ cat go.mod requires ( github.com/pulumi/pulumi/sdk/v3 v3.43.1 ) oh, cool, I can just navigate to https://github.com/pulumi/pulumi/tree/v3.43.1/sdk/v3 https://github.com/pulumi/pulumi/tree/v3.43.1/sdk/v3 to view the source ... oh, :sad-trombone: it's 404. Well, why is that? $ curl https://github.com/pulumi/pulumi/blob/v3.43.1/sdk/go.mod | head 1 module github.com/pulumi/pulumi/sdk/v3 Oh, because the "module" line is decoupled from the apparent URL. Then there's this `gopkg.in/yaml.v2` nonsense, as described by this: https://go.dev/src/cmd/go/internal/help/helpdoc.go#L251 https://go.dev/src/cmd/go/internal/help/helpdoc.go#L251 Meaning navigating to https://gopkg.in/yaml.v2 https://gopkg.in/yaml.v2 gets one thing, but https://gopkg.in/yaml.v2?go-get=1 https://gopkg.in/yaml.v2?go-get=1 produces another and only a view-source of the latter shows what golang is going to use. Yes, I'm aware that out of the kindness of the author's heart the browser version does link to the alleged source repo, but alleged is the key part of that
aaomidi 4y ago
I actually like how this article is written, and I'm a big go fan. I think the article has a conclusion it's trying to push to __stop using Go__. Maybe I misread it, but that's what it sounds like. Honestly though, I am fine with Go. Every language has its ups and downs. What I like about Go is specifically what the article pointed out, the simplicity means I need to only remember a few concepts. In contrast, with Rust, or C, or C++, or Java, or C# I have to know _so many small details_ to not shoot myself in the foot.
- kaba0 4y ago
  > In contrast, with Rust, or C, or C++, or Java, or C# I have to know _so many small details_ to not shoot myself in the foot. Java arguably has even less foot guns then Go and is an simpler language.
steeleduncan 4y ago
> Go is a pretty good async runtime I think the author is in many ways right, but has missed how important the runtime is to the average programmer. At the time of release Go made it easy to write evented IO servers, in a way that Rust, despite its superior language design (IMHO), still hasn't. This is why people continue to use it. Other examples are PHP, a car crash of a language, but suddenly it was easy to dynamically generate a webpage, or early versions of Java, widely derided for language design, but programmers were happy to trade the virtues of elegance and efficiency for the ease of the standard library, the GC, and portability. Give the programmers the ability to do easily something they weren't able to do prior to using your language, and they'll use it, whether PL enthusiasts are happy about that or not.
- unity1001 4y ago
  > PHP, a car crash of a language That car crash of a language can imitate the general characteristics and typing style of any language and provide for using any pattern/anti-pattern in computer languages by just modifying its ini files to however you want it to work. That's why its 80% of the web.
  - kaba0 4y ago
    Which is just as much of a curse, see lisps’ flexibility.
- aaomidi 4y ago
  This is also why NodeJS got so popular. Concurrent programming is made so damned easy in it, that of course it blew up in popularity. Most folks just need concurrent code, not parallel code. NodeJS was able to provide that.
- worik 4y ago
  I am not a fan of async/await paradigms. It is yet another example of making easy things easy. It is not hard to write non blocking code. No harder than remembering to insert a keyword "await". Event loops are very useful, I agree. I just do not see how a new syntax makes them "easier".
kelnos 4y ago
> The very reason I don't consider Go a language "suitable for beginners" is precisely that its compiler accepts so much code that is very clearly wrong. This struck me as a really insightful thing to say. I often talk about how I like languages with strong type systems, and how I like using those type systems as fully as my brain thinks is reasonable to do so, because when the compiler finishes with no error, I have much more confidence that what I wrote is correct. But I never really thought about it from the other side: being beginner friendly doesn't just mean "you can pick up the syntax in an afternoon". It should mean that the compiler saves you from beginner mistakes. As someone who only occasionally uses Go, I'd consider myself an "advanced beginner" at the language. And I remember many of the times I wrote code that seemed correct, and the compiler accepted, but was wrong because of Go's quirks. That alone is a reason to disqualify Go for me as a language to get serious work done in.
ctvo 4y ago
It's a little presumptuous to assume the teams and developers using Go are lying to themselves about Go vs. they've made the calculations and like the tradeoffs. Opinionated language and tooling plus good enough performance without a runtime may be worth more to them than the two (?? I lost count trying to find them in the article) issues the author brings up.
- worik 4y ago
  > It's a little presumptuous to assume the teams and developers using Go are lying to themselves about Go vs..... I think it is a bit naive to think that these sorts of decisions are made by competent technical people. In my experience these decisions are made by managers that have "Peter Principled" past their competence.
zippergz 4y ago
If this guy is good at anything, it's generating comments and driving traffic to his blog.
AlbertCory 4y ago
I was at Google the whole time Go was being developed. A friend of mine had two, count 'em, two quotes that pertain to it: 1. The answer to an unasked question 2. When your only tool is a hammer, every problem looks like a thumb And one I just made up: 3. I had a problem, so I invented a new programming language. Now I have 769 problems We could look at Rob Pike & the Bell Labs guys and imagine Stephen Stills saying "Hey, 'For What It's Worth' was the worst song Buffalo Springfield ever did. Let's fix it." Too late. It's out there. And C is out there.
- deleted 4y ago
  [deleted]
pharmakom 4y ago
C# has channels as part of the standard library and is much preferable to Go imo
loosescrews 4y ago
I'm a Go fan and the author makes some good points. That said, their arguments seem a bit one sided and there are a number of areas where they get close to, but miss what I feel should be the real conclusion. I'm going to focus on toolchain related issue because I feel better able to speak on these topics. The language issues the author brings up are similar though. RPCs instead of FFI. There is some truth here. I personally find wrapping foreign code in a C interface and using CGO to be pretty easy, but RPCs are a good choice as well. The author then jumps to this necessarily including TCP overhead which is wrong. If a FFI is the alternative, then running on a single machine is acceptable and a Unix socket is an option (I'm sure there is something similar for Windows). I have often combined these strategies where I wrap some C++ code in a C library and integrate it into a CGO gRPC service which serves on a Unix socket. I do this because I find setting up an RPC service in Go to be much easier than C++ and I want to isolate the C/CGO. Using an RPC interface also limits the unsafe code to a process which can be optionally further sandboxed (e.g. with SECCOMP). If you are concerned about memory safety, this might be a good idea even if you are using two languages with better FFIs. Even if both languages are memory safe, the FFI almost never is. In addition to the security benefits, this also makes debugging memory issues easier as it limits their scope. Another benefit to FFIs being bad is that it has pushed Go to be one of the only languages where most code has no C dependencies. Nearly the entire standard library is pure Go and the parts that aren't are not commonly used or provide optional functionality which is not commonly needed. Most third party libraries I find on GitHub are pure Go as well and only have pure Go dependencies. The majority of Go binaries I have encountered either are or can be built with CGO disabled. This has two major benefits. First, it makes Go code much safer. C dependencies are a major source of memory unsafety bugs. The most common C dependency (in Linux land anyway) is glibc. glibc is well known for its terrible code quality and history of security vulnerabilities. Go is one of the only languages which makes it easy to not depend on it. Since the author brings up Rust, I would personally feel better about untrusted data being processed by a pure Go program than a Rust program with C dependencies. Second, even the best FFIs make code harder to read. If nothing else, now you need to be familiar with both languages. Go libraries usually being pure Go makes it easy to jump into random library code and figure out what is going on. The author also mentions build systems with a vague comment about cases not considered important by the Go authors. In my opinion, the true build system for Go is Bazel. Bazel has great Go support because Go was built with Bazel in mind. The fact that Go and Bazel handle imports in almost the same way and that Bazel BUILD files can be generated from Go code is not an accident. Bazel is very powerful and is usually a good fit when you start running into the limitations of the built-in Go build system.
deleted 4y ago
[deleted]
yamtaddle 4y ago
> And so they didn't. They didn't design a language. It sorta just "happened". Maybe I'm wrong, but when I use Go it definitely feels designed: specifically, it feels designed to discourage the worst or most-alien-to-the-language's-intended-style dep in your dep tree from being too bad or too alien. That is, the design seems to me (and again, I could be wrong and this effect was in fact an accident) most concerned with keeping the quality and style-distribution of the language's ecosystem, or of a given codebase, on a nice, narrow, pointy curve rather than a flattish wide one, so much so that the authors would prefer an expert be a little annoyed with some part of the language to making doing the Wrong Thing too easy for less-adept developers (or for "experts"). If that was in fact unintentional, well, then my favorite quality of the language (and IMO the most interesting thing about it) was an accident, I suppose. And it's not like I've dug deep into the history of the language's development, so that may be the case for all I know.
hmomh 4y ago
Can someone help me understand what are go's value types good for from a language design point of view? In most other gc languages, value types are always stack allocated and there' no way to take a reference to them, but in go you can happily do so, letting the variable escape its scope and thus be allocated on the heap and be garbage collected. The only thing I can think of is a sort of substitute for immutability, so a function can take a variable by value rather than by pointer and guarantee that it won't modify it, but I don't see it being a win over just letting a variable be declared immutable. The only language I can think of with sort of similar semantics is perl, but in pratice haven't seen many %hashes flying around, it's always $hashrefs instead.
nvarsj 4y ago
Been a golang dev for a long time, although got out of it recently (I got very tired of it). Many contributions to k8s in the early days, etc. Thing I find the most frustrating about golang is the community. It almost seems to be made of people who never used another programming language in their life. Defense of things like lack of generics, lack of a good collections library, lack of good error handling, lack of good dependency management, etc. It's so bizarre to me. As a former Java dev, we all at least admitted the flaws of the language and came up with ways to deal with it (see Effective Java).
poulpy123 4y ago
I've never written a line of go in my life, but I totally disregard these kind of definitive and negative opinions about stuff (here a computer language) that are widely used. If so many people use it that means it's not completely garbage sorry

130 points by danslo 4y ago

On and off with Golang and now stay with c++17/c++20(a subset of it that is to make it good enough and simpler for daily coding). I need c++ no matter what, adding Golang did not gain much so far plus it is a very different programming paradigm.

ilyt 4y ago
Rust seems closer to C++ than Go

jarbus 4y ago

What's with all the Go hate on HN all of a sudden?

deleted 4y ago
[deleted]
somekyle2 4y ago
It is not all the sudden as far as I can tell. There's a long history of Go hate, and it makes sense to me. Go is a new(ish) and fairly popular language, which already guarantees some level of hate. More substantially, it is an implicit argument against most things language enthusiasts like about programming languages; it's lack of static features and dynamic capability, it's non-focus on optimality in any domain, there's no attempt at uniform elegance or a motivating theory, it's just a kinda mundane procedural language that tries to solve some problems C enthusiasts had while avoiding the things that bugged them about Java and C++ (to oversimplify). A language such as that succeeding socially and practically is borderline offensive to folks who love clever language and runtime design, who love things that can push the boundaries of performance or verifiability. Something so apparently mundane and poorly thought getting traction is a regression in the world of software engineering, supported by a Big Evil Corp that many folks dislike. I've also personally seen a social meta-effect of this, where in a particular space all of the language aficionados would make a point of dumping on Go whenever Go was discussed (or even when a dig at Go could be shoe-horned into another discussion), and at a certain point there are only negative discussions of it, and the snobbery (justified or not) is a form of social bonding. Of course, there are loads of legitimate criticism to be applied to the language design, the runtime, the rollout, the marketing, the framings of the authors, but there's a persistence, a snarl, to some of the critics that seems to me to go beyond an observation of the real issues. For reasons listed above, some people seem to take hating Go quite personally.
- erik_seaberg 4y ago
  The HN audience started out with fans of essays like http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html and http://www.paulgraham.com/hundred.html http://www.paulgraham.com/hundred.html, and now a language arose that seems to intentionally embrace the blub paradox.
  - kaba0 4y ago
    What exactly is novel about Go? The only thing that comes to mind is go routines, but it is not integrated well in the language for several reasons, and concurrency is just a very hard problem. Otherwise it is the exact same thing as the litany of basic managed languages.
    - tgv 4y ago
      Why should a language be novel? If you have to hang something on the wall, are you going to discard screws and plugs because they've been around for quite some time? Go is good enough. It has some short-comings. I'd like to see non-nullable types, even though I haven't had a memfault in ages. But it's easy to write it, runs fast, is memory efficient, and runs practically everywhere without a fuss. For normal software, that's such a big plus. I'd hate to have to go back to Java.
      - kaba0 4y ago
        Well, the screws and plugs are Java and the litany of older managed languages we have with almost the exact same guarantees. Why should I throw it away and buy a new set which will give me the same thing?
        tgv 4y ago
        Languages have advantages and disadvantages, aside from being novel. Java is a memory hog in comparison to Go; Go is probably a bit faster in execution. The "eco system" for Go is pretty good, tooling too; I'm sure Java has a larger set of libraries and frameworks to choose from, but less easy to integrate. Idk about the current state, but Eclipse and Netbeans were so unpleasant when I did Java. The choice is yours, novelty or not.
housingisaright 4y ago
wouldnt say its all sudden, this article has been linked multiple times before and there is probably 2-4 go hate threads per months on HN.
josephg 4y ago
Go has never been particularly popular on HN. It’s a bit on the nose, but lots of people here like to think of ourselves as clever (whether it’s true or not). Go, philosophically, is a terrible language to show off in. It’s intentionally designed for every line to require as little brainpower to understand as possible. It’s not an aspirational language - unless you aspire to be able to hire lots of junior programmers and make sure they don’t cause too much trouble. The lukewarm support go had here was because it was still new and trendy. Rust will lose its lustre in a decade or so too, and the tone will inevitably turn more negative. You can see the pattern slowly play itself out at the moment with docker.
- worik 4y ago
  Mēh! > The lukewarm support go had here was because it was still new and trendy. Rust will lose its lustre in a decade or so too, and the tone will inevitably turn more negative.... Are Rust and Go not the same age?
  - josephg 4y ago
    > Are Rust and Go not the same age? Rust only really started to get traction after 1.0 landed in 2015. Even then, writing web services and things like that in rust has only really been ergonomic in the last few years as async/await has stabilized. Rust is still a pretty niche language, and its much easier to admire something from a distance. Go hit 1.0 in 2012, but people started using it in production before even then.
    - zozbot234 4y ago
      I'd say the 2018 edition was even more relevant (and that was late 2018, in fact). Rust was very hard to use prior to non-lexical lifetimes. So the real mass popularity of Rust is very recent. Also why it's a bit silly to compare Rust to any other language (just pick your favorite: Go, C++, Java/C#, Python/Ruby, Haskell/Elixir, Javascript/TypeScript etc. and expect it to be just as popular. There's a whole lot of legacy projects written in older languages and they have to be maintained, even though some stuff does get ported to Rust in the meantime.)
guilhas 4y ago
Rust fans trying to convince everyone it's the next big thing
bsg75 4y ago
People seem to get really upset about a language that does not do what they want, or how they want it to be done, so they write articles about the language nobody is forcing them to use. I get that Rust or C++ has more power or expressiveness, but neither of those come without additional cognitive effort for us non-CS types. But if I don’t _need_ to work in Rust to get my work done, why bother ? Go is good enough for me, Rust for others, etc. Hating a technology that you can choose not to use seems futile.
- erik_seaberg 4y ago
  > language nobody is forcing them to use Only if I were adamant enough to quit each time it happens (I say this having joined a team that was explicitly Java/Scala-focused, and yet.)

jstx1 4y ago

That's a lot of words for a language you don't like and don't want to use.

richbell 4y ago
> That's a lot of words for a language you don't like and don't want to use. I agree, I'm glad the author wrote up such thoughtful constructive criticism. They clearly care about software development and want everyone to improve. :)
- ctvo 4y ago
  They didn't though. It's ... familiar quibbles surrounded by noise. I'd love it if you could summarize the thoughtful constructive criticism you saw for the rest of us.
  - worik 4y ago
    > It's ... familiar quibbles surrounded by noise. I found it helpful. It did confirm my priors (Go is useful for a big class of problems) and educate me a bit (uninitialised values set to zero??) I have compiled some Go (so fast) but written zero Go. I do not like garbage collected languages, but rather a garbage collector than reference counting (I have done a lot of Swift - Why? For money - there could be no other reason) > I'd love it if you could summarize the thoughtful constructive criticism you saw for the rest of us. The lack of protections for using uninitialised data structures. I learnt about that from this article. Makes me nostalgic for C
samtho 4y ago
I seriously cannot tell if you are trying to be ironic here.
- jstx1 4y ago
  My point is that they're putting a lot of unnecessary effort and attention into being negative about something that they don't have to use anyway. The author is making a living out of being a full time Rust online personality - https://fasterthanli.me/articles/becoming-fasterthanlime-full-time https://fasterthanli.me/articles/becoming-fasterthanlime-ful... - maybe these unnecessarily controversial takes help them attract more attention and make a bit more money.

convolvatron 4y ago

I find the opposite to be true about junior/senior. junior programmers accepts all kinds of awful things because they assume there is a good reason. senior programmers are pretty deeply aware that the whole jenga pile is suspect.

b3morales 4y ago
Agree, and the inverse problem is also prevalent, as we all know: someone without experience looks at a system, declares it to be shit while ignoring all the edge cases and design constraints that went into it, and insists they can do better by starting from scratch.
- richbell 4y ago
  At a company I worked at, one of the VPs secured his son a "Senior Developer" role fresh out of a boot camp. His son was assigned to a high-visibility project that had been in development for several months and immediately started trashing it for using SQL instead of NoSQL, amongst many other reasons. He drew up some fancy diagrams and managed to convince people that the only way for the project to 'scale' was to do a rewrite from scratch with a new shiny tech stack. Several months later and they were still struggling to deliver a "Hello World".
- Ygg2 4y ago
  Those who don't understand system's history/structure/constraints are doomed to re-implement it... Badly. See: C++/Java OOP implementation.
rxhernandez 4y ago
I was lucky to learn this a decade ago when I was an intern; except it came from the electrical engineering side of the department (a department who produced products that were seen as the gold standard for that part of the medical device industry) Manager (who was a world class electrical engineer): "why did you reuse this?" Friend (who was also an intern): "I assumed ${staffEngineer} knew what they were doing and it would be fine to just place it in this design" Manager: "never assume that anyone knows what they're doing here or at any other organization."

dochtman 4y ago

Previously: https://news.ycombinator.com/item?id=31205072 https://news.ycombinator.com/item?id=31205072 (Edited to point to page 1.)

metadat 4y ago
Why link to page 2? If you want to begin at page one, try this: https://news.ycombinator.com/item?id=31205072 https://news.ycombinator.com/item?id=31205072 Edit: thanks for the follow-up @dochtman, it was just a little confusing. Cheers!
- dochtman 4y ago
  Googled the link, posted a little too quickly. Fixed it up.

freecodyx 4y ago

You can’t have a perfect language. Go is good enough for what is good at. Plus advanced IDE will help make the experience even better

explodingcamera 4y ago
That doesn't mean there nothing to be learned from mistakes previous languages made and striving to create iteratively better languages
ilyt 4y ago
Sure, no language is perfect but some things in Go were apparently "to make it simpler", but by lack of them it made the code in the end more complex and/or verbose. Lack of generics made a lot of code less type-safe than it should, and just more complexity and/or duplication. Lack of sum types made some types ugly (like mentioned IP type), and other ways of control flow harder. Rust-like Result<T> would be massive improvement to verboseness of error handling in Go for example, without really any drawbacks.

firloop 4y ago

Little bit of a nit on the title if the author is reading this. Go is called Go, not Golang. https://go.dev/doc/faq#go_or_golang https://go.dev/doc/faq#go_or_golang

seneca 4y ago
It is extremely common to use "Golang" for Go to disambiguation the extremely common word. Not necessary on HN due to context, but it helps with SEO for blog posts.
nequo 4y ago
To me, "Golang" is a good compromise to make material about it searchable. For example, Lean is notoriously hard to find stuff about. Try entering "lean" into HN's search engine: https://hn.algolia.com/?q=lean https://hn.algolia.com/?q=lean I wish there was a convention to call it "Leanlang" or "leanprover" or something.
jmainguy 4y ago
I always list it as Go/Golang on resume. Don't want people thinking I'm good at that board game
- richbell 4y ago
  From what I've heard about its difficulty, I'd be far more impressed if you were proficient at Go.
- WJW 4y ago
  When people write phrases like "Proficient in C, C++, Go and Malbolge" on their resume it's always a pain to figure out if they mean the programming language or the board game.
  - aflag 4y ago
    I once interviewed someone who was "proficient in dart, go and nim", but I was puzzled when they said they never wrote a computer program in their life.

jasonhansel 4y ago

Something that annoys me: - Go's approach to normal error handling assumes that correctness and proper error handling are paramount: every error must be handled explicitly, and every control flow path must be made obvious, no matter how much verbosity this creates. - Go's approach to panic handling assumes that correctness and proper error handling don't matter: a function can halt at any given point, panics are easy to trigger by accident (e.g. methods with nil receivers), handling them explicitly is usually discouraged, and they tend to leave values in intermediate and unexpected states (unless you use "defer" very carefully and consistently). Rust partially resolves this issue by preventing many causes of panics, by using methods like "lock poisoning" to avoid leaving shared values in unexpected states, and by having proper destructors. Go's approach (just crash everything) makes it easy for one error to completely bring down an application. Handling panics leads to values being left in inconsistent states with operations half-completed.

tapirl 4y ago
> panics are easy to trigger (e.g. methods with nil receivers) No, methods nil receivers in Go don't trigger panics (if they are not dereferenced). > every error must be handled explicitly, and every control flow path must be made obvious, no matter how much verbosity this creates. Is this, bad? It is just the recommended way. You are not required to implement your code in this way.
- Cyph0n 4y ago
  Why would you have a method that doesn’t touch the receiver? Refactor it into a function.
  - assbuttbuttass 4y ago
    Dereferencing isn't the only way to touch a pointer: func (o *myObject) isNil() bool { return o == nil }
    - Cyph0n 4y ago

aetherson 4y ago

The author fundamentally misunderstands poor weather. Portland's weather is pretty nice! Definitely better than, say, Chicago, or St Louis, or Minneapolis, or Buffalo. I'd argue also better than Austin or Dallas, though people are free to disagree about the merits of unbearably hot weather vs rainy cold weather.

d1str0 4y ago
Absolutely! I’d much prefer a mild temp with constant rain vs. wildly changing temps at extremes and crazy wind or storms.
- aussiesnack 4y ago
  Clearly a matter of taste then. I much prefer the extremes, and find mild weather boring. Maybe it's having grown up in England. Much happier where I live now and I'm at frequent risk of fires and floods!
LikeAnElephant 4y ago
Amen. Mild weather + usually gray > extreme weather + usually sunny. Though I'd never fault someone for making different decisions. The fire season of the past few years are changing the equation for me though...

aeturnum 4y ago

Having shipped a little golang code (back in ~2017) and having watched things evolve, my sense is this: - Golang doesn't fit comfortably into the spectrum of "low level & fast v.s. high level and easy" languages, largely because it does go in different directions in many ways (see: critiques on their garbage collector, type system, etc). - Smart people are happy with Golang, but the fact that it makes different choices means that people regularly discover to their sorrow that the language isn't quite what they expected. - In general, most of the "go was wrong for us" stories seem to come from companies that use it as a side language. Teams where Golang is their main workhorse generally seem at peace with its choices. To me, it means I have no doubt you can build a company on Go - but maybe build that experimental high-performance replacement for a python service in Rust.

zozbot234 4y ago
"Teams where Golang is their workhorse" probably made that choice a long time ago and have a lot of legacy code in the language. Staying with Go for the most part is just the sensible thing to do in that situation.

foldr 4y ago

I fail to see the point of this. Buried in this post are one or two reasonable (but familiar) criticisms of Go. As for the rest of it, the author appears to be upset that everyone in the world didn't immediately stop using Go after reading his blog post of two years ago.

aidenn0 4y ago
The author does not think everyone in the world should immediately stop using Go. TFA even mentions that tailscale's use of Go could very well be the correct choice. TFA is about dismissive comments about the article and people burying their head in the sand rather than engaging with the criticisms.
- ilyt 4y ago
  Or they are just fine with the drawbacks and are annoyed by another non-user whining about it. Yet another whiner complaining about well-known problems that advanced users are aware of doesn't add anything and nothing in this article is new thing to any advanced user. Especially if the asshole behind article makes the title extra confrontational and aggressive just to piss off people.
  - richbell 4y ago
    > Yet another whiner complaining about well-known problems that advanced users are aware of doesn't add anything and nothing in this article is new thing to any advanced user. "Well-known problems that advanced users are aware of", in other words problems that you can and will shoot yourself in the foot with unless you've already shot yourself in the foot and know to avoid them? Why is it contentious to say that things should and could be better? > Especially if the asshole behind article makes the title extra confrontational and aggressive just to piss off people. Why do you feel the need to reproach constructive criticism as being from assholes and "whiners"? You can like Go, or anything else, while acknowledging its flaws and believing it should be better. I thoroughly enjoy Kotlin, TypeScript, and a handful of other technologies but I will be the first to admit and lament their failings. (I'll admit the title is cheeky/provocative, but I think calling the author an asshole and ascribing intent that they want to piss people off says more about you than them.)

tapirl 4y ago

The author doesn't use Go any more, but cares about Go so much. ;D

gefriertrockner 4y ago
Definitely gets attention on HN for it.

camdenlock 4y ago

[dead]

_cenw 4y ago

The article spends an inordinate amount of time to delve into meta arguments about groupthink and elitism and juniors vs. seniors which is interesting enough, but I find the meat of the argument a bit lacking. Go has some warts, but they're all things that make sense if you know some basic concepts about go (as in you can derive them from knowing how go ticks), versus thousands of random caveats in the core library of other languages. They seem to be most upset about allocation, but it is in fact pretty simple. Types that can be nil are nil upon initialisation, and everything else is a zero value (by virtue of not being a pointer). C isn't actually different here. The only thing I'd expect to surprise a C programmer here is that strings aren't pointers by default, despite being variable length. And I'm not sure what their point about CGO is. People always say to avoid it because you leave the Go world behind and because performance could be better, but it is still a legitimate way to achieve FFI. The SQLite package uses it and nobody recommends against using that either. It just comes with a "more complexity if you add this" disclaimer.

kelnos 4y ago
> Go has some warts, but they're all things that make sense if you know some basic concepts about go That's exactly the problem. I don't want to spend my time learning the myriad quirks of a language. I want to spend my time building my program. As someone who is an "advanced beginner" at Go, I assure you that just knowing "some basic concepts" is not enough to avoid Go's pitfalls and footguns. I don't want to work in a language where the solution to all these things is "just be careful when writing code". I'm fallible. Compilers, less so. The compiler should be doing this work for me.
- loosescrews 4y ago
  > I don't want to spend my time learning the myriad quirks of a language. That is just it. Go's quirks are mostly a result of its consistency, not a result of a lack of consistency. > I assure you that just knowing "some basic concepts" is not enough to avoid Go's pitfalls and footguns. It seems that Go has two somewhat contradictory goals: consistency and similarity to popular yet inconsistent languages. This seems to result in a lot of people who can generally use the language, but haven't learned the language model because the language doesn't require that in order to get started. This seems to frustrate a lot of people and prevent them from ever learning the language model. Languages which appear completely different from popular languages don't seem to suffer this issue because people tend to learn the language model up front. Go really only has one major source of inconsistency and that is the late addition of type parameterization. The built-in parameterized types are special, but still generally follow the same rules as other types with a few exceptions. The main thing you need to know about slices, maps, and interfaces is what they actually are. Once you know that, the normal rules apply. Channels are a different beast though.

candrewlee14 4y ago

I agree that structs should enforce using all fields or have provided some defaults at declaration, a result type would be nice, FFI is much harder than most other PLs I’ve worked with, and if your use case is a bad case for the GC, you’re in trouble. At the same time, I really like go. No other AOT-compiled language I know of makes concurrency so easy: `go foo()`. It’s wonderfully simple and I love that using the language doesn’t cram my working memory. It feels like all the space is there for my problem. It isn’t the right tool for some jobs, and of course, you’re perfectly entitled to your opinion. But I think it’s a welcome tool in the toolbox. I recently had to implement Raft in Go, and I don’t know of a better language for that. Feel free to inform me otherwise. The race condition checker, RPC libs, and simple concurrency let me focus on the algorithm implementation. The iteration speeds for me were super fast too since Go keeps compile times snappy. These are all useful tradeoffs for me to keep in mind when deciding the right tool for the job. I wouldn’t consider these “lies” personally, but maybe I do have the wool pulled over my eyes :)

ilyt 4y ago
> I agree that structs should enforce using all fields Nah, enforcement would be a problem if you're just say making a protocol decoder, you might "just" write struct as defined by API but not need to use all of its fields, or not use it inside the package (say package that decodes some JSON then just returns a struct with it) I'd like go vet option for that tho as in some cases that would be useful. > or have provided some defaults at declaration Outright initializers would be nice vs New*() for any type that needs it and having developer to remember to call that

aidenn0 4y ago

HN comment mentioned in TFA appears to be https://news.ycombinator.com/item?id=31194152 https://news.ycombinator.com/item?id=31194152

lvl102 4y ago

Go is OK. I think early adoption was mostly among Chinese startups due to the language being tied to Google and Pike.

eikenberry 4y ago

Programming languages are subjective mediums, with no real objective measures, and that the negatives of the language are part of what gives it its character is is why people like it, not why they dislike it. Reminds me of a diatribe by an oil painter on why people shouldn't use acrylic paints. Probably mostly a cathartic thing after the author took a job that needed it before trying it out.

cjk 4y ago

I've written a heaping pile of Go code over the last few years. I consider myself a fan, but not a fanatic. I tend to believe that Go's failings aren't any worse than the failings of most other languages, and for me, the drop-dead-simple cross-compiling and batteries-included standard library is well worth its warts. That said, I found myself vehemently agreeing with the author re: how hostile Go is to FFI/etc. IMO, a network boundary is indeed the sanest way for most other things to communicate with Go code. Re: Go on Windows: anecdotally, things seem a lot better than even a couple years ago, but there's still room for improvement for sure. It's baffling that the semantics of e.g. os.Rename() are so different between POSIX-y platforms and Windows when they don't have to be (Windows supports POSIX-style renaming semantics if you ask nicely). I ended up having to reimplement os.Rename() on Windows in terms of SetFileInformationByHandle() with the FILE_RENAME_POSIX_SEMANTICS and FILE_RENAME_REPLACE_IF_EXISTS flags set to get the behavior I was looking for. Re: mutable state, I think these concerns are mostly overblown. These are problems we've been dealing with in the vast majority of mainstream languages for many years now, and there are plenty of strategies for dealing with it. For example, if I want to pass an "object" by reference in Go but do not want it to be mutated, I'll wrap it in an interface with getter methods for its fields, but no setters or anything that can cause side effects. Sure, it's a bit more involved than tagging something with the `const` keyword in e.g. C++, but it's plenty effective.

worik 4y ago
> Re: mutable state, I think these concerns are mostly overblown. These are problems we've been dealing with in the vast majority of mainstream languages for many years now.... Yes. Do not minimise this. For very large complex systems immutable state is very helpful. > pass an "object" by reference in Go but do not want it to be mutated, I'll wrap it in an interface Making the point. Horses for courses, but this is picking the course for this nag.
- cjk 4y ago
  100% agreed -- if it wasn't clear, I wasn't trying to downplay the importance of immutable state. Just saying that it's perfectly achievable in Go with a small bit of effort.

alphazard 4y ago

Go criticism is always focused on the language itself, which is admittedly non-optimal. But it's non-optimal in the direction of missing features. Contrast that with most languages which are non-optimal in the direction of having too many features which are poorly designed. Go's position on the simplicity vs feature set continuum is perhaps the least interesting reason it's popular. There are a myriad of other reasons for its success: - It spits out static binaries with minimal fuss. - The import statement maps strings to symbols. No complicated module system to learn. The strings are resolved to something like URLs, but that's not part of the language. It's very easy to see code on GitHub and import it. - Packages are just directories. - No new package namespace with squatters and poor infrastructure. Go packages, in practice, are named with DNS. You know, the namespace that already exists and everything else has standardized on. - Rejection of complicated version selection. Go almost went down the npm route, there was even an "official experiment" that looked much like other package managers. Then the Go leadership stepped in and sorted things out. https://research.swtch.com/vgo-mvs https://research.swtch.com/vgo-mvs Go is set up to be the language of an ecosystem in a way that most other languages are not. If you are a language designer: take Go's import statement, packages, and modules, and just copy them. You aren't going to do better, and you probably weren't trying to innovate in that area anyway.

worik 4y ago
Plus very fast compile times.
mdaniel 4y ago
> The import statement maps strings to symbols. No complicated module system to learn. The strings are resolved to something like URLs, but that's not part of the language. It's very easy to see code on GitHub and import it. This is for sure untrue, unless one is already steeped in the golang ecosystem. $ cat go.mod requires ( github.com/pulumi/pulumi/sdk/v3 v3.43.1 ) oh, cool, I can just navigate to https://github.com/pulumi/pulumi/tree/v3.43.1/sdk/v3 https://github.com/pulumi/pulumi/tree/v3.43.1/sdk/v3 to view the source ... oh, :sad-trombone: it's 404. Well, why is that? $ curl https://github.com/pulumi/pulumi/blob/v3.43.1/sdk/go.mod | head 1 module github.com/pulumi/pulumi/sdk/v3 Oh, because the "module" line is decoupled from the apparent URL. Then there's this `gopkg.in/yaml.v2` nonsense, as described by this: https://go.dev/src/cmd/go/internal/help/helpdoc.go#L251 https://go.dev/src/cmd/go/internal/help/helpdoc.go#L251 Meaning navigating to https://gopkg.in/yaml.v2 https://gopkg.in/yaml.v2 gets one thing, but https://gopkg.in/yaml.v2?go-get=1 https://gopkg.in/yaml.v2?go-get=1 produces another and only a view-source of the latter shows what golang is going to use. Yes, I'm aware that out of the kindness of the author's heart the browser version does link to the alleged source repo, but alleged is the key part of that

aaomidi 4y ago

I actually like how this article is written, and I'm a big go fan. I think the article has a conclusion it's trying to push to __stop using Go__. Maybe I misread it, but that's what it sounds like. Honestly though, I am fine with Go. Every language has its ups and downs. What I like about Go is specifically what the article pointed out, the simplicity means I need to only remember a few concepts. In contrast, with Rust, or C, or C++, or Java, or C# I have to know _so many small details_ to not shoot myself in the foot.

kaba0 4y ago
> In contrast, with Rust, or C, or C++, or Java, or C# I have to know _so many small details_ to not shoot myself in the foot. Java arguably has even less foot guns then Go and is an simpler language.

steeleduncan 4y ago

> Go is a pretty good async runtime I think the author is in many ways right, but has missed how important the runtime is to the average programmer. At the time of release Go made it easy to write evented IO servers, in a way that Rust, despite its superior language design (IMHO), still hasn't. This is why people continue to use it. Other examples are PHP, a car crash of a language, but suddenly it was easy to dynamically generate a webpage, or early versions of Java, widely derided for language design, but programmers were happy to trade the virtues of elegance and efficiency for the ease of the standard library, the GC, and portability. Give the programmers the ability to do easily something they weren't able to do prior to using your language, and they'll use it, whether PL enthusiasts are happy about that or not.

unity1001 4y ago
> PHP, a car crash of a language That car crash of a language can imitate the general characteristics and typing style of any language and provide for using any pattern/anti-pattern in computer languages by just modifying its ini files to however you want it to work. That's why its 80% of the web.
- kaba0 4y ago
  Which is just as much of a curse, see lisps’ flexibility.
aaomidi 4y ago
This is also why NodeJS got so popular. Concurrent programming is made so damned easy in it, that of course it blew up in popularity. Most folks just need concurrent code, not parallel code. NodeJS was able to provide that.
worik 4y ago
I am not a fan of async/await paradigms. It is yet another example of making easy things easy. It is not hard to write non blocking code. No harder than remembering to insert a keyword "await". Event loops are very useful, I agree. I just do not see how a new syntax makes them "easier".

kelnos 4y ago

> The very reason I don't consider Go a language "suitable for beginners" is precisely that its compiler accepts so much code that is very clearly wrong. This struck me as a really insightful thing to say. I often talk about how I like languages with strong type systems, and how I like using those type systems as fully as my brain thinks is reasonable to do so, because when the compiler finishes with no error, I have much more confidence that what I wrote is correct. But I never really thought about it from the other side: being beginner friendly doesn't just mean "you can pick up the syntax in an afternoon". It should mean that the compiler saves you from beginner mistakes. As someone who only occasionally uses Go, I'd consider myself an "advanced beginner" at the language. And I remember many of the times I wrote code that seemed correct, and the compiler accepted, but was wrong because of Go's quirks. That alone is a reason to disqualify Go for me as a language to get serious work done in.

ctvo 4y ago

It's a little presumptuous to assume the teams and developers using Go are lying to themselves about Go vs. they've made the calculations and like the tradeoffs. Opinionated language and tooling plus good enough performance without a runtime may be worth more to them than the two (?? I lost count trying to find them in the article) issues the author brings up.

worik 4y ago
> It's a little presumptuous to assume the teams and developers using Go are lying to themselves about Go vs..... I think it is a bit naive to think that these sorts of decisions are made by competent technical people. In my experience these decisions are made by managers that have "Peter Principled" past their competence.

zippergz 4y ago

If this guy is good at anything, it's generating comments and driving traffic to his blog.

AlbertCory 4y ago

I was at Google the whole time Go was being developed. A friend of mine had two, count 'em, two quotes that pertain to it: 1. The answer to an unasked question 2. When your only tool is a hammer, every problem looks like a thumb And one I just made up: 3. I had a problem, so I invented a new programming language. Now I have 769 problems We could look at Rob Pike & the Bell Labs guys and imagine Stephen Stills saying "Hey, 'For What It's Worth' was the worst song Buffalo Springfield ever did. Let's fix it." Too late. It's out there. And C is out there.

deleted 4y ago
[deleted]

pharmakom 4y ago

C# has channels as part of the standard library and is much preferable to Go imo

loosescrews 4y ago

I'm a Go fan and the author makes some good points. That said, their arguments seem a bit one sided and there are a number of areas where they get close to, but miss what I feel should be the real conclusion. I'm going to focus on toolchain related issue because I feel better able to speak on these topics. The language issues the author brings up are similar though. RPCs instead of FFI. There is some truth here. I personally find wrapping foreign code in a C interface and using CGO to be pretty easy, but RPCs are a good choice as well. The author then jumps to this necessarily including TCP overhead which is wrong. If a FFI is the alternative, then running on a single machine is acceptable and a Unix socket is an option (I'm sure there is something similar for Windows). I have often combined these strategies where I wrap some C++ code in a C library and integrate it into a CGO gRPC service which serves on a Unix socket. I do this because I find setting up an RPC service in Go to be much easier than C++ and I want to isolate the C/CGO. Using an RPC interface also limits the unsafe code to a process which can be optionally further sandboxed (e.g. with SECCOMP). If you are concerned about memory safety, this might be a good idea even if you are using two languages with better FFIs. Even if both languages are memory safe, the FFI almost never is. In addition to the security benefits, this also makes debugging memory issues easier as it limits their scope. Another benefit to FFIs being bad is that it has pushed Go to be one of the only languages where most code has no C dependencies. Nearly the entire standard library is pure Go and the parts that aren't are not commonly used or provide optional functionality which is not commonly needed. Most third party libraries I find on GitHub are pure Go as well and only have pure Go dependencies. The majority of Go binaries I have encountered either are or can be built with CGO disabled. This has two major benefits. First, it makes Go code much safer. C dependencies are a major source of memory unsafety bugs. The most common C dependency (in Linux land anyway) is glibc. glibc is well known for its terrible code quality and history of security vulnerabilities. Go is one of the only languages which makes it easy to not depend on it. Since the author brings up Rust, I would personally feel better about untrusted data being processed by a pure Go program than a Rust program with C dependencies. Second, even the best FFIs make code harder to read. If nothing else, now you need to be familiar with both languages. Go libraries usually being pure Go makes it easy to jump into random library code and figure out what is going on. The author also mentions build systems with a vague comment about cases not considered important by the Go authors. In my opinion, the true build system for Go is Bazel. Bazel has great Go support because Go was built with Bazel in mind. The fact that Go and Bazel handle imports in almost the same way and that Bazel BUILD files can be generated from Go code is not an accident. Bazel is very powerful and is usually a good fit when you start running into the limitations of the built-in Go build system.

deleted 4y ago

[deleted]

yamtaddle 4y ago

> And so they didn't. They didn't design a language. It sorta just "happened". Maybe I'm wrong, but when I use Go it definitely feels designed: specifically, it feels designed to discourage the worst or most-alien-to-the-language's-intended-style dep in your dep tree from being too bad or too alien. That is, the design seems to me (and again, I could be wrong and this effect was in fact an accident) most concerned with keeping the quality and style-distribution of the language's ecosystem, or of a given codebase, on a nice, narrow, pointy curve rather than a flattish wide one, so much so that the authors would prefer an expert be a little annoyed with some part of the language to making doing the Wrong Thing too easy for less-adept developers (or for "experts"). If that was in fact unintentional, well, then my favorite quality of the language (and IMO the most interesting thing about it) was an accident, I suppose. And it's not like I've dug deep into the history of the language's development, so that may be the case for all I know.

hmomh 4y ago

Can someone help me understand what are go's value types good for from a language design point of view? In most other gc languages, value types are always stack allocated and there' no way to take a reference to them, but in go you can happily do so, letting the variable escape its scope and thus be allocated on the heap and be garbage collected. The only thing I can think of is a sort of substitute for immutability, so a function can take a variable by value rather than by pointer and guarantee that it won't modify it, but I don't see it being a win over just letting a variable be declared immutable. The only language I can think of with sort of similar semantics is perl, but in pratice haven't seen many %hashes flying around, it's always $hashrefs instead.

nvarsj 4y ago

Been a golang dev for a long time, although got out of it recently (I got very tired of it). Many contributions to k8s in the early days, etc. Thing I find the most frustrating about golang is the community. It almost seems to be made of people who never used another programming language in their life. Defense of things like lack of generics, lack of a good collections library, lack of good error handling, lack of good dependency management, etc. It's so bizarre to me. As a former Java dev, we all at least admitted the flaws of the language and came up with ways to deal with it (see Effective Java).

poulpy123 4y ago

I've never written a line of go in my life, but I totally disregard these kind of definitive and negative opinions about stuff (here a computer language) that are widely used. If so many people use it that means it's not completely garbage sorry