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

91–100 of 534 posts

Re: Go 2, here we come

#91

Post by copperx »

igravious wrote: post #43
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…

That would be quite a fundamental change. At the moment _int_ and _uint_ have certain semantics that, if changed, would surely break many applications and libraries that rely on the current semantics. I am finding it hard to think of a more sweeping and drastic change to the core of a language. Having said that, I'm by no means a Golang expert – this is the comment of an outsider looking in. I get that the proposer i…

I've been thinking about this, and even though it's indeed a breaking change, it's one of those changes that can be easily toggled through a compiler flag. I cannot picture many libraries relying on the edge cases that Pike enumerated.

Re: Go 2, here we come

#92

Post by rootbear »

acdha wrote: post #68
rootbear wrote: post #36

Earlier quoted context omitted.

I would like to see more Unicode operators, at least as options. It's crazy that we still use * for × in 2018. Yes, I know that most US keyboards don't have that symbol but that's a solvable problem. I use an international layout on my Linux systems and can type it easily. Also, I prefer using ' for the thousands separator and was happy when C++ adopted it. It's less visually intrusive, especially with variable width…

> It's crazy that we still use * for × in 2018. Yes, I know that most US keyboards don't have that symbol but that's a solvable problem. I see the appeal but there are two problems with this: “solvable” is not the same as “easy”, and that similarly also wants fonts which make × more distinct from x. In both cases that's something which is perhaps approachable for dedicated developers but it seems likely to turn newco…

Prior to some programming languages adopting it, I don't think there was precedent for using underscore as a thousands separator, so I don't consider it a strong precedent. The first language I recall using it was Ada. But I understand that using apostrophe has problems that would likely make its adoption impossible for an existing language. I was actually surprised when C++ adopted it. Interestingly, there is a locale that uses apostrophe for the thousands separator: de_CH (Swiss German). Try this in bash:

$ LC_NUMERIC=de_CH df --block-size=\'1KB

I don't know if there is a locale that uses underscore, I didn't find one when I looked a while back. Perhaps there should be...

Re: Go 2, here we come

#93

Post by bsaul »

ilovecaching wrote: post #9

Well I must say the Go team is certainly putting in the work to avoid a catastrophic major version bump (e.g. Python). That said, any major additive change to Go, especially generics and/or try/catch will push me away from the language. If I need a well designed language, I have Rust. Go's sell for me is it's so naively simplistic it's actually useful when your team members are idiots. If they bolt on type variables,…

I really don't know why you got downvoted. The fact that go was meant to force "average" programmers produce maintainable code is an extremely important push for the language.

I do think that generics are needed if go wants to become more useful in contexts others than network middleware or data plumbing, but i'm also pretty sure that adding them will help cripple a lot of codebase in a very short term.

Re: Go 2, here we come

#94

Post by weberc2 »

llimllib wrote: post #90
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.

Go modules are extremely suitable for current work; they're as un-risky as anything labelled "experimental" could be. I've been using them for a boring professional application for about 4 months now, and there are no hassles with using them.

Same here. I've been using them in production with no issues.

Re: Go 2, here we come

#95

Post by geezerjay »

llimllib wrote: post #90
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.

Go modules are extremely suitable for current work; they're as un-risky as anything labelled "experimental" could be. I've been using them for a boring professional application for about 4 months now, and there are no hassles with using them.

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

Re: Go 2, here we come

#96

Post by copperx »

stcredzero wrote: post #46
bryanlarsen wrote: post #29

Earlier quoted context omitted.

For the first round they are testing the GO 2 selection process by applying it to proposed changes for 1.13, which limits it to non-breaking proposals. It won't get interesting until they start selecting breaking proposals.

It won't get interesting until they start selecting breaking proposals. From what I see in the past couple of decades in popular languages, is there really a justification for breaking changes, from the POV of project maintainers?

That's a good question because they ostensibly do it to get more users aboard, but in most cases, the result is the opposite (e.g., the Python 2/3 disaster).

Re: Go 2, here we come

#97

Post by bsaul »

icholy wrote: post #8

> Go 2 will be much more community-driven. Please no ...

There must be some very angry people downvoting on this comment section today. Go is very opinionated and it's quite obvious that its original design being so radical (no class, no inheritance, no generics, no macro) was only possible because it was designed by a few very experimented people with a very specific goal in mind.

I'm also worried about how being "community driven" will change the philosophy of the language.

Re: Go 2, here we come

#98

Post by Stratoscope »

vram22 wrote: post #85
barrkel wrote: post #14

Earlier quoted context omitted.

It's a pun. "Go 2" -> "Go To". Dijkstra coined "considered harmful" with the paper (letter) on "Go To statement considered harmful".

I seem to remember seeing a few articles about "'$X considered harmful' considered harmful'. Also: Why Functional Programming Matters and Why Why Functional Programming Matters Matters Edit: Just saw the sibling comment by Stratoscope: "we would see all sorts of articles under the title 'X considered harmful' for almost any X, including one titled "Dijkstra considered harmful." :)

And this classic by Scott Meyers of Effective C++ fame:

"Considered Harmful" Essays Considered Harmful

https://meyerweb.com/eric/comment/chech.html

Re: Go 2, here we come

#99

Post by copperx »

org3432 wrote: post #51
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?

If you use Goland 2018 it's pretty seamless, there are a few things missing like being able to get ptr addresses and view values in hex, and it's a little laggy compared to VS but not bad.

Is Goland's debugger written by Jetbrains?

Re: Go 2, here we come

#100

Post by jstimpfle »

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

Call me crazy but deep inside I'm a toaster.
Post reply on HN