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

281–290 of 534 posts

Re: Go 2, here we come

#281

Post by paulddraper »

vram22 wrote: post #103
treis wrote: post #48

Earlier quoted context omitted.

>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. My experience was similar. In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those…

> In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs. This is like comparing apples and oranges, or at least, like comparing apples and apple-orange hybrids :) Just saying that Rails (R…

Is this the same type system that famously forces you to cast items in your collections to the universal supertype?

Re: Go 2, here we come

#282

Post by AsyncAwait »

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

Weird syntax? Maybe you should try Haskell, OCaml, Erlang, or even Rust instead. Then come back to Go and tell me if it's actually that "weird."

It's a bit Pascale-y, which may be a turn off to some.

I do wonder why you'd consider Rust, (or even Haskell), to have weird syntax?

Re: Go 2, here we come

#283

Post by AsyncAwait »

paulddraper wrote: post #281
vram22 wrote: post #103

Earlier quoted context omitted.

> In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs. This is like comparing apples and oranges, or at least, like comparing apples and apple-orange hybrids :) Just saying that Rails (R…

Is this the same type system that famously forces you to cast items in your collections to the universal supertype?

Everyone's aware of the lack of generics, it's been rehashed to death. This is a discussion on Go 2, which will add them.

The current type system is poor, but still better than dynamic languages.

Re: Go 2, here we come

#284

Post by AsyncAwait »

Cyph0n wrote: post #172
llimllib wrote: post #147

Earlier quoted context omitted.

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?

> a feature that is not guaranteed to be there, say, a year down the line, is that a good investment?

The Go devs have been extremely clear that Go modules is THE solution to Go packages.

Re: Go 2, here we come

#285

Post by atombender »

dolmen wrote: post #248
atombender wrote: post #70

Earlier quoted context omitted.

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 have written the 'contextio' package that may be useful to you. It provides io.Reader and io.Writer wrappers that handle context cancellation. This allows to transparently add optinal context cancellation awareness to routines that work with I/O without injecting context as argument. Doc: https://godoc.org/github.com/dolmen-go/contextio Example: https://godoc.org/github.com/dolmen-go/contextio#example-pac...

Cool, thanks!

Re: Go 2, here we come

#286

Post by meddlepal »

AsyncAwait wrote: post #276
meddlepal wrote: post #120

Earlier quoted context omitted.

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…

I like Kotlin and I write a lot of Kotlin for personal stuff, but I think it is a niche language in the backend/server space and hardly qualifies as mainstream outside Android.

Python with PEP484 is pleasant.

The concurrency story in Java is great already and it is going to improve once Project Loom is integrated.

I fail to see how Java is significantly more verbose than Go. At least not the core libraries. The ecosystem is a mess but getting better. Java 11 with `var` for local variable inference is pretty much on par with Go in terms of verbosity.

Rust brings a lot of new things to the table but its main competitor IMO is C and C++. I've done very little Rust but what I have seen I like (though there are some things I dislike too... like lack of keyword args... a minor nit I suppose).

Scala is a shit show to maintain with some teams.

Re: Go 2, here we come

#287

Post by diegs »

bdamm wrote: post #47
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,…

Isn't the premise of Go that a team sufficiently large enough will eventually act as a collective idiot in terms of code maintenance? I'm looking forward to some real research on the question of whether Go's design choices have had real world results in improving productivity with supersize code bases.

Anecdotally (n = 10 or so) every Go codebase I've worked on has devolved into a trash fire, so no. Turns out collective idiots can write horrible systems in any language.

Re: Go 2, here we come

#288

Post by eridius »

SwellJoe wrote: post #256
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…

I just started learning Rust for a small project, and I found its "one clear path" model very appealing (I don't know if it is a formal goal, or if it's just a happy accident based on a smaller, more focused, community). It doesn't just apply to the package manager, but that's one of the first bits a beginner sees. Rust has a single, easy-to-find, "pretty good" answer for nearly every question a beginner asks, at lea…

Rust explicitly set out to have an excellent built-in package management solution. They tapped Yehuda Katz early on for this.

Re: Go 2, here we come

#289

Post by weberc2 »

dunpeal wrote: post #215
weberc2 wrote: post #201

Earlier quoted context omitted.

Perhaps those languages also enjoy wider adoption in China than elsewhere in the world? Similarly, the software engineering industry has certainly advanced more rapidly in China than elsewhere in the world (as an artifact of China's rapid economic development), so their language adoption is likely skewed toward more recent languages (like Go).

These are good points, but the bottom line is "we don't really know". So I'd caution against assuming the number is very high just because it fits our hopes.

I agree, but I don't think anyone is assuming or hoping in this thread. Just speculating, which is what you do when "we don't really know". :)

Re: Go 2, here we come

#290

Post by earenndil »

friday99 wrote: post #268
WakiMiko wrote: post #195

Earlier quoted context omitted.

Rust has a `usize` which is 32 or 64 bits depending on the platform and also serves as the native index type for arrays and such.

Yeah, that makes sense because you need some type to span the address space and that depends on the size of the address space. That is what int is used for in go, though why they chose signed rather than unsigned is confusing. unsigned you would never have to do negative bounds checks and you can prove a lot of other useful things if you know your index is always positive.

I don't know how go does it, but in some languages negative indices count backwards from the rear end. E.G. myarr[-1] == myarr[myarr.length-1].
Post reply on HN