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

271–280 of 534 posts

Re: Go 2, here we come

#271

Post by pvg »

quickthrower2 wrote: post #223
adtac wrote: post #186

Earlier quoted context omitted.

The problem with overflow isn't just needing to store numbers larger than 2 billion. Sometimes, intermediate values are larger than that even if the final result isn't. Take averaging as a very simple example. Doing (a + b) / 2 will overflow if a and b are sufficiently large, even if the average will always fit in 32 bits. Things like this go unseen for years.

I get you point. I'd probably go float/double precision for that task.

Then you can lose precision that you might actually need - a bug that's even more annoying to track down than straight overflow.

Re: Go 2, here we come

#272

Post by usrusr »

icedchai wrote: post #249
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...

Yeah, sounds crazy. It only worked for C for 40+ years...

Ignoring the basic int type and using a zoo of preprocessor defines instead is what has worked for C all that time.

But I still think that native types have their place. It can often be quite reasonable to accept serious limitations on narrow machines where the performance gains won by the trade-off are desperately needed, lift those limitations on wider machines and grant an enormous safety margin on the widest architectures. When you dive deeper, the values where this makes sense still tend to be "index-like", as GP stated, but they don't have to strictly be indexes (e.g. IDs, a wider machine will be capable of working on bigger datasets and therefore be more likely to exhaust a given width of IDs, all indexes are identifiers but not all identifiers are indexes)

Re: Go 2, here we come

#273

Post by keyle »

Waterluvian wrote: post #141

As a newcomer to Go, by an immensely wide margin, the hardest, most frustrating thing, which soured the language for me, is whatever the heck package management is in Go. There's like three or four different angles, all of which overlap. Some are official. Some aren't. The unofficial ones seem more popular. They're all kind of incomplete in different ways. And it was all such a frustrating migraine to try and figure…

It's ironic from a language that invented gofmt...

Re: Go 2, here we come

#274

Post by paulddraper »

quickthrower2 wrote: post #181
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…

Meh I use C# and I rarely need an int bigger than 2147483647, and if I do I use a long which gets me up to 9223372036854775807, and if I need more than THAT then I'll use a math library of some sort.

There have been 1,543,530,695,158 milliseconds since epoch.

Re: Go 2, here we come

#275

Post by LukeShu »

toyg wrote: post #216
throwaway34241 wrote: post #207

Earlier quoted context omitted.

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

The subset of Go users who deploy on 32bit hardware in 2018 and care about performance at that level, is likely to be vanishingly small.

32 bit ARM is still very common.

Re: Go 2, here we come

#276

Post by AsyncAwait »

meddlepal wrote: post #120
kbd wrote: post #105

Earlier quoted context omitted.

> It does nothing better than any of the existing mainstream languages... Why say this? Even if you don't like Go it's objectively false. What languages are you comparing it to, Java? C++?

Java and Python. It's two closest peers. Go does not compete with C or C++ in my mind because of GC. The ONLY thing it does better is packaging because of its standalone native binaries. But most folks using Go are writing software for servers and those are predominantly Linux x86_64... so ¯\_(ツ)_/¯

> Java and Python. It's two closest peers.

See, I don't particularly enjoy Go, but that's because of its weak type system, which Python is no better at. Still, I understand that a lot of people enjoy Python, so good that it exists.

Java is too verbose. I'd had understood if you have said Kotlin, but Java is not that much better, (yes, it has generics, but I myself prefer the way they're implemented in Rust/Swift).

I feel like your examples are not much better than Go and in some ways may be worse, (concurrency?). If you have said Rust, Swift, Scala, Kotlin...I still wouldn't want Go to die, but at least could get behind the argument.

Re: Go 2, here we come

#277

Post by AsyncAwait »

pjmlp wrote: post #259
erik_seaberg wrote: post #202

Earlier quoted context omitted.

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

Just because the majority of them are commercial doesn't change the fact that they exist. They are more expensive than a stack of laptops, because FOSS made the business of selling software tooling only worthwhile when targeting enterprise customers. Those enterprise customers have developers using these compilers almost since Java exists.

> Just because the majority of them are commercial doesn't change the fact that they exist.

No, but it does explain why Java is not a worthwhile option for OP.

Re: Go 2, here we come

#278

Post by bdamm »

meddlepal wrote: post #41
rjplatte wrote: post #6

I'll be very sad if this goes the way of Perl 6

Honestly that would be great if it took the momentum out of Go and killed the language. I loathe working in Go.

Nobody is forcing you to use Go. If you loathe it so much then for goodness sake quit your job and do something you do find challenging or enjoyable!

Re: Go 2, here we come

#279

Post by paulddraper »

floatboth wrote: post #214
asien wrote: post #26

I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows. Haven’t tried it since. Hope lots of this change to make the language more welcoming for Newcomers to the language.

hah. GOPATH is the only thing I like about Go. I have all (non-Go) repositories cloned as URL-style paths e.g. ~/src/github.com/user/repo. I strongly dislike the non-standard internals (horrendous custom assembler, direct usage of syscalls instead of libc) and the "developers are too stupid to use this" attitude towards modern language features.

> direct usage of syscalls instead of libc

Why do you want to use libc for Go? You wouldn't use the Rust standard library for Go, why the C standard library?

Re: Go 2, here we come

#280

Post by AsyncAwait »

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

Why is that a problem? There's int8/16/32/64 for when you need to be specific.
Post reply on HN