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

171–180 of 534 posts

Re: Go 2, here we come

#171

Post by ryanianian »

simfoo wrote: post #66
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.

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 :)

C++ is definitely something to behold in terms of syntax. It's hard to justify much of the type-system syntax (meta-templates, `sizeof...(Args)`, and `std::forward(args)...` come to mind). I'm picking on argument-packs here and ignoring the beauty of initializer-lists, operator-overloading and user-defined literals (which allow great syntax in user-code but their own syntax is haunting in library-code). I doubt that C++ would look the same if the syntax were created from scratch with the current set of features.

So it's fair to say Go's syntax is unfortunately limited in expressiveness (and I too find myself mystified by how to express ideas neatly with go), but I have a hard time imagining C++ is something worth emulating without adding a whole bunch of subjective caveats to what "should" be avoided.

Re: Go 2, here we come

#172

Post by Cyph0n »

llimllib wrote: post #147
geezerjay wrote: post #95

Earlier quoted context omitted.

> they're as un-risky as anything labelled "experimental" could be. Yes, that's exactly the point, and why any decision to take a hard pass is more than obvious.

I don't understand what you mean, sorry

Think of it this way: if you spend time learning and using a feature that is not guaranteed to be there, say, a year down the line, is that a good investment?

Re: Go 2, here we come

#173

Post by Sharlin »

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

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.

Re: Go 2, here we come

#174

Post by [deleted] »

ekimekim wrote: post #110
Symmetry wrote: post #78

Earlier quoted context omitted.

Decimal floating point is actually an established thing and part of the current IEEE 754 spec. I'm not too familiar with COBOL but pretty much any modern language will offer it through a library or compiler extension. Recent IBM Power processors even have hardware support. https://en.wikipedia.org/wiki/Decimal_floating_point

Both you and the parent are correct. Decimal floating point is a long-established thing, but the vast majority of "Currency" or "Decimal" data types in modern languages are arbitrary or fixed precision (to some configurable precision) which uses integer math under the hood.

[deleted]

Re: Go 2, here we come

#175

Post by dunpeal »

ghthor wrote: post #158
dunpeal wrote: post #118

Earlier quoted context omitted.

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.

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

Re: Go 2, here we come

#176

Post by riwsky »

atombender wrote: post #70
infogulch wrote: post #23

I really really hope Go 2 can do something about `context`. Context is the biggest hidden wart of Go. We need the capabilities of context in different packaging.

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…

I agree heartily that context is viral in APIs, but would argue that that's essential to the nature of context. Accordingly: implicit association of context with a goroutine would introduce a complementary API virality issue: you now need need to worry about whether anything above or below you starts to delegate their work to separate goroutines.

Re: Go 2, here we come

#177

Post by dunpeal »

dvlsg wrote: post #153
dunpeal wrote: post #137

Earlier quoted context omitted.

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.

For the their purposes, the people who would care are those who are currently maintaining a significant Go codebase.

So even if you did Go full-time for 5 years, but then switched to Rust and now work full-time in Rust, you would not mind at all if the language added some backward-incompatible changes.

In fact you'd probably welcome them, since often you moved away because of features the language was missing.

Re: Go 2, here we come

#178

Post by jerf »

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

"int" in Go the native index type for arrays. I consider it an error to use it for anything else, and since I've adopted that policy, I've had no particular problem with ints.

Probably a good linter idea in there somewhere.

Re: Go 2, here we come

#179

Post by dunpeal »

bradfitz wrote: post #160
dunpeal wrote: post #117

Earlier quoted context omitted.

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.

But Go 2 is also introducing backwards incompatible changes, no?

Re: Go 2, here we come

#180

Post by dcow »

adrianmonk wrote: post #156
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

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…

Even Swift who’s mantra is do nothing unexpected or implicit has a machine dependent (word sized) Int type.
Post reply on HN