Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I'd like to see in Go 2.0

sethvargo.com

Post reply on HN
Print view View original

11–20 of 223 posts

Re: What I'd like to see in Go 2.0

#11

Post by lolive »

bstpierre wrote: post #7

Serious question: what are the odds that go 2 ends up like python 3 and it takes the world over a decade of pain to migrate? (I like both python and go, and I’m still maintaining a sizable body of py2 code.) “Backwards compatibility forever” seems like unnecessary shackles, and the language should be able to grow — I’ve seen some nice proposals for improvements. I just wonder what the strategy is going to be for migr…

Not a Go développer here, but let’s take the example of Java when it got (for example) generics or functional features. There was NO going back. These were so fundamental improvements that the past was absolutely outdated as soon as those new features were available. May be the same thing will happen for Go

Re: What I'd like to see in Go 2.0

#12

Post by lucian1900 »

mieubrisse wrote: post #4

I'd add one more to this list: proper enum types. We use enums heavily to force devs who use our code into good choices, but the options are currently: 1) Use int-type enums with iota: no human-readable error values, no compile-time guard against illegal enum values, no exhaustive `switch`, and no autogenerated ValidEnumValues for validation at runtime (we instead need to create ValidEnumValues and remember to update…

Or even better, proper sum types. They're a superset of enums anyway.

https://github.com/BurntSushi/go-sumtype is great, but a bit unwieldy. Language support would be much better.

Re: What I'd like to see in Go 2.0

#13

Post by brnt »

bstpierre wrote: post #7

Serious question: what are the odds that go 2 ends up like python 3 and it takes the world over a decade of pain to migrate? (I like both python and go, and I’m still maintaining a sizable body of py2 code.) “Backwards compatibility forever” seems like unnecessary shackles, and the language should be able to grow — I’ve seen some nice proposals for improvements. I just wonder what the strategy is going to be for migr…

Not so serious question: what is Go2 and Python4 would be the same thing?

Re: What I'd like to see in Go 2.0

#14

Post by masklinn »

lolive wrote: post #11
bstpierre wrote: post #7

Serious question: what are the odds that go 2 ends up like python 3 and it takes the world over a decade of pain to migrate? (I like both python and go, and I’m still maintaining a sizable body of py2 code.) “Backwards compatibility forever” seems like unnecessary shackles, and the language should be able to grow — I’ve seen some nice proposals for improvements. I just wonder what the strategy is going to be for migr…

Not a Go développer here, but let’s take the example of Java when it got (for example) generics or functional features. There was NO going back. These were so fundamental improvements that the past was absolutely outdated as soon as those new features were available. May be the same thing will happen for Go

Not sure how relevant that is, the old code worked fine in post-generics Java.

Re: What I'd like to see in Go 2.0

#15

Post by cle »

nightowl_games wrote: post #8
dewey wrote: post #5

Earlier quoted context omitted.

> Again, you only need one way to do things, and again, it's a rare thing to need. Not worth special syntax. This really is one of the parts I like the most about Go. It really makes so many things simpler. Discussing code, tutorials and writing it. Every time I'm trying to do something in JS I have to figure out why every guide has a different way of achieving the same thing and what are the implementation differenc…

It'd be nice if he had at least hinted towards what 'the way' is for this problem.

It’s in the article he’s responding to.

Re: What I'd like to see in Go 2.0

#16

Post by masklinn »

avg_dev wrote: post #9
bstpierre wrote: post #7

Serious question: what are the odds that go 2 ends up like python 3 and it takes the world over a decade of pain to migrate? (I like both python and go, and I’m still maintaining a sizable body of py2 code.) “Backwards compatibility forever” seems like unnecessary shackles, and the language should be able to grow — I’ve seen some nice proposals for improvements. I just wonder what the strategy is going to be for migr…

It would be nice if there was a tool that re-wrote your Go-1 code in Go-2.

Go-1 and Go-2 code could even cohabit using something similar to Rust’s editions system e.g. the `range` behaviour could be something like a package opt-in.

And half the article could be fixed by adding new APIs and deprecating the old ones.

Re: What I'd like to see in Go 2.0

#17

Post by norman784 »

bstpierre wrote: post #7

Serious question: what are the odds that go 2 ends up like python 3 and it takes the world over a decade of pain to migrate? (I like both python and go, and I’m still maintaining a sizable body of py2 code.) “Backwards compatibility forever” seems like unnecessary shackles, and the language should be able to grow — I’ve seen some nice proposals for improvements. I just wonder what the strategy is going to be for migr…

Rust solved this with editions[0], I don't know if is this feasible with Go.

[0] https://doc.rust-lang.org/edition-guide/editions/index.html

Re: What I'd like to see in Go 2.0

#18

Post by randallsquared »

The issue with the order of range seems like using the same name for satisfying a different requirement: in a template, you're much more likely to want the value than the index, so it makes sense that a looping construct with a single parameter would be putting the value in that parameter. In a loop in normal code, you're more likely to want to do math on the index. So, I'd say the problem is more about punning the name of these two behaviors than the behavior itself being bad.

Re: What I'd like to see in Go 2.0

#19

Post by cle »

mieubrisse wrote: post #4

I'd add one more to this list: proper enum types. We use enums heavily to force devs who use our code into good choices, but the options are currently: 1) Use int-type enums with iota: no human-readable error values, no compile-time guard against illegal enum values, no exhaustive `switch`, and no autogenerated ValidEnumValues for validation at runtime (we instead need to create ValidEnumValues and remember to update…

Personally I’ve run into more problems with strict enum types in distributed systems in a team setting, than I have with Go’s lack of them. In that setting, strict enums are usually over-strict and eventually you back yourself into a corner in terms of being able to roll out new enum values.

When there’s no clear winner in terms of tradeoffs, I prefer to leave it out of the language like Go has done.

Re: What I'd like to see in Go 2.0

#20

Post by t43562 »

Everyone has their own gripes. Modules are what cause me the most pain in Go - especially where they're in github and I need to fork them and now change all the code that references them. I don't know if the problems are even tractable because the way it all works is so incredibly complicated and any change would break a lot.

I would like to remove all the "magic" that's built-in for specific SCMS/repository hosting services and have something that operates in a simple and predictable manner like C includes and include paths (although obviously I don't like preprocessing so not that).

As for the language, I like the range reference idea but my own minor pet peeve is an issue with pre-assignment in if-statements etc which makes a neat feature almost useless:

  // This is nice because err only exists within the if so we don't have to 
  // reuse a variable or invent new names both of which are untidy and have potential 
  // to cause errors (esp when copy-pasting):
  if err := someoperation(); err != nil; {
    // Handle the error
  }


  // This however won't work:  
  func doThing() string {    
     result := "OK" 
     
      if result, err := somethingelse(); err != nil { // result does not need to be created but err does so we cannot do this.
          return "ERROR"  
      }
    

   return result
  }
I don't have any good ideas about how to change the syntax unfortunately.
Post reply on HN