5 ms·

These are the changes that if made Go wouldn't be language it is. Go is simple, straightforward if little verbose. To me Go fits perfectly for business apps tha

by geodel 10y ago

These are the changes that if made Go wouldn't be language it is. Go is simple, straightforward if little verbose. To me Go fits perfectly for business apps that I write currently in Java.

nemothekid 10y ago
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");
AnimalMuppet 10y ago
Let Go be Go, let Rust be Rust, and let Haskell be Haskell. There's no need to try to make Go into Rust; we already have one of those.
- Zikes 10y ago
  One of the primary design principles behind Go is that it be designed to incorporate the best available features of other languages, as much as it is able while remaining simple and easy to learn and use. If there is a way to incorporate the best features of Haskell and Rust while maintaining Go's current simplicity and ease of use, then it should be incorporated. To that end, the Go core developers have expressed an intent to implement Generics, however they want to do so in a way that does not (significantly) negatively effect the language's simplicity or compile times. https://github.com/golang/go/issues/15292 https://github.com/golang/go/issues/15292
  - kasey_junk 10y ago
    > One of the primary design principles behind Go is that it be designed to incorporate the best available features of other languages Is that documented somewhere?
    - Zikes 10y ago
      I expected I would find it in https://golang.org/doc/faq https://golang.org/doc/faq but I'm not seeing it there, so I have no reliable sources for that statement at this time. It's something I hear often, though. That Go is intended to be a "modern" language, with the definition of "modern" being that the opportunity that a blank slate provides allows for the application of the best features and learnings of the languages of the past.
      - AnimalMuppet 10y ago
        > ... with the definition of "modern" being that the opportunity that a blank slate provides allows for the application of the best features and learnings of the languages of the past. Application of the best features and learnings to a particular problem domain. The (intended) domain is Google-scale code bases that live for decades. The ideas that are important there may not be applicable anywhere else. If they are, it's more by happenstance than design.
kasey_junk 10y ago
I think go would actually be a pretty bad match for software that is modeling some sort of business domain. The type system is just not robust enough for it. What it is good for is software that is about moving bytes around from place to place. Network daemons, web servers, cli tools that interact with JSON/Xml in simple ways.

by geodel 10y ago

These are the changes that if made Go wouldn't be language it is. Go is simple, straightforward if little verbose. To me Go fits perfectly for business apps that I write currently in Java.

nemothekid 10y ago

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");

AnimalMuppet 10y ago

Let Go be Go, let Rust be Rust, and let Haskell be Haskell. There's no need to try to make Go into Rust; we already have one of those.

Zikes 10y ago
One of the primary design principles behind Go is that it be designed to incorporate the best available features of other languages, as much as it is able while remaining simple and easy to learn and use. If there is a way to incorporate the best features of Haskell and Rust while maintaining Go's current simplicity and ease of use, then it should be incorporated. To that end, the Go core developers have expressed an intent to implement Generics, however they want to do so in a way that does not (significantly) negatively effect the language's simplicity or compile times. https://github.com/golang/go/issues/15292 https://github.com/golang/go/issues/15292
- kasey_junk 10y ago
  > One of the primary design principles behind Go is that it be designed to incorporate the best available features of other languages Is that documented somewhere?
  - Zikes 10y ago
    I expected I would find it in https://golang.org/doc/faq https://golang.org/doc/faq but I'm not seeing it there, so I have no reliable sources for that statement at this time. It's something I hear often, though. That Go is intended to be a "modern" language, with the definition of "modern" being that the opportunity that a blank slate provides allows for the application of the best features and learnings of the languages of the past.
    - AnimalMuppet 10y ago
      > ... with the definition of "modern" being that the opportunity that a blank slate provides allows for the application of the best features and learnings of the languages of the past. Application of the best features and learnings to a particular problem domain. The (intended) domain is Google-scale code bases that live for decades. The ideas that are important there may not be applicable anywhere else. If they are, it's more by happenstance than design.

kasey_junk 10y ago

I think go would actually be a pretty bad match for software that is modeling some sort of business domain. The type system is just not robust enough for it. What it is good for is software that is about moving bytes around from place to place. Network daemons, web servers, cli tools that interact with JSON/Xml in simple ways.