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

331–340 of 534 posts

Re: Go 2, here we come

#331

Post by cdoxsey »

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.

FWIW GOPATH has not been required since 1.8. It now defaults to $HOME/go if not set.

Go is pretty easy to get up and running in Windows. There's an installer for the compiler and you can install vscode and the Go extension pretty quickly.

Windows is an afterthought for most programming languages (ever try ruby or c++?) and Go's cross-platform capabilities were a breath of fresh air.

Re: Go 2, here we come

#332

Post by hhmc »

copperx wrote: post #96
stcredzero wrote: post #46

Earlier quoted context omitted.

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

C++11 introduced breaking changes (https://stackoverflow.com/questions/6399615/what-breaking-ch...) but is widely regarded as a boon to the language.

Re: Go 2, here we come

#333

Post by xyproto »

pxia wrote: post #304
kbirkeland wrote: post #301

Earlier quoted context omitted.

I'm curious what the motivation was to use int instead of uint considering indexes cannot be negative in Go.

Because you want to represent errors. For example a find() function that returns the index of some element: you want to return -1 when the element doesn't exist.

Returning -1 instead of an error is abusing the type system. In C, there is no error type, so it might be excusable there, but it is inexcusable in Go, IMO.

Re: Go 2, here we come

#334

Post by aoeusnth1 »

dmurray wrote: post #233
13415 wrote: post #86

Earlier quoted context omitted.

Makes no sense to me to redefine existing integer types. Why not introduce a primitive type "num" for arbitrary precision rational numbers instead? As a long-time Racket and Scheme user, I'd say that arbitrary precision numbers as default bring more disadvantages than advantages. As an option with syntax support Yes, but not as a default. it just makes it harder to port all kinds of code that relies on modulo arithme…

> Why not introduce a primitive type "num" for arbitrary precision rational numbers instead? Rationals aren't supported natively by processors, so there's no real need to handle this as a primitive instead of letting people to use a library for it. Adding them to the base language just because some people would find it convenient would clash with Go's explicit minimalist philosophy.

"X isn't supported natively by processors, so there's no real need to handle this as a primitive instead of letting people to use a library for it" is a general-purpose argument to cherry pick which primitives you support and which ones you don't. Surely this isn't your actual reason you choose to oppose Rationals / BigIntegers as primitives while accepting hashmaps and arrays?

Re: Go 2, here we come

#335

Post by bradfitz »

dunpeal wrote: post #179
bradfitz wrote: post #160

Earlier quoted context omitted.

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?

See the doc I linked above: https://github.com/golang/proposal/blob/master/design/28221-...

Probably not. We can add things and we can opt-in remove things (e.g. user says they want v1.14 of language gets them new language features and removes some language features), but we can't change the semantics of existing programs. That is, if a program compiles with two different language versions, that program should mean the same in both versions.

Re: Go 2, here we come

#336

Post by naibafo »

Someone wrote: post #101
naibafo wrote: post #15

Earlier quoted context omitted.

> Edgar Dijkstra: Go To Statement Considered Harmful

Edsger, nog Edgar ( http://www.cs.utexas.edu/users/EWD/ ) Dijkstra would lambast you for that error :-)

He probably would :)

But I just quoted the linked PDF a few comments above in the chain.

Re: Go 2, here we come

#337

Post by ilovecaching »

pjmlp wrote: post #31
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,…

Languages are products as well, either they grow to fulfil the needs of their customers or their fade away.

What if the need is for a small language without generics?

Re: Go 2, here we come

#338

Post by smarterclayton »

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…

We do use it but mostly in middleware.

However, the reason we don’t use that more is partially because of the viral nature of context - it came late in kube lifecycle, so we didn’t ensure it everywhere and now it’s a lot harder to wire (clients have been iterated on for a while).

I have a closed PR from 2015 to kube that added per request ID tracking that we closed as “wait until we have context everywhere” and we’re still waiting.

Re: Go 2, here we come

#339

Post by glangdale »

I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments.

As for all the folks claiming they'll leave Go if it gets generics, it's faintly reminiscent of Mac fanboys claiming PowerPC chips were the Very Best right up until this was obviously not true. C++ generics are a PITA in many ways, but you can be insanely productive in the STL without having to hand-roll everything and with good type safety.

Despite the pain, I've been amazed at how easily you can build up some really complex data structures as pretty much one-liners ("Oh, I need a vector of maps from a pair of Foo to a set of Bar") that would either take a preposterous amount of code (or be a type-unsafe disaster waiting to happen) without generics.

Hopefully the final Go 2 generics proposal will capture some of this goodness without some of the horrifying C++ issues (error messages, bloat, sheer brain-numbing complexity).

Re: Go 2, here we come

#340

Post by nordsieck »

kbirkeland wrote: post #301
jerf wrote: post #178

Earlier quoted context omitted.

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

I'm curious what the motivation was to use int instead of uint considering indexes cannot be negative in Go.

> I'm curious what the motivation was to use int instead of uint considering indexes cannot be negative in Go.

I want to emphasize that I do not know the true answer to this question.

I think that indexes are int to play nicely with a decrementing loop counter. Doing:

    for i := len(n) - 1; i >= 0; i-- { fmt.Println(n[i]) }
requires i to be signed due to the last iteration.
Post reply on HN