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

191–200 of 223 posts

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

#191

Post by catlifeonmars »

maerF0x0 wrote: post #86
JulianMorrison wrote: post #72

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

could be interesting, however I'd hope for something more visually distinctive that val/var as it took about 2-3 reads for me notice what was even the diff between L2 and L3.

How about `mut var`?

Edit: this likely wouldn’t fly as it would be completely backwards incompatible

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

#192

Post by christophilus »

This was a surprisingly good list. Most of these kinds of articles just consist of someone bemoaning the fact that Go isn't Haskell or whatever language they like more. But this is a legitimate list of things that could and should (in my opinion) be changed without turning Go into not-Go.

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

#193

Post by christophilus »

ternaryoperator wrote: post #164

Mine would be a much larger collections library. Having come to go from Java and finding that the standard go library has no trees, no stack, no skip list, etc. was quite a surprise. Possibly the advent of generics will stimulate development of a more robust standard collections library.

It does have a doubly-linked list which can easily serve as a stack, though. And it has a heap which is a poor man's replacement for some uses of tree. I've found that I can get quite a bit farther with the built-in Go slices, maps, and lists than I thought.

But yeah. Now that generics are in, I do hope they add a handful of common collections.

[0] https://pkg.go.dev/container/list@go1.17.6

[1] https://pkg.go.dev/container/heap@go1.17.6

[2] https://pkg.go.dev/container/ring@go1.17.6

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

#194

Post by mikepurvis »

catlifeonmars wrote: post #190
mikepurvis wrote: post #132

Earlier quoted context omitted.

Isn't that an implementation choice? Like in C++, a const is absolutely allocated since you can get a pointer to one. And then you can do horrible stuff like const_cast that pointer and mutate the value, and the possibility of that occurring prevents the compiler from doing certain const-related optimizations.

> Like in C++, a const is absolutely allocated since you can get a pointer to one. If I understand you correctly, you claim you can get a pointer to a Go const. This is not the case. For example, the following code will not compile: const a int = 1 var b *int = &a ./prog.go:5:15: cannot take the address of a See https://go.dev/play/p/QPxP-tF6qIs for a live example.

I'm not an active golang user, so it wasn't a comment on that, more just on the GP's assertion that a const had to be an abstracted value. It sounds like that is indeed the case in Go (an implementation choice), but more broadly, I wouldn't expect "const" to mean anything more to most programmers than "give me an error if I or anyone else try to modify this thing."

And in C++, it certainly isn't. Even a constexpr in C++ is a thing you can get a pointer-to— C++'s only guarantee with a constexpr is that it has to be possible to evaluate it at compile time.

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

#196

Post by catlifeonmars »

mikepurvis wrote: post #194
catlifeonmars wrote: post #190

Earlier quoted context omitted.

> Like in C++, a const is absolutely allocated since you can get a pointer to one. If I understand you correctly, you claim you can get a pointer to a Go const. This is not the case. For example, the following code will not compile: const a int = 1 var b *int = &a ./prog.go:5:15: cannot take the address of a See https://go.dev/play/p/QPxP-tF6qIs for a live example.

I'm not an active golang user, so it wasn't a comment on that, more just on the GP's assertion that a const had to be an abstracted value. It sounds like that is indeed the case in Go (an implementation choice), but more broadly, I wouldn't expect "const" to mean anything more to most programmers than "give me an error if I or anyone else try to modify this thing." And in C++, it certainly isn't. Even a constexpr in…

Ah gotcha. Makes sense. The way I typically think of Go const is more akin to a typed macro, rather than a first class value reference where it is expanded in place. Notably, in Go constants cannot contain structs, arrays, so they have much less to do with mutability than in, say, in C++.

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

#198

Post by Jeff_Brown »

mountainriver wrote: post #77

I would really love to see default parameters and struct values. I jump between Python and Go in my day job and Go is a much better language overall but things like this make it painful

Default parameters have always struck me as dangerous. (And for my day job I use Python.)

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

#199

Post by dietr1ch »

ninkendo wrote: post #188
dietr1ch wrote: post #169

Earlier quoted context omitted.

Is it solved? How do you decide which enums are final and which ones need to be non-exhaustive to allow evolving the code? I think that Go's decision stems from protocol buffers as they allow to push new values through old binaries, which is a must once you grow enough. https://developers.google.com/protocol-buffers/docs/proto3#e...

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…

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

Yeah, non-frozen by default makes a lot of sense. The only gotcha left is that you can't retract from adding frozen, but that's ultimately behavior you want and something that must be able to bite you back.

> if you use your own enums in your own module and don't make them public, it treats them as if they're always frozen... which is nice because it's your internal code and you can always update your own usages without having to worry about compatibility.

That's neat

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

#200

Post by morelisp »

ninkendo wrote: post #188
dietr1ch wrote: post #169

Earlier quoted context omitted.

Is it solved? How do you decide which enums are final and which ones need to be non-exhaustive to allow evolving the code? I think that Go's decision stems from protocol buffers as they allow to push new values through old binaries, which is a must once you grow enough. https://developers.google.com/protocol-buffers/docs/proto3#e...

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?

Post reply on HN