3 ms·

I get that you don’t like some of the features go has done without, but how do you justify incomplete? What do you even mean by that word? Clearly lots of code

I get that you don’t like some of the features go has done without, but how do you justify incomplete? What do you even mean by that word? Clearly lots of code has been written in it. Its deficiencies do not prevent programs from being expressed. The only definition I can think of for complete would be Turing completeness, but that is clearly too low a bar for what you are saying.

bananapub 3y ago
> but how do you justify incomplete are you seriously suggesting that Go's insistence of requiring the programmer to scatter "if err != nil {}" after most function calls - with no compiler assistance if you forget - is complete either in the sense of "having all necessary parts, elements, or steps" or "being finished"? it's terrible, causes bugs and it seems incredibly unlikely to me that it won't be improved.
- im_dario 3y ago
  No "compiler assistance" doesn't mean no assistance at all. There is a growing set of linters based on the community-accepted analysis package [0] that prevent this and other gotchas that Go devs may be prone to. It isn't a perfect solution, but it works at community level without needing to wait for the Go team to take care of or changing the language/toolchain. 0: https://pkg.go.dev/golang.org/x/tools/go/analysis https://pkg.go.dev/golang.org/x/tools/go/analysis
- saturn_vk 3y ago
  > if you forget Does this happen? Is there any data on how often error checking is forgotten?
  - fl0ki 3y ago
    In my experience, outright forgetting is very rare because an unused err should be a warning, but the following is not nearly as rare as it should be: if err != nil { return nil } With how boilerplate the correct version is, you learn to skip over it entirely, meaning it can be hard to spot that anything is wrong here. Linters do exist for this now, but they have so many false positives on other error handling cases that most people don't bother with them.
- Conscat 3y ago
  Goland and Emacs (with Tree Sitter) can at least generate those automatically for you so they won't be forgotten, fwiw.
- randomdata 3y ago
  At very least, unless you hate other developers for some reason, you need to document in your test suite what errors are returned. How, exactly, are going to forget a necessary `if err != nil` without your test suite blowing up? If you do hate other developers for some reason, why not leave out some `err != nil`s to really drive home your hatred towards them?
  - kelnos 3y ago
    If you can forget to check an error at a call site, then you can just as easily forget to add a proper test for that error condition. I prefer writing in languages where the syntax and standard library and compiler will help me avoid mistakes, and not have to rely on tests -- more error-prone code I have to write! -- to do that for me (and yes, I understand that I will never avoid having to write some tests, but the more the language and compiler can do for me, the better). A language with generics and sum types (so you can implement something like Either, Try, or Result) doesn't let you use the result of a fallible function call without handling the error explicitly. And if the result is unit/void, most compilers/linters will still warn you if you haven't used the Either/Try/Result type that's returned. But ultimately it doesn't matter. Write in whatever language you feel comfortable and most productive. Well, unless you're starting a new security-sensitive project and want to write in C. Just... stop.
    - randomdata 3y ago
      I don't follow. Errors are part of your functional specification. Not even a complete type system can avoid you needing to write tests to document the error conditions. We are not talking about writing tests to stand in where an incomplete type system may be lacking. Assuming you don't hate other developers, and given the tests you would write in any language, how do you foresee missing an error branch? Again, not specifically trying to test for something that a sufficiently advanced type system would catch, just your regular level documenting that demonstrates to other developers that you don't hate them. > then you can just as easily forget to add a proper test for that error condition If an error condition is easily forgotten in the documentation, then who cares about the implementation thereof? It is obviously not important. In fact, it is arguable that your program is incorrect if you do handle the condition in such a case.
danmur 3y ago
I think it's more a sign that Go will eventually pick up (some of/all of) the features people complain of it missing, in time. Maybe when it's a complete language it will still be simple; maybe trying to keep it artificially simple now will hamper it later. Remains to be seen.
kelnos 3y ago
I personally am not a fan of Go, but I agree that it's a fine language that people are productive in. Opinions about languages are going to vary a lot, and I don't think it's productive to debate this kind of thing. I prefer languages with stronger, more expressive type systems, but I'll freely admit that I code slower (though usually more correctly) in languages like that. Some people prefer languages where they can easily hold all the language's syntax and rules and quirks in their head, and fire out code quickly. All of that is fine. There's no objective truth there. I agree with the GP that Go feels incomplete. Before generics, it felt embarrassingly incomplete. But if you're fine and happy and productive with it as it is, that's great!

bananapub 3y ago

> but how do you justify incomplete are you seriously suggesting that Go's insistence of requiring the programmer to scatter "if err != nil {}" after most function calls - with no compiler assistance if you forget - is complete either in the sense of "having all necessary parts, elements, or steps" or "being finished"? it's terrible, causes bugs and it seems incredibly unlikely to me that it won't be improved.

im_dario 3y ago
No "compiler assistance" doesn't mean no assistance at all. There is a growing set of linters based on the community-accepted analysis package [0] that prevent this and other gotchas that Go devs may be prone to. It isn't a perfect solution, but it works at community level without needing to wait for the Go team to take care of or changing the language/toolchain. 0: https://pkg.go.dev/golang.org/x/tools/go/analysis https://pkg.go.dev/golang.org/x/tools/go/analysis
saturn_vk 3y ago
> if you forget Does this happen? Is there any data on how often error checking is forgotten?
- fl0ki 3y ago
  In my experience, outright forgetting is very rare because an unused err should be a warning, but the following is not nearly as rare as it should be: if err != nil { return nil } With how boilerplate the correct version is, you learn to skip over it entirely, meaning it can be hard to spot that anything is wrong here. Linters do exist for this now, but they have so many false positives on other error handling cases that most people don't bother with them.
Conscat 3y ago
Goland and Emacs (with Tree Sitter) can at least generate those automatically for you so they won't be forgotten, fwiw.
randomdata 3y ago
At very least, unless you hate other developers for some reason, you need to document in your test suite what errors are returned. How, exactly, are going to forget a necessary `if err != nil` without your test suite blowing up? If you do hate other developers for some reason, why not leave out some `err != nil`s to really drive home your hatred towards them?
- kelnos 3y ago
  If you can forget to check an error at a call site, then you can just as easily forget to add a proper test for that error condition. I prefer writing in languages where the syntax and standard library and compiler will help me avoid mistakes, and not have to rely on tests -- more error-prone code I have to write! -- to do that for me (and yes, I understand that I will never avoid having to write some tests, but the more the language and compiler can do for me, the better). A language with generics and sum types (so you can implement something like Either, Try, or Result) doesn't let you use the result of a fallible function call without handling the error explicitly. And if the result is unit/void, most compilers/linters will still warn you if you haven't used the Either/Try/Result type that's returned. But ultimately it doesn't matter. Write in whatever language you feel comfortable and most productive. Well, unless you're starting a new security-sensitive project and want to write in C. Just... stop.
  - randomdata 3y ago
    I don't follow. Errors are part of your functional specification. Not even a complete type system can avoid you needing to write tests to document the error conditions. We are not talking about writing tests to stand in where an incomplete type system may be lacking. Assuming you don't hate other developers, and given the tests you would write in any language, how do you foresee missing an error branch? Again, not specifically trying to test for something that a sufficiently advanced type system would catch, just your regular level documenting that demonstrates to other developers that you don't hate them. > then you can just as easily forget to add a proper test for that error condition If an error condition is easily forgotten in the documentation, then who cares about the implementation thereof? It is obviously not important. In fact, it is arguable that your program is incorrect if you do handle the condition in such a case.

danmur 3y ago

I think it's more a sign that Go will eventually pick up (some of/all of) the features people complain of it missing, in time. Maybe when it's a complete language it will still be simple; maybe trying to keep it artificially simple now will hamper it later. Remains to be seen.

kelnos 3y ago

I personally am not a fan of Go, but I agree that it's a fine language that people are productive in. Opinions about languages are going to vary a lot, and I don't think it's productive to debate this kind of thing. I prefer languages with stronger, more expressive type systems, but I'll freely admit that I code slower (though usually more correctly) in languages like that. Some people prefer languages where they can easily hold all the language's syntax and rules and quirks in their head, and fire out code quickly. All of that is fine. There's no objective truth there. I agree with the GP that Go feels incomplete. Before generics, it felt embarrassingly incomplete. But if you're fine and happy and productive with it as it is, that's great!