6 ms·

The fact that the compiler doesn't cover that automatically doesn't mean Go fails at it, as it has very good primitives for handling them. Error handling and d

The fact that the compiler doesn't cover that automatically doesn't mean Go fails at it, as it has very good primitives for handling them. Error handling and deferring for resource closure work just fine. Sure you could say "but the compiler doesn't guarantee it". But that's not much of a point if it's not a real problem in practice.

valenterry 4y ago
> The fact that the compiler doesn't cover that automatically doesn't mean Go fails at it But that's exactly what OP was talking about. Maybe for you that doesn't mean Go fails here, but for (us) Scala developers it definitely feel like Go fails us. We want a language that fails at compiletime in as many cases as possible. > But that's not much of a point if it's not a real problem in practice. Maybe not for you. For me it is!
- cube2222 4y ago
  I agree it's fine to have different taste, as I mentioned in another reply to you. But it's the difference between whether this statement is objective, or subjective. > is the best concurrency library on any platform
  - valenterry 4y ago
    Fair enough, that sentence is a bit over the top. I personally agree, but it is subjective and sounds like a fact.
kaba0 4y ago
Error handling and Go doesn’t mix well.
- cube2222 4y ago
  That's a matter of opinion. Many, me included, very much like the current, very explicit, approach. I understand why people who like monadic constructs don't like it though.
  - kaba0 4y ago
    I don’t know — I don’t claim that algebraic datatypes are the only proper way to handle errors, I’m okay with exceptions as well (even checked ones). But what go has is only very slightly better than C’s attempt, so I’m not sure it is that subjective.
    - cube2222 4y ago
      I think the presence of multiple return values and the ability to easily use complex types for errors make a huge difference (adding wrapping messages, context, etc.). I agree algebraic data types could improve this. I don't think monadic result types or exceptions would be an improvement.
  - seer-zig 4y ago
    Not quite: https://www.uber.com/blog/data-race-patterns-in-go/ https://www.uber.com/blog/data-race-patterns-in-go/
closeparen 4y ago
Not a real problem in practice is just another way of saying rare. But given enough scale and enough time, rare things do happen, and they cost inordinately more programmer effort to chase down. I actually don’t mind if the compiler lets me ship very dumb bugs: those will be auto-rolled back out of production in seconds. It’s the subtle stuff that kills me.

valenterry 4y ago

> The fact that the compiler doesn't cover that automatically doesn't mean Go fails at it But that's exactly what OP was talking about. Maybe for you that doesn't mean Go fails here, but for (us) Scala developers it definitely feel like Go fails us. We want a language that fails at compiletime in as many cases as possible. > But that's not much of a point if it's not a real problem in practice. Maybe not for you. For me it is!

cube2222 4y ago
I agree it's fine to have different taste, as I mentioned in another reply to you. But it's the difference between whether this statement is objective, or subjective. > is the best concurrency library on any platform
- valenterry 4y ago
  Fair enough, that sentence is a bit over the top. I personally agree, but it is subjective and sounds like a fact.

kaba0 4y ago

Error handling and Go doesn’t mix well.

cube2222 4y ago
That's a matter of opinion. Many, me included, very much like the current, very explicit, approach. I understand why people who like monadic constructs don't like it though.
- kaba0 4y ago
  I don’t know — I don’t claim that algebraic datatypes are the only proper way to handle errors, I’m okay with exceptions as well (even checked ones). But what go has is only very slightly better than C’s attempt, so I’m not sure it is that subjective.
  - cube2222 4y ago
    I think the presence of multiple return values and the ability to easily use complex types for errors make a huge difference (adding wrapping messages, context, etc.). I agree algebraic data types could improve this. I don't think monadic result types or exceptions would be an improvement.
- seer-zig 4y ago
  Not quite: https://www.uber.com/blog/data-race-patterns-in-go/ https://www.uber.com/blog/data-race-patterns-in-go/

closeparen 4y ago

Not a real problem in practice is just another way of saying rare. But given enough scale and enough time, rare things do happen, and they cost inordinately more programmer effort to chase down. I actually don’t mind if the compiler lets me ship very dumb bugs: those will be auto-rolled back out of production in seconds. It’s the subtle stuff that kills me.