Live data from Hacker News

Go 1.13 Release Notes

golang.org

151–160 of 264 posts

Re: Go 1.13 Release Notes

#151

Earlier quoted context omitted.

> This is the first language in my 23 years programming that reports my usage back to the language authors I suppose that means you haven't used any of: 1. nodejs, which reports your usage back to npm Inc with the exact same amount of detail (names of dependencies, ip of caller) (and stores much more, since it publishes 'downloads per month', etc) 2. rust, which does the same with crates.io 3. perl, which does that w…

If I download something from a server, of course that server knows what I downloaded. This is different. It’s a proxy in front of others repositories. They want info on downloads from GitHub, gitlab, and anywhere else you get code from. They (google) are a 3rd party to the download.

> This is different. It’s a proxy in front of others repositories

It's not all that different.

It's perfectly possible to use gems in ruby without ever using the rubygems server by setting every gem to be something like 'gem foo, :source = "https://github.com/foo/bar"'

However, people want to use this centralized repository in the ruby community because it allows for easily updating gems and for convenient caching.

The go proxy is not just a proxy. It also pre-parses out go.mod/go.sum to provide metadata faster and to provide security guarantees.

In a similar way to how centralized repositories are helpful in other languages, the go proxy adds actual legitimate features.

If you look at the public information on its development of this feature, all the motivations cited are about security, performance, and useful features, not information collection.

> This is different

There is a difference. Other repositories, like npm, require someone to opt-in to code being available via it (e.g. type `npm publish`, whether the publisher owns the package or not), while the go proxy default opts-in everyone that publishes a go package publicly and uses the newer go toolchain.

In practice, with how the npm/rubygems/etc communities work, everyone does opt-in if they wish their code to be publicly used, so the difference doesn't seem meaningful to me.

Other than that, the difference seems vanishingly small. In both cases, a 3rd party exists that serves downloads, and it exists to provide performance and discoverability benefits (with the go proxy also does due to supporting version-related operations), and in some cases security benefits.

Re: Go 1.13 Release Notes

#152
post #29

Earlier quoted context omitted.

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

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.

Yes, Go is in many ways a DSL for writing servers. IMO it should be the default language you reach for when starting a new server project.

Re: Go 1.13 Release Notes

#153

Earlier quoted context omitted.

First programming language that I've had to read and understand a privacy policy to use.. and consider that it may change in the future. The idea that the language I'm programming in now reports anything back to google is distressing.. and I say that as someone who has been programming in Go for about 7 years. What right does google have to collect usage information from modules hosted on github (or elsewhere)? I che…

> This is the first language in my 23 years programming that reports my usage back to the language authors I suppose that means you haven't used any of: 1. nodejs, which reports your usage back to npm Inc with the exact same amount of detail (names of dependencies, ip of caller) (and stores much more, since it publishes 'downloads per month', etc) 2. rust, which does the same with crates.io 3. perl, which does that w…

perl, which does that with cpan

CPAN doesn't do that, because CPAN is a series of mirrors that neither collect nor report aggregate download numbers.

Re: Go 1.13 Release Notes

#155

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 think Go is the only software release at this point to whose releases I respond with ‘Ooh shiny’ and not ‘Oh god’. I love the way they’re doing this — calm, collected, slow, and with ample heads up. At this point, I think we all have some JavaScript PTSD.

C# obviously has a very different design philosophy than Go, but its releases are moving along at a similar (and IMO, reasonable) pace.

Re: Go 1.13 Release Notes

#157

Earlier quoted context omitted.

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

Mysterious hacker news downvoting! This my preferred way of writing numbers with lots of 0s as well.

But underscores also work for numbers that don't have lot of zeros. Compare:

    12_345_678
    1.2345678e7

Re: Go 1.13 Release Notes

#158

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

Goroutines are quite a lot nicer than async for a few reasons. Firstly, there are no “forgot to await” errors, secondly there is no need to worry about some library making a sync call way down the call stack and therefore blocking your event loop, and thirdly goroutines can use all cores on a CPU to parallelize CPU intensive tasks, which means you don’t block the event loop unless you really are out of CPU. Blocking the event loop is a really big deal since it can cause health checks to fail which can cascale onto other instances and bring your app down. We’ve experienced this with both CPU- and IO-bound event loop blockages, and they’re really hard to debug. These just aren’t issues that happen in Go.

Re: Go 1.13 Release Notes

#159

Earlier quoted context omitted.

Python's optional type hints even with mypy are nowhere near strict/expressive than a statically typed language like Go. Type hints in Python are an afterthought and it shows in a lot of cases.

Type hints in Python are IMO great and quite expressive! You can create sum types (a bit verbose but they are there). You can introspect them at run time and create things like pydantic[0] and fastapi[1]. Strict null checks with Optional[T] are great! Now I'm not too familiar with Go's type system, but with protocols, Unions, Optional[T] and other generics offered by MyPy[2] I'd wager the type system is __more__ expr…

The type system is more expressive, but much clunkier and also it needs to be expressive to accommodate all of the weird things people do in Python (and you still can’t model SQLAlchemy types).

Re: Go 1.13 Release Notes

#160
post #44

Earlier quoted context omitted.

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.

You will if you ever do concurrency stuff in go. The way goroutines capture their working variables in a closure make things like `x := x` useful and clear (once you know why you do it in the first place )
Post reply on HN