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

81–90 of 223 posts

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

#81

Post by donatj »

amw-zero wrote: post #67
donatj wrote: post #56

Earlier quoted context omitted.

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.

Depending on code review instead of a static type system does not scale. Look at all of the memory safety security vulnerabilities that are solved by "simply making sure to manage memory correctly." Also: variableDefinedInAFarAwayModule := 17 ... TestSomething(variableDefinedInAFarAwayModule) It's not always as clear as a constant value being passed to an incorrect type.

I don't understand your example here, that's not going to compile.

variableDefinedInAFarAwayModule is definitionally type int and will not be cast. It is also unpublished, so you couldn't be using it for a faraway module?

Your 17 in the previous example has it's typed determined at compile time which is why it can be a problem.

see: https://go.dev/play/p/jEdAhKDeLy6

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

#82

Post by oblio »

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.

It wasn't well executed. The standard migration tool (2to3) was kind of considered a failure and the better one (six) wasn't ready, or even around at the time.

Python came this || close to dying during the migration, its users all having moved to other languages. Primarily data science saved it and then some time passed and libraries moved on, etc, and after a while the cost benefit calculation started swaying towards Python3, probably after 3.3 at least, so 4 years after Python3's launch.

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

#83

Post by jaggederest »

rocqua wrote: post #51
assbuttbuttass wrote: post #33

Earlier quoted context omitted.

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.

Is there no equivalent to a lexical scope let definition?

let {

  var err := error
  
  scoped code

}

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

#84

Post by tapirl »

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

No need to invent a new keyword, it is ok to just use "const": https://github.com/go101/go101/wiki/An-immutable-value-propo...

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

#85

Post by avgcorrection »

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.

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

#86

Post by maerF0x0 »

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.

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

#87

Post by lanstin »

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

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

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

#88

Post by JulianMorrison »

tapirl wrote: post #84
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".

No need to invent a new keyword, it is ok to just use "const": https://github.com/go101/go101/wiki/An-immutable-value-propo...

No, they are very different conceptually.

- A const is an abstracted value.

- A variable is an allocated piece of memory.

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

#89

Post by amw-zero »

masklinn wrote: post #70
amw-zero wrote: post #55

Earlier quoted context omitted.

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.

> Really not sure what you're talking about. Have you considered reading?

Friend - this is a learning opportunity. Check the upvotes.

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

#90

Post by rplnt »

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

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.
Post reply on HN