10 ms·

Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that fin

• tejinderss 4y ago
  > everything from TLS to CSV is rolled into std without ever having to import a third-party repository And yet the std library is missing some basic data structures like Set.
  • p-e-w 4y ago
    Because they can't be properly implemented without generics, and generics were only shoehorned into Go a decade after its initial release.
    • kasey_junk 4y ago
      The go language has had generics since inception, just not user defined ones. If they wanted a set data structure they could have had it like they do maps and slices.
      • XorNot 4y ago
        Set is just a Map though where you don't care about the values. var m[string]struct{} implements this for you. What you're really missing is the usual suite of helper methods which make sets ergonomic - and for that you need proper generics.
        • masklinn 4y ago
          Fwiw lots of folks dislike m[K]struct{}, because while it’s efficient checking for presence is horrible: _, present = m[k] It looks weird and is not an expressions. Obviously you could paper over this with a dedicated builtin function but that’s not great. A common alternative is m[string]bool, memory density is worse but contains/add/remove are easier to read and more convenient.
    • masklinn 4y ago
      They could be implemented as builtins, like channels, slices, and maps were. Though what's really missing is generic set functions, and a decision as to which "hashmap shape" is the blessed set (between map[T]struct{} and map[T]bool), a "set" builtin can just be an alias to that in the same way "any" is an alias for "interface{}".
  • xanthrax 4y ago
    set := map[settype]struct{} This usually covers most cases I've seen for the use of sets
• sylens 4y ago
  I’m glad it’s not just me who is perplexed at some of the decisions made with golang. This was a golden opportunity to implement some typical form of exception handling. Instead you have to bundle your errors together and then unwrap them (often using multiple methods to handle the cases of both a single error and a bundle of errors) and then still implement even more logic to walk the tree you made?
  • Thaxll 4y ago
    Exception handling sucks, stop asking for it. Did you worked in Java? Did you worked with async and exceptions?
    • kasey_junk 4y ago
      Where did the poster ask for exceptions? And golang has them in the form of panics and they suck in goroutines.
      • ovao 4y ago
        > This was a golden opportunity to implement some typical form of exception handling.
    • qsort 4y ago
      I work in Java every day and I'll take exceptions any day over... that. I have a lot of respect for the engineering work the Go team put into the compiler, toolchain and stdlib, it's truly commendable. But the language itself is frankly a step back form everything else on the market today. Java, C#, hell, even python are better designed languages than Go.
      • zaphar 4y ago
        When it comes to error handling I rank things along a spectrum: Enumerated Types > Checked Exceptions > Error values > Unchecked Exceptions. The spectrum I'm ranking on is how much assistance the compiler gives me in ensuring I am aware of the error. Java has support for the second best option but culturally avoids it like the plague. Go has support for the third best option and culturally leans hard into it. C# and Python are ranked strictly at the bottom. The preference in many language communities for an error handling path that encourages little awareness of the errors that can occur reeks of laziness to me. Laziness that I will, without a doubt, fall victim too without superhuman amounts of diligence on my part to avoid. Any problem that requires superhuman diligence just screams out for a robot to handle in my experience. Java, C#, Python and a myriad of other languages fail hard here. Go gets a little better culturally by focusing on checkers that are built into the compiler toolchain with a default to running culturally as well as having type a signature for return values clearly indicate the error. But the gold standard for error handling has to go to any language that has enumerated types. Rust, ML variants such as OCaml or Haskell as common examples.
• papito 4y ago
  I feel a lot of that has to do with Googlers not daring to question the famous authors, and the same authors seem to have been asleep for the last three decades in terms of modern programming language developments. I geared up to learn Go one day, got the book and everything, and after just a few hours of trying to write and rewrite error-handling code, I was wondering how this ever got out of the Request for Proposal stage. Oh, you have to manually chain your errors and no you don't get stack traces out of the box. If you want to to know where the error message is, I don't know, guess? It's insane. Exceptions happened precisely because manual error-handling was messy and did not scale, but suddenly it's The Way.
  • leetrout 4y ago
    Coming from Python I appreciated that there were no exceptions. I much prefer the explicit error returns instead of exceptions being used for flow control.
    • metaltyphoon 4y ago
      But thats the programmer’s fault. You shouldn’t use exceptions for flow control.
      • leetrout 4y ago
        To an extent, sure, and that can apply arbitrarily to lots of things. The Python community, by and large, embraces "easier to ask forgiveness than permission" and some features in the standard library use exceptions for their flow control. It's much more likely to run into overuse of exceptions in Python than not.
    • kaba0 4y ago
      It’s not explicit error returns any more than C code with all those larger than 0 checks. You will leave it out or get angry at the line noise and will miss(handle) an important error case and will have a bad program and you won’t know about that until it’s too late. A loud exception is way better.
  • 4y ago
• bpicolo 4y ago
  Go with Rust-style tagged unions would be a delight (and that would improve error and null handling in many ways)
• kaba0 4y ago
  For all that you have the JVM ecosystem with multiple better languages (including Java itself)
  • switch007 4y ago
    3 second builds?
    • pjmlp 4y ago
      Yes, thanks to compile on save on IDEs. Also Turbo Pascal, Modula-2, Delphi, VB 6 were already doing that in 1990's hardware. Here Turbo Pascal 5.5 marketing material from 1989, 34 000 lines per minute. https://archive.org/details/TurboPascal55 https://archive.org/details/TurboPascal55 Go compile times are a reason to admire only for those that never used such compiler toolchains.
      • foldr 4y ago
        I think people are comparing Go’s compile times to the compile times of other languages that they have the option of using in the present day. Go is not the only language in history for which there exists a fast compiler, but its fast compile times are certainly salient when comparing it with a number of popular alternatives. OCaml springs to mind as a plausible alternative to Go that also has a fast compiler, but its ecosystem is vastly smaller.
  • p-e-w 4y ago
    I would hesitate to call Java a better language than Go, but Java is much older so the designers of Go should have learned from Java's mistakes, which they did not. When Java was new, though, it was certainly a far better language compared to its contemporaries than Go was when it came out in 2009.
    • jpgvm 4y ago
      That and Java still continues to be both faster moving and more innovative than Golang despite all that baggage.
• foldr 4y ago
  Isn't this line of argument somewhat self-defeating? It sounds as if these language design decisions that cause a vocal minority to complain loudly have only a marginal impact on actual productivity (or at least the perception of it). If so, that would be quite a good justification for not complicating the language by, e.g., adding enums, a non-nil pointer type, etc. etc.
  • bstpierre 4y ago
    I think that what you’re talking about might even be the killer feature that is often ignored: the forced simplicity. It’s a simple enough language that you can drop into a codebase and read without having to look up much syntax, assuming you have some familiarity with c-family languages. Yes, there are some weird bits that you have to learn, but the learning curve is very short compared to a lot of other languages.
    • p-e-w 4y ago
      Indeed, Go is reduced to the bare essentials! That's why it has primitive types representing complex numbers, which maybe 1 in 10,000 projects will use. It doesn't have enums though, because who needs those?
      • foldr 4y ago
        No need to be so salty. No-one is claiming that Go is an ultraminimalist language, just that it's relatively simple compared to most of the alternatives.
    • matwood 4y ago
      > the forced simplicity I appreciate this about Go. I'm not a programming language wonk, and Go's forced simplicity makes it easier to read other people's code.
    • kaba0 4y ago
      Ad absurdum that would mean that programming in assembly is the most readable. Abstraction is the only reason we can write any complex program.
• divan 4y ago
  > Years and years of discussions about Go's poor and verbose error handling ...with majority of users saying that it's actually great and simple, unlike "usual" approaches... > Many "features" of Go are borderline insane ...which start make sense as long as you use them and put some thought behind the reasons of the design, instead of sticking to "what I used to is the only right way" mentality... > (date formatting) Of course, mnemonics 1-2-3-4-5-6-7 (1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6-th year, 7th timezone) is harder to remember than mmHHMMssSSYYyy crap that is different in different languages. Without knowing the language, guess what will be printed by "15:04 Jan 2 2006" and by "MM:ss mmm D YYYY"? > were recognized as mistakes decades ago (nil pointers) ...by popular urban myth and people who love reductions of the complex ideas into simple black-and-white statements... It's funny how people can believe that great compiler, an amazing standard library, and high-quality official tooling can be a result of a bad design :) Good luck in spending so much energy in communicating your lack of intent to understand Go design from fundamental principles instead of comparing to the mainstream languages.
  • Smaug123 4y ago
    The insane bit about date formatting is recognised to be insane by the Golang team themselves. To quote https://pkg.go.dev/time https://pkg.go.dev/time: > It is a regrettable historic error that the date uses the American convention of putting the numerical month before the day. Such a "historic error" is literally impossible if you use the "MMddyyyy crap": it's always clear from context what format is in use. (I mean, in what world is it even remotely memorable that the canonical order is month, day, hour, minute, second, year, timezone? That decision is just… really bad!)
    • divan 4y ago
      This clause is just about slight inconvenience for non-US citizens to remember the order of month and day, and not about not using letter-mapping approach, which in some languages is using the whole alphabet. Are you intentionaly trying to misrepresent that clause of "regrettable error" or didn't read carefully?
• cube2222 4y ago
  Implicit interfaces are one of the defining features of the language that make it so great, I love them. Calling them borderline insane without any supporting arguments does make me question whether you ever gave idiomatic Go a chance. What do you dislike about them? Re error handling, I've been looking at the proposals and haven't yet seen a satisfying one. Sure, the current error handling is a bit verbose (three lines after each erroring function call), but it's a completely irrelevant problem to me in my day to day, and I much prefer it to exceptions as it makes you think about each error and makes people wrap errors with helpful context everywhere. In general, I like the approach of the Go team of only accepting proposals that are good and actually widely requested, as opposed to accepting "something" because "our story for this isn't great to some".
  • Smaug123 4y ago
    > I much prefer it to exceptions as it makes you think about each error and makes people wrap errors with helpful context everywhere… This would be absolutely fine, for the reasons you state, if Go made you deal with the error. But because it will silently allow you to completely ignore the error, your statement that it "makes you think about each error" is quite optimistic. In an exceptionful language, the runtime will let you know loudly and fatally when you've got garbage; in a language with a type system that admits a Result type, the compiler will forbid compilation unless you note that you're throwing away the error (which might be a single character of syntactic sugar, it need not be verbose!). But Golang and C and friends are the languages where you silently get garbage if you forget to do the due diligence that machines are perfectly capable of doing for you, and it makes me extremely sad every time I see a bug of this nature.
    • cube2222 4y ago
      That is a fair point and it's why I use errcheck[0]. [0]: https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck
      • Smaug123 4y ago
        Magic! I just checked, and this found the bug in a Go tool I use that bit me a couple of months ago, which I'm still smarting from. Thanks!
• fourseventy 4y ago
  That's just your opinion. I love the error handling in go and I believe it is a vocal minority that complain about the error handling on hn.
• lelanthran 4y ago
  > Go repeats design mistakes that were recognized as mistakes decades ago (nil pointers) All popular languages have some way to encode the fact that a value is absent. When languages that don't support nil/null values become popular, you might have a point in claiming that it was a mistake. Right now it makes no sense to make that claim.
  • kajaktum 4y ago
    >All popular languages have some way to encode the fact that a value is absent. The problem is that many languages don't make the distinction in the type system. Why oh why do we not force everyone to null check every time?
  • neysofu 4y ago
    The concern around C-style nullable pointers is that you can't opt out of nullability; everything you point to may or may not dereference. As opposed to other designs (e.g. "optional" types leveraging generics) that are opt-in, and thus let you choose which references are always valid and which ones are not.
  • p-e-w 4y ago
    Rust doesn't have nil/null values. It has an Option type that enforces at compile time that you explicitly handle missing values, through pattern matching, transformations, or unwraps. This makes 95% of the problems associated with nil/null pointers magically disappear. The difference this makes for the safety of large-scale systems is huge.
    • lelanthran 4y ago
      > Rust doesn't have nil/null values. Yeah, and it's also not popular. The reason I said "popular" is because the popular languages are addressing pain-points for devs. If nil/null was a pain point, none of the popular languages would allow nil/null values. The simple fact is that, for many developers, there is a pressing need to indicate lack of a value. Languages that don't address this pain-point never really get taken up en masse.
• bamboozled 4y ago
  Sorry, but what are you talking about? Poorly designed? A lot of incredibly good software is written in Golang and while that might not mean it's the best language ever designed, it would be hard to say it's "poorly designed" based on that fact alone?
  • shakow 4y ago
    Incredibly good software has been written in JS, that does not make a good language out of it. To a competent team, a bad language is an hindrance, not a deadly obstacle.
    • bamboozled 4y ago
      So then it's just a subjective statement because whether or not you think the "design" is good, it's design is obviously practical, well liked and in heavy use?
    • sethammons 4y ago
      The difference is options. Developers can use anything on the back. You are stuck with JS on the front. That devs _choose_ Go means something.
      • za3faran 4y ago
        You'd be surprised that the answer in a lot of times cooties just be hype or inertia. I've seen it first hand at an employer that supported both Java and golang. A new project was started in golang just because of inertia, whereas Java would have been a strictly superior choice on basically every front. The resulting code base was a huge mess, even as per the admission of the "lead" who made the original decision, who clearly had no business making that decision in the first place. Literally over a million dollars spent on a mediocre, unmaintainable result
• pjmlp 4y ago
  It only worked out because language authors are on Google's paychecks. Their former language designs (see Limbo and Alef) weren't as successful. Go is basically Limbo with a bit of Oberon-2 facelift.
• nprateem 4y ago
  You took the words out of my mouth
• lokar 4y ago
  Go explicitly prioritizes productivity in large Eng orgs with a range of programmer experience. This is often at the expense of what language enthusiasts this is important/new/cool You may not agree, but they are doing what they said they would from the start, and it’s been fairly effective.
  • kaba0 4y ago
    Java has been doing that (“blue collar language”) since its inception, and is arguably doing a much better job at it.
  • hocuspocus 4y ago
    Eschewing industry standard ergonomics that have been taught to every developer for the past 3 decades seems like the total opposite of "prioritizing productivity" to me. Besides, in large engineering organisations you're always going to find multiple languages. Even at Google, which keeps a very short list of blessed languages compared to most companies, the Googlers I know who typically work on "proto to proto" middleware in Go are often jumping into codebases in Java, Kotlin, Dart or TypeScript. So clearly, they can deal with modern language features too.
    • lokar 4y ago
      At google it mostly displaced uses of C++ and python
• za3faran 4y ago
  I'll disagree that the compiler is great. Is it fast? Sure, but it produces suboptimal code. I personally believe that the biggest factor that it became popular was marketing, having well known names behind it both as a corporation, and individuals who had some contributions in Unix land