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

71–80 of 223 posts

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

#71

Post by masklinn »

szastamasta wrote: post #42
masklinn wrote: post #25

Earlier quoted context omitted.

I mean… yes, but also, not even remotely. Languages like Rust have solved this through the concept of editions (or whatever you want to call it), essentially package or module-level “compilation mode” which allows evolving the language without breaking the old code. The issue of the Python transition is that it was way too massive and the repercussion were way too widespread (e.g. they necessarily leaked into the API…

If you can make compiler work with both - new and old code, then yes, I totally agree. But Python expected you to transpile your code to new version and recompile while also updating many of your dependencies. And that’s not something you easily can do in large codebases. I’m not sure how editions in rust work, but if compiler can compile all editions and link them in single binary, then its something I’m totally for…

> If you can make compiler work with both - new and old code, then yes, I totally agree.

Which you can, technically even Python has that mechanism (`from __future__ import ` can change the language syntax).

However the ability to use that for the 2/3 transition was basically nil as an enormous number of apis were impacted, the syntax changes were really the easy bits, the semantics were much more difficult to deal with (talking from experience).

> I’m not sure how editions in rust work, but if compiler can compile all editions and link them in single binary, then its something I’m totally for.

That is exactly how it works.

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

#72

Post by JulianMorrison »

> Alternatively, Go 2.0 could implement "frozen" global variables

A more general change would be to implement the "var" and "val" distinction that exists in some languages.

    const x = 1 // x is a compile time alias for the untyped abstract number 1
    var x := 1  // define x at runtime to be (int)1, x is mutable
    val x := 1  // define x at runtime to be (int)1, x is immutable
Then the globals can be defined with "val".

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

#73

Post by dpatterbee »

mieubrisse wrote: post #60
tialaramex wrote: post #44

Earlier quoted context omitted.

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.

I believe new keywords are not backwards-compatible as they will invalidate any code using that as an identifier.

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

#74

Post by tapirl »

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.

I remember that someone in Go core team (Ian?) said Go 1.18 is Go 2. That means Go 2 is back compatible with Go 1.

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

#75

Post by mountainriver »

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.

I’ve never heard that take, it seemed completely botched to me. The first couple versions of py3 didn’t even work well, and they were still pushing people to cut over

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

#76

Post by friseurtermin »

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...

One caveat here is serialization. Writing your (or another package's) enum to a database will get you in trouble if you ever want to add another value in the middle. Sure, you can be careful and should document this, but who knows

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

#78

Post by tapirl »

AtroxDev wrote: post #2

From Rob Pike on reddit regarding this post[0]: The and and or functions in the template packages do short-circuit, so he's got one thing already. It was a relatively recent change, but it's there. Non-deterministic select is a critical detail of its design. If you depend on a deterministic order of completion of tasks, you're going to have problems. Now there are cases where determinism might be what you want, but t…

> but (deterministic-select cases) hey are peculiar.

It looks for most select blocks in Go code, it doesn't matter whether or not they are non-deterministic or deterministic.

But, if the default is deterministic, user code could simulate non-deterministic, without much performance loss. Not vice versa (the current design).

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

#79

Post by infogulch »

jatone wrote: post #30
fastest963 wrote: post #26

Earlier quoted context omitted.

You should be able to use "replace" to use your forked module instead of the original and you don't have to change anything.

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-...

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

#80

Post by masklinn »

da39a3ee wrote: post #45

Can someone explain this one? I couldn't see why go gave this result. > What is the value of cp? If you said [A B C], sadly you are incorrect. The value of cp is actually: [C C C]

The "trap" of the snippet is that `cp` is an array of pointers.

What it shows is that Go doesn't have a `value` per iteration, it has a single `value` for the entire loop which it updates for each iteration. This means if you store a pointer to that, you're going to store a pointer to the loop variable which gets updated, and thus at the end of the loop you'll have stored a bunch of pointers to the last item.

This is most commonly an issue when creating a closure inside a loop, as the closure closes over the binding, and since Go has a single binding for the entire loop all the closures will get the same value.

Post reply on HN