Hacker News Reader

Comment by hedora | Hacker News Reader

I’ve worked with a few large code bases that use channels. In all those code bases, they were about as maintainable as GOTO-based control flow, except that GOTO makes you have unique label names. All the channel-based code I’ve seen just has 100’s of call sites like “chan->send()” and “chan->recv()” sprinkled around, and doesn’t even have the discipline to put related senders and receivers in the same source file.

At least old-school syntax like “GOTO foobar_step_23” and “LABEL foobar_step_23” is grepable).

I greatly prefer programs that “color” functions sync/async, and that use small state machines to coordinate shared state only when necessary.

Go technically supports this, but it doesn’t seem like it is idiomatic (unlike rust, the go compiler won’t help with data races, and unlike C++, people don’t assume that the language is a giant foot-gun).

View on HN

> All the channel-based code I’ve seen just has 100’s of call sites like “chan->send()” and “chan->recv()” sprinkled around, and doesn’t even have the discipline to put related senders and receivers in the same source file.

Any language that supports true multithreaded parallelism provides foot-rail-guns, no matter if you’re locking, asyncing or channeling. For concurrent data structures, you can’t lazily rely on the compiler to catch your errors. Not even in eg Rust. You should never sprinkle concurrent primitives just because.

For every channel created, you need to determine how the invariants of both the channel itself and the contents that pass through it. This is, for the most part, an easier exercise than with locks, because channels provide a way to think about ownership, and crucially, transfer of ownership between threads (goroutines). It also decouples the response to an event from the production of it, whereas with locks you have to dispatch the “next action” from the code that produced the event. I’ve never had a language that’s so easy to do things like “spin up 10 concurrent requests at a time with individual timeouts, cancel outstanding requests if any of them succeeds or canceled by the user, and ensure all tasks are torn down before returning”. It’s near-trivial to get right with channels, contexts and waitgroups.

In either case, since concurrency is so difficult, I would say that the Go docs and resources are quite lightweight on how to use their primitives correctly. Right now, it’s a bit “now finish the rest of the fucking owl”. You need discipline to use them, but there’s no parental figures around to tell you how to watch out for the dangers.

Kind of sick of seeing this misconception so I want to clear it up: async/await (as most commonly implemented) != pre-emptive and truly parallel multithreading.

All parallel execution is asynchronous, but not all asynchronous execution is parallel.

async/await interleaves execution in a cooperative fashion: a "fiber" runs until it yields by doing something blocking (such as blocking I/O, the most often cited use case). There are no data races and no need to use synchronization primitives since there is never a case where 2 fibers modify a piece of data at the same time: because execution is interleaved, the operations are always ordered one after the other. Whenever a fiber blocks, execution is returned to the scheduler, which resumes execution in one of the other fibers which were blocked.

fork(pthread_create)/join(pthread_join) parallelizes execution: a "thread" runs until it is done or is killed externally (the scheduler can also pause execution). A thread X can wait for another thread Y to be done by calling join(Y). There is a need to use atomics or other synchronization primitives such as channels (or mutexes, or barriers, or semaphores) when 2 threads share a variable in order to make sure only 1 at a time modifies, because although threads can be ran in an interleaving fashion (and sometimes they are interrupted (pre-empted)), they are usually ran in parallel on different CPU cores/threads (if you have a SMT CPU, which most nowadays are: n CPU cores and each CPU core has 2 "CPU threads").

P.S. A CPU thread != OS thread

async/await is just syntax. There's nothing saying that two async calls can't run fully in parallel. "Blocking" is subjective too; in a way even JS is doing some parallelism.

I covered my ass:

> async/await (as most commonly implemented)

Javascript is famously single threaded, which is probably the runtime on which most async/await code runs today.

But yes, Rust for instance has the Tokio async runtime which is parallel, although it also has cooperative async runtimes.

For those who are reading this and feeling unsure: Go has parallel execution, and it calls `fork()` `go`. Go doesn't feature a `join()`, for that you must use channels:

    func main() {
     done := make(chan bool)
    
     go func() {
      fmt.Println("goroutine running")
      time.Sleep(2 * time.Second) // simulate some work
      done <- true
     }()
    
     <-done
     fmt.Println("goroutine finished")
    }

Funny thing: if you have a goroutine which is waiting to receive some value from a channel, but it never does this, and the other handles to the channel are gone, you get a goroutine leak! The goroutine is blocked, and unrecoverable/unkillable.

I mean, the top comment wasn't talking about runtime characteristics, they were talking about the patterns resulting from using co-routines with messaging vs async/await.

That's right. So if Golang wanted to do async/await, it would probably be in a fully parallel way.

Isn’t a WaitGroup a more common way to do join?

https://pkg.go.dev/sync#WaitGroup

Thank you, this is indeed true, though it's important to be aware of implementation differences - poll-based Futures that are "merged" into a single big Task like Rust, or continuation-scheduling granular hot-started Tasks like C#.

e.g. in C#, the following is true:

    using var http = new HttpClient() {
        BaseAddress = new("https://news.ycombinator.com/")
    };

    // Runs sequentially
    var page1 = await http.GetStringAsync("?p=1");
    var page2 = await http.GetStringAsync("?p=2");

    // Submitted sequentially, everything after the first yield completes in parallel, IO does not block the caller
    var page3 = http.GetStringAsync("?p=3");
    var page4 = http.GetStringAsync("?p=4");

    // Waits for page3, then page4 to complete, they are effectively parallel
    DoSomething(page1, page2, await page3, await page4);

But in Rust, this requires explicit join handle, and if you would like to parallelize/fork the execution flow - you have to schedule a separate task. It requires more effort but in return you get lower async overhead, which is critical for areas Rust is applied to (and host-starting Tasks or Futures would not be easily compatible with borrow checker I presume).

You said "All parallel execution is asynchronous, but not all asynchronous execution is parallel."

But later you mentioned threads running in parallel on different CPU cores.

The way I always understood it, is that this is the only real form of parallelism able to happen on a CPU. But that does seem kind of incompatible with your statement at the beginning.

The way I think about it is, when Rob Pike says "Concurrency is not parallelism", I really rewrite it as "All concurrency is parallelism, but not all parallelism is concurrency." If you just think of concurrency as an instance of parallelism, you start to realize there are many ways to achieve concurrency, and thread-safe queues are one of the better ways to do it.

Individual CPU cores are parallel because they are executing multiple instructions simultaneously (even though they are from the same instruction stream).

> "All concurrency is parallelism, but not all parallelism is concurrency."

The other way around. Alternating two executions on one CPU core is concurrency, but not parallelism.

> All concurrency is parallelism, but not all parallelism is concurrency

As sibling notes, you have it exactly backwards. It should read "All parallelism is concurrency, but not all concurrency is parallelism." I thought maybe this was a typo, but then you said:

> If you just think of concurrency as an instance of parallelism, you start to realize there are many ways to achieve concurrency, and thread-safe queues are one of the better ways to do it.

This is demonstrating parallelism as an instance of concurrency, not the other way around. A thread-safe queue can be processed by multiple tasks running interleaved in a single thread in which case it is executing concurrently, but not in parallel.

> Individual CPU cores are parallel because they are executing multiple instructions simultaneously

This is an implementation detail of the CPU. Not all CPUs execute instructions in parallel.

> All the channel-based code I’ve seen just has 100’s of call sites like “chan->send()” and “chan->recv()” sprinkled around

This just sounds like badly written chaotic code. Unfortunately there are some people who seem to think "Go has channels, therefore, I need to use channels as much as possible", but that's almost always a mistake.

Channels shouldn't be used very frequently, but they can be very handy especially in combination with select and/or buffered channels. Usually there should be a clear and "obvious" API.

Go does have the `- race` flag for test + build commands [1], which can help (not 100% iirc, but some) with datarace detection.

[1] https://go.dev/doc/articles/race_detector

You may as well say variables are bad because people are bad at naming variables. I mean, yeah? I don't call my channels "chan", I call them "outputChannel" or "inputChannel" or "foobarProducer" or "twiddleListeners" or whatever.

it's idiomatic in go to use short names like chan though. I ignore that personally and use names like yours, but it's not been especially common in the go code or docs I've seen.

Copying docs like this as idiomatic code seems problematic in any language. The docs have no clue what your domain is and couldn't give a sensible name for a variable in it.

For example, lets look at "string". Most examples are gonna just call it a "str" or even "s". But if what you have is someone's name you should get called out for calling it a "str" rather than "name".

You shouldn't name all your mathy variables x, y, i, j.

You shouldn't name your channels "chan" or "c". Unless its just generic channel code.

I don't mind short domain variable names. But "chan" isn't that. It's like calling all your ints "num" or all your strings "str".

> it's idiomatic in go to use short names like chan though

There's a linter which I like[1] that checks variable name length based on the scope of its usage.

The idea is a variable name can be short if it is used in a small lexical scope (e.g. a function parameter in a one-line function) because it won't affect readability much. But names should be descriptive if used in a larger scope (e.g. a constant used across a file).

1. https://github.com/blizzy78/varnamelen

oh this sounds great! thanks for sharing

> outputChannel … inputChannel Channels are read/write. What’s the difference between an input and output ch

It's in how you use it. One piece of code's output channel might be another piece of code's input channel.

This is why I think each instance of a channel should be a global singleton as soon as they escape a local context. IMO you could solve this by having each instance of a channel be a unique type that must be annotated as that type everywhere it's used. Channels are generic, but you should not generally use them generically.

In Go you can use a type alias to make this work:

type ExitChan <-chan nil

Unfortunately it doesn't really enforce anything at the compiler level, but at the very least you can grep for it.

I'm confused about why we're comparing GOTO control flow with channels, since they're completely unrelated. I guess you can make a mess with each when you use them inappropriately? With GOTO, you should avoid it because there are better options (notably, conditional statements).

Unlike GOTO, there isn't really a better alternative for synchronizing parallel programs. Parallel programming (or even concurrent programming, for that matter) is just harder than sequential programming, and if you don't know what you're doing (regardless of whether you use channels or not) you're going to end up with a mess. Channels help to tame parallel programs, but they can't compensate for programmers who don't know how to write correct parallel programs.

And while Rust can prevent against data races, data races are a tiny sliver of parallel programming bugs. Far more common are race conditions and deadlocks, against which Rust is powerless.

> I greatly prefer programs that “color” functions sync/async, and that use small state machines to coordinate shared state only when necessary.

Async/await similarly doesn't solve the problem of undisciplined programmers making a mess. If you give undisciplined programmers async/await and shared state, they'll make a mess as easily as they will with goroutines and channels. If you're hiring people who can't be trusted with shared memory parallelism, then you have to take away parallelism or mutability or you have to train them to write correct parallel programs.

I think GP was comparing them because they are both capable of producing spaghetti code. But you can create spaghetti code with functions and modules, too (and I've seen plenty of examples of that). It shouldn't disqualify the entire technique.

> I'm confused about why we're comparing GOTO control flow with channels, since they're completely unrelated. I guess you can make a mess with each when you use them inappropriately? With GOTO, you should avoid it because there are better options (notably, conditional statements).

Notes On Structured Concurrency goes into some depth on this comparison:

https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

If channel sends are being used as invocations, then this description can apply just as well to channels as it does to the go statement.

> Notes On Structured Concurrency goes into some depth on this comparison:

Yeah, this is why we use `sync.WaitGroup`s and similar abstractions in Go. Using bare channels (like using `goto`) is fine for small local things, but if you're building abstractions you should use patterns like those discussed in the article (for example: https://go.dev/play/p/UoB8ECDbaTw --I'm sure this can be abstracted further).

Function coloring is orthogonal to async or not. I also greatly prefer function coloring, but I'm agnostic when it comes to either explicit async/await or sync code in green threads. For example, Haskell has function coloring, but it also has Go-style lightweight threads and sync code. It's the nicest experience IMO.

I think the reason channels become harder to understand is that you jump to having a network topology of senders and receivers to reason about.

With async/await, everything is still a function. Your IDE and debugger help you understand when and where a function is called. When debug-breaking on a function you have the stack trace.

Async/await gets you fast context switching for IO ops as it is a single OS process (no threads for the OS to constantly switch).

But once you go beyond a single OS process, then you need something like messaging or shared memory on top of async/await to communicate between OS processes/threads.

I think Golang jumps straight to messaging which is better for multiple cores, but misses the first step of async/await which is easier to reason about when you have a single process on a single core.

Evergreen https://www.arp242.net/go-easy.html

though Go has generics now, so there is that.

Also the link to SliceTricks goes to stale content

Golang should have async/await and exceptions, both of which can be implemented as syntactic sugar on top of existing features.

Having used both async/await and goroutines, I much prefer the latter. But yes, goroutines and channels are powerful tools that require understanding and discipline.

Go has exceptions. Always has.

Yes, but when writing idiomatic Go one would prefer error types over using panic (panic is Go's term for an exception).

The parent is really complaining about idiomatic Go. Which is fair, because idiomatic Go feels like writing Java 6 (that is to say, making lots of compromises due to limitations of the language).

> panic is Go's term for an exception

No. An exception is a datatype. Not completely unlike an error type in concept, but intended for erroneous conditions that could have theoretically been caught at compile time (i.e. the programmer screwed up), as opposed to conditions that are not decidable at compile time (i.e. something happened in the outside world).

In Go, panic creates an exception, which may be the source of your confusion. The exception contains any metadata you passed to panic along with other data, like a stack trace. This is not panic in and of itself, though.

> but when writing idiomatic Go one would prefer error types over using panic

Not really. Idiomatic Go says that errors are in no way special and is faulty to think of them as being special. They are just values like any other. Go exceptions allow attaching any value as metadata.

The official line is that panic stack traversal should not cross package boundaries, but internal use is perfectly acceptable. Even the Go standard library does it.

This is confusing, so I'll put it this way, Golang doesn't have exceptions the way someone coming from Javascript, Java, Python, ObjC... would understand: thrown anywhere and automatically propagated up the call stack unless caught.

There is nothing to be confused about. The syntax may be slightly different to other languages, but there is no meaningful difference in the design. If you understand exceptions and exception handlers in those other languages, you understand them in Go. There is no exactly a lot you can do with exceptions to see them differ in any big way.

Why is it that Go attract so many "experts" who have clearly never used the language even just once?

I understand how to use them in Golang, it's just annoying to have to keep checking and returning errors everywhere.

The language doesn't impose this upon you. You can use the exception handling system to pass values around, just like you might in the aforementioned languages. Even Go's standard library does it. Read the encoding/json source sometime.

You might impose it upon yourself when you start to understand the pitfalls of using exceptional handlers for anything other than exceptions, but such is engineering. Everything comes with tradeoffs.

What's imposed on a Golang user is two choices, panic/recover or regular error handling, and almost always you take the latter. There's no option of using exceptions the same way you would in most other languages.

Same as all of those other languages mentioned. What gives you the impression that Go is somehow magically different? Or have I misinterpreted you?

One technical challenge to using panic to represent normal exceptions is that most go code is then not exception safe. This was a design choice for the ecosystem if not the language itself (see eg: Effective go about panic not crossing package boundaries, or Google's style guide).

Within a package it can work, but then you'll find language support lacking. For example defer is scoped to a function so you need to write pretty unusual code to make the equivalent of a try block.

Like randomdata said, Go does have this with panic/recover, it's just that Go programmers (from what I have seen) greatly prefer Error types which do not automatically propagate up the stack until caught.

Go _doesn't_ have any form of checked exceptions, though, which are required by the compiler to be caught by the caller.

Golang programmers indeed don't prefer panic/recover, but that's not comparable to exceptions in other languages.

Panic/recover is perfectly equivalent to try/catch in most languages. There is some small difference related to exactly how un caught panics are handled (in Java, an un caught exception kills the thread that raised it; in Go, it kills the whole Go process); and the amount of built-in type checking for recover vs catch (but you can do manual typechecking and re-panic from a recover if you want). But otherwise they are almost perfectly equivalent.

Of course, Go code uses panics much more sparingly than Java or C# or JS or Python use exceptions.

It's different syntax, less convenient, and less obvious what you're try-catching. Also you can't scope it to just part of the function.

  func outer() {
    defer catch() {
        if r := recover(); r != nil {
            fmt.Println("Recovered:", r)
        }
    }()
    // ...
    doSomething() // Can panic
    doSomethingElse() // Can also panic
  }

vs JS:

  const outer = () => {
    try { doSomething() } catch(err) { console.log(err) }
    try { doSomethingElse() } catch(err) {
      console.error("dang it bobby", err)
      throw err
    }
  }

But in any real Golang situation, you'll be working with libraries or teammates who return (type, error) instead of using panics. You might say this isn't inherent to the language, but it kinda is when all the built-in standard libraries like net/http work this way and the official language style guide tells you to do this.

  func outer() {
    r, err := doSomething()
    if err != nil {
      fmt.Println("Recovered:", r)
    }
    r, err := doSomethingElse()
    if err != nil {
      fmt.Println("Recovered else:", r)
    }
  }

> Also you can't scope it to just part of the function.

Why not?

    func outer() {
        func() {
            defer catch() {
                if r := recover(); r != nil {
                    fmt.Println("Recovered from doSomething:", r)
                }
            }()
            doSomething() // Can panic
        }()
        func() {
            defer catch() {
                if r := recover(); r != nil {
                    fmt.Println("Recovered from doSomethingElse:", r)
                }
            }()
            doSomethingElse() // Can also panic
        }()
    }

I don't get why we keep getting these "expert" comments from people who have never used Go before.

Hell, if you long for try/catch for some reason, you can even get creative:

    func try(fn func(), catch func(any)) {
        defer func() {
            if r := recover(); r != nil {
                catch(r)
            }
        }()
        fn()
    }

    func outer() {
        try(func() {
            doSomething()
        }, func(r any) {
            fmt.Println(r)
        })
        try(func() {
            doSomethingElse()
        }, func(r any) {
            fmt.Println(r)
        })
    }

But then you soon start to realize how awful try/catch actually is, so...

Try-catch is awful if you're forcing it in a language that doesn't really support it. I provided a JS try-catch example above; is there something wrong with it?

The recover is still function-wide in your example, which is what I said. You can nest funcs just to deal with this, but it's ugly, and code reviewers won't like it. I use Go on my team, and yeah I'm not as expert as the team who created Go here, but idk why you keep saying I've never used it. My complaint about "if err" is pretty common among Go users, who would understand the joke of calling it "Errlang."

> I provided a JS try-catch example above; is there something wrong with it?

Yes, it suffers all the same problems. And then doesn't even help you with the errors once you get them! You then have to resort to this kind of craziness to do something with the error:

    try {
        doSomething()
    } catch(error) {
        if (error instanceof FooError) {
            console.log('foo')
        } else if (error instanceof BarError) {
            console.log('bar')
        } else if (error instanceof BazError) {
            console.log('baz')
        } else {
            console.log('unknown')
        }
    }

Which leaves you wondering why you didn't just write:

    err := doSomething()
    switch {
    case errors.Is(err, ErrFoo):
        fmt.Println("foo")
    case errors.Is(err, ErrBar):
        fmt.Println("bar")
    case errors.Is(err, ErrBaz):
        fmt.Println("baz")
    default:
        fmt.Println("unknown")
    }

At least Java gives you multiple catch blocks to make things slightly more sane.

But I get the impression that those who find benefit in passing errors using exception handlers don't handle errors. If you don't have to worry about errors in the code you write, then I think there is a good case to be made that errors as exceptions is a better approach.

That is, after all, the difference between scripts and systems. Scripts can simply fail, leaving the user to try again. Errors as exceptions, or something in the same vein, make sense as the predominant mechanism in scripting languages. Systems, on the other, have to deal with failure. You don't get to just bubble it up and let the user deal with it. This is where errors as exceptions becomes a nightmare. Go is unabashedly a systems language. It is not meant to be a scripting language.

Different tools for different jobs.

The point of exceptions is to make it convenient to propagate errors upwards and unlikely that you accidentally ignore an error, as discussed in the other thread. This doesn't magically do your error handling too, but the Golang example isn't any nicer.

They aren't different jobs, though. The two most common uses of JS are backend systems (like you'd often use Golang for) and web frontends, not scripts. Backends will usually catch errors in one place, an HTTP or similar handler, sending back the appropriate status code with maybe a payload. Golang backends do something similar, which is why you see so much "if err != nil... return err" in practice.

Python is more for scripts aka CLIs, but Python backends are fairly common too. And Golang CLIs are also common.

This Golang guru talk of "handling errors" is almost entirely BS in my experience. I've almost never seen a Go library or code example that does anything other than bubble an error it got from its lower levels up to its callers, with some extra context if you're lucky. The rare exceptions are either some retries for network operations, or just ignoring the error and returning some default value.

I hear this in C++ too since we can't use exceptions here. "Unlike some other toy languages, we don't ignore errors, we handle them head-on." Uh no you don't, in fact it took a lot to make people stop ignoring errors or "handling" errors by crashing the entire service.

But at least we have a rule checking that you actually did something with the return statuses.

No, I think you just showed that trying to use Go as if it was designed to use panic as an exception is ugly. Other languages use exceptions perfectly well and I would say consequently have a much better error handling story than go. I really like go - a lot. But its error handling is truly awful.

How are panic/recover not comparable to exceptions?

Well ok, you can draw the similarity in how they both automatically bubble up. But the catching behavior is different, and they look different. Overall they weren't designed for similar uses.

A minor nitpick, but checked exceptions are a feature entirely unique to Java (maybe also one or two JVM languages?), so it really shouldn't be discussed so often when touching this topic.

That's fair! My point is that being forced to check exceptions can be beneficial. Go does not have any mechanism for this.

If you want to use a Result/Optional type I think that is way better than exceptions. As long as the compiler can enforce that you are acknowledging (or explicitly ignoring) both the happy and error cases. Ideally the error case for the Result/Optional type would also have an attached stack trace.

Thank you for taking the time to reply so thoughtfully!

So, if I'm understanding you correctly:

An exception is an unexpected failure at runtime that could have been caught by the programmer. For example, you might have a switch block with a default block saying "this can never happen". The programmer might miss a case in the switch block leading to an exception. This would be analogous to an unchecked exception (RuntimeException) in Java -- these exceptions are not required to be caught.

In Go, `panic` creates an instance of the type `exception`. When `panic` is executed it attaches metadata like the stack trace to the created exception. When I say "exception" this is the behavior that most people think about.

An error is for an expected failure, like a file potentially not existing when performing I/O operations. Like you said (and this matches my understanding), error types are just a normal type -- really any type that implements the `Error` interface. There are a lot of utilities functions/libraries that act on that `Error` interface, like assertions for unit tests, the multierr library, etc.

`Error` is similar to a checked exception (Exception) in Java, though it misses the behavior you expect like requiring it to be caught, and the try-catch syntax. Additionally, you don't have the stack trace/metadata automatically added.

Go programmers seem to _heavily_ prefer errors over exceptions, even when they should be using `panic`.

My problem with errors in Go are that they are too easy to ignore accidentally and they don't contain stack traces, so they can be hard to track down. I inherited a codebase where we had _hundreds_ of unchecked errors being silently ignored.

I understand that these problems go away if you have linters or a very detail-oriented team, but I unfortunately have no power over the actions of my team before I join. It's also _very_ hard to convince a team that they've been doing things incorrectly by ignoring errors.

> My problem with errors in Go are that they are too easy to ignore accidentally

This is a problem for values of all types, not just errors. One I'm not sure we've figured out how to solve[1]. There are a few languages out there that force variable assignment to try and address the problem, but even then there is really nothing to say that you haven't accidentally ignored the variable assigned.

> It's also _very_ hard to convince a team that they've been doing things incorrectly by ignoring errors.

To be fair, if you are able to completely leave out entire blocks of logic without anyone noticing even under the most cursory of testing, perhaps it wasn't actually needed? Forgetting entire code branches isn't exactly a subtle bug.

[1] Short of going all the way to formal proofs.

It's a problem for values of all types, which is why exceptions are usually handled specially in other languages. I get that it seems impure, but everything you call has some way to fail <1% of the time that you probably want to handle very differently from any other outcome. It's sensible for a language to force you to either designate a different code path for that or let it bubble up (edit: which, to clarify, Golang does not enforce with error return types, which is what the other person dislikes about it).

I've read a lot of code in my life. I see that exception handlers are sometimes used to carry errors, virtually always exceptions, but almost never anything else. Who is it that you are think are passing around email addresses and geocooreinates using exception handlers?

But even assuming it is done sometimes, is the developer going to actually handle it? I don't know how many times I've come across "catch" blocks that are empty or something equally inappropriate. Nothing was gained. It turns out that programmers will still forget no matter how hard you try to hold their hand.

I'm not sure there is any other solution than to test it, and once you get into testing, entire blocks of logic missing are going to stick out like a sore thumb. Forgetting an entire branch is not exactly a subtle bug. At that point it really doesn't matter what language constructs you do or don't have available.

> I don't know how many times I've come across "catch" blocks that are empty or something equally inappropriate. Nothing was gained. It turns out that programmers will still forget no matter how hard you try to hold their hand.

You are right, but the difference is that the programmer is making the choice to ignore that error versus accidentally ignoring the error.

There was no indication that it was an active choice. I'm speaking to where it was clearly incorrect behaviour, not where one honestly wanted to ignore the condition. I'm assuming these programmers would write out the boilerplate (perhaps even automatically by some IDE feature) and then forgot to return to it to fill in the logic.

And fair enough. It would be just as easy to forget to do that as it would be to forget to handle errors in any other language. There is no silver bullet here.

Adding a try{...} with an empty catch{} takes a lot more effort than simply forgetting to do something with an error return value.

> This is a problem for values of all types, not just errors. One I'm not sure we've figured out how to solve[1]. There are a few languages out there that force variable assignment to try and address the problem, but even then there is really nothing to say that you haven't accidentally ignored the variable assigned.

The difference is that the happy case is well-tested. If you aren't handled the error-free route you probably will notice that very quickly unless you aren't testing your code, even manually.

e.g. it doesn't matter if you ignore normal variable assignments because the programmer will usually catch that themselves. They will not likely catch all of the possible error assignments without some help.

> To be fair, if you are able to completely leave out entire blocks of logic without anyone noticing even under the most cursory of testing, perhaps it wasn't actually needed? Forgetting entire code branches isn't exactly a subtle bug.

In this case we were silently ignoring errors which caused multiple types of issues that we had to then manually track down. This is an entire class of defects that can be avoided with better tooling, either at the language level with checked exceptions, or with a linter like errcheck.

errcheck seems very sensible.

Colored functions are a huge hit to take, and the things you do to make colored functions tolerable are also things you can do to mask off the complexity of channels from library callers. Async/await for Go seems like it would not be a win.

I think exceptions are pretty much a dead letter in new language designs at this point? You could get people on board for real algebraic types and matching.

Since the boat has already sailed for Golang having async/await from the start, adding it now would require maintaining compatibility with uncolored functions. Waiting for a channel to have data from a go func is similar. JS has similar compatibility with uncolored code using Promises. Python's migration to async/await is a lot worse because it didn't have coherent parallelism features to begin with.

Exceptions are a smaller deal than async/await. Basically instead of manually writing "if err" everywhere, it's implicit if you aren't catching it. The most popular languages do this. Rust "?" syntax is also a decent compromise.

Every go developer I know who likes the language disagrees with this sentiment (including myself). If you really want async/await Go is probably not the language for you. Thats ok! There are a lot of languages that other people like that I do not want to use.

We don't need to have one language to rule them all. Its fine for languages to make different choices and trade-offs.

And yet they keep adding features that golang devs scream in unison aren't needed, until they are added.

It's a weird cult-like thing.

And go is reaching the point where like Java it gets crammed down your throat. Which is probably why golang should start adding even more features

Lots of Golang users told me generics aren't needed until they were added. But let's leave "cult" accusations out of this.

Nowhere did I suggest one language should rule them all. Golang has advantages like efficiency and greenthreading, but that's not because they omitted async/await and exceptions. I just think that was a mistake. And I do use Golang on my team.

I used languages with exceptions for 16-17 or so years and I've been using Go for 7-8 years.

It took me quite a while (years) to go from thinking that returning error (conventionally as the last return value) was a bit clunky to thinking that this is actually a very good idea. I don't mind the if err != nil pattern. I can't think of a single experienced Go programmer that is sufficiently annoyed by this to complain. I sometimes see people new to the language complain about this, but it tends to fade as they adapt.

With the ability to join errors, do sensible comparisons etc, errors work well for me when needing to express high level errors and their low level root causes. (eg the high level error may be "failed to read configuration" and the root cause might be "permission denied when opening file X").

I've come to realize that I like Go style errors better than exceptions for two reasons. First off, a lot of code in, for instance, Java uses unchecked exceptions. Which means that the whole idea that you have to handle exceptions goes out the window.

This, of course, varies from codebase to codebase, but the it is common enough that having exceptions available in a language doesn't mean people will use them in a way that forces discipline. Which kind of makes exceptions pointless. They just become syntax for emitting and handling errors. And awkward syntax at that. Which is the second reason. Exceptions tend to introduce extra scopes you have to deal with. This is annoying and in some cases it can get somewhat complicated.

Exceptions, the way they are commonly used, are a weak enforcement mechanism made more dangerous by people pretending it isn't. If you want discipline, neither exceptions nor Go errors are the way to go. You probably want to look to something like Rust.

I have a hard time seeing how exceptions would make Go better. Yes, if someone could come up with some syntactic sugar for Go 2 to deal with errors, that would be nice, but I have seen no proposals for this that represent actual improvement.

`if err != nil` is actually extremely readable and to justify new syntax for expressing this it would have to be a _lot_ better. I'm open to listening if people can come up with something.

Exceptions didn't end up doing what people hoped it would do in Java. We should learn from that and try not to pointlessly repeat this mistake. Besides, Go has already made its choice. Retrofitting it is only going to do harm.

The entire difference is whether or not you have to type "if err != nil { return err }" repeatedly. Some languages force you to handle exceptions, and some force you to handle non-exception errors.

Almost every single usage of channels in Go i've encountered was a mistake, buggy and hard to understand. To me nowadays seeing channels in use in code i just see it as a code smell and think how difficult it would be to remove them.

There are multiple ways to use channels wrong, the compiler will not help you and most of the docs and "tutorials" will not cover that. The best thing you can do in Go is stay as far away from channels as you can.

My thought is that channels isn't bad but they are too low-level. Sometimes they are used as a queue. Sometimes they are used as a future. Indeed, channels combine features like synchronization, signaling, and data transfer. It is this versatility that makes code unreadable.

The worst is when people use channels simultaneously with mutex.

Reply on news.ycombinator.com