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

51–60 of 223 posts

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

#51

Post by rocqua »

assbuttbuttass wrote: post #33
t43562 wrote: post #20

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…

The fix is pretty simple, just declare err ahead of time: func doThing() string { result := "OK" var err error if result, err = somethingelse(); err != nil { return "ERROR" } return result }

Part of the reason OP liked the `if assignment` was to avoid polluting the higher-level scope with a variable that is only needed during the if statement.

Your solution fixes the error, but at the cost of losing the upside OP saw.

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

#52

Post by amw-zero »

donatj wrote: post #48
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…

> Use int-type enums with iota: […] no compile-time guard against illegal enum values Create a new int type and use that for your enums. While you still can create an illegal enum value, you basically have to be looking for trouble. It’s not going to happen accidentally. It’s even harder if it’s an unpunished type in a different package. See: https://github.com/donatj/sqlread/blob/91b4f07370d12d697d18a...

This compiles:

  type Test int

  const (
    T1 Test = 0
    T2      = 1
  )

  func TestSomething(t Test) {}

  ...
  
  TestSomething(17)
So this isn't a good suggestion, because you can easily pass any int value and will not get a compiler error. You may as well be using strings at that point.

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

#53

Post by [deleted] »

mseepgood wrote: post #43
cle wrote: post #19

Earlier quoted context omitted.

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.

> 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. Yes, they are poison for the evolution of a public API.

[deleted]

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

#54

Post by amw-zero »

mseepgood wrote: post #43
cle wrote: post #19

Earlier quoted context omitted.

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.

> 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. Yes, they are poison for the evolution of a public API.

Swift solved this problems with [non-exhaustive enums](https://github.com/apple/swift-evolution/blob/main/proposals...).

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

#55

Post by amw-zero »

masklinn wrote: post #10
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…

> We use enums heavily to force devs who use our code into good choices Beware, tho, that with many languages today you’re not really doing that even when they advertise enums e.g. in both C# and C++, enums are not type-safe (not even `enum class`). Iota is, at least, a fair acknowledgement of that. > with a FromString() function That seems like way a step too far, is there any such “default method” today? And I don’…

Really not sure what you're talking about. If you use enums in a real language like Swift, Kotlin, Rust, etc., you can only construct the values of the enum. There are no ways to get around it.

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

#56

Post by donatj »

amw-zero wrote: post #52
donatj wrote: post #48

Earlier quoted context omitted.

> Use int-type enums with iota: […] no compile-time guard against illegal enum values Create a new int type and use that for your enums. While you still can create an illegal enum value, you basically have to be looking for trouble. It’s not going to happen accidentally. It’s even harder if it’s an unpunished type in a different package. See: https://github.com/donatj/sqlread/blob/91b4f07370d12d697d18a...

This compiles: type Test int const ( T1 Test = 0 T2 = 1 ) func TestSomething(t Test) {} ... TestSomething(17) So this isn't a good suggestion, because you can easily pass any int value and will not get a compiler error. You may as well be using strings at that point.

Fwiw a literal 17 in a function call, let alone anywhere outside an equation or constant definition is a code smell that should never make it past review.

I see your point however.

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

#57

Post by jerf »

Eun wrote: post #40

I would like to add proper JSON5 support. The template problem is a real problem. I used it once and it was pain and moved away instantly. I would vote for go inside go as a template system. So you can effectively write go code. With the help of yaegi[1] a go templating engine can be build e.g here[2]. [1]: https://github.com/traefik/yaegi [2]: https://github.com/Eun/yaegi-template

You don't need official Go support for JSON5. Same for templating. The templating library in the standard library isn't anything special, it's just in the standard library. If you don't like it, go get one of the dozens of others on offer.

I think there's a number of language communities you can "grow up" in that teach you that things in the standard library are faster than anything else and have had more attention paid to them than anything else, like Python or Perl, because those languages are slow, and things going into the standard library have generally been converted to C. I think that because I look in my own brain and find that idea knocking about even though nobody ever said it to me directly. But that's not true in the compiled languages, of which Go is one. The vast majority of the Go standard library is written in Go. The vast majority of that vast majority isn't even written in complicated Go, it's just in Go that any Go programmer who has run through a good tutorial can read, it's not like a lot of standard libraries that are fast because they are written impenetrably. (Although the standard library may have subtle performance optimizations because it chooses this way of writing it in Go rather than that way, it's still almost entirely straightforward, comprehensible code.)

If you want JSON5 or a different template library, go get or write one. The Go encoding/json or text/template don't use any special access or have any magical compiler callouts you can't access in a library or anything else; if you grab JSON5 library (if such a thing exists), you've got as much support for it as JSON or text/template.

It's even often good that it's not in the standard library. I've been using the YAML support a lot lately. The biggest Go YAML library is on major version 3, and both of the jumps from 1 to 2 and 2 to 3 were huge, and would have been significantly inhibited if v1 was in the standard library and the backwards compatibility promise applied. v1 definitely resembles encoding/json, but that's missing a lot of things for YAML. If Go "supported YAML" by having v1 in the standard library, everybody would be complaining that it didn't support it well, and by contrast, asking anyone to jump straight to the v3 interface would be an insanely tall ask to do on the first try without any experimentation in the mean time. And I'm not even 100% sure there won't be a v4.

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

#58

Post by amw-zero »

cle wrote: post #19
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.

What problems did an enum cause you, and how was the enum responsible for the problem?

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

#59

Post by mieubrisse »

donatj wrote: post #48
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…

> Use int-type enums with iota: […] no compile-time guard against illegal enum values Create a new int type and use that for your enums. While you still can create an illegal enum value, you basically have to be looking for trouble. It’s not going to happen accidentally. It’s even harder if it’s an unpunished type in a different package. See: https://github.com/donatj/sqlread/blob/91b4f07370d12d697d18a...

As amw-zero pointed out though, a user could accidentally create the int type and it would only fail if you have runtime checking (which requires you to build it, either via a custom enum constructor that returns `error` or an `IsValid` function, which then require you to maintain the ValidEnums list).

Int types also don't give you any guards when deserializing.

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

#60

Post by mieubrisse »

tialaramex wrote: post #44
mseepgood wrote: post #6

Earlier quoted context omitted.

I don't think you would need a 2.0 (backward-incompatible language change) for any of this.

Exhaustive switch seems likely to be backward incompatible if done well. What you want here is something akin to Rust's match behaviour on enumerated types. If your alternatives aren't exhaustive, it doesn't compile. Now, Rust is doing that because match is an expression . Your day matching expression needs a value if this is a Thursday, so not handling Thursday in your day matching expression is nonsense - even thou…

Yep, agreed. Maybe a new hypothetical `exhaustiveswitch` keyword could be added that would be backwards compatible, but it doesn't seem very Go-like to have such similar functionality as separate keywords.
Post reply on HN