Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.13 Release Notes

golang.org

Post reply on HN
Print view View original

61–70 of 264 posts

Re: Go 1.13 Release Notes

#61

Post by burntsushi »

pcwalton wrote: post #28
gameswithgo wrote: post #2

I like the way Go proceeds as a language, with features added very very slowly and the compiler and tools regularly improving. I hope Rust can settle down into a similar focus soon.

Rust moves slowly too. I'm not sure where the idea that Rust makes changes willy-nilly came from, but anyone saying that is deeply unfamiliar with the RFC process. It's extremely hard to get new features into Rust.

Maybe Rust moves slowly, but not nearly as slow as Go. I know because I use both languages daily. I spend almost no time in Go code keeping up with deprecations, new APIs and new language features. Not all of those things need to go through the RFC process. For example, I don't think there's any backpressure against deprecating stuff right now. As soon as a replacement comes along, a deprecation pretty routinely occurs just a couple releases (a few months) after it. I don't spend a ton of time in Rust responding to churn, but it's definitely noticeable.

This is why I've been bleating a bit more now than I have before about reducing churn.

N.B. On reflection, perhaps I do have some bias here. My daily work on Go is mostly for $work, and involves one large codebase. My daily work on Rust, however, involves maintenance of dozens of crates. So if there's churn, I feel it repeatedly. So its effect might be magnified for me personally.

Re: Go 1.13 Release Notes

#62

Post by rb808 »

sime2009 wrote: post #21

How does Go compare to Rust these days with respect to language maturity, community size and general maturity/availability of libraries? So far I've found Rust more interesting and pushes the envelope a bit more. But what is the sales pitch for Go?

I just wish there were more jobs for either. They're both much less popular than I expected.

Re: Go 1.13 Release Notes

#63

Post by Touche »

bsaul wrote: post #49
gameswithgo wrote: post #2

I like the way Go proceeds as a language, with features added very very slowly and the compiler and tools regularly improving. I hope Rust can settle down into a similar focus soon.

Rust can't settle down right now, because it still has to make necessary changes to critical parts of the language, such as async. Go always had a very narrow and precise ambition and scope (a better C, aimed at server-side data plumbing). Which is the reason why it was able to nail a set of features from the start and keep it that way. Rust has a much wider ambition : all the modern languages facilities (generics, m…

I don't know if "all the modern languages facilities" was a goal of Rust from the start. It seemed like the initial goal was to be able to develop a web browser with memory safety.

"all the modern languages facilities" seems to be something that's come along more recently (last couple of years) as a result of a lot of non web browser developers taking an interest in the language.

Re: Go 1.13 Release Notes

#64

Post by donatj »

Contrary to what someone else has said, this is my least favorite release of Go ever.

I'm salty about how the proxy, which is enabled by default, makes it so much more difficult to pull private modules by having to set environment variables on everyone's individual machines.

I've got an issue being discussed on GitHub about it https://github.com/golang/go/issues/33985

Re: Go 1.13 Release Notes

#65

Post by onei »

mfer wrote: post #60
onei wrote: post #57

Earlier quoted context omitted.

Why do you need a proxy to fetch the modules in the first place? It seems a little odd for a package manager.

The jFrog folks provided a good example with GoCenter. It was optimized for the performance use case. If you used their proxy, released at the end of last year I think, the time to pull a dependency was significantly less than to pull it from GitHub. This leads to things like faster CI builds.

Ah, that makes more sense. I was imagining it as a routing thing rather than caching the packages.

Re: Go 1.13 Release Notes

#66

Post by DuskStar »

astockwell wrote: post #58
zubspace wrote: post #25

I actually just started to use go on windows just to check it out. First impressions from a newbie: - Getting started with go and vscode is kinda bad right now. I installed go, set up GOPATH, installed all kinds of extensions in vscode and then, somewhere down the official tutorial I learn about GO111MODULES, go mod init, vendor folders and the language server... I was completely confused and still am. I removed all…

I am trying to help a Windows-using team ramp-up on Go dev, and it's pretty rough. Currently my advice to them is ditch VS Code and download GoLand, the editor change is jarring but the experience is much more fluid on Windows overall. Also transparent support for modules, per project. For compiling when your code (or a package you're using, e.g. sqlite) has a cgo dependency - afaik YES you will need to go down the d…

Personal recommendation, if you need to stay on windows and don't want GoLand - set it up to use wsl 'remotely' [0]. All the offline ability of a local environment, but with the software compatibility (and ecosystem) of linux. (That being said, GoLand has been great on both Windows and Mac for me - the only thing VSCode does that GoLand doesn't is remote dev, and that's supposedly coming soon™ [1])

0: https://code.visualstudio.com/docs/remote/wsl

1: https://blog.jetbrains.com/go/2019/08/15/2019-3-roadmap/

Re: Go 1.13 Release Notes

#67

Post by root_axis »

littlestymaar wrote: post #53
bsaul wrote: post #49

Earlier quoted context omitted.

Rust can't settle down right now, because it still has to make necessary changes to critical parts of the language, such as async. Go always had a very narrow and precise ambition and scope (a better C, aimed at server-side data plumbing). Which is the reason why it was able to nail a set of features from the start and keep it that way. Rust has a much wider ambition : all the modern languages facilities (generics, m…

> a better C, aimed at server-side data plumbing I agree with all what you said but this. Go isn't a better C, it's a better Java.

I think in practice it has become something closer to a better python than a better java.

Re: Go 1.13 Release Notes

#68

Post by DuskStar »

onei wrote: post #65
mfer wrote: post #60

Earlier quoted context omitted.

The jFrog folks provided a good example with GoCenter. It was optimized for the performance use case. If you used their proxy, released at the end of last year I think, the time to pull a dependency was significantly less than to pull it from GitHub. This leads to things like faster CI builds.

Ah, that makes more sense. I was imagining it as a routing thing rather than caching the packages.

Also, the dependency resolution really just relies on `go.mod` and `go.sum` - having to download the entire git tree just to access different versions of those files is a bit inefficient. (It also makes it harder for 3rd parties to serve different versions of a dependency to different people - and easier for Google to do the same)

Re: Go 1.13 Release Notes

#69

Post by remus »

derefr wrote: post #30
gameswithgo wrote: post #2

I like the way Go proceeds as a language, with features added very very slowly and the compiler and tools regularly improving. I hope Rust can settle down into a similar focus soon.

I feel like Go is the way it is, mostly because its maintainers are also responsible for the continued productivity of thousands of engineers working on Google's numerous Go codebases. Any "breaking change" that requires rewriting Go code is a tangible negative for them, in that it'll interrupt Googlers from getting real work done, and the blame will come back to them. In a sense, Go is more like a corporate-internal…

Personally I think this is a pretty positive thing. If a language is at all popular then any breaking change is going to mean work for users, and having those users sitting next to you in the office keeps it fresh in your mind when you're tempted to make that "one small change" to the language.

Re: Go 1.13 Release Notes

#70

Post by pcwalton »

remus wrote: post #69
derefr wrote: post #30

Earlier quoted context omitted.

I feel like Go is the way it is, mostly because its maintainers are also responsible for the continued productivity of thousands of engineers working on Google's numerous Go codebases. Any "breaking change" that requires rewriting Go code is a tangible negative for them, in that it'll interrupt Googlers from getting real work done, and the blame will come back to them. In a sense, Go is more like a corporate-internal…

Personally I think this is a pretty positive thing. If a language is at all popular then any breaking change is going to mean work for users, and having those users sitting next to you in the office keeps it fresh in your mind when you're tempted to make that "one small change" to the language.

This thread isn't about breaking changes, though. Neither Rust nor Go make breaking changes.
Post reply on HN