36 ms·

Lies we tell ourselves to keep using Golang

• 1970-01-01 4y ago
  Why's this flagged? It's not poorly written and makes good points. I don't agree with many of them, yet I still up-voted because it makes good points.
• zozbot234 4y ago
  What's up with the anti-Golang shitposts lately? I liked fasterthanlime better when he didn't just sound like a card-carrying Rust zealot. This isn't even about the practicalities of his argument really; optics matter, and it's especially bad since the Rust community used to be known for its politeness and always being fair to other language communities.
  • mattrighetti 4y ago
    Just a small reminder: fasterthanlime is not the Rust community
  • jamesmunns 4y ago
    The last time his "I want off" article was reposted[0], the comments were pretty rough, ranging from ad-hom attacks to (at best) misunderstandings of the arguments he was making. I see this article being an address to these criticisms (which are not limited to this forum, I've seen similar arguments on twitter, etc.). Pointing out shortcomings isn't really impolite or unfair. The author specifically mentioned shortcomings of Rust as well. [0]: https://news.ycombinator.com/item?id=31191700 https://news.ycombinator.com/item?id=31191700
    • rob74 4y ago
      Pointing out shortcomings isn't impolite - writing that Go wasn't designed, but happened by accident is however (IMHO).
      • clpm4j 4y ago
        Especially since it was designed by computer science luminaries who are almost certainly better programmers/engineers than the author of this blog. It's also more accurate to say that Rust wasn't designed / was an accident since it was technically a side project of one guy at Mozilla.
        • samhw 4y ago
          Both languages were designed by probably better programmers than most in this thread. For that matter, the vast majority of successful programming languages surely were. I'm utterly lost at how that relates to anything. One can plainly be a good programmer and yet create a bad language. I'm sure you are well-informed enough to analyse his argument on its merits, even if it were written by a gang of monkeys with typewriters.
      • samhw 4y ago
        > writing that Go wasn't designed, but happened by accident is however [impolite] That's one of the most mild and inoffensive criticisms I've ever read on the internet. You can't seriously be indignant about that.
      • oxnrtr 4y ago
        The truth cannot be impolite.
    • masklinn 4y ago
      > The last time his "I want off" article was reposted[0] Of note: the last time in question was yesterday, the flagging and ad-hominems pretty obviously made lime's cupeth runneth over.
  • cnasc 4y ago
    > the Rust community used to be known for its politeness and always being fair to other language communities I have no particular affinity for Go or Rust. As an outsider this is not how I’ve ever perceived the Rust community, because the most present and visible parts of the Rust community were people showing up and complaining that Project X didn’t use their preferred silver bullet
    • collegeburner 4y ago
      Also honestly it's very toxic to anybody right of center. It's the type that says "we're so accepting" when really they only are of certain stuff. Lots of pronoun people and making the mascot "non binary" is needlessly shoving their ideology down people's throat. Not a problem in the U.S. because it fits with the corporate woke ideology but sure as hell gonna be if they want more worldwide community. It's also way too hugboxxy and tbh that feels just as toxic some times as the alternative. Positivity to the point where it's obviously fake and forced and insincere. Edit: howinteresting I can't reply to your comment but you are proving my point. At least you people are being more honest that it is intended to exclude a bunch of people.
      • howinteresting 4y ago
      • Georgelemental 4y ago
        As someone who both loves the Rust language and is very right of center, I've never found politics to pose much of a problem for the Rust community in practice. Yes there is occasional virtue signalling here and there but people don't let it get in the way of making programs that work.
        • samhw 4y ago
          Yeah, as someone who's gay and left-wing but equally irritated by the 'virtue signalling' stuff (my ideology is basically r/stupidpol), I don't find the Rust community too bad. (FWIW, I appreciate your open-mindedness. I think that's the main thing I find objectionable on (parts of) both sides of the aisle: an inability to regard those who disagree as fundamentally well-intentioned human beings who happen to hold different beliefs.)
  • JyB 4y ago
    From the outside the Rust community seems so defensive about Go that it makes me very reluctant to dive deeper into Rust.
    • ericbarrett 4y ago
      I use both & like both. Ignore the noise!
      • rgrmrts 4y ago
        Yeah, same. They’re both nice languages, they both have great tooling, and they both have areas where they shine. I don’t see them as competitors really, but “You can also implement X in Y” is a fairly useless statement, of course you can. I’m glad we have as many languages options as we do, and I enjoy writing a variety of languages for a variety of different projects. Sure, I have moments where I think “ugh why can’t I do X in language Y” or “C is cleaner in Y” etc etc. I’ve found helpful people, critics, and fanatics in every language community. Don’t let that dissuade you from learning Rust (or Go, or …)
    • styluss 4y ago
      One person is not the community
  • asxc11 4y ago
    I might not agree with fasterthanlime's opinion on Go (9/10 times I would opt to use Go over Rust), but calling this post a "shitpost" is unnecessarily dismissive. The post, like his previous post on Go, contain well thought out points that add to the discussion at the very least. Also I like his sense of humour :) Edit: though, I suppose saying Go is not designed is also equally unnecessarily dismissive and hyperbolic.
    • zozbot234 4y ago
      Well-thought out, how? It's flogging a dead horse in a transparent, deliberate attempt to create controversy and flamebait. That's a shitpost pretty much by definition.
      • unethical_ban 4y ago
        I don't think it's obvious this was done in bad faith, even if the author is at times flippant.
    • ibejoeb 4y ago
      > Portland Oregon, the capital of grunge, coffee, poor weather and whiteness it's kinda a shitpost
      • biorach 4y ago
        It's sarcasm, dumb humor - not trying to be inflammatory, or provocative - i.e. not shitposting. And let's face it, Portland kinda takes itself too seriously.
        • hsnewman 4y ago
          I moved from Austin TEXAS to Portland to get away from the heat and forced conservitism. I also moved to Portland for the weather (cool and wet vs hot as hell and dry). I don't have to use my air conditioner! As for Portland taking itself too seriously, are you serious? Portland has so many quirky things that the conservative states don't have(much less putting walls up and making some people, making 2nd class citizens ((yes, voting rights)), and you say Portland is too serious? Good luck with that gaslight.
  • unethical_ban 4y ago
    Calling a well documented blog post, even one you disagree with, a "shitpost" should be an embarrassment to you. Guy makes a blog post about Go a few years ago. It gets posted here time and time again, not of his doing. A bunch of people challenge his premises, so he makes another post diving deeper into his arguments. So what? What's up with the literal hundreds of "Golang is amazing" posts this site has had? Is someone attempting to express dissent clearly that much of a bother?
    • rob74 4y ago
      But he doesn't dive deeper! If anything, he's more shallow. This just doesn't read like an honest appraisal of Go's pros and cons to me, he already has his mind set from the beginning (ok, we knew that two years ago already) and is just heaping on invectives: "one really good bit does not a platform make", "Evidently, the Go team didn't want to design a language", "Go is not adequate for production services unless your shop is literally made up of Go experts (Tailscale) or you have infinite money to spend on engineering costs (Google)" etc. etc. What makes me angry about all this Go-bashing is that it might influence decision makers against moving from things like PHP or Node to Go - which I think would be an improvement, no matter how many flaws Go may or may not have.
      • biorach 4y ago
        > What makes me angry about all this Go-bashing It's just a language! Take it easy. The guy is not "heaping on invectives" - he's not criticizing you or someone you care about. He's pointing out some flaws in a language in a sarcastic way.
        • AnimalMuppet 4y ago
          I would consider "Evidently, the Go team didn't want to design a language" to be at least borderline invective. From dictionary.com, definition 3: "an insulting or abusive word or expression". Yeah, that's pretty clearly insulting.
        • Karrot_Kream 4y ago
  • fasterthanlime 4y ago
    Reminder that I'm not part of /any/ Rust teams, not part of the Rust foundation, etc. etc. My site is my space, and it is specifically designed to let me post my point of view without having to bear ( ) the responsibility of speaking for entire communities at once. It's important for individuals to be able to do that, and it's on everyone else to make the distinction.
    • samhw 4y ago
      Thanks for your article. I hope you can ignore all the vitriol. It's embarrassing to see what I thought was a generally intelligent community having a collective tantrum because someone was mean about its favourite toy.
• aw4y 4y ago
  how boring? Don't wanna use Go? Use something else. What's the point? Invest your time on questioning your knowledge and improving it instead of this.
  • alkonaut 4y ago
    The point of these articles and other opinion-making (such as right here on HN) is that we don’t choose tools. We are given the popular tools. They are popular because other developers chose them at the companies were we work. And they chose them because they thought they would be suitable for the purpose. So if you want to do everything in your power to prevent a tool you think is terrible from being more popular - you can do very little apart from writing opinion in blogs or forums, improving the tool, or provide better alternatives. Shitting on a technology might seem like the least noble of the 3, but it’s likely quite time-efficient compared to the other two. It’s certainly not useless.
    • aw4y 4y ago
      Why should I care if Go/Rust/anything else becomes popular? I don't expect that if I don't "fight" against a language I'll be forced to use it in 2 years: there will be space for different techs, tools and so on. I can agree with you if we talk about "tools" that attacks our privacy, our rights and our freedom: spend you time convincing people to abandon facebook or something similar and you'll do something good. But in this case, it doesn't change much, imho.
      • erik_seaberg 4y ago
        > I don't expect that if I don't "fight" against a language I'll be forced to use it I didn’t used to worry about this until it started happening to the sharp, experienced Scala/Java team I’m on by preference. Other teams are now deploying half-finished platforms on which only Go is supported fully, or sometimes at all.
• anacrolix 4y ago
  couldn't agree more!
• foldr 4y ago
  > Go's confusion between "type aliases" and "newtypes". The only way to make a newtype in go is to make a separate package with an opaque type and use interfaces for indirection, which is costly and awkward. It's very unclear what this is supposed to mean. 'type Foo int' in Go creates a new 'Foo' type that can't be used as an int without casting (a̶l̶t̶h̶o̶u̶g̶h̶ ̶y̶o̶u̶ ̶c̶a̶n̶ ̶a̶s̶s̶i̶g̶n̶ ̶a̶n̶ ̶i̶n̶t̶ ̶t̶o̶ ̶i̶t̶). If you don't want to allow that, you can just wrap it in a single member struct.
  • paskozdilar 4y ago
    > 'type Foo int' in Go creates a new 'Foo' type that can't be used as an int without casting (although you can assign an int to it). You can't, in fact: type Foo int func main() { var foo Foo = 1 var bar int = 2 foo = bar // cannot use bar (variable of type int) as Foo value in assignment } The reason you can do things like: var foo Foo = 1 is that because numeric literals in Go are not ints, they are untyped [0]. [0] https://go.dev/blog/constants https://go.dev/blog/constants
    • foldr 4y ago
      Ah yes, good point. Thanks for the correction.
  • smasher164 4y ago
    Yeah, his complaint about newtypes is just incorrect.
  • fasterthanlime 4y ago
    I moved some words around to make the nit less confused - thanks for the feedback!
    • foldr 4y ago
      Still not seeing it. You don't have to use interfaces to make an opaque type. A package boundary is sufficient. Not sure why you would want a fully opaque type internally to a package anyway. A regular `type Foo Bar` declaration is sufficient to give you a `Foo` that can't be accidentally interchanged with a `Bar`.
• rob74 4y ago
  Oh no, here we go again. So you don't like Go (no idea what this "golang" thing is everybody keeps talking about)? That's cool! You don't have to write yet another blog post saying that you really, really don't like it, with more strawman arguments and again quoting that quoted-to-death quote by Rob Pike about Go being designed for stupid developers, we got you the first time!
  • lnxg33k1 4y ago
    I'd just to point out that I think fanboys are not that useful and you have the right to don't read the article as much as he has the right to write it..
  • tomlin 4y ago
    I dunno, aren't you just as guilty of not moving on? If Go is garbage, you defending it isn't going to suddenly correct that. Also, it's called golang because that's what a lot of people call it (i.e. https://www.reddit.com/r/golang/ https://www.reddit.com/r/golang/)
    • rob74 4y ago
      Then you could also say "He's called a [insert ethnic epithet here] because that's what a lot of people call him" - but I hope we can all agree that would be a bad idea?
      • tomlin 4y ago
        I am not sure what you mean by your completely disconnected analogy.
  • heffer 4y ago
    > no idea what this "golang" thing is everybody keeps talking about The Go FAQ can help you understand where this is coming from: https://go.dev/doc/faq#go_or_golang https://go.dev/doc/faq#go_or_golang
    • 4y ago
• kitd 4y ago
  The author obviously doesn't like Go. Ok, he can have his own opinions. I've been coding professionally since 1987, using everything from mainframe assembler, Fortran, C, VB, Java, C++, to most recently Go. IMHO, the language itself plays a smaller role in its usefulness than most think. As important is the tooling, stdlib, ecosystem, community and "StackOverflow"-ability. Go has a few warts, like every language, but not that many, and they are more than made up for by how easy it is to assemble and run a project using it. It's that that makes it the most productive language I've used so far.
  • paskozdilar 4y ago
    For me, the goroutines + channels + select is what makes Go leagues above any other popular language. As far as I know, no other popular language allows you to read from multiple queues at the same time, which is an extremely useful pattern in concurrent programming. The only way to "select" from multiple sources in other languages is to use some kind of poll/select syscall on file descriptors - and even that is very limited, since kernel (at least Linux) does not allow userspace programs to create private file descriptors for intra-process communication - they must always be bound to some file/pipe/socket.
    • fasterthanlime 4y ago
      > As far as I know, no other popular language allows you to read from multiple queues at the same time Off the top of my head, that's certainly possible in Rust, C++ and Java - probably many others I just don't know about. That particular bit of concurrency goodness comes from the 70s, so you can be sure other languages picked it up.
      • npe 4y ago
        As I understand it, he's talking about select/alt (i.e. guarded commands from CSP) being a native feature of the language rather than callback-based approaches. It's possible to implement CSP channels in most languages, but they're not first-class like go.
• wara23arish 4y ago
  Im a go noobie so I had a question about the following. > Go's lack of support for immutable data — the only way to prevent something from being mutated is to only hand out copies of it, and to be very careful to not mutate it in the code that actually has access to the inner bits. I thought everything was handed out as copies in go by default unless a pointer was being passed. So this would make it “easy” to tell whether you are mutating a object or not. would appreciate if anyone can clear that up for me. side notes: since Im still a junior, not too interested in language wars and feel like everything i touch i learn something from no matter how old/new it is. honestly, i would never have the confidence to critic this <language> in that fashion. i cant convince myself that i know enough about language design/systems to critic anything that harshly. maybe its my shortcoming as a junior :)
  • ainar-g 4y ago
    They mention it elsewhere in the post, but there are a few types that are essentially pointers but don't look like pointers. Slices, maps, interfaces, and channels (and also functions, but that isn't that important here). So you cannot just think that anything that doesn't have an asterisk is a copy. Besides that, there is also the fact that slices share underlying array storage, and `append` doesn't make a copy unless there is still capacity, which means that you should be careful when working with subslices that get appended to. https://go.dev/play/p/Iqd84_eAMNF https://go.dev/play/p/Iqd84_eAMNF
    • wara23arish 4y ago
      I see! Thank you for the example that was helpful. I read through the example regarding the struct containing the map. I recently ran into that when working on something. slightly meta: So how can one evaluate whether that is a good decision or bad? Does forcing the programmer to use make explicitly for maps help prevent errors or is it tedious and better off having the zero value of map not cause errors?
      • ainar-g 4y ago
        I actually agree with the author that nils are a massive pain in the arse most of the time, and that Go would be much better off without them. There is no precise, mathematical answer to your question, since it's always contingent on many things, but one way to evaluate a “correctness” of a design choice is the old adage that a good interface is hard to misuse. If your code can handle a nil map okay, and not requiring a non-nil map brings significant ergonomics advantages, you may not need to check it. Otherwise, I personally would err on the side of caution and design an API that either doesn't give the user a choice (i.e. creates the map itself) or returns an error if they provide invalid data.
• deleted 4y ago
  [deleted]
• warent 4y ago
  • unethical_ban 4y ago
  • tagolang2313 4y ago
  • mountainriver 4y ago
  • kevinmgranger 4y ago
    I agree that this article is low-quality and self-contradictory, and flagged it too. However, > It reads as an asshole college sophomore who rips on plebs who dare to have different perspectives than them This is going a bit too far, don't you think?
• SeanLuke 4y ago
  I don't know nothin' about Go. But this complaint really surprised me: > Go not letting you do operator overloading, harking back to the Java days where a == b isn't the same as a.equals(b) Does this guy really not understand that in a mutable language, (eq ...) is not the same as (equalp ...) and should never be confused with it? Also: operator overloading is the spawn of Satan.
  • WalterBright 4y ago
    > operator overloading is the spawn of Satan I used to agree with you, because of the abuse of operator overloading like iostreams and making DSLs with it. D does support it, but in a way that discourages non-arithmetic uses (such as it won't allow < <= >= > to be overloaded separately). Operator overloading allows for things like complex numbers, arbitrary precision numeric types, etc., to be done with a library module.
    • nemo1618 4y ago
      > Operator overloading allows for things like complex numbers, arbitrary precision numeric types, etc., to be done with a library module. Why is this desirable vs. implementing those types in the language itself? I think we've gone down a weird path where implementing things "in userspace" is seen as an inherent good -- why?
      • WalterBright 4y ago
        > Why is this desirable vs. implementing those types in the language itself? That's a very good question. 1. It's simpler. In D, we transitioned from a builtin complex type to a library type. It was a happy experience. The simpler the compiler, the easier it is to deal with. 2. Most any programmer can create a library type. Relatively few can modify a compiler to add a new type. 3. It takes the pressure off the compiler team to develop more arithmetic types. 4. Users can add arithmetic types without needing anybody's consent, and can do it right now. 5. It tests and verifies the metaprogramming abilities of the language.
• deleted 4y ago
  [deleted]
• unethical_ban 4y ago
  > Why does the Go compiler suddenly care if we provide explicit values now? If the language was self-consistent, it would let me omit both parameters, and just default to zero. Without analyzing the rest of the post (which I read without having the skill to fully comprehend), this stuck out to me. Perhaps the language behaves one way and not another by design? It's abstraction. By using a Struct, I'm telling the function "don't worry what is in this one box of data, just take it and process it as best you can" while defining two inputs to a function says "I demand that two pieces of data be present". I don't think it's an inconsistency to see this behavior.
  • fasterthanlime 4y ago
    It is a very minor point and could easily be removed from the article, but I had that realization while writing those samples and it stuck with me. I really think that if we follow the "zero values by default" philosophy, it wouldn't be shocking for Go to accept omitting function arguments and just zero them. The fact that it doesn't, and insists on you passing the right number of arguments, makes the point that you can't in fact, just afford to zero out everything that isn't explicitly specified.
    • arccy 4y ago
      that's a trade-off with catching user errors, are you more likely to forget to pass an argument or need to pass a zero value?
  • myrrlyn 4y ago
    why isn't it inconsistent to allow creation of a record with missing components but to deny creation of a stack frame with missing components
• ctvo 4y ago
  Unrelated (though a fun read) to the content: Thank you for making your blog readable. The typography choices are exemplary.
• jonathanstrange 4y ago
  Meh, this blog post is a rather subjective rant. I can offer the opposite opinion, although I'm not sure that's helpful. The more I use Go, the more I like it. I'm very productive with it, similar to -- though not quite on a par yet -- the productivity I had when I was programming in REALBasic. Most of the benefits of Go result from the tooling and the availability of 3rd party, open source libraries with permissive licenses that are "good enough" for my purposes. I could probably also use Python instead and benefit from even more 3rd party support, but there would also be downsides to it. I appreciate Go's compact executables and easy deployment. Quite honestly, in what concerns choices of languages, my experience is that it's not so much the language per se that counts, but rather the tooling, developer community, and the availability of 3rd-party libraries.
• georgia_peach 4y ago
  I believe he wrote a binary diff/patch system in it. If I had to do such a thing in Go, I would also hate Go. He should just own up to trying to shove the square peg into the round hole and move on with his life, rather than blame the peg. There is no shame in it. At one point or another, we've all done it.
• steaminghams 4y ago
  I generally like go and also see its problems as the author does. However, with respect to the points about Go as a prototyping/starter language, there is not better language to start writing a project with in my opinion. Lots of languages have big communities of packages of various levels of maintenance but almost no other language has a standard library that is as usable as Go with the same guarantees between versions. I think its the biggest downfall of all these new languages like Rust/Zig/Hare etc, they all go for these minuscule standard libraries. I have no wish to start a project with any of them as all of them would involve I hunt down the 'best' http library and the 'best' async library and weigh their upsides and downsides, so I just reach for go and crack out the code I need to get it done, nothing else lets me do that half as easily, maintenance may be harder but at least I'm probably going to spend less time maintaining the list of packages that are still usable.
  • valcron1000 4y ago
    If you want a big standard library why not use something like Java or C#? I mean, you even have UI toolkits available from the get go
    • steaminghams 4y ago
      I dont know them as well as I do Go but the libraries (java especially) don't feel as coherent as the go libraries do, though that may be subjective and to do with my lack of experience with them. In addition both of these languages are large enough and have projects structured in such a way as to make it difficult to just use a text editor, which i consider a barrier to me just 'cracking out' a project. C# also had pretty middling linux support the last time i worked with dotnet. and java tooling is not as out of the box as go is where I have to know is gradle good or still used or should i just use maven. Its all part of me not wanting to have to choose the best dependencies for my project and being handed for the most part good enough dependencies by the language standard library. Another thing to appreciate in go is it produces good enough binaries and produces them very very quickly -- i've worked on several massive go projects and the build/test turnaround time is quite good.
    • conor- 4y ago
• JamesMcMinn 4y ago
  This is an opportunity piece written for no reason other than to ride the wave from a recent re-post of a 2 year old blog article. It offers nothing over the original blog post and it's difficult not to be cynical about the authors intent with this article.
  • unethical_ban 4y ago
    >ride the wave from a recent re-post of a 2 year old blog article You've been here a decade! This is part of the HN experience. I'm sure we'll have an Atlas Obscura submission about the scintillating history of Serbian skin-contact white wines later today.
• streblo 4y ago
  I didn't care in the last post and I don't care about this one either. I care about my productivity, I care about my team's productivity, and I care about getting stuff shipped. Those are the things I care about, and go works great for that. If you care about those things too, and you're using go, you shouldn't stop using go. My whole career people have been telling me to stop using languages or tools I've been productive with. I've built successful companies where everything was written in python, the whole time people on HN telling me how I was using a lowly language because of things like whitespace significance or strings that were not unicode by default. If you care about other stuff, fine. If you don't think go works for you, don't use go. Just stop telling people who are using go (and other productive languages) to stop using them because of obscure language design issues or obscure API choices that people rarely encounter day to day. That isn't what matters to most people, and it's actually bad advice. The problem is that there are a ton of less experienced people reading stuff on HN (just as I once was) who will take this to heart but have nothing actionable to gain from it, except to think they're a bad developer using a bad language. They aren't, and they're not.
  • tomlin 4y ago
    I think your POV works in your very specific world view. As a head of an agency, hiring a developer that knows mainline languages serves a lot of good in hiring, keeping teams happy, and low turnover. We've all seen the agencies that hop on a new, hip language - only to go up in flames 6 months later because they couldn't find talent for their narrow viewpoint. This isn't an argument against Go, moreso that your perspective is objectively elitist.
  • greybox 4y ago
    I don't think that the author is telling anyone to stop using Go. They are suggesting that there should be a better alternative, and there are lessons to be learnt. I don't think we should be so cynical as to just lie down and accept that some things are just too hard to get right
    • oxnrtr 4y ago
      Especially when other languages got them right.
• tristor 4y ago
  I use Go. I love Go. The reason why is pretty simple for me: It gets things done in a way that feels comfortable and has strong tooling. I am well aware it has shortcomings. I occasionally even run into them. However, as someone who doesn't particularly /like/ writing code, and instead sees it as the inevitable requirement of creating things that do something for me, I really appreciate that Go for the most part doesn't get in my way so I can make things that do something and move on. I generally heavily preference scripting/interpreted languages over compiled languages, because compiled languages have a bevy of stuff that qualifies as "getting in my way". Go is refreshingly not like that, and therefore is the primary compiled language I use these days, and largely the primary language I use at all. Then again, I'm not an SWE. I'm a SysOps/SRE turned PM-T. So it's unlikely I would ever dig deeply enough to care about the particulars of a language's design other than knowing which problems it is best at and which problems a better choice can be made to solve. Both this article and his previous article, I've read thoroughly. I understand and appreciate the criticism. But fundamentally there's seems to be an implicit assumption within both articles that other developers who use Go don't already know (most of) these things. Anyone who uses Go long enough will eventually run into some of its shortcomings. I'm not sure exactly why it rubs me the wrong way, but it feels like there's something subtlety insulting in the way the author presents his arguments. Like if we weren't all stupid rubes we'd just use whatever his preferred language is (Rust, presumably?). The way people get zealoted about languages these days (especially some pretty terrible ones for getting things done) tempts me to just go back to writing Perl. In all the languages I've used over the years, I've probably got more raw work done in Perl than anything else, and it's still near and dear to my heart, despite being objectively a badly designed language.
• cglan 4y ago
  I just don't see the issue with Go. After dealing with inscrutable errors in some python code that interfaces with OpenSSL. Or dealing with impossible to trace errors in Spring Boot. Or Javascript? An absolute nightmare from start to finish. There's something extremely nice to get an error, place a breakpoint and trace exactly (even if it's a third party library) that error is happening. I will take all the footguns in the world for that ability. Plus in general the tooling is just amazing. I know there is other Unix tooling out there but I'm sorry, they kinda suck and are terrible to use. They're for the type of person who can use vim with their eyes closed and unfortunately that's not me. The other footguns he mentioned? Valid. A linter will catch a chunk of them though. I just generally don't think they matter half the time. I think of it like the iPhone. It's a pleasure to use like 80% of the time maybe 85% and 10% it feels hacky and terrible to get something working and 5% you just can't or shouldn't do it. So for the 80% use case (backend crud apps or backend web apis) I'd take Go every time. Plus it compiles almost instantly versus multi minute turnaround times in a lot of other languages.
  • noisy_boy 4y ago
    > Or dealing with impossible to trace errors in Spring Boot. Spring Boot is not Java. You can debug Java just as easily. On the upside, you can probably get the same stuff done in probably one third less code + use the vast ecosystem. On the downside, compilation may be a bit slower and you don't get a nice little executable out of the box. I wrote a tool in Golang and while it did everything as advertised, the boilerplate just bogged me down. Any new changes is just so much more LOC compared to Java (or Python or Rust...). To be clear, I would prefer Java or Rust compared to Python any day. Either way, I just don't want to write so much verbose code anymore.
    • kaba0 4y ago
      I seriously doubt that Go would compile faster than Java. Like, neither does any reasonable amount of optimization, and I have never heard Java considered slow in compile time. Sure, one can do some very cryptic module-graph with their chosen build tool, but otherwise it should be as fast as it gets.
    • 4y ago
• unethical_ban 4y ago
  One more thing to note (on this post that is already on page 2 of HN after 47 minutes): To me, as a scripter-ops kind of person, Go is useful as a Python variant. You get types, you get a huge standard library, and much of ops is network-based communication and glue code. The last job I had, I was tasked with rewriting a moderate Python lambda into golang as a POC for ease of use, and performance. I relearned the basics of go in about two days, used google and docs copiously, but otherwise did not change the structure of the program. The execution time was cut in half! It's an easy language to get using quickly and serves that purpose well. I wonder if the author could acknowledge the comparison to Python.
  • fasterthanlime 4y ago
    I really don't know enough about Python to discuss it, so I usually don't. There have been some semi-recent developments re typechecking Python (see https://dropbox.tech/application/our-journey-to-type-checking-4-million-lines-of-python https://dropbox.tech/application/our-journey-to-type-checkin...) that have made me interested in trying out for real.
• prophesi 4y ago
  I use Go for simple CLI apps and it's pretty dang good for that. They're used by coworkers, contractors, and clients so the fact I can just send over an executable for any OS is really nice. I wouldn't use it for anything too complex, or requiring a GUI. Mainly because I'd be much better off using the languages in my day job that I'm more familiar with.
• penlightment 4y ago
  It's the matter of one's opinion, I personally love it. The design has +n years of experience behind it and stands on shoulder of some serious people (yea you already know who they are). Every language has its own gotchas, and if you are not satisfied with it, coding some Java might help you gain a little perspective.
  • oxnrtr 4y ago
    Coding in Java is outright ok, compared to Go. Also, you should read the article, it mentions reactions like yours.
• unethical_ban 4y ago
  This post should not have been flagged, just because people don't like hearing criticism of a language.
• trentnix 4y ago
  I'm not emotionally attached to Go, I want to learn rust, and I'm old enough to realize the search for the perfect tool is utter folly. So the inevitable religious wars that surround critiques like this don't move the needle for me. So while this article didn't really convince me of anything, I have to admit I did learn a thing or two (or five). Kudos to the author, who is a fantastic writer and communicator. Even if you aren't neck deep in the language wars, it's worth reading.
• rvieira 4y ago
  I guess that, like everything, it depends on what you're using it for and which compromises one is willing to do. I'm not proficient nor use at $DAY_JOB C, Go or Rust. However, I wanted to write an Emacs dynamic module and those were my main choices AFAIK. I've picked Go to write a grunt work module (fetching JSON, parsing it, transform it, send back to Emacs) and it's been smooth sailing. I then found the benefits of writing client glue code between Minikube, direct K8s and Docker and Emacs a breeze. What lie am I telling myself?
• lucasyvas 4y ago
  This shouldn't be flagged...
  • deleted 4y ago
    [deleted]
  • fxtentacle 4y ago
    I flagged it because it appears to be written to mostly elicit outrage, as opposed to informing the reader. For example the headline "Mom smokes, so it's probably okay" and then 8 paragraphs of lead-up to the argument that the Go standard library has an inelegant IP type. Afterwards the author equates people using custom types to "build a whole new type system". "Evidently, the Go team didn't want to design a language." is also pretty insulting if you consider how much the Go team wrote and talked about why they designed things in this way. And to make a lot of weird arguments work, the author then refuses to treat any cgo feature as part of the Go language ecosystem. That's the point where I was convinced that the author wrote the summary before researching the arguments.
    • deleted 4y ago
      [deleted]
    • rmasters 4y ago
      Are those issues really so egregious? There is a tremendous amount of content geared towards "informing the reader" and I'd prefer to draw my own conclusions about the author's intent rather than having a censor (who is assuming bad-faith) try to protect me from a rather mild rant (in my opinion).
    • tinco 4y ago
      The headline and the paragraphs lead up to an illustration how the IP type in Go is inelegant because of several shortcomings in Go. It's a perfectly acceptable instrument to the argument. It immediately follows up with interesting discussion about how it's acceptable for a team of experts to use Go. I think he's wrong, Go is perfectly powerful in the hands of novices. And I actually think a team of experts like Tailscale would probably be much better served by choosing Rust. But that's all besides the point. The article is excellent, fits our forum and is a great basis for discussion. You are not using the flagging feature as it's intended to be used.
• smasher164 4y ago
  Not a fan of articles that attempt to speak for me or say that I have stockholm syndrome. It’s super gaslighty and a pernicious form of contempt culture in the tech community. Instead of just saying how they feel about a language, they try to claim a moral high ground.
• throwaway4good 4y ago
  This article should not be flagged.
  • tomlin 4y ago
    Yeah, unfortunately sorta shows that this community is becoming like a lot of communities: anything they don't like == toilet.
• Zababa 4y ago
  I have a hard time judging the "actual quality" of the article, but considering the quality of the discussions it generates, I don't think something like that is a good fit for HN. There's something that I think is important to mention: there's a difference between theorical ways to make bugs and bugs that happen in reality. The author spends more time talking about theorical ways to make bugs than bugs that happen in reality. I'm all for the "we should be using good tools", but there's also a point where you shouldn't use a tool just to use it. An example of that: at work we have a very huge codebase that's a pile of C++, C#, JS and TS. The codebase is more than 20 years old. Typescript is a relatively recent addition. I've seen part of the adoption, and talked a lot with the people that adopted it. And the conclusion is that it didn't really reduced the errors we have in production. We already have processes to cover for that: being careful during development, pair programming, code reviews, automated tests, manual tests. However, it made the development way easier, since Typescript has a better IDE support. But it didn't lead to use reducing our processes. A lot of the article seems to be rationalizing bad experiences with Go due to bug happening in production. I don't want to reject the criticism entirely, but I think the language isn't the only thing you can blame here. And my own experience is that processes matters more than the language when try to write good code. It seems like the author has a different experience compared to mine, and I don't want to fall into the fallacy of "it's possible to write bad code in every language". But I think the author should recognize that people can have widely different experiences, and that there isn't always someone that's right and someone that's wrong. I've read lots of thing about Typescript adoption and lots of people/companies mention a reduction of bugs in production. This didn't happen for us. That doesn't mean they're wrong, and that also doesn't mean that Typescript is useless for reducing bugs in production. It means we have different experiences. I think it would be more productive to talk about our experiences, and try to find out why they are so different. This way we could learn a bit more about software engineering, and develop more empathy for each others.
  • fasterthanlime 4y ago
    > there's a difference between theorical ways to make bugs and bugs that happen in reality On a large enough (time)scale, no there isn't. But also, all this is rooted in years of running and/or watching someone run Go in production. These bugs aren't theoretical, they cause incidents and outages, and occasionally wake me up. I don't like being woken up.
• HL33tibCe7 4y ago
  The author writes well and makes compelling points. His "I want to get off Mr Golang's Wild Ride" post is good too. But I don't find myself agreeing with his position, which is "you shouldn't use Go for production services" (he explicitly says this in one of his Go posts, I forget which one and don't have time to look right now). The better alternative to Go is Rust. Okay, sure, I'm willing to admit that in the examples presented, Rust handles things better. But Rust isn't a panacea. Rust is complicated and hard, and often it's not worth taking on that burden just to theoretically handle cases that rarely occur and even more rarely cause any problem. Programming is a means to an end, and the cost of using Rust (hiring, increased development time) is often not worth it. The reason Go is successful is because it's easy for companies to use to solve production problems with teams of varying expertise. Its stdlib is well-featured, its ecosystem is good. There's generally one correct way of doing things. The same doesn't appear true in Rust. For example, an _incredibly_ common thing to do in production code is to make a web request. In Go, there is no need for debate, you use the stdlib. In Rust, you have to use a crate, which requires a decision to be made. Even worse is the async story, in Rust you have to decide whether to use Tokio or whatever. That burden is just not present with Go. Btw this article should not be flagged and it's pathetic that people have flagged it.
  • ParetoOptimal 4y ago
    > increased development time In my experience it is only increased initial development time. I find that initial development time is frequently conflated with development time overall. So obviously worse is better languages will be preferred.
  • weatherlite 4y ago
    > The reason Go is successful is because it's easy for companies to use to solve production problems with teams of varying expertise. It would've never got to where it's at if it wasn't for Google, that's the most important reason why its successful.
  • draxil 4y ago
    Definitely. Go and Rust both have strengths and weaknesses. And I think they both have a love/hate dynamic because they make pretty strong choices in their own ways, and so people react strongly in response. Personally I'm a fan of both.
• fxtentacle 4y ago
  I guess this is mostly a Rust fanboy virtue signalling in their eternal war against Go and C. sigh
• blindseer 4y ago
  I've used Go and Rust professionally and in side projects, and I had used Go first before Rust. When I first used Go, I was like "oh wow, this is so simple and easy", and I didn't realize that I was putting up with the language. Learning Rust was relatively harder, but once I did and wrote some non trivial programs in Rust, it was like a pathway in my brain opened up and was previously blocked, and then when I went back to Go, I was painfully aware of issues that I the programmer had to keep in mind (or write a LOT of boilerplate code to keep track of). Issues that Rust's type system just solves. The way `nil` can seep into your codebase in Go and how bad the FFI is in Go will prevent me from ever choosing it for a project going forward. And I personally would not feel confident modifying Go code written by someone else, and would not feel confident accepting PRs into my Go codebase unless I understood every line inside and out. Rust is a breath of fresh air in that regard. All that said, I think the author here is idealistic in a certain sense. In the scale of "solving a problem by hand (or using Excel/a proprietary tool etc)" to "writing a computer program to automate it", both Go and Rust are very close to each other. And once someone learns Go and knows it well enough, the incremental cost of learning Rust or even thinking about the problems Rust solves for you becomes not worth it. I think that it's sad that this is the way it works, but that's just how it is. It's easy for settle for a local optima like Go when taking into consideration family, pets, salary, time, effort etc. I do think on a long enough timescale, programmers will eventually move to a "better" language. But in my opinion, that time scale exceeds the lifespan of a human :)
  • busterarm 4y ago
    I will say that playing around with Rust was an enjoyable experience, but it still has some warts where I think it's not quite ready for serious work yet (even though serious work is being done with it). These days I find myself leaning heavily on either Haskell or Elixir/Erlang's ecosystem (with a preference for the latter). Or JavaScript (there's just an order of magnitude more jobs)...
    • bobbylarrybobby 4y ago
      What did you think those warts were?
• assbuttbuttass 4y ago
  I feel like go hits a sweet spot between productivity and correctness. Working in Python, I constantly run into errors that static typing could have caught. Working in Rust, I feel like I'm constantly fighting the borrow checker. Maybe a more experienced Rust programmer would feel differently, but one of the strengths of Go is that it's relatively easy to learn
  • hajile 4y ago
    The sweet spot is something like StandardML. You get an actually sound type system (with genetics that aren’t a hack), but skip the complexities of direct pointer manipulation. It can do this while also being easier to learn than go too (designed so students could learn it and implement it too). The only reason go is popular is because google put thousands of man years and countless millions of dollars into it.
• chimen 4y ago
  One quick question as a TLDR: did he write about Rust being better?
• mcluck 4y ago
  I'm honestly surprised at the response to this article. I'm not involved in the Rust or Go spaces enough to have any strong opinions. This article was, yes, a little aggressive in tone but presented very honest and accurate information about a language that the author clearly has experience in. It seems like a lot of the people complaining in the comments didn't actually read the article. The author even explains how those who have bought in to Go may not want to hear what they're saying and it's right. No one wants to hear that their baby is ugly but sometimes it's the truth. To those who do use Go: someone can call your baby ugly and you can still love it.
  • gjsman-1000 4y ago
    This is the second day in a row where a post about Go in a negative light was flagged. The first one was an extremely detailed criticism, maintained the front page, and was flagged like crazy. What gives?
    • eatonphil 4y ago
      Could you link? I must have missed it.
      • gjsman-1000 4y ago
        https://news.ycombinator.com/item?id=31191700 https://news.ycombinator.com/item?id=31191700
        • eatonphil 4y ago
          Ah OK just the author's 2020 post. Thanks!
    • sph 4y ago
      This is the second day in a row where a post about Go _from the same blog_ has been posted. I think that's enough, especially since it's mostly a knee jerk reaction from that very HN post from yesterday. https://news.ycombinator.com/item?id=31191700 https://news.ycombinator.com/item?id=31191700
• victoryhb 4y ago
  Why is HN flagging this article? Just because it exposes the (debatable) flaws of a language that the HN crowd love? Justifications must be provided.
• benreesman 4y ago
  You guys flagged this? That is not the move of a vibrant, growing, confident community. I’m no fan of the Rust jihad myself, but this isn’t spam or hate speech or whatever. That is a super weak move.
  • robonerd 4y ago
    Flagging articles that criticize popular tools seems to be common. Particularly so with Go specifically.
    • jeroenhd 4y ago
      Go and Rust seem to have some of the most rabid fan bases of all programming languages and this article mentions both. A perfect HN storm. I think all the arguments against Go in this article are fair and I think you can write articles just as long about any programming language of your choosing. It's very strange to see the level professional programmers will stoop to if their favourite tool gets criticised. The fanboys of programming languages are the worst part of a language community. The "why not rewrite it in Rust" and the "you're golanging it wrong" crowds only drive people away from their respective languages.
  • otterley 4y ago
    Right now our only mechanism to indicate that we don't think a post is appropriate is to flag it. We don't have the ability to downvote posts that we don't feel meet the quality bar for being featured on HN.
    • sigzero 4y ago
      Why is it flagged then? It is clearly an appropriate posting.
      • otterley 4y ago
  • 4y ago
• beltsazar 4y ago
  Does anyone know the guidelines of when to flag submissions? For me, submissions that spread misinformation should be flagged. But just because you don't agree or like the article, doesn't mean that you should flag it. I guess this submission is flagged because some people don't like it but HN doesn't have downvote button, so they use the flag button as an alternative.
• mfrw 4y ago
  I use go at my ${DAY_JOB} and I love go. I think it’s a little too aggressive on our part as a community to flag this post. Although, I do not agree to all the opinions shared by the author. Let's agree to disagree :)
• blub 4y ago
  The author doesn’t fundamentally misunderstand programming language design, but rather misunderstands programmers. Most programmers don’t need someone to tell them which tools to use. Of those green enough to need it, they certainly shouldn’t look to the internet for advice and they absolutely shouldn’t look to HN or random blogs for advice. Instead they should find a local community which can offer them support when they stumble and point them to interesting job opportunities. Because those people are real and they can build relationships and connections which will be much more valuable than some measly programming language. Many online authors - even if technically skilled - have quite an over-inflated sense of importance. What makes somebody think that their experience in domain X and country Y apply in any way shape or form to the hundreds and thousands of industries, countries and cultures all over the planet?
• boulos 4y ago
  As people have remarked, Amos's style can be grating and hyperbolic. That doesn't make a lot of his complaints about Go as a language incorrect. I do think he's misunderstanding that the design intent is "networked C" and that Go + Protobuf is much better than he thinks. A lot of his complaints with the language and runtime boil down to: - It's got a primitive type system (yep, nobody disagrees) - It leaves a lot of problems to you (yep, just like C) - you can't integrate it into existing binaries (yep, distributed systems connected by RPC) He comes to terms with the last one and admits it, but it is not only the thing Go is good at but it was the design intent. If you start from "we want a language and runtime for writing distributed systems that would otherwise be written in C or Java" then Go is pretty good! I'm a happy Go, Rust, C, and C++ person. They're each for different things. That Rust worked out (is working out?) despite being an incredibly powerful and complex language (compared to C) is awesome. In the mid-2000s, it's not clear that you'd bet on a language like Rust. It is clear you could do better than Java or C++ for distributed systems programming, and Go hit that pretty reasonably (I do wish the language had a better type system, and I'm glad to see Ian finally land generics, but I'd absolutely reach for Rust when writing code in a small group that can handle the "language complexity" in exchange for the benefits).
  • kaba0 4y ago
    What I don’t generally get is why Go when there is Java already? Like other than the somewhat smaller memory footprint that is not inherent to the language, but the runtime — in what way is Go better that could not have been a Java library? Hell, with Google’s resources one other GC/mode could be added to OpenJDK that prioritizes memory footprint (at the expensive of throughput - there is no free lunch). Sure, Java has some warts but it is a very easy and small language, the reflection-based frameworks are not at all mandatory, Java can be quite expressive without those as well and it is extremely performant. Once value types get included it will be really hard to get ahead of Java.
    • boulos 4y ago
      There are a few things, mostly due to the runtimes but also because the JVM bytecode assumption has real implications for system behavior. Let's start with bytecode. It "requires" (except for AOT work) a warm-up / JIT phase that tends towards slower start times. This isn't hard and fast, but in practice it's true. (And when you search for "jvm startup", you end up at lots of pages about how to tune things to try to make this better). For some people, just as bad or even worse (remember, distributed system) is the impact that JIT-compilation and warm-up has on tail latencies. The static nature of most compiled languages mean this isn't a thing you worry about. You've got enough tail latency problems in your life, you don't need "oh hey, I just saw this loop for the Nth time, I took 10ms to hot compile it!". That leads into the runtime and some of the language choices around it. Java GCs are generally fighting a harder problem than Go's GC, and with a very different tuning point. Java making everything an object and support classloading and so on, has real knock-on effects for the amount of work required to get high-quality, low-pause GC to work. This is much better today than it was in 2008 when the Go team started, but it's still the case that Go has an out-of-the-box better GC experience. Yes there exist special, tuned GCs (e.g., Azul's C4, Shenandoah) but Java GCs have to really be super clever compared to the fairly simple strategies that work in Go; I applaud the ingenuity in Java GC work, but if what you care about is "reasonably good at collecting memory, never pauses for long", the Go language decisions made the GC problem easier. I think it's fair to ask "Shouldn't Google have just improved Java?", but I think you miss out on lots of the concurrency ergonomics. Again, this has to be compared to a decade ago. Especially post 2010 (Oracle acquisition) it was super unclear that you'd want to attempt to "bet on Java". To be clear, I do think Go is at the wrong point on the language/type-system sophistication curve for my tastes. That said, I find myself shaking my head at most Java code, while looking at the Go code and thinking "sigh, lots of repetition. I hope one day that gets better, but at least it's obvious".
• black_13 4y ago
• rmasters 4y ago
  Flagging this post strikes me as shameful censorship of an unpopular opinion. You may say it's the snark/anger/frustration that got flagged, but I suspect it would not have been flagged if the topic were different. Presuming the author is making bad-faith arguments for internet blog points goes against the spirit of HN. I prefer to draw my own conclusions, thank you. I normally expect HN to take the higher ground with calm and reasoned counter arguments of the content but not today I guess.
  • otterley 4y ago
    • rglullis 4y ago
      What's "inappropriate" about the post? I for one wish that we had more posts like these instead of typical stuff that has been getting to the front page lately.
      • otterley 4y ago
  • victoryhb 4y ago
    I am also surprised that a reasoned discussion like this gets flagged while comments calling it a "shitpost" are not.
    • dang 4y ago
      It's like this: when the input is a soup of reasoned discussion plus sensational flamebait, the flamebait will always dominate, and will always determine the output. Sad, but reliable.
    • goodpoint 4y ago
      Because people learn to cling emotionally to hyped-up topics. Any criticism of sacred icon is taken like an aggression to the reader's sense of self.
• eatonphil 4y ago
  I use Go heavily cross-platform developing DataStation [0] and dsq [1]. I am not an expert. And I don't have proof for it but on some rudimentary benchmarks the Linux-specific file idioms in the Go standard library definitely don't seem to translate well to even macOS let alone Windows. For example some good streaming techniques for reading large files on Linux that work really well there seemed to be pretty bad on macOS. I think Amos has presented more proof than I can on the topic of just how Linux-influenced Go is. And I think it is fine for the majority of Go users because the majority users of Go are building server apps or Linux CLIs. Amos has spent some time building cross-platform desktop systems with Go for itch.io and I think I'm seeing some of the same things they are in that scenario. I think this is a reasonable article. I didn't notice anything too flame-y myself but if for you Amos gets flame-y at any point I think that's worth ignoring because there does seem to be something up with Go in cross-platform applications. Amos does have good experience here. (Go look at itchi.io's github like wharf [2] or butler [3] where they are/were the main contributor.) I like Go a lot and for most things I'd keep using it still. Just sharing some observations. [0] https://github.com/multiprocessio/datastation https://github.com/multiprocessio/datastation [1] https://github.com/multiprocessio/dsq https://github.com/multiprocessio/dsq [2] https://github.com/itchio/wharf https://github.com/itchio/wharf [3] https://github.com/itchio/butler https://github.com/itchio/butler
• Thaxll 4y ago
  I'm just wondering why the author keeps making those articles about strongly disliking Go, ok we get it your favorite language is Rust, you don't like Go. Why does the author does not move on, exactly? "Fine. It may well be that Go is not adequate for production services unless your shop is literally made up of Go experts (Tailscale) or you have infinite money to spend on engineering costs (Google)." This is really wrong on so many level especially coming from someone that has shipped what exactly in production? What is the expertise of OP to tell people to not use a language that was proven to be very successful.
  • etblg 4y ago
    As far as I can tell he has made.......2 One of them a couple of years ago, detailing his experiences with using Go to accomplish something, contrasting it with how it would work in Rust. And then this new one, which seems like a semi-response to that previous article hitting the HN front page again. I wouldn't say he "keeps making" them, he's made two, and they're not coming out of nowhere. As he said in a comment of the most recent submission of his previous article (https://news.ycombinator.com/item?id=31193260 https://news.ycombinator.com/item?id=31193260): > Author here: I wrote this in 2020, have changed jobs twice since. Both jobs involved Go in some capacity, where it's supposed to shine (web services). It has not been a pleasant experience either - I've lost count of the amount of incidents directly caused by poor error handling, or Go default values. > Because that's the kind of code I inevitably end up being on-call for, and I'm tired of being woken up because of the same classes of preventable errors, all the time. It doesn't matter that I don't personally write Go anymore: it's unescapable. If it's not internal Go code, it's in a SAAS we pay for: and no matter who writes it, it fails in all the same predictable ways. It's not that it's not his favourite language, it's that he's experiencing actual day to day issues at work caused (in his opinion) by the design of the language. I think that's fair to write about.
  • andrelaszlo 4y ago
    I thought the criticism was pretty balanced. I've seen worse articles here about other languages. Pretty used to getting this feeling about the Python articles. It's almost always about the lack of some feature that exists in other languages. It seems to be part of the cycle of a language that gets widely adopted. I think the next step is that people stop fighting over it and just accept that it has some nice features and some bad parts. Articles like this helps me (as a dev who's not using go very often) getting a feeling for what types of problem go might be good for and not. If it's well-written like this one, I think it's a good balance to the many positive articles that I've read. Clearly the author cares a lot about language design. I get that he might be coming from a different background with different tastes. The fact that he doesn't like go isn't saying your time spent learning the language has been for nothing. Clearly a lot of code is being written in it, don't worry! Here's some stuff he's done: https://fasterthanli.me/about https://fasterthanli.me/about I think he's entitled to an opinion either way though. Very interesting to see the response. Had no idea it was this touchy. I can get a bit weary seeing the millionth article saying that Python sucks because it doesn't have a feature of another language - but it also makes me want to try out that other language for myself.
• dimgl 4y ago
  This article should get unflagged. This is an eloquently written article and a good discussion about Golang. I think we need more articles critical of Golang. Edit: I'm really shocked by the downvotes. Can someone explain why my comment is worthy of being downvoted?
• evo_9 4y ago
  The flagged feature needs to be tweaked on HN; it's being used far too often to censure opinions others simply do not agree with.
  • otterley 4y ago
  • johndfsgdgdfg 4y ago
    It's pretty much the whole culture now, not just HN. Anything I don't agree with is an evil and must be stopped at any cost.
  • yjftsjthsd-h 4y ago
    It's also being used to try and avoid another flamewar, which this article seems practically guaranteed to cause.
    • oxnrtr 4y ago
      Go fans misbehaving shouldn't be a reason to avoid submitting articles.
• avl999 4y ago
• v4vvdq 4y ago
  Author should have used this article to propose Go 2.0 changes. For me, I read it like a rant.
• amznbyebyebye 4y ago
  Why is this flagged? Come on
• kgeist 4y ago
  We have tens of microservices written in Go. Go is good for onboarding new devs because it's simple. Our existing PHP devs were taught Go and it was painless. Jumping from PHP straight into Rust would be pretty painful, I think. Finding Rust devs isn't easy in our town. But I agree with most of the points. You got to be very careful when writing in Go, because there are many gotchas. So many gotchas that I had to write a large document describing all the conventions and rules to remember to write bug-free (hopefully) Go. This "Go with conventions" reminds of the days when you'd try to simulate OOP in C - it works but error-prone. Many of the problems are caught early with good unit and integration testing, however, just like with scripting languages. In my experience, most of the bugs in production in our Go microservices come from logical mistakes, not from misusing Go.
  • aidaman 4y ago
    can you shoot me the doc?
  • frou_dh 4y ago
    That means Go was easy for those devs to pick up, not that Go is simple. Rich Hickey gave an all time classic presentation about this seemingly nitpicky but important distinction https://www.youtube.com/watch?v=SxdOUGdseq4 https://www.youtube.com/watch?v=SxdOUGdseq4
    • themantri 4y ago
      Interestingly, I have always heard Go is simple, but not easy.
    • deleted 4y ago
      [deleted]
  • oxnrtr 4y ago
    I readily believe that PHP devs struggle with anything more complex with Go, but that makes me question how people end up with the lack of will to learn and improve in this profession.
• mattbee 4y ago
  Yes, this is a really good article, I think the tone is warranted! I'm writing a Go course at the moment - all the basics on channels, slices, pointers with all their warts - and am not shying away from saying "sorry this doesn't make any sense, you just have to know it and beware". I appreciate the nil method receivers, the zero value meanings, the types that are actually hidden pointers, but if you're not coming from C, a lot of it sounds inconsistent and counter-intuitive. And I'm not sure there's a way to justify it to programmers who have grown up on better, safer, clearer abstractions, even with the potential performance gains.
• DLA 4y ago
  So much Go hate and arguments over language design details. Meh. Back to producing fast, well-organized, maintainable, bullet proof code in Go for real-world problems.
  • oxnrtr 4y ago
    > bullet proof Based on the article, I doubt it.
• hintymad 4y ago
  I'm not sure why choice of programming language is such a heated topic. "Want to use Java? Over my dead body", said a ex-Uber employee. "Let's rewrite Kafka in Rust to avoid using Java in our team", said an employee in a $10B+ unicorn. "Go is a plague. Let's use Rust", said an employee in another $5B+ unicorn. Doesn't language itself contribute just a small portion to our productivity? The platforms and ecosystems of programming languages usually matter more? And it's simply childish to argue that GC sucks when your services handle merely 100s of QPS (even if millions of QPS, so what? It really depends on what you try to achieve), or to argue that language X sucks because it does not have feature Y. I hate to break the news to language fanatics: your program is slow most likely because you didn't choose the right data structures or algorithms instead of using the wrong language. You productivity sucks most likely because you didn't write simple, correct, or operable software.
  • palmtree3000 4y ago
    > I'm not sure why choice of programming language is such a heated topic. I think there are two reasons. First, languages live or die by their ecosystems. If you love a language, it's very much in your interest for other people to use it, so they write code that you can use. Second, most programming happens at work. Most people don't get to choose what programming language they write at work: they're locked into whatever choice somebody else made. The more popular your language is, the more likely that choice is to be made in your favor (or alternatively, the easier it'll be to find a job where that choice has been made in your favor). If I want to write Idris at work, well, tough luck. Both of these are largely zero-sum, which makes things worse. It's not 100% zero-sum, in that if you manage to light a passion for <language> in somebody they might write code (in that language) that might not have been written at all. But mostly language evangelism won't change the total number of programming hours per year (or the number of available programming jobs), so all that's left is to fight over who gets how much. So if you care a lot about which programming language you write, I don't think it's odd to come at it from combative angle: it's a fight! Some will lose and some will win, so you better try and be one of the winners.
  • dragonwriter 4y ago
    > I'm not sure why choice of programming language is such a heated topic. Because the market identifies job suitability by years of experience with a particular tool, so the popularity (in the market) of tooling a programmer has experience with is intimately tied to their job opportunities and financial prospects. If you are an “X programmer“, attacks on X are attacks on your livelihood. Conversely, if there is an abundance of Y programmers, convincing people that X, which far fewer are proficient in but where you are one of them, is superior for some high-value domain, is enhancing your livelihood. You’ve seen informercials exaggerating the negatives of alternatives while hyping a product in order to sell it? Well, while it's framed as being about tooling that's one step removed, that's basically what programmers are doing in language flamewars.
• pphysch 4y ago
  The recent paper from Go core devs, "The GO PL and its Environment" highlights that a major aspect of Go is its environment/ecosystem, from the very start. But the OP, in either article, zeroes in on narrow language/STL design choices and never zooms out to consider the ecosystem and how Go works in an actual software engineering team. Pardon the vulgar analogy, but this is like zooming in on a dog's asshole and going "what the fuck is this? It looks gross and shit comes out" without considering that it is an integral part of a well-functioning whole. It all comes down to misunderstanding each other's positions.
• TheMagicHorsey 4y ago
  I'm just a simple dev in a 3-man team building an app and a back-end to go with it. Our company is default dead. Maybe some day I will regret choosing Go for our back-end. But right now it is the right balance of scalability, easy async, good tooling, great back-end infrastructure (Google App Engine and Firestore) and productivity. I read articles like this, and think to myself ... some future CTO will curse my choices today. But then I feel that future CTO will curse any choices I make, and it won't be fair for her to curse my choices ... because I'm just trying to get us from default dead to default alive without running out of the small amount of money we raised. Rust is absolutely not an option for us. We don't have the skills or time to write a Rust backend right now.
• fearfulofview4 4y ago
• crawshaw 4y ago
  Tailscalar here. Go made prototyping our product easy. We have relatively rarely needed Go expertise on the team to make the product better, when we did it was for the exotic iOS environment (not normal iOS, the Network Extension). It’s far from perfect (and I really should write an experience report about all the times Go has let us down!), but it gives us less trouble than Node and Swift do, for our relatively minor uses of those languages. I don’t think any other language would have been a better choice, even putting our expertise aside. On the whole I would say you don’t need Go experts on your team to build products in the language.
  • VMtest 4y ago
    Author's criticisms are valid, but "There's two types of languages, languages people complain about and languages no one uses" Is author being serious about all people who write Go for production would be waking up at 3am to fix issues? If this is happening, software engineers are being abused, enough said And not recommending C/C++ because it is easy to shoot yourself in the foot, apparently the devs enter hospitals so many times when memory-related vulnerabilities happen in Windows/Linux/Android/MacOs/iOS and Chrome/Safari/Firefox people should stop idolizing programming languages
• HerrmannM 4y ago
  2014 Story Time, when I was a phd student working on programming languages (apologies for my broken English, non native speaker here). The multidisciplinary lab I was in had a "Go or Rust" dilemma. As the language guy, I was asked for my opinion. I had no experience with Go, and a small bad one with Rust: there was weird stuff going on with pointers, and even seemingly simple programs would fail to compile due to a less than happy borrow checker. Working with Rust required a heavy learning investment. On the other hand, Go looked simple, with amazing goroutine, fast compilation time (great for the code/compile loop), and backed by a big company, which is reassuring for then still young languages. As I could not form my opinion on significant coding experience, I looked at the principles. It appeared to me that Rust design was guided by language principles, whereas Go was guided by system/engineering requirements. For example, Rust had generic and sum types, which Go lacked. Rust error are "naturally" dealt with using sum types, whereas Go relied on error codes. Go had that "operating system flavor", with features usually closed to the OS directly implemented in the language (goroutines, which are great). Rust had that "things are complicated flavor", in both the language (borrow checker, several kind of pointers), and the library (several kind of string?!) which at first is of-putting. Being a language guy, I argued for Rust's good use of language principles over Go's more practical approach. My bet was that Rust usability would improve. A mix of Java/Scala was chosen. I now code in C++... --- --- --- A note on simplicity. Simplicity is a lie. Things (not only programming languages) are not simple, they are messy, hard. Truly hard. In my experience, simplicity claims are usually superficial, and show their limits when going a bit deeper. As programmers, we like to have simple, generic, abstracted constructs, because it makes our life easier. But the world is not generic; it is full of special cases, corner cases, situations that do not fall in a nice hierarchy, which is its beauty. It took me too long to "accept" this beautiful complexity, and to stop fighting it. If you are still looking for simplicity, maybe check that you are not fighting the world's complexity.
  • zozbot234 4y ago
    Rust was very much half-baked in 2014. Version 1.0 was released in 2015, and critical features for dev UX like non-lexical lifetimes or async weren't supported at all until late 2018. In fact, Rust would've been a terrible choice back then. Lots of people seem to miss that, but it's also why this whole anti-Golang flamewar is so pointless: a lot of the Golang stuff out there is not greenfield, but was written back when there was hardly any reasonable alternative to it, and certainly nothing like modern Rust was available.
• pensatoio 4y ago
  I don't understand all the attention these articles are getting. If you don't like it, stop using it. Why are you going to so much effort to complain? You can write bad code in any language. You can write difficult to read code in any language. Every language has pitfalls and downsides. Personally, I work in golang full time, and I adore it. Development is painless, and our codebase feels very easy to read.
  • Tomis02 4y ago
    > You can write bad code in any language. Some languages make it much easier to write bad code. Some languages introduce safety checks that eliminate entire classes of bugs. So your claim that all languages are the same is very far away from the truth; not all tools are the same.
• overlisted 4y ago
  Did someone take down his server because of this blogpost?