261–270 of 534 posts
Am I reading this right that the list in the #Proposals header are the only proposals from the Go2 bucket that are being considered for 1.13? I was hoping "check" would make the cut.
I'm learning Go, just a naive question, why does Go put the variable type at the end of declaration, is this an absolute need? no other widely usage language does that, and it just feels odd to me.
procedure SetColor
(const NewColor: TColor; const NewFPColor: TFPColor); virtual;
fn do_twice(f: fn(i32) -> i32, arg: i32) -> i32
f func(func(int,int) int, int) func(int, int) intI'm learning Go, just a naive question, why does Go put the variable type at the end of declaration, is this an absolute need? no other widely usage language does that, and it just feels odd to me.
You get used to it. Having to deal with this kind of differences between different programming languages is a lesser concern in the grand scheme of things.
I'm learning Go, just a naive question, why does Go put the variable type at the end of declaration, is this an absolute need? no other widely usage language does that, and it just feels odd to me.
Pascal did it: procedure SetColor (const NewColor: TColor; const NewFPColor: TFPColor); virtual; Rust does it too: fn do_twice(f: fn(i32) -> i32, arg: i32) -> i32 Go is similar, but less symbols: f func(func(int,int) int, int) func(int, int) int
Earlier quoted context omitted.
I really don't know why you got downvoted. The fact that go was meant to force "average" programmers produce maintainable code is an extremely important push for the language. I do think that generics are needed if go wants to become more useful in contexts others than network middleware or data plumbing, but i'm also pretty sure that adding them will help cripple a lot of codebase in a very short term.
Is there a definitive source for the "average" programmers target? I'd always considered it a tongue-in-cheek response to architecture astronauts who sneer at Go's simplicity.
-- Rob Pike
From https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr...
And there are other hints on https://talks.golang.org/2012/splash.article
Earlier quoted context omitted.
For the first round they are testing the GO 2 selection process by applying it to proposed changes for 1.13, which limits it to non-breaking proposals. It won't get interesting until they start selecting breaking proposals.
It won't get interesting until they start selecting breaking proposals. From what I see in the past couple of decades in popular languages, is there really a justification for breaking changes, from the POV of project maintainers?
Earlier quoted context omitted.
It may be crazy but it's not exactly without precedent. Neither C nor C++ fix the sizes of the fundamental integer types, although for backward-compatibility reasons popular 64-bit platforms still have 32-bit `int` and even `long`. But yeah, there's a reason eg. Rust has no `int` and friends but `i32` etc. instead.
Rust has a `usize` which is 32 or 64 bits depending on the platform and also serves as the native index type for arrays and such.
I'm curious if making go an ISO standard was ever considered.
Given that go is already pretty well specified (and, perhaps more importantly, has 2 mature implementations) it's hard to see what advantages having it formally standardised would bring. https://golang.org/ref/spec
Earlier quoted context omitted.
It's a rational practice when your language allows casting pointers to integers. Since the size of the pointer itself will vary based on the underlying architecture, you need an integer type which will also vary based on the underlying architecture.
I feel you, but, that's uintptr. int is more useful as the "native type" for array/slice length/cap/indexing