1. 20
  1.  

  2. 36

    Without discussing any of the other points, this article (published in late 2020) misunderstands or misrepresents (point 5) the state of go dependency management, citing a 2015 thread about vendoring dependencies. The author may not be the most informed writer.

    1. 22

      Most articles that use “Golang” in the title are not from the most informed writers.

      I’m not overly pedantic about these sort of things, but I’ve noticed for a number of years it’s a fairly accurate heuristic (although hardly perfect, exceptions as well).

      1. 5

        I was told this by an Old Gopher with respect to a readme in a GitHub repo & my response was that I had reflexively done so to make finding it with search engines more obvious since Go has many meanings.

        1. 3

          I list “Golang” on my CV for more or less the same reason (as Go (“Golang”)), and there are plenty of exceptions as well of course: like all heuristics it’s far from perfect. But it holds up fairly well in general.

          The SEO value is probably not all that much; right now my “Statically compiling Go programs” article is the first result on a DDG for both “golang compile static” and “go compile static”, and for Google it’s the second result. It doesn’t use the word “Golang” in either the title or body.

    2. 30

      One cannot help but notice the author omitting the dog’s breakfast more “intelligent” languages encourage young, excited programmers to come out with. Capping the amount of bad you can do in a language is just as, if not more important, than increasing the amount of good.

      1. 16

        I agree and to that end I propose banning all programming languages. Let’s be done with all this nonsense.

        1. 3

          Hear, hear! Turing completeness is the biggest footgun of them all.

        2. 6

          Capping the amount of bad you can do in a language is just as, if not more important, than increasing the amount of good.

          Is it really? Sure, limiting the amount of damage a non-expert can do is a desirable property of any language, but Go has to trade things for its particular brand of “capping the amount of bad”.

          Depending on context this may be more or less important e.g. in a large team with a lot of inexperienced developers I might want to trade some “sharp tools”-ness for guard rails. But that’s not at all the tradeoff I want to make with a small experienced team on on weekend projects.

          I’m also not sure how successful Go actually is at this goal. Show me a turning complete language and I’ll show you some really garbage code written in it. I don’t really think the problem of young, excited programmers producing poor code is solvable at the language level.

          1. 11

            I don’t really think the problem of young, excited programmers producing poor code is solvable at the language level.

            It’s not solvable, but you can limit the type of poor code. Like, it’s relatively straightforward (not easy, mind you, but straightforward) to DRY up exceptionally redundant code, trace boring procedural routines, and so forth–but a novice just learning the power of macros, low-level OS and threading primitives, monkeypatching, AST manipulation, and other forms of metaprogramming can mess up a codebase to the point where burning it down and starting it over is the only way to be sure.

            From the people side, it’s also more likely you can get other engineers and seniors to help each other out if they are dealing with a language that scale horizontally instead of vertically; you may have a bright young dev who creates super clever things in Lisp or Haskell that nobody else can really help them with.

            1. 9

              Of course Go won’t prevent writing “garbage code”; this article actually contains an example of such code, but as friendlysock said, it does limit the scope of it. And of course this is a trade-off, because pretty much every feature added to every language ever is useful and solves real problems for people. The problem with stuff like this is the assumption is that people aren’t aware of this trade-off and are just blubbering idiots who don’t know any better. That’s not really the case.

              Some actual examples of this:

              Years ago when I worked as Ruby on Rails developer I tasked one of our new developers with modifying something on a login screen on his first or second day. We use devise, which is a “authentication system in a box”-kind of library; it’s pretty nice. Something or the other on the login screen didn’t fit our needs, so you can override the controller methods being used in the config and point to your own.

              I told him to use that, but when he sent me the patch for review it monkey patched the Devise code instead. Why? He wasn’t sure either, but it sure wasn’t a better way of doing things. I told him to try again.

              Monkey patching is a great feature, and something I sometimes miss in Go. A big reason I run my site on Jekyll and am not planning to switch to Hugo or whatnot is because it’s written in Ruby so I can fairly easy just modify parts without much effort; it can be really helpful and really allows you to quickly solve problems that are hard to solve otherwise, and for something like Jekyll it’s a fine solution (although the Stack Overflow crowd doesn’t seem to like it, well, whatever).

              But to replace methods in some library in a real-world production app, especially when there’s already an option for it? Not such a great fit.


              Another example is when we had this Gulpfile for building the frontend; the last step/plugin being run was replacing the links in HTML with versions (i.e. src="script.js" to src="script.js?v=deadbeef", and for some reason that sometimes took a full minute. I tried looking at it to solve that, and the code was inscrutable: it’s a straightforward thing to do, but everything was using promises all over the place and even with various debug printfs I couldn’t even figure out the basic control flow, much less where this minute was being spent. After half an hour I just gave up and accepted the fact that the s/.../.../ step in JS took twice as long as compiling our entire Go application 🤷

              1. 1

                After half an hour I just gave up and accepted the fact that the s/…/…/ step in JS took twice as long as compiling our entire Go application 🤷

                Did you try profiling?

                1. 3

                  This was five years ago. And spending more than 30 minutes on this wasn’t really worth the time.

                2. 1

                  The problem with stuff like this is the assumption is that people aren’t aware of this trade-off and are just blubbering idiots who don’t know any better.

                  Sure, totally. But I think the animus in the article is not from the assumption that Go’s designers (or Go users) are unaware of this tradeoff, probably the opposite. Like if you go and work in a go shop that’s consciously made this tradeoff it’s kind of like being told “we don’t trust you with more powerful/expressive/dangerous languages” which again I don’t think is always the wrong thing but I understand how it’s kind of hard not to take that as an insult, especially if you’re a more experienced developer and believe (correctly or not) that you can be trusted with sharper tools.

                  1. 3

                    From the article:

                    In my opinion, Go was developed by people who have used C all their lives and by those who did not want to try something new.

                    This kind of stuff does not demonstrate a deep understanding. It’s just a slightly nicer way of saying “blubbering idiots who don’t know any better”.

                    it’s kind of like being told “we don’t trust you with more powerful/expressive/dangerous languages”

                    I find that’s a fairly inaccurate way to describe it, and that someone might take this as an “insult” is frankly just weird. There are all sorts of reasons why Go is designed the way it is, and it really doesn’t all boil down to one 15-year old quote from Rob Pike. People get so hung up on this they stop looking any further.

              2. 4

                Capping the amount of bad you can do in a language is just as, if not more important, than increasing the amount of good.

                Maybe, but since Go encourages use of pointers, which might be null, and which can be shared between concurrent processes and race and crash on trivial examples, I don’t think it has the guard rails one might be looking for :)

              3. 24

                This is getting tiresome. It’s always the same points rehashed. Why beat the same dead horse?

                1. 12

                  Because they are beating a dead horse and ignoring that Go is an excellent pony.

                  Many languages are weak at limiting ever expanding dependencies and build times. Go addresses this, and also has an excellent deployment story.

                  Go was created partly out of frustration with C++ within Google and addresses many things that takes years to see that are problems in the first place.

                  1. 6

                    This. Go does a lot of things wrong, but it got so much things right, ebough to make itself relevant.

                    1. 6

                      … addresses many things that takes years to see that are problems in the first place.

                      Very eloquently said. Throwing the kitchen sink into a language means supporting a ton of problematic patterns and footguns.

                      For example, even though I think everyone, even in the Go community, accepts that generics are pretty useful, doing them well means trade-offs. When you’ve seen some of the bizarre ways people abuse them in C++, it should give you pause that they’re always-good-no-caveats. Which is why the Featherweight Go paper that forms the model for Go’s eventual generics plan is heartening — it may not be perfect either, but it applies some wisdom to the right way to go about it without jumping into the deep end.

                      1. 4

                        C++ templates are also unusually terrible as far as templates go. I don’t think this is a strong argument.

                        I think this is less “Templates let you write really bad code” and more “C++ lets you write really bad code with templates.” For instance, D templates are much nicer - and more powerful.

                    2. 9

                      This is getting tiresome. It’s always the same points rehashed. Why beat the same dead horse?

                      As someone who changed languages from PHP to Go, after all these years I … still have no clue why people feel the need to do that.

                      But I’ve learned to smile. In my imagination I pat the “smart” developer on the head and just continue with my day. You know, making useful stuff that people like. If people need to vent, let them vent. But don’t take a blog post as gospel, just because it contains a lot of strong opinions.

                      1. 6

                        Why beat the same dead horse?

                        Usually because someone is forcing them to write Go and the terrible pain it causes them squirts out in a blog post.

                        1. 3

                          I do not see how anybody is “forced” to write Go. The market is so hot right now that anyone can just switch jobs if they are forced to program in a language they do not like.

                        2. 2

                          It looks like the author is a D-lang person.

                          You know the meme, about D programmers, misunderstood who think their language is the best, etc.

                        3. 19

                          TL;DR - the usual Googlers quote, Go has limited expressive power, toy programs are shorter in D, no generics, and an old quote about dependencies.

                          1. 16

                            Not exactly sure what makes this person feel qualified to speak for smart programmers.

                            1. 15

                              This post is just a rehash of all the “meme” phrases people throw at golang:

                              1. Lol err==nil
                              2. lol
                              3. no
                              4. generics
                              5. lol gomods
                              6. C++/D is a real systems language
                              7. systems programming is for stronk people
                              1. 12

                                to me it is very telling when the central argument against Go is the Rob Pike quote that a design value of Go is that it should be easy for programmers with not much professional experience to use Go to get professional experience. This article, like many articles about why Go is bad hinges on a central assumption: that the reader agree that programming for programming’s sake is the most pure form of programming, and that people who code for the purposes of making a living are inherently worse at programming (or less smart), not people who have different, legitimate goals.

                                and besides, the author’s first example is atrocious code, both in functionality and in style, as it fails to recognize when it is throwing out arguments and needlessly buffers the entire contents into memory instead of handling the input as a stream. A Go programmer would be more liable to write that program as so: https://gist.github.com/jordanorelli/36beba899fd0d837d0b38227e14e473d

                                and as others have said, the things the author cites are either dated (a six year old post about dependency management) or misinformed (“idiomatic generics in Go”).

                                1. 1

                                  misinformed (“idiomatic generics in Go”).

                                  What’s the currently idiomatic way to… imitate generics these days?

                                  1. 6

                                    I don’t think the question is framed particularly well. The more relevant question would be “I would naturally solve [some problem] using generics, but since Go lacks generics, what would be the idiomatic way of approaching [that problem]”. Without specific problems, it’s tough to answer. There is no idiomatic way of implementing map and reduce, because map and reduce are not problem statements, they’re solution strategies, and those solution strategies are rarely idiomatic to Go.

                                    The one place I’ve found the lack of generics to be problematic is in defining container types, which is especially annoying when the natural way of solving a problem would be to use sets. I do find the handling of container types to be frustrating in Go, but it has posed problems for me less frequently than might be expected; slice and map types get you what you need most of the time, and where they’re lacking, making a struct that contains both is often far simpler than making a sophisticated container type. In the cases where I’ve had to make more sophisticated container types, I’ve often found it to be the case that it’s highly unlikely that the contained value type should be interface{}, and not either some struct (or struct pointer) type or some meaningful interface type that I have defined. In any case, I would recommend not searching for “an idiomatic way of imitating generics in Go”, but rather to search for idiomatic ways to solve the specific problems at hand.

                                    1. 4

                                      What’s the current idiomatic way to emulate infix notation in forth?

                                      1. 2

                                        Yeah, you’ve got a point there.

                                        What’s really frustrating here is that, while infix notation really just isn’t Forth, generics could have integrated seamlessly with Go. Despite what Go’s authors said for a very long time, and their excuses for not adding them are incredibly weak. Generics may be hard to design and hard to implement, but they’re fairly easy to use. My guess is that they were lazy or pressed for time, and then rationalized their choices.

                                        Also, I’m not sure they could even have said something like “Generics would have been nice, but our bosses said we need the language this month” publicly.

                                        1. 3

                                          There have been a whole bunch of quite detailed generics proposals from the Go maintainers that they themselves eventually rejected for one reason or the other before the current type parameters proposal was accepted. The current effort is the culmination of about ten years of active work on the issue.

                                          You may disagree with the reasons why those proposals were rejected, but I think any claims of laziness or post-hoc rationalisations are very hard to defend.

                                          1. 3

                                            Remember that it took years for the maintainers to even admit that Go might need generics after all. They stated reasons for not adding generics, but it would take some serious hubris for them to actually believe them.

                                            As for why it is taking time: a blunder of this magnitude is not easy to correct. you have backwards compatibility to deal with, existing constructs that were there only because we didn’t have true generics, kludges in the standard library that we’ll need to address if we find a better way… Now I have nothing to complain about from the moment they stopped being stupid and started admitting Go would be better with generics. (Which is an implicit admission of a monumental mistake, though I don’t expect them to publicly admit it.)

                                            As for why failing to add generics in the first place was incredibly stupid. Especially for a team of their calibre:

                                            First, Benjamin Pierce’s Types and Programming Languages was first published in 2002. It’s a seminal book that’s known to pretty much every programming language enthusiast. When you design a language over 6 years after its publication, failing to learn its material is overwhelming evidence of second order incompetence (that is, not even realising that you don’t know everything, and you might want to get familiar with the state of the art before you go and influence the whole world with your thing). I don’t really fault the language designers for not being familiar with generics right away. I fault them from not getting the hint from Java, C# C++, ML, Haskell… and then not learning the relevant material. Which was conveniently concentrated in a famous, very well written book.

                                            Second, when backward compatibility is not a problem, generics are easy. I know because I’ve done it myself, with my first serious programming language. The end users wanted a scripting language with a REPL to pilot and configure a test environment for programmable logic controllers. I gave them a statically typed one, with local type inference, a smidge of OOP syntax, and static dispatched based on the type of the first argument (similar to C++ overloaded functions). I quickly realised that I would need generics to write parts of the standard library, so I added them. The whole thing, compiler + bytecode interpreter, took me 3 months. The customers started using my thing right away, and I was still around 6 months later. I only had to correct one bug.

                                            Considering how easy generics actually are, I can only conclude that if Go’s initial designers had learned a bit of type theory, they would have designed a language with generics in mind. They didn’t, so I can only conclude that they were either lazy, or ignorant and unwilling to learn (another form of laziness, I guess).

                                            1. 3

                                              Remember that it took years for the maintainers to even admit that Go might need generics after all.

                                              It took a little bit less time, from 2009 (less than a month after the first public release): https://research.swtch.com/generic

                                              generics are easy

                                              No one ever claimed that implementing generics is too hard; just that doing it in such a way to aligns with Go’s other design goals is not obvious. Designing any programming language is easy; JavaScript was famously done in a week and loads of people are using it every day: doesn’t mean it got everything right.

                                              a blunder of this magnitude is not easy to correct. you have backwards compatibility to deal with

                                              Implementing generics but getting it wrong would be significantly harder to correct.

                                              1. 2

                                                It took a little bit less time, from 2009 (less than a month after the first public release):

                                                That fast? That hints as a rushed release, then. Pressured for time for some reason. They tried to get away with it, but apparently the backlash quickly told them that nope, they’re not going to get off the hook that easy.

                                                No one ever claimed that implementing generics is too hard; just that doing it in such a way to aligns with Go’s other design goals is not obvious.

                                                Pierce explains how to combine parametric polymorphism with subtyping. The solutions were known. The rest of Go’s type system is not so unique that it would require anything special.

                                                Implementing generics but getting it wrong would be significantly harder to correct.

                                                Look at ML/Haskell (the basic stuff only, don’t necessarily bother with modules or type classes), limit yourself to local type inference to make your life easier, it’s pretty hard to get it wrong.

                                                https://research.swtch.com/generic

                                                That’s a false dilemma. The “box vs bloat” choice should be an implementation detail. If you expose it to the users like C++ did, you’ve already painted the language into a corner.

                                                Now a proper generic system will likely appear to users as if we box everything. But the compiler has ways to bypass boxes under the hood (especially if it inlines stuff). You could also take the bullet, instantiate your types, and swallow the code bloat. You could do a mix of boxing and template-like instantiation. Granted, the best compilation strategies won’t be easy to find, but at least users have a nice interface with no nasty surprises.

                                                1. 1

                                                  Implementing generics but getting it wrong would be significantly harder to correct.

                                                  But did they do their due diligence? What solutions did they investigate and what problems did they find that required a decade of further research?

                                                  JavaScript was famously done in a week and loads of people are using it every day: doesn’t mean it got everything right.

                                                  This reflects worse on Go than on JS; no one would have expected a toy made in ten days to be used (with few major changes) for major tasks twenty years later, whilst Go was made from the onset as a serious systems language.

                                            2. 2

                                              Since Go was a project created to keep a famous person interested enough to stay at Google so they could say said famous person work’s there, and did not see any meaningful adoption at Google for years (and even still is hardly the most popular internal language) I don’t think they were pressed for time ;)

                                          2. 1

                                            interface{}

                                            1. 1

                                              OP did make make an interface{} based attempt, so I’m not sure he was as misinformed as @scraps suggested.

                                        2. 10

                                          I feel the golang version of the first example is written (purposely?) to be obtuse compared to D. i.e. using flag instead of os.Args. I don’t disagree with the point being made, but shoddy examples undermine it.

                                          1. 7

                                            No one said Go wasn’t verbose, but yeah, the example is silly. It’s also not even correct, as the newlines will be stripped, which is probably not intended.

                                            The more obvious way to write it is something like:

                                            var (
                                            	err error
                                            	fp  = os.Stdin
                                            )
                                            if len(os.Args) > 1 {
                                            	fp, err = os.Open(os.Args[1])
                                            	if err != nil {
                                            		log.Fatal(err)
                                            	}
                                            }
                                            
                                            text, err := io.ReadAll(fp)
                                            if err != nil {
                                            	log.Fatal(err)
                                            }
                                            fmt.Println(string(text))
                                            

                                            (Which doesn’t close the fp, but that’s okay for a short-lived CLI program)

                                            1. 5

                                              Also, as mentioned in another comment, the example in both cases is just… a bad way to solve the problem regardless of the language since it’s buffering the entire input unnecessarily.

                                              I know it’s just a toy example in each case meant to show features of the language, but still.

                                              1. 1

                                                Oh yeah, I always forgot about io.Copy() for some reason; usually you want to actually use the data you read in your application, so using io.Copy() is pretty artificial here.

                                          2. 9

                                            With the disclaimer that I am neither an experienced Go programmer, nor have I worked on large teams, I don’t understand what any of this has to do with being bad for smart programmers. In fact, I would say that many of the deficiencies that the article lists are in fact pitfalls for juniors programmers. Much of it comes down to having a substandard type system, so the compiler and associated tooling can’t give you useful guarantees or feedback. An experienced programmer may be able to keep the code’s requirements in their heads, but most junior programmers should have the compiler check their work, and Go’s design makes it impossible to do this.

                                            1. 12

                                              I thought Go was well known for having extremely good static analysis tools. The type system isn’t that powerful, but static analysis isn’t just type systems.

                                              1. 1

                                                That’s possible. I’m not in tune with the Go ecosystem enough to know if that’s the case, but this is the first I’m hearing of it. I’d be curious to know what these analyses are and what guarantees they provide.

                                                1. 5

                                                  The golangci-lint list of linters is probably a good view of what people are using generally.

                                                2. 1

                                                  The analysis package makes it pretty easy to write them too, with the biggest downside being that for some reason I always struggle spelling analysis correctly 😅

                                                  A simple example to check for copyright comments, and a slightly more complicated example to check if you’re actually calling functions that return a function in defer (defer Fun()()).

                                                  Both go vet and staticcheck are implemented with this.

                                                  1. 1

                                                    I wrote one at a previous job to make sure that event constants were matched up with functions of the correct type. Most helpful because that was a common thing people fat-fingered.

                                              2. 8

                                                So a slightly longer version of http://www.golang.sucks/ ?

                                                1. 12

                                                  The entire existence of a .sucks TLD is already …ugh… And it costs a whopping $199 to register one.

                                                  Imagine being such an unimaginative boring twat that you can’t think of anything better to do with $199 than to register a golang.sucks domain to list a few links.

                                                  That https://www.get.sucks/ is atrocious btw. It literally says right there on the front page:

                                                  Protect your identity online so that no one can defame your name.

                                                  It’s not even “wink-wink would be a shame if anyone would register yourcompany.sucks to spread bullshit nudge-nudge”. Nope, right there on the front page: “buy our service now so you can stop illegal defamation”.

                                                  1. 5

                                                    This was a minor controversy a while back. Vox Populi was charging trademark holders thousands of dollars to register their .sucks.

                                                    1. 3

                                                      Imagine being such an unimaginative boring twat that you can’t think of anything better to do with $199 than to register a golang.sucks domain to list a few links.

                                                      Oh yeah I know, that’s why I posted this link. TFA is just a shallow dismissal of Golang, so oft-repeated that there’s even a .sucks domain that rounds all of the criticism up. The reason it gets upvotes is because people here dislike Go, which is fine, but reminds me of the things I find odious about Lobsters. Biases here are so strong that trite content gets upvoted while the community frequently praises itself for being a good discussion site. 🤷 Language criticisms can be done well, but this isn’t it.

                                                      1. 7

                                                        People can’t downvote things they disagree with unless they actively break site rules, so the number of upvotes doesn’t tell you what the general community feels. Two comments dunking on the article have more upvotes than the article itself, which I see as a sign that the general community isn’t a huge fan of this kind of content.

                                                        1. 4

                                                          Eh, outside of tallying up points, I think anyone who has used this site can agree that literally any article relating to “I did this cool thing in Go” or that even just has a neutral tone with regard to Go gets about a thousand replies about how Go is a bad language. This thread is definitely the exception. It’s probably >75% of Go articles on this site that turn into endless “well, actually, Rust is good and if you like Go you’re an idiot” threads. It feels like this article in particular was just obviously obnoxious on its face, so nobody is really bothering to defend it.

                                                          1. 2

                                                            There’s no doubt here. If you take a look at the distribution of posts by inactive-users, so folks who’ve exited the site, most are folks who post threads with tags involving Go and C. It’s obvious to anyone who’s looking.

                                                          2. 1

                                                            Two comments dunking on the article have more upvotes than the article itself, which I see as a sign that the general community isn’t a huge fan of this kind of content.

                                                            Yeah fair enough. I guess this is a consequence of a no-downvote policy.

                                                            (Though I will say, +14 on the score and +19 (at time of this writing of course) on the top-level comment means that almost 42.4% of the “viewers” on this thread (assuming viewers are bifuricated between both options which certainly is overly optimistic) does not make me feel good (wait until this changes and this entire parenthetical is useless lol).)

                                                            1. 4

                                                              I’ve seen much worse articles get upvoted much higher.

                                                              And I mean, it’s not like all the points in this article are necessarily bad either: Go is rather verbose, the error checks are controversial for a good reason, the lack of generics has been cited as a problem even by the Go authors going back over a decade ago, dependency management was an issue (but now solved). This is all true, and all fair points to criticize Go on.

                                                              It’s just that the author doesn’t seem to understand why things are the way they are, what trade-offs are involved, and why other approaches weren’t chosen. Plus, there’s some nonsense mixed in to it as well (Go doesn’t allow to “abstract the details into types and provide encapsulation” … ehm, yes it does). Plus, at this point the horse is long dead and buried, and the 6th generational decedents of the horse are being beaten.

                                                              It all makes it rather tiresome.

                                                    2. 5

                                                      It’s good for programmers who too smart for their own good.

                                                      Yes, it’s easy to use and easy to read. It’s possible these things are more important than concision, even to some smart people.

                                                      1. 6

                                                        The takeaway shouldn’t be “programming languages are for REAL PROGRAMMERS like Mel, who know what a monad is” - it’s that Go is such a dull blade it hurts the productivity of workman programmers trying to get done; i.e. constantly typing if (err != nil).

                                                        If you want an example of how you can do the good PLT shit in a mainstream, pragmatic, workman’s language, I think C# is a great example. The average enterprisey programmer doesn’t need to understand the minutae of generics, but a List<string> is far better than ArrayList and dealing with covariance. Likewise, there’s unsafe, but you’ll never need to know it exists until you need it, nor will not knowing it harm you unless you’re working on systems code. It handles the progressive disclosure of concepts well.

                                                        To elaborate further, Java shares a lot of the paternalistic “you’ll cut yourself on this blade” philosophy, and it ends up making the language even more confusing:

                                                        • Operator overloading is hard. Now you have to explain the difference between == and .equals.
                                                        • Value types are hard. Now you have to explain the difference between Integer and int.

                                                        Your simple language is no longer simple to explain. Then you get the other fun stuff like erasure-based generics and lack of unsigned. C# plucked the low hanging fruit on the “what’s wrong with Java” tree and dealt with the hard stuff later; to its benefit. All because people like Syme have a better outlook of the average programmer than Pike.

                                                        1. 3

                                                          Most Go programmers don’t really like the design philosophy of Java a whole lot in my experience, so there won’t be any disagreement on most of the actual points in your comment. It’s just confusing how you think this relates to Go beyond you claiming they’re both designed to limit footguns and then listing several Java-specific footguns that don’t apply to Go. You’ve demonstrated Java is a painful language to use (it is, you’re right, most Go programmers will agree; its approach to object orientation in particular is nightmarish enough that I come very close to writing “object orientation was a mistake” blog posts every time I’m forced to use Java) but you’ve then claimed this somehow means Go is too. None of the problems you list with Java have any particular analogues in Go. This is a very confusing comment.

                                                          I’m sorry you happen to like typing catch more than != nil but I’m happy I get to be the first to tell you that it’s only one extra character. It’s never been demonstrated to me exactly why typing err != nil every once in a while is actually all that traumatic. It’s comparable in code footprint to typing out try/catch, but nobody considers those horribly annoying, terrible, awful boilerplate that destroy your productivity as a programmer.

                                                          And as near as I can tell the idea that typing err != nil is a huge drain on programmer productivity is the only thing you actually say about the Go programming language here.

                                                          1. 2

                                                            I’m sorry you happen to like typing catch more than != nil but I’m happy I get to be the first to tell you that it’s only one extra character. It’s never been demonstrated to me exactly why typing err != nil every once in a while is actually all that traumatic. It’s comparable in code footprint to typing out try/catch, but nobody considers those horribly annoying, terrible, awful boilerplate that destroy your productivity as a programmer.

                                                            I don’t want exceptions, I want discriminated unions and pattern matching to make it less tedious. I’m not a smart person that can tell you about category theory, but I know it’s useful.

                                                            1. 1

                                                              Oh, okay, well that’s valid, I suppose, although in the general use-case for pattern matching in most languages it’s equivalent to sugared-over switches. I only referred to try-throw-catch because the only language your comment expressed admiration for was C#, which to the best of my knowledge uses try-catch. Which raises the question of why you like C# and don’t like Go if the only criticism you actually brought up of Go is in relation to something you don’t seem to disagree is equivalent to the way it’s done in a language you claim to like.

                                                              1. 1

                                                                I have many qualms with C# (mostly related to its current direction), but I was mentioning it in terms of a language intended for median programmers that trusts them with complex tools through making the complexity manageable.

                                                        2. 1

                                                          I flagged this as broken link (could not find any alternative that fits better) because I only see a paywall and cannot read the article. Anyways, I haven’t had any high expectations since this is an article on medium.com .