4 ms·

I'm not sure - I've been writing Go for 4 years in a production setting, when we switched our API service from Python to Go at the release of Go 1.1. Since then

I'm not sure - I've been writing Go for 4 years in a production setting, when we switched our API service from Python to Go at the release of Go 1.1. Since then our default language is Go, and I write Go everyday. Things like Generics I haven't been really bothered by. But where I thought he brought up really good points are 1. nil. He's right compared to more recent languages, nil is awkward. I've been bit multiple times by the 'nil checks sometimes fail.' concept. Option/Sum types are so much cleaner, and having non-nullable types make a lot of things easier to reason about. 2. error checking. My main gripe is when you are writing a process that involves calling multiple functions that could return errors. You then need more boiler plate in order to stay sane and DRY - and I've admittedly bitten myself with the 'err' shadowing that happens sometimes. I don't think a Maybe type would have made Go more complex, and I think it would have fit in nicely with the 'Zero Value' concept.

richardwhiuk 10y ago
Maybe/Option/Result types don't work without generics, because you significantly reduce the type checking.
- stouset 10y ago
  And this is why people have been begging the golang developers to add generics practically since it was conceived. Yes, generics make compiler-writers' lives more difficult. But they can dramatically simplify the lives of everyone else.
- saghm 10y ago
  I'm not a Go programmer, but from what I understand, things like Go's map implementation in the standard library are usable as if they're generic. Couldn't they add a few more types like this (e.g. Option and Result) in the same way without exposing generics as a language feature?
  - jimsmart 10y ago
    I program some Go - I believe you are talking about the 'empty interface', e.g. map[string]interface{} The problem with that is that you instantly lose compile-time type checking, and have to check/assert the types yourself at runtime after accessing the map. In a strongly-typed language this kinda goes against the grain, and is a PITA. (Although it still can be useful at times). My 2p.
    - sbov 10y ago
      The point is that a map can be type safe because it's built into the language, and that the designers could do exactly the same with a maybe/option/result feature.
  - kasey_junk 10y ago
    You are absolutely correct. Go has generics. It just doesn't have user defined ones. If the language designers thought an Option/Result/Try was valuable they could add it. Just like they could add Futures/Promises and concurrent safe maps if they wanted to.
gue5t 10y ago
Sum types aren't a "more recent" idea than Go; they've been around for about half a century. Go is just designed by/for programmers who have brain damage from writing C (in any language) for many years.
stcredzero 10y ago
2. error checking... I've admittedly bitten myself with the 'err' shadowing that happens sometimes. This is indeed a problem. It's the same problem with people writing a catch-all exception in Java, then forgetting to write the correct handler later. Considering the Go team's priorities, it's one they should fix!
- kevhito 10y ago
  Go has "defer", which is great. Perhaps it should have a similar "whenever" construct. val, err := foo() if err != nil return err vee, err := bar() if err != nil return err Would become: var err error whenever err != nil return err val, err := foo() vee, err := bar() Static analysis would insert the appropriate check any time err is assigned in the function. Aliasing might be a gotcha, but I'd bet that is a rare case and static escape analysis could maybe catch it and either error, or just insert extra checks.
  - deleted 10y ago
    [deleted]
Gibbon1 10y ago
> 2. error checking What I want? I want to a) have an option where an unchecked return error causes the program to log and exit. error SomeFn(int blah, int haw) { if(blah < 0 || haw < 0) error(1); return(bah*haw); } // program will die here SomeFn(-20, 23); // program will not die here if(SomeFn(-20, 23) != 0) { // something } b) be able to pass a label to a function to handle errors. Example int SomeFn(int blah, int haw, error oops) { if(blah < 0 || haw < 0) oops(1); return(bah*haw); } int res = SomeFn(-20, 23, crap); printf("res =%i\n", res); // SomeFn returns here crap: print("parameters can't be negative");

richardwhiuk 10y ago

Maybe/Option/Result types don't work without generics, because you significantly reduce the type checking.

stouset 10y ago
And this is why people have been begging the golang developers to add generics practically since it was conceived. Yes, generics make compiler-writers' lives more difficult. But they can dramatically simplify the lives of everyone else.
saghm 10y ago
I'm not a Go programmer, but from what I understand, things like Go's map implementation in the standard library are usable as if they're generic. Couldn't they add a few more types like this (e.g. Option and Result) in the same way without exposing generics as a language feature?
- jimsmart 10y ago
  I program some Go - I believe you are talking about the 'empty interface', e.g. map[string]interface{} The problem with that is that you instantly lose compile-time type checking, and have to check/assert the types yourself at runtime after accessing the map. In a strongly-typed language this kinda goes against the grain, and is a PITA. (Although it still can be useful at times). My 2p.
  - sbov 10y ago
    The point is that a map can be type safe because it's built into the language, and that the designers could do exactly the same with a maybe/option/result feature.
- kasey_junk 10y ago
  You are absolutely correct. Go has generics. It just doesn't have user defined ones. If the language designers thought an Option/Result/Try was valuable they could add it. Just like they could add Futures/Promises and concurrent safe maps if they wanted to.

gue5t 10y ago

Sum types aren't a "more recent" idea than Go; they've been around for about half a century. Go is just designed by/for programmers who have brain damage from writing C (in any language) for many years.

stcredzero 10y ago

2. error checking... I've admittedly bitten myself with the 'err' shadowing that happens sometimes. This is indeed a problem. It's the same problem with people writing a catch-all exception in Java, then forgetting to write the correct handler later. Considering the Go team's priorities, it's one they should fix!

kevhito 10y ago
Go has "defer", which is great. Perhaps it should have a similar "whenever" construct. val, err := foo() if err != nil return err vee, err := bar() if err != nil return err Would become: var err error whenever err != nil return err val, err := foo() vee, err := bar() Static analysis would insert the appropriate check any time err is assigned in the function. Aliasing might be a gotcha, but I'd bet that is a rare case and static escape analysis could maybe catch it and either error, or just insert extra checks.
- deleted 10y ago
  [deleted]

Gibbon1 10y ago

> 2. error checking What I want? I want to a) have an option where an unchecked return error causes the program to log and exit. error SomeFn(int blah, int haw) { if(blah < 0 || haw < 0) error(1); return(bah*haw); } // program will die here SomeFn(-20, 23); // program will not die here if(SomeFn(-20, 23) != 0) { // something } b) be able to pass a label to a function to handle errors. Example int SomeFn(int blah, int haw, error oops) { if(blah < 0 || haw < 0) oops(1); return(bah*haw); } int res = SomeFn(-20, 23, crap); printf("res =%i\n", res); // SomeFn returns here crap: print("parameters can't be negative");