23 ms·

Lies we tell ourselves to keep using Golang (2022)

• neonate 2y ago
  Should be called "Lies we tell ourselves to keep Go-ing"
• SomeoneOnTheWeb 2y ago
  The title lacks a (2022) Otherwise great article :)
• gnabgib 2y ago
  (2022) Discussions at the time: (130 points, 148 comments) https://news.ycombinator.com/item?id=34188528 https://news.ycombinator.com/item?id=34188528 (748 points, 544 comments) https://news.ycombinator.com/item?id=31205072 https://news.ycombinator.com/item?id=31205072
• voidUpdate 2y ago
  I really wanted to like go, and I tried to write a discord bot using it, but the very opinionated brace style (which isn't the one I prefer to use), and the fact that I struggled to much to try and split my code across two files kinda turned me off it. In the end I just went back to python
  • chikere232 2y ago
    Python has the most opinionated brace style though
    • josefx 2y ago
      You can abuse list comprehensions to enclose your code in [ ] instead of having to deal with all that whitespace.
      • chikere232 2y ago
        oh that's evil :)
  • voidUpdate 2y ago
    Genuinely curious, why am I being downvoted? Did I say something wrong?
    • WesolyKubeczek 2y ago
      Probably just your opinion being shallow. I mean, come on, coming to Go and of all things complaining about brace style? Coming to Python and of all things complain about syntactically significant whitespace? Coming to Lisp and complaining about parentheses? This is so old.
  • linhns 2y ago
    Of all the things you can complain about the language, how could you choose the thing that Go got right? It's K&R style is probably the best.
• devjab 2y ago
  This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take explicit error handling which happens exactly where the errors occur every day. You can argue that Rust does it in a more elegant way, and I prefer it for personal projects. For big projects with a lot of developers of various skill level joining and leaving I think Go’s philosophy is one of the sanest approaches to error handling in the modern world. Staying in that lane. In my part of the world Go is seeing adoption that no other “new” language has exactly because of its simplicity. It’s not the best language, but it’s often the best general purpose language because it has a lot of build in opinions which protect you from yourself.
  • XorNot 2y ago
    When I started trying to teach myself Rust, the error handling story fell apart on me very quick. Like as soon as I wanted to try and get sensible reporting in their, suddenly we were relieving libraries, adding shims and fighting mismatched types and every article was saying the same thing: haha yeah it's kind of a problem. I'm very, very unsold on explicit error handling compared to exceptions for practical programming. The number of things which can error in a program is far larger then those that can't.
    • lkirkwood 2y ago
      I felt the same but after switching to anyhow and thiserror in pretty much every Rust project I work on I find it quite painless. It's not ideal to rely on crates for a core language feature but I never find myself fighting error types anymore. Have you tried those crates? Do you still hold that opinion?
      • masklinn 2y ago
        You don’t need crates for it, anyhow is basically a better Box<dyn Error>, if you just want the error signal you can use that. The main thing missing from the stdlib fur this use case is I don’t think there’s anything to easily wrap / contextualise errors built in.
• bowsamic 2y ago
  The author's last post they referenced is a bit bizarre. I don't think that some overly simplified and error prone std library APIs is a particularly compelling reason to dislike a language. I didn't read the entire thing though because it was extremely long
• fire_lake 2y ago
  > Because they're Go experts, they know the cost of using Go upfront, and they're equipped to make the decision whether or not it's worth it Well maybe not. If I’m an expert in only Java 6, I might not be aware of all sorts of useful features that other languages have, such as sum types, traits, type inference… I only know one side of the trade off. I might be vaguely aware of those ideas and dismiss them because I can’t imagine how they would fit in my Java 6 workflow. And yet when some of them arrive in later Javas, I begrudgingly use them. Years later I can’t imagine how I ever lived without them! We’ve seen this play out so many times. Remember when lambdas were just for weird functional languages?
• troupo 2y ago
  Even async in Go isn't that good, ultimately. You can't monitor channels, you can't properly react to errors, you can't shutdown and restart them. A panic in a channel will kill your program. Etc. It's "we learned about green threads and didn't bother to learn anything else" approach (also prevalent in many other languages)
  • p_l 2y ago
    It's more that it's CSP from early to mid 1990s, over which Go just added syntax sugar
• WesolyKubeczek 2y ago
  The article is great. The bigger picture, of course, is that it’s always “pick your poison”. On one hand, say, I love operator overloading, I love how Python does it (once you satisfy an interface, its operators Just Work). On the other hand, I can appreciate the choice not to do it at all because half of the ecosystem will do it, and another half won’t. Also, it would require implementing function overloading, and it is a can of worms. Or generics and rich type systems, which all come with their own tradeoffs. I hear that Rust cajoles you into tinkering with the type system, and wach tweak requires refactoring of more codebase than anyone would like (don’t take my word for it, it’s just what I heard from a few different sources). I know that Nim is so expressive that it can be annoyingly trivial to be too clever and run into a valid edge case that will make the compiler barf and die. Go sidesteps the issue by not wading into that territory, and that may be perfectly okay, albeit verbose. It’s always picking your poison, so I guess check your tolerances and allergies so it doesn’t kill you before you get the job done…
  • thaumasiotes 2y ago
    > I love operator overloading, I love how Python does it (once you satisfy an interface, its operators Just Work). Is this different from other styles of operator overloading? Why does it matter whether, when I want to overload the + sign, I need to define a function called `__add__` or `operator+`?
    • WesolyKubeczek 2y ago
      For me it's easier to introspect, fewer unexpected corners. Contrast this with operator overloads which you can put literally anywhere.
• akira2501 2y ago
  > I've mentioned "leaving struct fields uninitialized". This happens easily when you make a code change from something like this: Really? Are you not using gopls? It absolutely will warn you about this. And the mutex case. And a lot of the other similar criticisms. > Go not letting you do operator overloading, harkening back to the Java days where a == b isn't the same as a.equals(b) In languages that have it I've never used operator overloading to produce anything good or that was obviously better than just using methods. > The Go toolchain does not use the assembly language everyone else knows about. Honestly I've never noticed or had to care. And you can build plenty of things that don't require CGO. The whole "gnostic" tone in language articles on HN is becoming overbearing. There are parts of the language to criticize but couching it in this "lies _we_ tell ourselves" and somewhat kitchy writing that presents minor matters of taste as fully existential issues makes this an unsatisfying read.
  • rvense 2y ago
    > In languages that have it I've never used operator overloading to produce anything good or that was obviously better than just using methods. I used a Scala library for S3 once that overloaded + to mean upload. var bucket; var file; bucket + file; Which is obviously bad and unnecessary. It's really a feature that should be used very rarely by those who make basic libraries, but there it can make a lot of sense - data structures, numeric types, etc.
    • monksy 2y ago
      That says more about the library design more than it does about the library. There are much better examples of the operator overloading for example cons: item :: item2 Later you can break that down in pattern matching.
• afiodorov 2y ago
  Not sure why Go is compared to Rust all the time, whilst most appropriate comparison is Java.
  • kybernetikos 2y ago
    I think this is exactly the right way to understand Go - it's targetted at building servers in environments where having strong consistency of code and a short ramp up time for junior engineers is valuable - i.e. it's perfect for all the big corp scenarios that Java was used for. I think maybe the more common, but less helpful comparison of go vs rust comes from the fact that they are both part of a new wave of languages and that they both default to producing staticly linked binaries.
    • monksy 2y ago
      > consistency of code There are many stylecheck tools that should be apart of a good stack. Accepting the creator's style is putting a lot of weight on their opinion. Most organizations have their own preferences for good reason. > short ramp up for junior engineers Junior engineers aren't a place you're concerned on being productive. Most of the time at that stage in someone's career they should be learning more, getting up to speed with professional practices, tools, and trying to learn code bases+patterns. Ramp up time for a language is a very minor consideration. Both of those things have very little to do with server environments. Bigger corporations struggle with Go's module system and forced reliance on seperate repos for separate modules. (Can you bundle multiple modules in the same repo.. yes but you're going to have a bad time)
      • kybernetikos 2y ago
        > Both of those things have very little to do with server environments My experience of bigcorp is that they need lots of servers (http is the modern bailer twine) and want developers to act as far as possible as indistinguishable resource. They will have rotating, high churn, globally distributed teams of vendors, contractors, consultants, internal staff and the teams will encompass a vast range of skill levels and abilities. Some languages amplify skill level disparity, some attenuate it.
• mjevans 2y ago
  There _are_ two problems with Golang that I _would_ like to wave a magic wand and fix if that was a power I had. 1) Sum types (E.G. C/C++ union types) - Yeah, something similar to that should exist... it's syntax sugar over #2 2) 'casting' / reshaping perspective on data ; as long as something has the same struct size a programmer should be able to tell the compiler 'but this is actually that'. Which also implies a way of fixing the layout of a given data structure. I figure that's why Golang doesn't allow this already. Yeah, 24 bytes (len, cap, pointer) per slice (dynamic array) has a cost, but if that really gets your goat use a fixed size array, or pointer/reference to such [n]thing. 3) Seriously, for a slice, make it like a map, a pointer/reference to a len,cap,blob - so that when I pass a slice by value I pass the WHOLE slice, not a COPY of len and cap and a reference to the slab. Current golang has the worst of all worlds with passing slices around, in that changes mutate, UNTIL it's resized or manually copied. The current design has the behavior it does to support slices of slices, which requires the pointer to the blob. A more complex scheme of a container behind the slice, and references to that could also work, but would be an entirely different datatype.
  • CharlieDigital 2y ago
    I started learning Go and when I got to the chapter on slices is when I dropped it. I can't put my finger on why it was so off-putting, but it just left a bad taste.
    • mjevans 2y ago
      It's exactly what I described in point 3 as 'the problem'. Maps 'work' because as a programmer you're aware of how expensive it is to copy a whole hash table, and it makes sense that a pointer to the thing is the whole thing. So it's an exception, but one _clean_ exception that just behaves consistently. Slices are horrid in that they SOMETIMES work the way someone who passes by value expects, and that's the same for both NOT updating AND Updating. This is because the management stage is passed by copy, not reference, but the backing data IS a reference, which initially is copied. That leads to in-place overwrites when no change in size has happened. It leads to appends that do get written but not reflected in other copies of the slice, and then if there's a need to re-allocate it leads to even the updates not updating the other copies of the slice. Slices are the most beginner un-friendly part of Golang.
• jamiejquinn 2y ago
  Seems like Zig is actually meeting much of the writer's expectations for good language design. Although I'm still not wholly convinced by it's move from LLVM and hell-bent desire for incremental compilation.
• fabian2k 2y ago
  I liked the idea of a language with minimal syntax that is easy to learn and easy to understand because the code is forced to be straightforward. It didn't work out that way to me in practice. It's a bit too low level for many use cases in my opinion, and that does get in the way somewhat. It also works against the "easy to learn" part unless you start with developers familiar with low level programming. I also found some types of library code surprisingly difficult to read, especially when empty interfaces where used. The standard library was great though, it covered stuff that others don't and it just worked out of the box.
• rob74 2y ago
  Oh well, here we go again... (2022)
• serbuvlad 2y ago
  I love Go, so I am biased. However, the beautiful thing about Go is that it doesn't even attempt to prevent classes of bugs by making them impossible. It's a car with ABS but no lane assist, with power steering but no collision detection. Out of all the bugs which Go permits I have yet to see one which could survive in production for some time without being discovered. Almost all of them would cause a failure the first time a segment of code is run.
  • ViewTrick1002 2y ago
    Instead it is a plethora of footguns which are attempted to be managed through convention. This post is always a scary read: https://www.uber.com/blog/data-race-patterns-in-go/ https://www.uber.com/blog/data-race-patterns-in-go/
• jchw 2y ago
  Every time I read a critique of Go, I feel the same way: I'm still going to continue to use it anyways. The reason why I am going to continue to use it anyways is because while I understand that it has plenty of easily documented issues in theory (and that people regularly do actually run into in practice), I still find that it is one of the better programming languages in practice anyways. Some of the things that people commonly list as shortcomings I don't agree with (I like the explicit error handling everywhere) and for other things... I often agree, but it doesn't bother me much more than the shortcomings of other programming languages, of which there is certainly no shortage. I guess I feel bad for people who are particularly sensitive to the areas that Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives. The truth is though, I don't use a bunch of rationale about what is the best programming language to choose which one to work on for a project, I choose a language that I feel works well for me, that I feel I can consistently write good software in, that feels, well, nice to work in. Being a person that values correctness, I do sort of wish that language could be something more like Rust, but for now, it's just not, though it's not like I hate Rust, it's just not what I reach for in a pinch. Enough has been written about how terrible Go is by this point. At least now I know what it's like to have been a fan of PHP a few years ago! (That's an exaggeration, but it's not that big of one in my opinion.)
  • pif 2y ago
    > I choose a language that I feel works well for me Which is the wisest choice for everyone. Golang is only a problem when a manager imposes it on you.
    • vasco 2y ago
      "Manager imposes it on you" just means you work in a team rather than alone. You can pick whatever you like for side projects, of course you're going to use whatever your team uses otherwise.
      • pif 2y ago
        [flagged]
• kgk9000 2y ago
  The superpower of go is goroutines and channels. The kryptonite of go is its limited libraries. Go is a great choice for many concurrent applications. I couldn’t finish reading the article because it lacked focus.
• pif 2y ago
  [flagged]
• vander_elst 2y ago
  Currently onboarding to go. For me personally, it's too opinionated e.g. for: error handling, mutability, unit testing, naming conventions, lack of features like sum types. As a new joiner, some things have a "religious" feeling, like: the go gods have given us THE language and we must use it their way, without questioning too much. I have the feeling other languages are less opinionated and this allows for more ergonomics and comfort when developing.
  • chikere232 2y ago
    I suspect it's designed that way intentionally. It's a language built to make it hard for new joiners to mindlessly add complexity, as the language itself will fight you. It makes it hard to add dependencies that aren't very visible and vendored in, it makes it hard to change how the language behaves with overloading, preprocessor magic or macros, and so on. It's built to fit Google specifically, with their army of new grads, and deep investment into reinventing all the dependencies themselves, and having a huge monorepo. If you're not google, you're gonna have a bad time, which is also good for google.
• a-french-anon 2y ago
  One of my biggest beefs with Go and dozens of other languages is: static typing without a sufficiently developed type system is masochism. If I can't get at least ADTs and parametric typing, give me gradual like CL.
• cedws 2y ago
  Go is just an evolution of C, it works at a higher level but shares many ideas. If you can’t appreciate the simplicity of C, then you probably won’t appreciate the works of Bell Labs, and I have lost all interest in the debate.
• misonic 2y ago
  While the article raises some valid critiques, it often overlooks the fundamental tradeoffs that make Go successful in its niche. Go’s simplicity is not a flaw but a deliberate choice, enabling rapid onboarding and maintainable code for large teams. Its explicit error handling may seem verbose but ensures clarity and avoids hidden surprises common in exception-heavy languages. The complaints about ecosystem isolation and tooling ignore the fact that Go provides powerful built-in tools like pprof and dlv, which are better suited for Go’s runtime than general-purpose alternatives. Go isn’t trying to be Rust or Python—it’s a pragmatic tool for scalable, performant systems.
  • euroderf 2y ago
    This. And there is one technique that would help in this. Too often I see code like "xyz := pkg1.SomeFunc(a, b, c)" that makes xyz's type non-evident, especially when interfaces are involved. Please write Go code like var xyz pkg2.SomeType xyz = pkg1.SomeFunc(a, b, c) My 0.02€, YMMV.
    • maleldil 2y ago
      I don't get it. Why not use a code editor that shows the inferred type on hover?
    • spirit-sparrow 2y ago
      That should not be an issue, unless the code is written in notepad. As for interfaces, a better approach is to return struct and accept interface in your functions wherever it is possible.
      • linhns 2y ago
        Sometimes it's better to to return interfaces, like contract style programming.
• Jare 2y ago
  > Evidently, the Go team didn't want to design a language. This excerpt should be enough for you to know if you will find the article insightful or useless.
  • fransje26 2y ago
    And this is why I normally start by going to the HN comments before reading an article.
• bvrmn 2y ago
  > I've started caring about semantics a lot more than syntax, which is why I also haven't looked at Zig, Nim, Odin, etc: I am no longer interested in "a better C". A strange take. Zig, Nim and Odin are about fixing semantics not to bring syntax sugar.
• elcritch 2y ago
  > I've started caring about semantics a lot more than syntax, which is why I also haven't looked at Zig, Nim, Odin, etc: I am no longer interested in "a better C". Well the post rambles a fair bit, IMHO. The whole bit about Go being “accidental” is BS given that Rust is just as much “accidental” in its origin and design. One thing stuck out to me is that Nim certainly isn’t a “better C”. It has a GC or you can use reference counting. You can use it as a better C if you really want. Nim’s type system avoids many of the problems that Go has, though it’s not nearly as pedantic as Rust. At the end of the day lots of software has been written and shipped in Go which runs fast, has minimal downtime, generally seems effective, and has minimal security issues. I’d argue (much) fewer software projects have been shipped in Rust. Firefox is still 95%+ C++.
  • RMPR 2y ago
    > I’d argue (much) fewer software projects have been shipped in Rust. Firefox is still 95%+ C++. It's funny but this comment reminded me of this tweet[0] from 2022 (!). I don't have a horse in this race as I am happily using Python and C++ at $DAYJOB. I'd argue that even if much less software has been written in Rust (source?), it still qualifies as "lots of software has been written and shipped" with it. Not to mention all the investments by $BIGCORPS in the language. 0: https://x.com/m_ou_se/status/1599173341117435905 https://x.com/m_ou_se/status/1599173341117435905
• KingOfCoders 2y ago
  Go: "I'm a simple language!" User uses Go for some time. User: "I hate you, you're a simple language!" Perhaps it's because I'm 50+, I love a simple language. I feel the "critique" is not very balanced, and I view judgements that are not balanced as weak, as everything in technology is about tradeoffs. I of course come to a different conclusion: https://www.inkmi.com/blog/why-we-chose-go-over-rust-for-our-startup https://www.inkmi.com/blog/why-we-chose-go-over-rust-for-our...
  • richbell 2y ago
    I wish the discourse that Go is a "simple" language would die. Despite its veneer, once you start writing Go it quickly becomes apparent that it isn't simple. Hidden complexity and footguns are abundant (e.g., https://archive.ph/WcyF4 https://archive.ph/WcyF4). It's nevertheless a useful language, and I use it quite a bit, but it's not "simple".
    • jonathanstrange 2y ago
      I have no idea why anyone would say it's not simple, it's super-simple. Learning how duck typing works with interfaces and how to use it is perhaps the only hurdle. In my experience, only certain BASIC dialects like VisualBasic are simpler.
      • LinXitoW 2y ago
        I think the sticking point is what people mean when they say simple. To me, and likely to many saying Go isn't simple, simple is not a synonym for easy. Go is easy, but it is not simple. For example, solving the problem of generics in a generic way from the start so the same problem can be addressed in the same way everywhere, would be simple, but maybe not (as) easy. Contrast that to giving the runtime/standard library a special exception with maps and lists. That's easy, but not simple. People used to literally use code generators or weird UTF-8 characters to fake generics, that's not remotely simple.
        • 2y ago
• jonathanstrange 2y ago
  This is a silly article, though I can only speak for myself. First of all, language design is pretty much the last reason anyone should consider when choosing a language. For me as a solo developer who needs to get results in time, the main criteria for choosing Go were compilation speed, development speed, general tooling, and third-party support. Especially the latter is extremely important; I cannot develop all kinds of libraries like e.g. an Excel or Word document parser in-house, I have to use whatever MIT-licensed libraries that are there. I've developed in all kinds of languages in the past: Pearl, Java, C++, REALBasic, PowerMOPS (a Forth derivate in the 90s), Ada, Rust, Python, Java, Racket and various scheme dialects, CommonLisp, ObjectPascal/Lazarus, just to name a few. Out of these, REALBasic was by far the one in which I was most productive. Alas, it became unaffordable and the vendor lock-in really burned me. No more commercial languages or IDEs it is for me. If Ada had a garbage collector, I would probably use it even though the development time is a bit longer. Likewise, I'd love to use CommonLisp and think it's the best dynamic language. But it simply doesn't have enough 3rd-party support, and I'd also be wary about how it runs on mobile platforms. I've got to say I'm pretty happy with Go so far. Is it the ideal language for me? No, because full OOP with multiple inheritance would make my life much easier. But it works, is easy and fast to develop in, and the results speak for themselves. I have no problems with bugs. The explicit error handling may be a bit cumbersome but it forces you to think about and deal with every error, unlike people in languages with exception system who often ignore errors until so far up the call chain that they don't even know what actually happened any longer. I don't see the point of that. If you have an illegal state of an object it doesn't matter if you call the object nil or DefunctInstanceOfBla, you're going to have to deal explicitly with the illegal state. Notably, C# was also in my final selection of languages. For my principal use case - distributed client/server applications with GUI - Go's GUI options were not so stellar and I was thinking about using C# instead. AFAIK, C# is very suitable and a great language, too. I decided against it because of the C#'s bizarrely complex runtime library situation and naming schemes (WTF?) and simply because I would have had to learn it first and already knew Go fairly well. Beware the language aficionados and purists. I used to be one of them, too, advocating Scheme & CL. However, in the end purely practical considerations are always more important. Programming languages are tools for getting things done.
• vrnvu 2y ago
  “An idiot admires complexity, a genius admires simplicity, a physicist tries to make it simple, for an idiot anything the more complicated it is the more he will admire it, if you make something so clusterfucked he can't understand it he's gonna think you're a god cause you made it so complicated nobody can understand it. That's how they write journals in Academics, they try to make it so complicated people think you're a genius” ― Terry Davis Please note, no offense intended, I just like this quote to describe Go success.
• PittleyDunkin 2y ago
  I find it fascinating the extent to which language choice makes a programmer emotional looking around at these comments.
  • Mawr 2y ago
    Well, the post title implies people using Go are delusional, so that's expected. Starting a conversation by calling someone stupid isn't likely to end up productive.
• rednafi 2y ago
  I want to build things and could care less about intellectual masturbation. It was built for proletarians like myself. I like Go because it's neither Rust nor Python. But I do understand that there are times when having some nice abstractions over common patterns doesn't hurt. At the same time, Go has come a long way over the years.
• k_bx 2y ago
  When the article started the part "but Tailscale still uses it" I almost felt watched
• RandomThoughts3 2y ago
  The article is arguing that Rust is a better choice which is laughable. Go is a small GC-ed language. Rust is an obnoxiously complex language with strong emphasis on memory management. I don’t see any projects where you could legitimately hesitate between the two. Truth be told I quite like Go. It’s small and simple. It does the job. You can onboard people on it quickly and in practice with the toolchain you don’t run into the issue mentioned. Would I rather use Ocaml most of time? Of course but it doesn’t have the same ecosystem. Would I rather use Rust? Heck no, I’m not going to deal with the borrow checker and life cycles if a GC is fine.
• poulpy123 2y ago
  It's weird. At a time I was looking for a "better" python. Something simpler and safer than C/C++ but faster than python and more importantly that can produce a single binary. So I looked at everything from Rust to obscure language like Hare. Go should have been the obvious choice but for a reason I don't understand I dislike its syntax. For Rust I understand: it uses a lot of special characters that aren't easy to remember and to type with a non qwerty keyboards (plus other unrelated pain points). For the different lisp, it was the parenthesis and the reverse polish notation. But for Go, I'm unable to rationalize why I don't like it. For the anecdote, I settled on compiling my python code with nuitka. No speed gain that I'm aware of but I can now provides a binary. I'm also looking more and more at C# because of its progressing AOT compilation and although I dislike the verbosity of its base mode and the fact it's so tied to windows. I liked a lot nim and crystal but the small community was a barrier, although I'm really impressed by what nim is managing to do with such a small community and it may me think it's an excellent language (I will try to motivate myself to pick up one of the language I mentionned above also)
  • poilcn 2y ago
    >and the fact it's so tied to windows Dotnet Core is not tied to windows except for certain frameworks like wpf (and there are alternatives for it that work everywhere), credential store. And it's actually really good to use these days.
    • CharlieDigital 2y ago
      Yup, common misconception for folks that haven't used it in a decade. Our team uses C#. We dev on Apple silicon Macs. Some use Rider, others just use VS Code. We build on Linux via GitHub Actions. Ship to prod running AWS t4g Arm64 instances. C# to me is like TypeScript++. The language, syntax, and core constructs are close enough that anyone with a good handle on JS and TS can pick it up easily and be productive.
      • SirGiggles 2y ago
        Sorry for the segue, but how your team's experience with C# on VSCode? Any recommendations for plugins? I've heard of a lot of people recommend Rider but not much, aside from neonsunset, talk about VSCode.
• atemerev 2y ago
  I wish I could take the Rust pill like everyone else and be happy. I am not a stranger to the programming world. I am fluent in Python, Java, Scala, Erlang. I can write acceptable Haskell and C++ and Common Lisp. I am well versed in functional programming (though I don’t hate OOP — it is still a good thing when done correctly, and I am a big fan of Smalltalk). However, for some reason, I am completely unproductive in Rust. It always fights me. There’s always something I want to do (graph structures? spliced lists?), and it’s always “you don’t need that” and “it’s not the Rust way”. There’s always explicit lifetimes and you miss something and you need to rewrite huge swaths of your code. And nothing is refactorable. It’s not even a good functional language, there are no persistent data structures, and it’s a pain to make them, and no ways to express yourself functionally like I used to do with Scala. But apparently, everyone and their dog like Rust and are insanely productive in it. What am I missing?
  • gspr 2y ago
    I do miss several of the things you list, too, especially (safe) self-referential data structures. But Rust is a fantastic compromise solution if your number one priority is to match the performance (or rather, performance possibilities) of C and C++, and have memory safety while doing it. If your number one goal is to be able to write memory safe ideomatic code that is entirely comparable to those languages, and then add some functional programming and lots of quality of life stuff to that, then it's pretty sweet. In other words: Don't think of it as rivalling the entry cost of Python or Java, or the expressiveness of Haskell or Scala. Try to think of it as a replacement for C++, with memory safety and piles of quality of life improvements. And then with a sprinkle of the other things on top.
    • atemerev 2y ago
      I am fine with C++ memory safety if I am mostly working with RAII and explicit move semantics when needed (it is not perfect, but it will get us through the night). However, fighting the borrow checker drastically _decreases_ my quality of life, and I couldn’t find the way to get myself to free flowing code as I had in other languages. Interestingly, I have the same feeling when trying to write something with Vulkan — the amount of ceremony and boilerplate before you even get to the first triangle is a huge barrier for my productivity. I want something more immediate.
• gigatexal 2y ago
  So what’s the alternative then to go?
• yapyap 2y ago
  Okay so I’m wondering, if you’re not in the Golang universe yet, what language is better to start with learning?
  • Lucasoato 2y ago
    I'm curious as well. Are there alternatives to Go in some fields completely dominated by it? (like Kubernetes controllers/operators)
  • k__ 2y ago
    Depends on what you want to do. Go's channels are probably awesome, if you need parallel computing. If you want to build in k8s land, you can't avoid Go. But besides that? Maybe, use Gleam or Elixir.
• sureglymop 2y ago
  Rust and Go are very different and I feel people want a middle ground that just doesn't exist currently. A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc. Syntactically, Gleam and Kotlin come somewhat close but not really. I like Rust but I do believe it is too complicated for many people who are capable of creating something but are not CS grads nor working as programmers. If you're only gonna use the language every once in a while you won't remember what a vtable is, how and when things are dropped etc. I understand that "the perfect language" doesn't exist but I think both Go and Rust brought amazing things to the table. I can only hope someone takes inspiration from both and creates a widely usable, simple programming language.
  • ForceBru 2y ago
    > A garbage collected relatively simple language that compiles into a statically linked binary and has a [good] type system Yeah! Pattern matching too. What are currently available languages closest to this? AFAIK, Gleam relies on a virtual machine, but otherwise seems promising.
    • blue_pants 2y ago
      Stretching 'currently available' a little, there's Roc lang [1]. Though still in development, you can use it for small personal projects. Another caveat is that it's a functional language, which could potentially hinder its wide adoption [1] https://www.roc-lang.org/ https://www.roc-lang.org/
  • fire_lake 2y ago
    Try F# with the new AoT compilation option and publish single file switch.
  • tessela 2y ago
    > A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc. Swift.
• baalimago 2y ago
  >After spending years doing those FFI dances in both directions, I've reached the conclusion that the only good boundary with Go is a network boundary. It works perfectly well with stdin/stdout as well, as seen in many LSPs
• edf13 2y ago
  Erm.. > As it happens, I am not a junior developer, far from it. Some way or another, over the past 12 years, I'd say that's isn't too far from it to be fair.
• im_dario 2y ago
  I remember it took a me a bit of investigation to make Ruby call Go functions, but it wasn't really hard: https://dario.cat/en/posts/portal-between-ruby-and-go/ https://dario.cat/en/posts/portal-between-ruby-and-go/ The argument about FFI and CGO was the most unappealing to me. If you really need to do that, it feels that at some point some decisions were made that weren't the right fit for the project. Also, I feel that many arguments in the article are potential pitfalls for unintended side effects I've experimented in other languages, like Ruby itself. Keyword arguments are nice, but I know that they've bitten me several times. Go forces the developer to be explicit about their intentions, that's why I also don't find something bad that your struct functions need to have the pointer receiver. It can be annoying when you forget, but that's what linters are for.
• 0x_rs 2y ago
  CTRL+F "rust", 24 matches, I had a feeling that would be the case. What does Golang, for the most part, have to do with Rust? I also find the following bit somewhat funny: >The success of Rust is due in large part to it being easy to adopt piecemeal and playing nice with others. And as if Rust itself didn't suffer from the same kind of imperfections one can find in Golang. So much for that "nothing new under the sun" back in 2012! But then it starts talking about the "rust shills" boogeyman, and one has to wonder if it's not trying to justify one's choices. (which is fine, anyway) And I agree wholeheartedly to each and every single one of the "lies" listed in the article, that you could very easily rewrite half of which to fit Rust, and the other half requires no changes to apply.
  • sapiogram 2y ago
    > And as if Rust itself didn't suffer from the same kind of imperfections one can find in Golang. Which imperfections are these?
• optician_owl 2y ago
  The worst thing - default values as a solution for absent values. What can go wrong with implicit value assignments?!
  • bobertlo 2y ago
    Would you rather have undefined initial values?
    • optician_owl 2y ago
      I would. Not because it's something pleasant. There is a huge difference between no value and default value. I had plenty cases where I needed to distinguish them because absent value is a violation of a contract. Defaults are not a solution. And more. Defaults bring their own problem. Chosen values are neutral only for some operations. The most simplest case - int default value is 0, but it kinda "works" only for sums. With nulls you'll get an error in production. With defaults discovery of the error is postponed even more. It's literally the same as making up values ignoring clients will (and this decision even not ours but designers of the lang). Defaults are implicit. It's simplifies mistakes due to human factor.
• iamcalledrob 2y ago
  There's a lot of valid critique of Go, but I've never found anything like it that lets me build lasting, high quality, bug free software. Explicit error handling means that I actually think about and handle errors. No surprises in production. No random exceptions throwing deep inside some dependency. I've been running some Go services for years with no crashes. The brain-dead simplicity means I am not tempted to waste time being clever. The tooling means my code is trivial to build, even years later on a new machine.
• voodooEntity 2y ago
  Well, i feel like this is the 100th article i read about why golang is bad "mkay". For my personal background, i started with golang about 6 years ago and im using it mainly for private and open source projects. Yes golang for sure isn't perfect, but what language is tho? I think the major point is - the language you use should match your use case. If it doesn't it will always feel "bad" or you will more likely tend to find points why the language isn't perfect (for your needs). Sure you could write a website builder in ASM or you can write an Operation System in Javascript - but why should you? Just look at your use case - check your needs and decide what language fits the best. If its golang? Fine use it. If its not golang, than don't. But don't take a language and try to match it on "everything" and than complain that it doesn't do the job - because no language will. Thats my 5 cent's on this topic....
• kif 2y ago
  My biggest problem with Go is readability of some projects. In many cases, the code is split across files in an unintuitive way, and you can only navigate with the help of an IDE.
• ThinkBeat 2y ago
  [meta] Does anyone else color schema? I found the blue links hard to read with the dark background. Or maybe the links are left to the default for the browser to decide. Either way I would prefer an easier to read color.
• shikck200 2y ago
  The author clearly does not weigh in on the "whys" some things work in Go like they do. So, adding an extra struct field results in the base value, and by design this should be used as a base default. The go proverb make base values useful goes hand in hand. Obviously functions are not the same. And calling function with the wrong args is a compile time error. There is also CI check that check for this use case. Overall this seems like a comparison to Rust, and its obvious they are not same same. Apples to Oranges.
  • Joker_vD 2y ago
    Rust is also not the same as C, and therefore shall not be compared to it. Crabs to Cats. Of course they are not same; that's why we want to compare them in the first place: were they the same, there'd be no need to compare them at all. Since, you know, they would be same and have no differences.
• impulser_ 2y ago
  Every time I work in a different language I'm always wanting to go back to Go even if it's not the perfect language. I just love the fact that it literally just works. You install Go, you download code, and write code that's it. No figuring out what version, runtimes, configurations, build tools, package managers to use. Just install and Go. I think maybe Rust is the only other programming language that provides the same experience. Maybe these are just lies I'm telling myself, but every time I use Python, Typescript, or Java I dread programming because I just want to write code and I'm often debugging things or figuring out related to configurations, package managers, build tools and versioning.
  • Cthulhu_ 2y ago
    This is the power of Go, its integrated toolchain. It makes interop more difficult like the article says, but in my personal and limited experience that's not a frequent use case.
  • linhns 2y ago
    This should be the most celebrated aspect of Go, which Rust adopted, along with channels.
• icar 2y ago
  I just want to say that I started working with Go a few months ago at my new work, and I've been disappointed. The type system doesn't even have union types, and the implicit implementation of interfaces has caused a couple headaches that I would've never had with explicit languages such as Typescript (strict). At this point, I prefer strict Typescript with very restrictive ESLint rules than Go. I don't understand how this language was pushed for web servers, it lacks common constructions to represent very frequent data types in API design. Also, the whole go func(){} and channels is nice if you are coming from a language with worse ergonomics (C?), but when doing multiple web requests to other places and wanting them to happen in parallel, it gets messy fast. It lacks a pretty abstraction -- I very much miss an await-like construction which uses wait groups under the hood. So, I very much agree with the post. I like errors as values, though.
• spirit-sparrow 2y ago
  I wonder what makes someone go such a great length to bash a language, any language. I say bashing, because even the few valid points in the post are not written in a constructive style. After all is there a language that can't be criticised? Is the post written to make one feel better having a failed a project the language? (It's not me, it's the language) Or is it the failure to understand that not everyone thinks / works the same and what one finds unacceptably bothersome, others barely notice? Languages that do not cater for a real need would likely vanish on their own, they rarely need help. As for Go, despite the differences compared to "more sophisticated" languages it works brilliantly for the projects I've encountered. I hope the author is not forced to work with Go though. For the rest of the community, we keep churning out services, giving our feedback to the Go team and seeing the slow evolution of the language without breaking our stuff in production.
  • deleted 2y ago
    [deleted]
  • deleted 2y ago
    [deleted]
  • pas 2y ago
    > what makes someone go such a great length to bash ... """ Inherent complexity does not go away if you close your eyes. When you choose not to care about complexity, you're merely pushing it onto other developers in your org, ops people, your customers, someone. Now they have to work around your assumptions to make sure everything keeps running smoothly. And nowadays, I'm often that someone, and I'm tired of it. """ > [Go] works brilliantly for the projects I've encountered. Of course, C, C++, PHP and JavaScript works too! Of course many many many things "work" in our world. Of course just adding one more lane works too, of course police states work too! Yet something else would work even more brilliantly?
    • eikenberry 2y ago
      That quote sounds like an argument against Rust, not GO. Rust is a complex language and that complexity doesn't go away if you close your eyes to it either. All complexity adds to project complexity.
• gwd 2y ago
  His criticisms include: - No sum types - Default zero values - "Go is an island": Fully integrated toolstack makes it easy to use the same tool top-to-bottom, but makes it difficult to use with any other project None of those are lies; apart from the first, they all have advantages and disadvantages. Sure, there's an advantage to forcing you to specify every value, but there are disadvantages too. And sure, there are disadvantages from Go being an "island", but he lists some of the advantages right there in his post. If those are deal-breakers for him, then sure, go use something else. But lots of us like the advantages more than we dislike the disadvantages.
• stefantalpalaru 2y ago
  [dead]
• gregwebs 2y ago
  I’m successfully using Go and agree with the author at the same time. For me it’s not a choice between Go and Rust- Rust is not as productive for high level code because every API maximizes performance. Since this article was written Go introduced generics which does solve some of the complaints. The rest I mostly solve with linters, libraries, and conventions. Go has a syntax that is well designed (arguably one of the best) if you’re aiming for familiarity with C style syntax in an imperative language. Other than that it’s a poorly designed language with by far the best engineering work having gone into things that aren’t actually the language per say (cross compilation, asynchronous runtime, GC, module system, super fast builds, etc). They wrote an ACM Queue article essentially stating that: https://cacm.acm.org/research/the-go-programming-language-and-environment/ https://cacm.acm.org/research/the-go-programming-language-an...
• Saphyel 2y ago
  Golang it's a huge career mistake. You can comeback in 5 years to this message to confirm the obvious.
• Mawr 2y ago
  [flagged]
• Sudheersandu1 2y ago
  One thing what i observed is any language you right ask AI to optimize in Rust..why its so much of a debate when scale comes. In 6months AI will make any rewrite possible with full context aware. So don't spend your energy on things that can be done by machines and focus on things which u can get deep on for distributing the software.
• Sudheersandu1 2y ago
  AI can rewrite any dream code which u write and putting ur brain on that is pure seless way of pointing start with some island as you pointed get to scale and in 6months every code can be rewritten how many ever time u want..tokens will be so affordable to run full context code base shift..don't worry about it just focus on distribution for ur product with the code you right..thats a good thing to worry about.
• tomburgs 2y ago
  > and most importantly, you adopted a language that happened by accident. Is the author implying that Go was created by accident?
  • gary_0 2y ago
    "Accident" is hyperbole, but IIRC Go evolved out of Google's internal high-performance HTTP server tooling, so they didn't initially set out to create a general-purpose programming language.
• rd1000 2y ago
  It really does not matter. There are so many critical services running off of Go. You don't wanna use it? Go to hell.
• Mawr 2y ago
  Context for those unaware: This article was a response to a 2022 HN thread [1] about the original article of the author's. Then the following discussion happened: [2]. First off, let's appreciate the fact the author has managed to write this humongous article in a day. That's some writing skill. And indeed, leveraging writing skills to unleash a flood of words in order to overwhelm anyone trying to respond is just the first tactic of many used by the author to sound more convincing, which is going to be the point of my post. I'm going to analyze each rhetorical device, fallacy, and bias present in the article. > The author is a platypus The point of this paragraph is not to present any arguments, it is devoid of them, but to elicit sympathy from the reader for the poor author who is clearly getting ganged up upon. Comments in the referenced HN thread did not in fact attack the credentials of the author in any way. See Appeal to pity [3]. > Mom smokes, so it's probably okay Lots of words here, but the gist of it is: > Or you can be horrified, as you realize that those complex problems only exist because Go is being used. Those complex problems would not exist in other languages, not even in C, which I can definitely not be accused of shilling for (and would not recommend as a Go replacement). Setting aside the validity of the technical arguments, the tactic used here is to imply that since certain other languages don't have the specific mentioned problems, they are strictly superior. In reality, had another language been used, the Tailscale team would simply be dealing with different problems. To riff off the C example, if Tailscale used C, they'd be dealing with memory safety issues instead. > The good parts A clever attempt at a lie of omission. First we list a tiny subset of the pros of Go, then we claim that this tiny subset is not enough to make up for the numerous cons. See Cherry picking [4] and Straw man [5]. > And since, just like C and Java, you do not get to decide what is mutable and what is immutable (the const keyword in C is essentially advisory, kinda), passing a reference to something (to avoid a costly copy, for example) is fraught with risk, like it getting mutated from under you, or it being held somewhere forever, preventing it from being freed (a lesser, but very real, problem). Here we see a thinly veiled reference to the main bias behind the article. Can you guess what language the author is implicitly talking about here? > Go is an island Nothing really interesting here, but it's worth noting that, just like the majority of arguments presented so far, this largely applies to most languages out there (but of course not to the language we're really talking about here). > All or nothing (so let's do nothing) The thrust is another strawman, quite simply nobody argues this: "It's not like you can prevent all problems anyway.". This section is only a lead-up to the next one anyway... > "Rust is perfect and you're all idiots" Huh, why do we suddenly have a tirade about Rust in what's supposedly an article on Go? If you correctly guessed earlier that this entire article is actually about Rust, congratulations. > Folks who develop an allergic reaction to "big balls of mutable state without sum types" tend to gravitate towards languages that gives them control over mutability, lifetimes, and lets them build abstractions. That those languages happen to often be Go and Rust is immaterial. Wait a second, language*s* with sum types, control over mutability, and lifetimes? So, Rust, Rust, and Rust? > Because function signatures don't tell you much of anything (does this mutate data? does it hold onto it? [...] Only Rust is good enough, we get it already. --- Overall, we have quite a few strong technical points here that could have made for a compelling article, but they're marred by copious use of fallacious arguments and blind fanboyism for a certain language. --- [1]: https://news.ycombinator.com/item?id=31191700 https://news.ycombinator.com/item?id=31191700 [2]: https://news.ycombinator.com/item?id=31205072 https://news.ycombinator.com/item?id=31205072 [3]: https://en.wikipedia.org/wiki/Appeal_to_pity https://en.wikipedia.org/wiki/Appeal_to_pity [4]: https://en.wikipedia.org/wiki/Cherry_picking https://en.wikipedia.org/wiki/Cherry_picking [5]: https://en.wikipedia.org/wiki/Straw_man https://en.wikipedia.org/wiki/Straw_man
• voidhorse 2y ago
  Go is great for a variety of projects. Smaller codebases, little cli tools, simple servers, etc. It has its quirks, as any language does, but it is foolish to write off an entire language when some of the very properties you dislike may actually be a good fit for the problem at hand. When engineers focus on language features they focus on the wrong things. Yes, languages like Java and Rust are fantastic for large codebases because generics and strong encapsulation become especially important as the number of engineers working on a project scales. Contrarily, Go would probably be a million times better for a small project of one to three staff that primarily revolves around a few well-designed data structures and basic array manipulation. In this context, the more sophisticated features of a Rust or Java are actually hindrances and end up making things more elaborate than needed. Languages are a resource and a tool, not an identity marker. Use the language that makes sense for your constraints. Programming is all about modeling problems. No language will do this for you and each one has features that help or hinder and some are better or worse form problems of different shapes. Learn about how computers and compilers actually work so that you are empowered to use a wealth of languages and can choose the best one for your project on rational grounds. Or, you can embrace Haskell and use the only perfect programming language to have been thus far invented :)
• bitbasher 2y ago
  I have recently started to port a large codebase from Go to Rust. I thought it was going to take more code in Rust, but I have been surprised at how much less code it takes. As of right now, the Rust version is 60% smaller in terms of LOC. I think a large part of this is due to error handling in Rust and the sugary `?` syntax which is so incredibly useful.. I can't count how many times I have done the following in go x, err := Foo() if err != nil { return nil, err } // or something like this I'm pretty sure a large chunk of the LOC reduction was in that alone. Though, a large chunk is also some crates that make a lot of boilerplate go away (serde, serde_json, etc).
• jonathaneunice 2y ago
  I see this false promise all the time: Simple tools are simple to use. NO. Not necessarily. Use a handsaw to fell a forest if you like, or a hoe to till 1,000 acres. But I will not. Tool simplicity will come back to bite you if the task you're trying to accomplish is complex or high-scale. And simplicity of design in no way correlates to simplicity of outcome, or of your workflow using the tool. Golang has, to be fair, more going for it than just its relative simplicity. But in many ways the OG criticism rings solidly true. The "we'll do just enough language features and tooling" becomes an abdication and an excuse in a complex world.
• blixt 2y ago
  I feel like the author is fed up with being disagreed with, yet makes very opinionated statements about how others should (or will, at some point in the future) feel. They make good points about problems in Go, but I gotta say they also make a lot of points that might never become a problem at all. I've written code that runs in production for 20 years now and every language I ever shipped software with, from ASP, PHP, and C# to Swift, TypeScript and Rust, one thing is always true: there's a pretty good reason the language was picked, and yet a long list of grievances. The reason a language is picked is most often productivity, some belief that software will ship more safely and often if we pick this language. Of course that belief can be uninformed and proven wrong later. But it's really hard to say, for any language, that "you will regret picking this language". Sure maybe you shouldn't pick PHP for your new startup backend because you'll have a harder time finding developers. Maybe you shouldn't pick Python because despite asyncio there's still that one call you accidentally did that will lock up your highly concurrent service. Maybe you shouldn't pick Java because it's got verbose factories and something about billion dollar mistakes. Possibly picking Rust is a mistake because your developer team will spend 80% of their time fighting the borrow checker. Picking Swift to do your backend seems rather odd, and C++ is too risky with all its undefined behaviors and segmentation faults. Beware of Node.js unless you're ready to dedicate beefy RAM instances to it. That is of course all hyperbole, I've seen productive code in all of the above languages. And I should add that many of them were not designed any more than Go was, to address one of the author's concerns. I've picked Go many times since it hit 1.0 and I don't regret it, even with production code that is over 10 years old. Go does concurrent processes and I/O really well. The GC works very well for long-running programs with lots and lots of individual goroutines. I also saw developers that had never touched Go enter the code base and make productive edits, which I consider a benefit of Go's simple design (or non-design, as per the author). I've also done similar systems in other languages, especially Node.js, Python, and Rust, but they haven't been as productive in my experience for this use case. Ironically code written in Rust did wake me up in the middle of the night more than Go did, possibly because it was harder to express the mental model the way originally intended, and instead the code was written to satisfy the computer's memory model. I would still use Rust every day for things where that matters more, but the author seemed to imply somehow avoiding Go avoids unexpected errors, but they happen in every language. TLDR: Programming languages live on because they make people feel productive. Maybe this feeling is aligned with the business needs, maybe not. But don't go saying that everyone should avoid a language entirely because of your personal experiences.
• amai 2y ago
  Sorry to spoil the party, but the future is mobile and none of your favorite programming language ( Rust, go, Python, Nim, Lisp, Zig, Smalltalk ...) is ready for this. The future will be Kotlin, Swift and Javascript and I already hate it.
  • zaptheimpaler 2y ago
    The present is already mobile but the backends serving those mobile devices run on servers. There's also no reason mobiles can't run Rust/Go/Python - Android already runs Java.
    • amai 2y ago
      You are right there is no reason mobiles can't run Rust/Go/Python. But actually they don't, because there is no infrastructure and no tooling to build mobile apps using these languages. And this is the big oversight of the creators of these languages. All these languages we love so much as developers will die. Not because they are missing generics or error handling or coroutines or a static type system or other nifty language features. They are simply missing tools to create mobile apps.
      • zaptheimpaler 2y ago
        I think you're vastly overstating the case saying these languages will die.. The majority of code we write runs on servers, even if its ultimately in service of a mobile/web client. Even if mobiles didn't support them, that doesn't mean these languages will die. The servers still have to run. Creating the tools to run them on mobile is a solvable problem. Rust is already supported in the Android platform [1]. It takes more work to write an application in a non-standard language but its doable. Just saying don't worry about every other language dying out because of mobile, that won't happen :P [1] https://source.android.com/docs/setup/build/rust/building-rust-modules/overview https://source.android.com/docs/setup/build/rust/building-ru...
        • amai 2y ago
• xlii 2y ago
  So I’m completely new to the Go but I have very specific need and I couldn’t fit it anywhere else: I want to orchestrate asynchronous, highly fallible tasks. I could use Rust but I feel I would drown in correctness of handling various edge cases over which I’d rather panic and wind down everything I can. Elixir/Erlang would also be an option, but getting it installed in specific version isn’t simple (and ASDF was guilty for long time of installing Elixir built on different OTP than defined one) and also problem lies in interacting with IOs, which also bring consequences. And so, yeah, Go is simple enough so that I feel confident that if aj get hit by a bus there won’t be enough magic so that it won’t be picked up by someone and it… works. After being in pull rope competitions with bash, sh, Perl and Python I have fun working with it.
• deleted 2y ago
  [deleted]
• alper 2y ago
  Then why am I still messing around with Axum and friends and people using Go are shipping microservices like there's no tomorrow?
• kazinator 2y ago
  The argument that a language is inconsistent if it allows all structure members to be defaulted to zero, but does not default function arguments to be omitted such that they default zero, seems to me like someone climbing out on a limb, out of the window of lunatic asylum.