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

91–100 of 264 posts

Re: Go 1.13 Release Notes

#91

Post by mseepgood »

skunkworker wrote: post #12
tptacek wrote: post #8

Honestly, and I don't think I'm snarking (but would have to reflect a bit on it), "0b", "_", and signed shifts are probably going to make Go more pleasant for me than generics would have. This is my favorite release in years.

It brought one of my favorite parts about writing numbers in languages such as Ruby over to Go. From 10000000 to 10_000_000 is such a readability improvement and should be no-cost.

> From 10000000 to 10_000_000 is such a readability improvement and should be no-cost.

1e7

Re: Go 1.13 Release Notes

#92

Post by est31 »

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.

One example where Rust is moving faster than Go is the compiler:

* Excluding patch releases, Go has a release twice each year [1], while Rust has a release every six weeks (about 9 times per year) [2].

* For minor (patch) releases (security updates, etc), Rust only cares about the latest version released. Go provides patch releases for the last two releases [3].

* The latest release of the Go compiler (1.13, Sept 2019) is able to bootstrap itself from Go 1.4 [4], released on Dec 10 2014. The latest release of the Rust compiler 1.37.0 (Aug 15 2019) needs Rust 1.36.0 (Jul 04 2019) for bootstrap.

* For the language, I think relative to itself, Rust has considerably slowed down with development compared to the pre-1.0 times. Now it's still evolving more quickly than Go. Rust is getting async_await, const generics, etc while Go is discussing about an error handling operator that Rust already had two revisions of since its 2015 release (try! and ?).

I'm not saying that all of this churn that Rust has is bad. Some of it is good, like the tighter release schedule that prevents half finished stuff to be released. But other things, like the tight version range that the compiler can bootstrap from, could be improved.

[1]: https://github.com/golang/go/wiki/Go-Release-Cycle

[2]: https://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

[3]: https://github.com/golang/go/wiki/MinorReleases

[4]: https://golang.org/doc/install/source

Re: Go 1.13 Release Notes

#93

Post by pcwalton »

est31 wrote: post #92
pcwalton wrote: post #28

Earlier quoted context omitted.

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.

One example where Rust is moving faster than Go is the compiler: * Excluding patch releases, Go has a release twice each year [1], while Rust has a release every six weeks (about 9 times per year) [2]. * For minor (patch) releases (security updates, etc), Rust only cares about the latest version released. Go provides patch releases for the last two releases [3]. * The latest release of the Go compiler (1.13, Sept 201…

Does the compiler bootstrap version matter though? Taking the principle that compilers should compile on the most easily accessible toolchain, writing the compiler in C++ would be the best option of all. But nobody wants to do that.

Re: Go 1.13 Release Notes

#94

Post by AnimalMuppet »

abofh wrote: post #46
tptacek wrote: post #39

Earlier quoted context omitted.

You mean, do I work with binary constants? Yes.

I think the question was more around how often is 0b1100 useful outside of a block of consts at the beginning? Surely you're not typing out long constants manually that often?

He might be reading them more often, though...

Re: Go 1.13 Release Notes

#95

Post by erik_seaberg »

alexbanks wrote: post #87
meddlepal wrote: post #82

Earlier quoted context omitted.

> it's a better Java. Ah ha ha ha ha ha ha. No. Just no. I say this as someone who writes Go day in and day out and wrote Java for a decade. Maybe it is if the last time you touched Java was 2001.

Can you explain why they're wrong?

Java got async I/O in 2002, generics and "for (x : iterable)" in 2004, and lambdas in 2014. Vintage 2001 Java was drastically harder to read and slower, though error handling was always less cumbersome than Go.

Re: Go 1.13 Release Notes

#96

Post by zubspace »

zemo wrote: post #44
zubspace wrote: post #40

Earlier quoted context omitted.

I know. The question is, why does it need a colon? It seems completely superfluous, from a syntax perspective.

it's not. Go has block-level scoping. = means "assign the existing identifier to this value". := means "create a new identifier". https://play.golang.org/p/Irqxm0okfkt

Thanks for the example. In all my life I never actually wanted to do something like this, but well... It's neat that go allows this.

Re: Go 1.13 Release Notes

#97

Post by saisasidhar »

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…

> The syntax is very weird after writing too much C#. Sometimes I have the feeling, that declarations are reversed just for the sake of it.

Rob Pike explains the reasons behind Go's deceleration syntax in this blog post: https://blog.golang.org/gos-declaration-syntax

Re: Go 1.13 Release Notes

#98

Post by rajangdavis »

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 think the selling points with Go are:

1. Cross-platform 2. Fairly mature ecosystem 3. Pretty easy to pick up coming from either a dynamic or static language background 4. Somewhat simpler approach to concurrency (although I've created my share of race conditions) 5. Backed and used by Google (if that is positive for you as a developer) 6. Is a pretty good multi-purpose language

I think in comparison to (my limited understanding of) Rust, Go is beginner friendly. Also, I think Rust has most of the above covered as well, but it seems like there are lower level primitives with functional aspects built-in. Haven't needed these in Go, so haven't investigated them there.

Re: Go 1.13 Release Notes

#99

Post by ngrilly »

pcwalton wrote: post #35
sime2009 wrote: post #32

Earlier quoted context omitted.

Would it be fair to say that Go's concurrency support makes it a good match in the network services space? I see Go more often in Docker and cloud contexts.

Rust has broadly the same concurrency support, with a more powerful compile-time race detector (but one that also comes with a learning curve). The main difference is that Go uses M:N threading, while Rust uses 1:1 threading with optional explicit async/await constructs.

Rust is really great, but I feel like you are overselling it a bit here:

- async/await is available in the nightly version of Rust (1.39), but not in the stable version (1.37).

- 1:1 threading is not strictly equivalent to M:N threading (the main practical difference being that the stack size per OS thread is larger than the stack size per goroutine).

Writing that "Rust has broadly the same concurrency support" is misleading right now. But it could be true in a near future.

Re: Go 1.13 Release Notes

#100

Post by alexbanks »

erik_seaberg wrote: post #95
alexbanks wrote: post #87

Earlier quoted context omitted.

Can you explain why they're wrong?

Java got async I/O in 2002, generics and "for (x : iterable)" in 2004, and lambdas in 2014. Vintage 2001 Java was drastically harder to read and slower, though error handling was always less cumbersome than Go.

It sounds like the point the person was trying to make was in use-case, rather than language semantics. As in, where one might've used Java before, they would now use Go. Not that Java and Go are semantically similar.
Post reply on HN