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

201–210 of 223 posts

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

#201

Post by synergy20 »

Most important items in my plate

    1. a unified improved *error* in stdlib with stack trace support.
    2. a unified log interface(mentioned)
    3. a STL library like c++
    4. shared library support so we dont have 100 static binaries that among them each have 90% of duplicated content. go shall support shared libraries/modules officially.

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

#202

Post by Jeff_Brown »

honkycat wrote: post #178

What I would like to see: - Enun Types - A special operator to cut down on `if err != nil { return err }` and just return at that point. - Named arguments, and optional params with defaults - Default values on structs - ...macros? We already have `go generate ./...` ( edit: Removed unformatted source code )

Sum types would satisfy the first two on that list, as well as making an ergonomic optional type trivial to define.

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

#203

Post by jatone »

infogulch wrote: post #79
jatone wrote: post #30

Earlier quoted context omitted.

unfortunately replace is not supported well with modules. and they are hell bent on not supporting it well.

You mean this? https://thewebivore.com/using-replace-in-go-mod-to-point-to-...

yes. now try to go install your application with the replace directive. it will silently replace the code with the original upstream version.

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

#204

Post by morelisp »

asah wrote: post #37
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…

IMHO the long python3 migration was well executed and we're now comfortably on the back side of it. Reminds me of perl4=>5 and other big lifts. Yes, commercial codebases understaffed for maintenance are kinda stuck, just like any legacy system. IMHO the solution must come from the business model down. Also, security, compliance & cost can help drive priority.

This is an absolutely implausible take. Perl 4's entire lifetime was about 5 years; released in 1991 and Perl 5 utterly dominant by 1996. Python 2 shows no signs of an actual EOL to this day!

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

#205

Post by jatone »

cube2222 wrote: post #64
jatone wrote: post #30

Earlier quoted context omitted.

unfortunately replace is not supported well with modules. and they are hell bent on not supporting it well.

I've been doing forks of modules and using replace to use them in my code base extensively. I had 0 problems, it works marvelously. If you're doing some kind of global find/replace on fork, then something's definitely not right.

yes that is one approach. it shouldn't be necessary.

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

#206

Post by ninkendo »

morelisp wrote: post #200
ninkendo wrote: post #188

Earlier quoted context omitted.

Well, one thing is that enums are non-frozen by default, so you have to actively tag it as `frozen` if you want to put yourself in a scenario where you're never allowed to add cases. When clients use `switch` on a non-frozen enum from outside its defining module, Swift emits a warning if they don't have an `@unknown default:` case... so consumers of your enum will have to have default logic for handling new cases in…

> which is nice because it's your internal code and you can always update your own usages without having to worry about compatibility. Unless your services talk to each other or share some external data storage? Which is actually really common?

Services talking to each other, and storage persistence, are only tangentially related to internally defined enums. At some point you need to marshal data in and out of a serialization boundary, and it is at that point that you must handle cases you didn’t anticipate. But it’s just serialized data; it may be intended to represent the same value your enum describes, but it’s up to the deserialization code to do the right thing if it encounters a value it doesn’t recognize.

What I mean is, code that deals with serialization cannot by definition avoid the problem of “what if the data is invalid”. It’s not just enums but every aspect of your type system that must deal with this problem (typically by just throwing an error if the data is invalid, etc.)

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

#207

Post by cpeterso »

Two Go 2 proposals that interested me were:

* nillability annotations: https://github.com/golang/go/issues/49202

* Change int from a machine word size (int32 or int64) to arbitrary precision (bigint): https://github.com/golang/go/issues/19623

Sadly the nillability annotations were rejected because they weren't backwards compatible. The bigint change is also unlikely to be accepted because the issue is already five years old and there are concerns about performance.

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

#208

Post by morelisp »

ninkendo wrote: post #206
morelisp wrote: post #200

Earlier quoted context omitted.

> which is nice because it's your internal code and you can always update your own usages without having to worry about compatibility. Unless your services talk to each other or share some external data storage? Which is actually really common?

Services talking to each other, and storage persistence, are only tangentially related to internally defined enums. At some point you need to marshal data in and out of a serialization boundary, and it is at that point that you must handle cases you didn’t anticipate. But it’s just serialized data; it may be intended to represent the same value your enum describes, but it’s up to the deserialization code to do the ri…

"Invalid" is different than "unknown but safely be round-trippable" though. We round-trip unknown-to-the-local-unmarshaller enums through our protobuf services or DB layers all the time.

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

#209

Post by _0w8t »

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…

Another possibility is to use boolean flags. Of cause the compiler then will not enforce that only one of the flags is set. On the other hand on few occasions I observed how initial design with disjoint cases evolved into cases that can be set at the same time modeled with flags.

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

#210

Post by ninkendo »

morelisp wrote: post #208
ninkendo wrote: post #206

Earlier quoted context omitted.

Services talking to each other, and storage persistence, are only tangentially related to internally defined enums. At some point you need to marshal data in and out of a serialization boundary, and it is at that point that you must handle cases you didn’t anticipate. But it’s just serialized data; it may be intended to represent the same value your enum describes, but it’s up to the deserialization code to do the ri…

"Invalid" is different than "unknown but safely be round-trippable" though. We round-trip unknown-to-the-local-unmarshaller enums through our protobuf services or DB layers all the time.

If you want to carry marshaled data around without knowing what is, carry the marshaled data around. If you want to know what that data is and deal with it, marshal it into a known swift enum.

I honestly think we’re talking about different things… the guarantees a programming language gives you are independent of the guarantees a serialization format gives you.

Post reply on HN