3 ms·

I agree, LoC is a very important measure of a language, not flexibility. If you really want to, just ignore the errors with "_" and let the runtime panic. Or ma

I agree, LoC is a very important measure of a language, not flexibility. If you really want to, just ignore the errors with "_" and let the runtime panic. Or maybe just use the language as intended.

deleted 4y ago
[deleted]
masklinn 4y ago
> LoC is a very important measure of a language, not flexibility. That is a completely false dichotomy. You can provide terseness for the common case while allowing flexibility for when that’s warranted. You can even artificially increase verbosity as disincentive for constructs which are necessary but should be avoided.
- grey-area 4y ago
  I agree it’s be nice to be able to return error + zero values in a simpler way. Personally I think they should add a keyword like returnif or check to do this, as sometimes (maybe half the time?) you don’t need to decorate an error if you want to handle it higher up. So you could just do: returnif err I hate the guard proposal as it mixes up error handling and function calls, but it’d be nice to have a simpler less verbose way to return errors. In comparison with languages throwing exceptions though, Go is far far easier to reason about, even if more verbose.
  - kitd 4y ago
    returnif err That's exactly his proposal at the end of the article, except he uses 'guard' as the keyword.
    - grey-area 4y ago
      Sorry, was commenting on the guard proposal not the article but yes you’re right about the article reiterating this but with 'guard' - this is an old idea that multiple people have proposed over the years usually with returnif or similar as the keyword. Very confusing that he tried to repurpose ‘guard’ for something which is just a return.
peterashford 4y ago
That's rather dismissive. I use Go. I like it a lot, its a really practical language that helps me get a lot of stuff done. That's pretty much gold standard for programming languages to me. But it is clear that Go is stupidly wordy when dealing with errors and examining ways to fix that should be something we're open to. FWIW I don't like the original proposal nor the article's solution to it
petesergeant 4y ago
How is this adding flexibility?

I agree, LoC is a very important measure of a language, not flexibility. If you really want to, just ignore the errors with "_" and let the runtime panic. Or maybe just use the language as intended.

deleted 4y ago

[deleted]

masklinn 4y ago

> LoC is a very important measure of a language, not flexibility. That is a completely false dichotomy. You can provide terseness for the common case while allowing flexibility for when that’s warranted. You can even artificially increase verbosity as disincentive for constructs which are necessary but should be avoided.

grey-area 4y ago
I agree it’s be nice to be able to return error + zero values in a simpler way. Personally I think they should add a keyword like returnif or check to do this, as sometimes (maybe half the time?) you don’t need to decorate an error if you want to handle it higher up. So you could just do: returnif err I hate the guard proposal as it mixes up error handling and function calls, but it’d be nice to have a simpler less verbose way to return errors. In comparison with languages throwing exceptions though, Go is far far easier to reason about, even if more verbose.
- kitd 4y ago
  returnif err That's exactly his proposal at the end of the article, except he uses 'guard' as the keyword.
  - grey-area 4y ago
    Sorry, was commenting on the guard proposal not the article but yes you’re right about the article reiterating this but with 'guard' - this is an old idea that multiple people have proposed over the years usually with returnif or similar as the keyword. Very confusing that he tried to repurpose ‘guard’ for something which is just a return.

peterashford 4y ago

That's rather dismissive. I use Go. I like it a lot, its a really practical language that helps me get a lot of stuff done. That's pretty much gold standard for programming languages to me. But it is clear that Go is stupidly wordy when dealing with errors and examining ways to fix that should be something we're open to. FWIW I don't like the original proposal nor the article's solution to it

petesergeant 4y ago

How is this adding flexibility?