Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 2, here we come

blog.golang.org

Post reply on HN
Print view View original

151–160 of 534 posts

Re: Go 2, here we come

#151

Post by wpietri »

I really like the humility in this part of the statement:

> After almost 10 years of exposure, we have learned a lot about the language and libraries that we didn’t know in the beginning, and that was only possible through feedback from the Go community.

It's so tempting to hold one's project back until it seems perfect. And then, even worse, to defend it as perfect in the face of real-world feedback. I really appreciate it when smart people do their best, but in full recognition that a lot of things will be learned once real use happens.

Re: Go 2, here we come

#152

Post by Phrodo_00 »

goto11 wrote: post #126
Zenst wrote: post #77

Earlier quoted context omitted.

When I started work in the early 80's as a COBOL analyst programmer, I encountered ideology vs reality of GOTO. When I learned COBOL, I was taught Jackson Structured Programming. No use of GOTO at all, even exception handling. Fast forward in my first week into work and having done a nice JSP program for the task at hand a senior came over with my code and had a chat. Then took me to the system developers who did all…

> why do CPU's still have JUMP instructions you could counter-argue Machine code is linear and executed one instruction at a time. It does not have the concept of blocks, so there is no way to have structured programming. Jumps are the only way to create a loop or conditional.

> Machine code is linear and executed one instruction at a time.

Only conceptually. In reality, it's executed out of order and branches are run in parallel.

Re: Go 2, here we come

#153

Post by dvlsg »

dunpeal wrote: post #137
DougBTX wrote: post #74

Earlier quoted context omitted.

Vague estimate is that there are 18 million programmers in the world[1] and that 4% of them use Go[2], so 0.7 million would be a starting point guess as the total number. Note that these were the first two Google search results I found for "number of programmers in the world" and "percentage of programmers in different languages" so... being off by a factor of 10 or more is likely. [1] https://www.computerworld.com/a…

These numbers seem pretty accurate, and I wouldn't expect that they're off by anywhere like a factor of 10. Think about it: the number of programmers in the world is certainly not off by 10 factor - no way there are 180 million programmers in the world, only 18 of which are visible. Similarly, there's no way that 43% of programmers in the world are Go programmers, that's again quite clearly off. I think an estimate o…

Kind of depends on how "go programmer" is defined, too. I've used go, but I certainly wouldn't call myself a "go programmer" at this point.

Re: Go 2, here we come

#154

Post by nwmcsween »

tigershark wrote: post #88
joppy wrote: post #27

I’m hoping that https://github.com/golang/go/issues/19623 will come through, and we’ll get a native “true integer” type (and hopefully a rational one as well, though maybe this is pushing it a bit). This is really something that should be implemented at the language level, so that “int” can become a true integer, yet still remain efficient in many cases. It is bizarre to me that languages boasting built-in language-l…

I am misunderstanding or really go is using the ‘int’ type that can be 32 or 64 bit depending on the system that it runs on??? If this is the case I think that is crazy and I can’t think of any useful use case for it. If it’s not the case then please explain me what that proposal is really about...

Its not crazy, its defined by the system ABI, C, C++ has this too in that can be whatever depending on the ABI, hell char can be 32 bits.

Re: Go 2, here we come

#155

Post by ghthor »

zapzupnz wrote: post #107
weberc2 wrote: post #65

Earlier quoted context omitted.

Pretty sure Go hit 1.0 in 2012 and Swift in 2014. In any case, I think the age is not a significant indicator or driver of stability (at least for these young languages), but rather the community's commitment toward stability. The Swift community definitely seems to value stability less than the Go community.

Swift can get away with it because the majority of its users are using Xcode which has excellent tools for migrating between versions of Swift, and also interop with Objective-C code. Plus, the current compiler can target a limited number of older versions’ syntax but allowing use of new APIs for some degree of forwards compatibility in large code bases. Whereas I doubt there’s one canonical Go dev environment common…

The standard go cli toolchain comes with `go fix which was used to do the update code for breaking changes or styles during the time before 1.0 release. If anything, I suspect the swift team was partially inspired by this pattern.

Re: Go 2, here we come

#156

Post by adrianmonk »

the_clarence wrote: post #104
joppy wrote: post #27

I’m hoping that https://github.com/golang/go/issues/19623 will come through, and we’ll get a native “true integer” type (and hopefully a rational one as well, though maybe this is pushing it a bit). This is really something that should be implemented at the language level, so that “int” can become a true integer, yet still remain efficient in many cases. It is bizarre to me that languages boasting built-in language-l…

Why oh why do people want a value to have different bounds depending on which system it is used? This is a source of huge confusion and why people stick to uint8 and other precise types

It's a perfectly reasonable niche use case for achieving maximum performance.

My main issues with it are:

1. Like many other performance optimizations, it is a trade-off. You may be sacrificing easy maintenance or even introducing breakage (if the person using it doesn't understand the limitations and implications). So IMHO you should only do it if you can show through profiling, etc. that the gain is real and worth it.

2. As a matter of language ergonomics, it should never be something that anyone does unknowingly. You should have to explicitly ask for it. The type name should be something blindingly obviously like "native_int" or "word_int".

Re: Go 2, here we come

#157

Post by JulienSchmidt »

This blog post doesn't answer likely the biggest of all questions: Will there be breaking changes? If so, how will those be handled?

"As a rule of thumb, we should aim to help at least ten times as many developers as we hurt with a given change" sounds like there might be breaking changes, but on the other hand Robert still talks about including new features in the Go 1 compatibility guarantee.

I'd love if the compiler would stay backwards compatible and packages / modules could be pinned to a certain version, either during import or in the package / module itself. Then one could write Go 2 code but still use packages which are not yet updated to Go 2. Personally I think that making breaking changes is a good idea, as it allows to clean up previous mistakes. However, Go should at all cost avoid incompatibilities like between Python 2 and 3.

Re: Go 2, here we come

#158

Post by ghthor »

dunpeal wrote: post #118
weberc2 wrote: post #62

Earlier quoted context omitted.

Not sure, but I wouldn't be surprised. There seem to be a lot of Go developers in China and elsewhere who don't really participate in the English-speaking Go community.

I don't really see a reason why there'd be a large iceberg of Go developers in China. There's no reason why programmers in China would use Go in higher proportion than elsewhere in the world.

The first class unicode support is one of the reasons that is big in China.

Re: Go 2, here we come

#159

Post by atombender »

nathanaldensr wrote: post #143
atombender wrote: post #70

Earlier quoted context omitted.

This doesn't seem to be a popular opinion, but I agree. It's such a pervasive functionality in concurrent programs that it really should be a built-in aspect of a goroutine. The problem with context isn't necessarily the interface, it is that it is "viral". If you need context somewhere along a call chain, it infects more than just the place you need it — you almost always have to add it upwards (so the needed site g…

Forgive me since I've never used Go, but this sounds similar to having to add the async keyword to methods in C# all the way up the stack once you attempt to use an async method, as well as having to pass CancellationTokens down the stack to support cancellation. I've noticed it pollutes code with a lot of ceremony that I wish had been added to the runtime itself. Is this what you're talking about?

Absolutely. Contexts are similar to your CancellationToken; a context contains a channel you can listen to, just like CancellationToken's WaitHandle. They're slightly simpler in that I believe CancellationToken supports registering callbacks, which contexts don't.

Go doesn't actually have async support in the sense of promises/futures (as seen in C#, JavaScript, Rust, etc.). The entire language is built around the idea that I/O is synchronous, and concurrency is achieved by spawning more goroutines. So if you have two things that you want to run simultaneously, you spawn two goroutines and wait for them. (Internally, the Go runtime uses asynchronous I/O to achieve concurrency.)

Re: Go 2, here we come

#160

Post by bradfitz »

dunpeal wrote: post #117
bradfitz wrote: post #12

Earlier quoted context omitted.

It won't. It's an explicit requirement that it will not. Or even a Python 3. I had a slide saying as such in an earlier presentation: https://docs.google.com/presentation/d/1DmyTABhGLvN0m2uHktvk... (slide 140) Ian had a good talk & doc about this too recently: https://github.com/golang/proposal/blob/master/design/28221-... https://www.youtube.com/watch?v=LqKOY_pH8u0

How can you have an "explicit requirement" not to end up like Perl 6? Nobody planned to "end up like Perl 6", it's just something that happens when your new, backwards-incompatible version of the language doesn't catch on. Also, sounds like Go 2 is going to make backwards-incompatible language changes. How is that different from Python 3, or even Perl 6?

Perl 6 decided from the beginning to break away from Perl 5 and not care about backwards compat. That was their choice. We don't make the same choice.
Post reply on HN