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

51–60 of 264 posts

Re: Go 1.13 Release Notes

#51

Post by JNRowe »

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.

While I too like the change, there can be a user cost. For example, it makes using grep across a project slightly more annoying. Much like the flexible identifier rules in nim, it feels great but using common tools suddenly needs more thought.

Re: Go 1.13 Release Notes

#52

Post by mfer »

I started poking around and noticed that Go 1.13 now defaults to the Golang Proxy to fetch modules. This means a proxy, governed by the Google Privacy Policy, is now capturing everyone's module usage by default. Unless you change settings this includes proprietary/corp stuff.

https://codeengineered.com/blog/2019/go-mod-proxy-psa/

Re: Go 1.13 Release Notes

#53

Post by littlestymaar »

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…

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

Re: Go 1.13 Release Notes

#54

Post by big_chungus »

derefr wrote: post #27
paulddraper wrote: post #24

Earlier quoted context omitted.

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.

Not sure about go, but you can do this in C as a compile-time constant:

  #define foo 1.34E8
Maybe go would benefit from a pre-processor? Though it can be somewhat byzantine in C (and result in very unpredictable final source, if abused), it's very helpful to have a complete functional language available for code transformation. It might help go in some cases, too.

Re: Go 1.13 Release Notes

#55

Post by cameronbrown »

Exuma wrote: post #31
cameronbrown wrote: post #22

Earlier quoted context omitted.

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

Yes I do actually -- my best advice is to watch this course. It's hands down the best course I've ever seen (across any language, actually), and he jumps RIGHT into it, almost from a computer science aspect. He doesn't talk about learning the language at all (he assumes you know all that), instead he fills in all the gaps in a very thorough way that are left out from all the tutorials and such you'll read. I've read…

Thanks for the recommendation!

Re: Go 1.13 Release Notes

#56

Post by SomeOldThrow »

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.

This is immensely reflective of the type of problems you tackle.

Re: Go 1.13 Release Notes

#57

Post by onei »

mfer wrote: post #52

I started poking around and noticed that Go 1.13 now defaults to the Golang Proxy to fetch modules. This means a proxy, governed by the Google Privacy Policy, is now capturing everyone's module usage by default. Unless you change settings this includes proprietary/corp stuff. https://codeengineered.com/blog/2019/go-mod-proxy-psa/

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

Re: Go 1.13 Release Notes

#58

Post by astockwell »

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 dark road of cygwin/Mingw, if you want your development cycle to be at all normal... and even then, my observation is compilation times are an order of magnitude slower on Windows :(

At GopherCon I met folks who worked for huge, "old guard" Windows companies who said "just run a linux VM" to develop in Go.

If you just need to compile for windows once and a while (e.g. for releases only, not as part of your normal dev cycle), check out xgo [1], which uses docker to deal with all the cgo mess. No cygwin/Mingw to install/worry about.

Best of luck! If anyone else has tips for working in Windows, I'd also love to hear them.

[1] https://github.com/karalabe/xgo

Re: Go 1.13 Release Notes

#59

Post by zubspace »

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

> 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 u…

Thank you for your elaborate perspective. I initially thought that I'm just dumb, but I guess there are really alot of new things coming around lately, so I'm ok with some minor problems.

Really hope to use GO more and that those rough edges will be gone after a while.

Re: Go 1.13 Release Notes

#60

Post by mfer »

onei wrote: post #57
mfer wrote: post #52

I started poking around and noticed that Go 1.13 now defaults to the Golang Proxy to fetch modules. This means a proxy, governed by the Google Privacy Policy, is now capturing everyone's module usage by default. Unless you change settings this includes proprietary/corp stuff. https://codeengineered.com/blog/2019/go-mod-proxy-psa/

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.
Post reply on HN