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

111–120 of 223 posts

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

#111

Post by JulianMorrison »

avgcorrection wrote: post #85
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".

I don’t understand why Scala chose “var” for mutable variables. A variable is not defined by being mutable—it is defined by being variable, i.e. not a constant. And it is immutable in math (where we don’t have to care about performance). So “val” is also a “var”, conceptually.

I think it was Fortran which introduced the equivalence between programming variables (that are a mutable piece of memory) and mathematical variables (which describe a relationship). But they aren't really the same. And "variable" has become too fixed in computer science usage to be repaired back to its earlier mathematical meaning.

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

#112

Post by bruce343434 »

avgcorrection wrote: post #85
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".

I don’t understand why Scala chose “var” for mutable variables. A variable is not defined by being mutable—it is defined by being variable, i.e. not a constant. And it is immutable in math (where we don’t have to care about performance). So “val” is also a “var”, conceptually.

if it is not constant, it must be variable i.e. changing. Mutation = change.

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

#113

Post by JulianMorrison »

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.

Fair point. "value" and "var" then, perhaps?

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

#114

Post by lanstin »

tapirl wrote: post #98
lanstin wrote: post #87

Earlier quoted context omitted.

Any time there is more than one channel being selected for it needs to cover them all equally.

Equality is meaningful only if at least two case operations are always non-blocking. This is rare in practice. In fact, in practice, sometimes, I do hope one specified case has a higher priority than others if they are all non-blocking.

As far as priority goes, most interesting cases will have priority based on the data in the read, except for this specific case of a done chan el and a data channel. I used that pattern at first but have been moving away from it. To be sure i am mostly writing long lived processes with fixed pools of worker go routines and either never exit or exit based on WaitGroups determining the work is all done.

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

#115

Post by geenat »

I'd like to see ergonomics improvements, particularly to function parameters.

The current best practice of "functional options" and long function chains results in far too many function stubs ... its a minimum of 3 extra lines per parameter. Parameter structs require a whole extra struct.

Suggestion: Just borrow named / optional parameters from Python. It would cut down length and complexity of Go code drastically.

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

#116

Post by masklinn »

rplnt wrote: post #90
masklinn wrote: post #10

Earlier quoted context omitted.

> 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’…

Every time I see discussion about go and enums there are people who are referencing these mythical C-like enums that had never existed. It's some sort of constructed memory. And I'm sure there are languages that do enums "properly", but it's always C/C++ that is referenced.

The point here has little to do with Go, which you can see by the quote it replies to having nothing to do with go:

> We use enums heavily to force devs who use our code into good choices

the note is that this is very much language-dependent and there are languages which get it very, very wrong.

> And I'm sure there are languages that do enums "properly", but it's always C/C++ that is referenced.

That makes no sense, the original comment obviously assumes a language which does it "properly".

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

#117

Post by rplnt »

masklinn wrote: post #116
rplnt wrote: post #90

Earlier quoted context omitted.

Every time I see discussion about go and enums there are people who are referencing these mythical C-like enums that had never existed. It's some sort of constructed memory. And I'm sure there are languages that do enums "properly", but it's always C/C++ that is referenced.

The point here has little to do with Go, which you can see by the quote it replies to having nothing to do with go: > We use enums heavily to force devs who use our code into good choices the note is that this is very much language-dependent and there are languages which get it very, very wrong. > And I'm sure there are languages that do enums "properly", but it's always C/C++ that is referenced. That makes no sense,…

Sorry, my comment wasn't trying to address (let alone bash) the original comment in any way here, just a tangent based on your note about C# enums.

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

#119

Post by lanstin »

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

This has suprised me twice, once in my own code where i ended up ot really understand the problem but just mutated the code till it worked and then later when I was helping someone with their code and the way they structured the question made the still suprising answer memorable.

A fix wouldn't be unwelcome but it seems it would have a good chance to cause performance regression - a lot more allocated values maybe on a lot of inner loops. I guess escape analysis might help avoid the allovations in the general case. ?

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

#120

Post by usrbinbash »

tapirl wrote: post #78
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).

> Not vice versa (the current design).

    select {
       case: chan3_whichItreatTheSameAsChan2
    }
Post reply on HN