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

181–190 of 534 posts

Re: Go 2, here we come

#181

Post by quickthrower2 »

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.

Re: Go 2, here we come

#182

Post by [deleted] »

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.

[deleted]

Re: Go 2, here we come

#183

Post by user5994461 »

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.

C only defines char, short, int has having a minimum size of 8, 16 and 32 bits.

Re: Go 2, here we come

#184

Post by carapace »

grumpydba wrote: post #163
geezerjay wrote: post #80

Earlier quoted context omitted.

> there's an experimental feature That's not a feature but a fix for a design problem, and currently the only fix is an experimental one. For those seeking to invest their time learning a professional tool, that's a whole pile of no-nos that naturally point to a very hard pass.

"All that is excessive is insignificant.", said Talleyrand. By your standards c and c++ are not professional tools.

Not the OP, but uh, no neither of those are "professional" in the sense that professional should use them, regardless of the plain fact that "professionals" do use them.

Those are both garbage languages, despite their utility.

Re: Go 2, here we come

#185

Post by user5994461 »

drb91 wrote: post #122
the_clarence wrote: post #104

Earlier quoted context omitted.

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

People have traditionally wanted to use the maximum sized type that can fit in a register.

Traditionally the register size was too small, it's very common to have numbers above 256 or 65536. It's not true anymore with 32 bits numbers and a limit of 2 billion.

Re: Go 2, here we come

#186

Post by adtac »

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.

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.

Re: Go 2, here we come

#187

Post by mrb »

user5994461 wrote: post #183
Sharlin wrote: post #173

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.

C only defines char, short, int has having a minimum size of 8, 16 and 32 bits.

Actually C defines the minimum size of "int" as 16 bits, because it defines the minimum range it should support as [-32768 .. 32767]

See https://en.wikipedia.org/wiki/C_data_types

Re: Go 2, here we come

#188

Post by genericone »

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.

You might want to re-evaluate that line of thinking:

Here's a post from 2014 that made it to HN

http://herman.asia/why-is-go-popular-in-china

https://news.ycombinator.com/item?id=8872400

Re: Go 2, here we come

#189

Post by michaelcampbell »

vanderZwan wrote: post #106
christophilus wrote: post #72

Earlier quoted context omitted.

It’s been a while since I COBOLed, but if I recall, the COBOL decimal is similar to Currency types in languages like C#. (Maybe I’m misremembering.) If I’m right, though, it’s not a floating point number. It’s currency properly handled via integer math under the hood.

Given the age of COBOL and the age of IEEE floating points, it would be very unlikely if it used a floating point number. (And yes, I know that Conrad Zuse invented floating point over a century ago ;))

Probably implementation dependent, but the COBOL I used that put me through college used some variation of BCD (binary coded decimal).

Re: Go 2, here we come

#190

Post by PavlovsCat »

elcomet wrote: post #84
simfoo wrote: post #66

Earlier quoted context omitted.

Same here. For me it was primarily the syntax. So many people think that syntax is something you get used to, but I don't. Syntax matters a lot for me, and the way Go does it just isn't compatible with my brain. Regular grammars are great for parsers. But really, having an easy to read (conceptually!) language is way more important imho. But call me crazy when I say that I like C++ and can read it effortlessly :)

Well of course you get used to it, like you did get used to C++ (unless you were born that way which I doubt). It just takes time, you don't want to spend that time getting used to Go and that's perfectly understandable.

I can get used to something and still dislike it.. with Go it's mostly the bracket style, or put differently, the inability to turn off automatic addition of semicolons before parsing. I'd actually rather "have to" put semicolons manually, but no, I have to suffer so others don't have to put an additional line into their style guide.
Post reply on HN