Live data from Hacker News

Go 1.13 Release Notes

golang.org

21–30 of 264 posts

Re: Go 1.13 Release Notes

#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?

Re: Go 1.13 Release Notes

#22
post #17

I occasionally use Python for large-scale processing of structured data (XML, JSON) and the data's really messy as you'd expect (malformed responses, missing fields, normalisation, etc..). One of the things putting me off of Go for these kinds of projects is it's much more verbose/harder to handle edge cases - it feels like I'm less productive writing the program, but end up building something much more stable than t…

I kind of wondered that myself. All the completely automatic marshalling using tags seemed like it assumes things are very nice (which they aren't when working with some of the terrible data sources I've seen). Everything else feels very cool to use Go though, I just used it on my first real project.

> I just used it on my first real project.

Have you got any relevant advice I can take? Interested to hear how people feel about the language before I dive in.

Re: Go 1.13 Release Notes

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

Underscores are nice.

10 * 1000 * 1000 worked pretty well too.

Re: Go 1.13 Release Notes

#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 extensions except the main one from vscode and the language server was crashing like crazy until I unset GOPATH. Works now, mostly. Intellisense and code formatting seems to be still unstable now and then. But geez, that first experience was horrible.

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

- Why does go need := with the colon? I know it's a declaration, but I haven't figured out the reason for the colon.. Seems weird..

- I love gofmt and format-on-save. But it was not the default setting. Still don't know if I should use another one.

- I hate configuring vscode. After hearing only good things about it, the configurations and keybindings are horrible and that I need an extension for each and every small thing. Maybe I'm in the minority, but Visual Studio is miles ahead in this regard, I think.

- Fast compilation times are awesome. I love, that I can create a simple exe without a framework dependency.

- I can parse 2GB of simple JSON files in less than 20s. I'm awed.

- I have no idea how to compile some modules like the sqlite one. Seems to need gcc..? Do I have to fully switch to Mingw/WSL?

- I was losing my mind when I saw my program giving different results on each run... Until I found out about that randomized map iteration.. Funny.

- Finding an item in a slice: Yeah, sometimes generics would be nice but let's not start a holy war...

- Need to get used to error handling.. It can get really verbose and those scoping rules are strange.. I miss exceptions, but I can get used to the go way.

- I love that I can use the official docs locally: godoc -http=localhost:6060

- I had to use google and stackoverflow more than I initially thought for a 'simple' language... But well, I guess that's normal?

Sorry for the rambling. I love the simplicity of the language and hope to get into it more. But the initial experience is still, umm, not streamlined, it seems? But I hope that's just temporary.

Re: Go 1.13 Release Notes

#26

Nice to see that out-of-bounds panics will now include the offending index. Was that difficult to implement, or just controversial? Seems like something that could have been added a long time ago and saved much frustration when debugging.

I think the concern was that it would be too expensive, but then later they were able to figure out a way to do it.

Some more details: https://github.com/golang/go/issues/30116

Re: Go 1.13 Release Notes

#27

Earlier quoted context omitted.

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.

Underscores are nice. 10 * 1000 * 1000 worked pretty well too.

Compile-time integer exponentiation in Go would be neat, e.g. 5 * (1000**4).

I know we have scientific-notation integer literals, but it's not the same thing, especially when trying to calculate e.g. Mebibytes.

Re: Go 1.13 Release Notes

#28

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.

Re: Go 1.13 Release Notes

#29

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?

“Go is to services what Rust is to systems.”

Re: Go 1.13 Release Notes

#30

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 DSL that the public just happen to be able to use. (Erlang is—or at least, was, for the first ten years of its life—another language that is this way.)

Post reply on HN