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

201–210 of 534 posts

Re: Go 2, here we come

#201

Post by weberc2 »

dunpeal wrote: post #175
ghthor wrote: post #158

Earlier quoted context omitted.

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

It's a nice feature, but several other languages have that, including languages that directly compete with Go.

Perhaps those languages also enjoy wider adoption in China than elsewhere in the world? Similarly, the software engineering industry has certainly advanced more rapidly in China than elsewhere in the world (as an artifact of China's rapid economic development), so their language adoption is likely skewed toward more recent languages (like Go).

Re: Go 2, here we come

#202

Post by erik_seaberg »

pjmlp wrote: post #165
virmundi wrote: post #128

Earlier quoted context omitted.

I don't like Go either, but I'm making my entire product on it. The reason is that I need multiple services, with a small memory foot print, which compiles to binary, all of which runs for web with either HTML or REST. As far as I can see there is no alternative. Java, which I've used for 15 years, requires a JVM, the currenct Alpine Docker for Java only go to 8, and require too much memory. Dlang looks interesting,…

In those 15 years never learned about Java AOT compilers to native code?

GCJ was abandoned. Is there an AOT Java compiler that isn't severely proprietary and more expensive than a stack of laptops?

Re: Go 2, here we come

#203

Post by Groxx »

atombender wrote: post #159
nathanaldensr wrote: post #143

Earlier quoted context omitted.

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

>Go doesn't actually have async support

I usually phrase this part of Go as: no async/await, it only has threads. But no thread handles. Everything is potentially parallel under the hood and all coordination requires external constructs like WaitGroups / chans / etc.

async/await has major complications like changing call syntax through the whole chain, so I actually prefer it this way. the lack of thread handle objects (e.g. a return value from `go func()`) is strange IMO tho.

Re: Go 2, here we come

#206

Post by lemoncucumber »

Sharlin wrote: post #173
tigershark wrote: post #88

Earlier quoted context omitted.

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

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.

Right, 64-bit Windows has 32-bit int and long and 64-bit long long (LLP64) while 64-bit unixes generally have 32-bit int and 64-bit long/long long (LP64).

Re: Go 2, here we come

#207

Post by throwaway34241 »

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

Which would you choose instead? To default to 32 bits (even on 64 bit systems) or to default to 64 bits (even on 32 bit systems).

Defaulting to 64 bit math on 32 bit systems will have a huge performance penalty on generally the slowest/oldest systems where this penalty is least desirable. It's not clear to me what the benefit to this would be for most programs.

Running 32 bit ints on 64 bit systems will cause problems handling large arrays on systems with a lot of memory. I think it also complicates generating efficient loop code, although C++ gets around this with signed integer overflow being "undefined behavior".

Of course Go has int64 and int32 types if you want to use them (and all conversions require explicit casting), but the default type for array lengths etc is the platform native type. But what is the better alternative?

Re: Go 2, here we come

#208

Post by Groxx »

curiousDog wrote: post #42

I haven't been keeping up with Go much these days but is there proper debugger support now? Or is it still a half-broken experience?

IMO: very much still half broken. Calling functions is still experimental[1] and in my experience has yet to work even once, there's no display formatting options (afaik) so you are often looking at a chunk of bytes instead of something useful (after diving several times more layers deep than other debuggers require), and you pretty often can't view memory that's in scope at another call stack location without going to that location. All of which gives you a pretty crippled experience, especially as it makes conditional breakpoints extremely limited in use.

That said, it's mostly just half, before it was like 3/4 or worse. It has improved in stability (I haven't had it randomly disconnect at all since late Go 1.9 days, but I haven't pressed it hard at all either) and GoLand's integration works well and is mostly fast. It just can't do anything except set breakpoints and view memory.

[1]: https://github.com/derekparker/delve/blob/master/Documentati...

Re: Go 2, here we come

#210

Post by codegeek »

esrauch wrote: post #168
codegeek wrote: post #162

Earlier quoted context omitted.

I always appreciate a good joke but unfortunately this has become the top comment as of now and is not adding to the real discussion around Go 2. This is a typical case of when I use my downvote power. Great joke but we should keep HN noise free.

Is it really so harmful to have it at the top of the comment thread? I think HN can be focused mainly on serious discourse without being completely humorless.

I think about it all the time. But imagine leaving the page and coming back a few hours later. Now you have to sort through tons of unnecessary comments (even if funny and humorous) while you look for the quality stuff. Quality requires sacrifice and I am willing to sacrifice the humor part for quality unless you throw in a bit of humor with quality content.
Post reply on HN