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

101–110 of 264 posts

Re: Go 1.13 Release Notes

#101

Post by zubspace »

DuskStar wrote: post #66
astockwell wrote: post #58

Earlier quoted context omitted.

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

Thanks for your feedback. GoLand looks really nice (like everything from JetBrains), but the price is a bit steep for just playing around once in a while. But I'll keep it in mind.

I'll try the WSL Route and see how it goes. (VSCode already made me install that extension.)

Re: Go 1.13 Release Notes

#102

Post by sangnoir »

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/

Had you read the linked release notes, you wouldn't have had to poke around to find that out: it's not some hidden thing. The second paragraph starts off with: As of Go 1.13, the go command by default downloads and authenticates modules using the Go module mirror and Go checksum database run by Google.

Re: Go 1.13 Release Notes

#103

Post by timothycrosley »

axaxs wrote: post #14
cameronbrown wrote: post #6

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…

> 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 the Python equivalent This is exactly how I felt moving from a Python codebase to Go. But you realize on the 100th or so Python stacktrace that it's worth the investment up front, if not for type safety alone. > I really need the performance for my worklo…

> This is exactly how I felt moving from a Python codebase to Go. But you realize on the 100th or so Python stacktrace that it's worth the investment up front, if not for type safety alone.

Luckily, you don't have to choose between those two outcomes:

https://github.com/python/mypy

Re: Go 1.13 Release Notes

#104

Post by est31 »

pcwalton wrote: post #93
est31 wrote: post #92

Earlier quoted context omitted.

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.

Yeah, if you take the principle further it would be even better to write it in C89 because this language is comparatively easy to write compilers for. But the principle is not absolute and it doesn't stand above everything else.

There are major differences in how easy it is to write compilers in C++ vs C89. There are major differences between C++ and Rust with its ADTs and pattern matching. But are there major differences between, say Rust 1.32 and Rust 1.36? I'd argue no.

There are real use cases like distros wanting to maintain/bootstrap a Rust compiler independently from upstream binaries. The more often these people have to port a compiler, the more troublesome it is for them.

Rust seems like it's the odd one out: Swift is written in C++, Go supports bootstrapping from years old compilers, LLVM does so as well, and GCC has probably some of the best backwards compatibility stories out there.

Re: Go 1.13 Release Notes

#105

Post by sangnoir »

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.

Write-only caches are a good way to avoid left-pad-type debacles[1]

1. https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/

Re: Go 1.13 Release Notes

#106

Post by timothycrosley »

cameronbrown wrote: post #19
axaxs wrote: post #14

Earlier quoted context omitted.

> 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 the Python equivalent This is exactly how I felt moving from a Python codebase to Go. But you realize on the 100th or so Python stacktrace that it's worth the investment up front, if not for type safety alone. > I really need the performance for my worklo…

> This is exactly how I felt moving from a Python codebase to Go. But you realize on the 100th or so Python stacktrace that it's worth the investment up front, if not for type safety alone. Yep. Maybe I just suck at programming but I couldn't write enough tests to avoid not being fed up debugging stack traces in production. I started using Python's type hints, since this was the source of most of the bugs which helpe…

Have you tried async? I find it much easier personally to reason about and debug than channels, and is perfect for IO-bound problems. If you really like channels, note that Python 3.9 will have sub-interpreters and channels as well: https://hackernoon.com/has-the-python-gil-been-slain-9440d28...

Re: Go 1.13 Release Notes

#107

Post by cameronbrown »

timothycrosley wrote: post #106
cameronbrown wrote: post #19

Earlier quoted context omitted.

> This is exactly how I felt moving from a Python codebase to Go. But you realize on the 100th or so Python stacktrace that it's worth the investment up front, if not for type safety alone. Yep. Maybe I just suck at programming but I couldn't write enough tests to avoid not being fed up debugging stack traces in production. I started using Python's type hints, since this was the source of most of the bugs which helpe…

Have you tried async? I find it much easier personally to reason about and debug than channels, and is perfect for IO-bound problems. If you really like channels, note that Python 3.9 will have sub-interpreters and channels as well: https://hackernoon.com/has-the-python-gil-been-slain-9440d28...

Unfortunately I deploy on App Engine which is still at Python 3.7.

Re: Go 1.13 Release Notes

#108

Post by pcwalton »

ngrilly wrote: post #99
pcwalton wrote: post #35

Earlier quoted context omitted.

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

The features that each language offers are the same: threads, channels, and blocking I/O (though Rust has more features for safe concurrency--Rust prevents data races statically, while Go is not even memory safe in the presence of such races). What is different is the performance characteristics. In some cases, M:N will be more efficient; in some cases, 1:1 will be. But just as I wouldn't say Go is lacking FFI features because M:N makes cgo slow, I wouldn't say Rust is lacking concurrency features.

Re: Go 1.13 Release Notes

#109

Post by zubspace »

saisasidhar wrote: post #97
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

Wow, this is really mind-opening. Everything makes sense now. Thank you.

It's also funny, that they stuck to the * pointer notation which led to the problem, where they could not tell apart a pointer from a multiplication, so they put it to the left of the variable name. It's the small things...

But I guess * is just too convenient and ingrained.

Post reply on HN