Here's a sample quote from Russ Cox from 11 years ago on this site: [1]

We have spoken to a few true experts in Java generics and each of them has said roughly the same thing: be very careful, it's not as easy as it looks, and you're stuck with all the mistakes you make. As a demonstration, skim through most of http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.ht... and see how long before you start to think "was this really the best way to do this?"

And of course, they asked other experts for help, including Philip Wadler (of Featherweight Java and Haskell fame): [2] [3]

We’ve been thinking about generics since work on Go began, and we wrote and rejected our first concrete design in 2010. We wrote and rejected three more designs by the end of 2013. Four abandoned experiments, but not failed experiments, We learned from them, [...]

Last year [2018] we started exploring and experimenting again, and we presented a new design [...] and we’ve been working with programming language theory experts to understand the design better.

[1] https://news.ycombinator.com/item?id=9622417

[2] https://go.dev/blog/experiment

[3] https://go.dev/blog/generics-next-step#acknowledgements

Comments URL: https://news.ycombinator.com/item?id=48905287

Points: 2

# Comments: 0

How long the google-run module cache (aka, module proxy or module mirror) at https://proxy.golang.org caches the contents of modules is I think slightly nuanced.

That page includes:

> Whenever possible, the mirror aims to cache content in order to avoid breaking builds for people that depend on your package

But that page also discusses how modules might need to be removed for legal reasons or if a module does not have a known Open Source license:

> proxy.golang.org does not save all modules forever. There are a number of reasons for this, but one reason is if proxy.golang.org is not able to detect a suitable license. In this case, only a temporarily cached copy of the module will be made available, and may become unavailable if it is removed from the original source and becomes outdated.

If interested, there's a good overview of how it all works in one of the older official announcement blog posts (in particular, the "Module Index", "Module Authentication", "Module Mirrors" sections there):

https://go.dev/blog/modules2019#module-index

Thanks for that link.

Based on reading through that whole discussion there just now and my understanding of the different ecosystems, my conclusion is that certainly people there are telling Filippo Valsorda that he is misunderstanding how things work in other languages, but then AFAICT Filippo or others chime in to explain how he is in fact not misunderstanding.

This subthread to me was a seemingly prototypical exchange there:

https://lobste.rs/s/exv2eq/go_sum_is_not_lockfile#c_d26oq4

Someone in that subthread tells Filippo (FiloSottile) that he is misunderstanding cargo behavior, but Filippo then reiterates which behavior he is talking about (add vs. install), Filippo does a simple test to illustrate his point, and some others seem to agree that he is correct in what he originally said.

That said, YMMV, and that overall discussion does certainly seem to have some confusion and people seemingly talking past each other (e.g., some people mixing up "dependents" vs. "dependencies", etc.).

From what I can tell, the core Go team seems generally favorable to it, so seems like a decent chance it will happen.

From:

#73608 proposal: all: add bare metal support

https://github.com/golang/go/issues/73608

> Go applications built with GOOS=none would run on bare metal, without any underlying OS. All required support is provided by the Go runtime and external driver packages, also written in Go.

And:

> These hooks act as a "Rosetta Stone" for integration of a freestanding Go runtime within an arbitrary environment, whether bare metal or OS supported.

Comments URL: https://news.ycombinator.com/item?id=46303164

Points: 4

# Comments: 0

https://tip.golang.org/doc/go1.26

Comments URL: https://news.ycombinator.com/item?id=46294257

Points: 1

# Comments: 1

> The proposal to add arenas to the standard library is on indefinite hold due to concerns about API pollution.

I think the parent comment was using arenas as an example that GOEXPERIMENTs don't always move forward (like arenas), or can change while still GOEXPERIMENTs in a way that would normally not be allowed due to backward compatibility (like synctest).

The arena GOEXPERIMENT has not yet been dropped as of Go 1.25, but as I understand it, the plan is to remove arenas from the runtime when 'regions' are introduced, which have similar performance benefits but a much lower API impact:

https://github.com/golang/go/discussions/70257

As discussed there, seeing how people actually used the arena GOEXPERIMENT influenced the 'regions' design.

FWIW, that's not quite correct. For example, a string literal passed as a fmt argument won't be moved to the heap.

The upcoming Go 1.25 release has some related improvements that help strings in more cases. See for example https://go.dev/cl/649079.

Comments URL: https://news.ycombinator.com/item?id=43995665

Points: 2

# Comments: 0

Someone in the community recently built a searchable directory of Bluesky "Starter Packs" (which are a way for a user to publish a set of interesting people & feeds to follow, primarily to help newcomers bootstrap their experience):

https://blueskydirectory.com/starter-packs/all

Dan Abramov posted about it earlier today, saying he liked it and:

"the fact that it can be done in the ecosystem is awesome. let the ecosystem cook" [1]

And maybe more poignantly:

"seeing random projects pop up in the atproto ecosystem reminds me just how much public web common were stifled by social companies closing down their APIs. an entire landscape of tools given up on and abandoned" [2]

[1] https://bsky.app/profile/danabra.mov/post/3lar3sdna222d

[2] https://bsky.app/profile/danabra.mov/post/3lar3xpuu4c2d

I might have misunderstood your comment, but FWIW, Go does allow pointers into the stack from the stack.

When resizing/moving/copying a stack, the Go runtime does indeed find those pointers (via a stack map) and adjust them to point to the new stack locations. For example:

https://github.com/golang/go/blob/b25f5558c69140deb652337afa...

(The growable stacks I think replaced the segmented stacks circa Go 1.3 or so; I can't speak to whether they were contemplating growable stacks in the early days whilst considering whether to start their project with the Plan 9 toolchain, LLVM, or GCC, but to your broader point, they were likely considering multiple factors, including how quickly they could adapt the Plan 9 toolchain).

Comments URL: https://news.ycombinator.com/item?id=38472777

Points: 1

# Comments: 0

Bluesky has a main PDS instance at https://bsky.social that serves almost all of the Bluesky user base.

There is a good overview of the architecture here:

https://blueskyweb.xyz/blog/5-5-2023-federation-architecture

Here’s a snippet from the protocol roadmap they published 3-4 weeks ago [1]:

Multiple PDS instances

The Bluesky PDS (bsky.social) is currently a monolithic PostgreSQL database with over a million hosted repositories. We will be splitting accounts across multiple instances, using the protocol itself to help with scaling.

[1] https://atproto.com/blog/2023-protocol-roadmap

  "Research Unix Sixth Edition (v6) kernel written in Go and using rsc.io/unix/pdp11 to run user-mode code"

https://github.com/rsc/unix/blob/main/v6unix/proc.go#L25-L67

A fix for the loop variable closure problem is now in the official proposal process, which is how language changes happen in Go.

It’s a concrete proposal from the core Go team and seems to be on track for acceptance:

https://github.com/golang/go/issues/60078

An implementation is already available on tip and in the upcoming Go 1.21 release behind a GOEXPERIMENT flag.

The community reaction has been extremely positive. As one approximate measure, an earlier draft of the proposal had 671 upvotes and with 0 downvotes:

https://github.com/golang/go/discussions/56010

"It's a special purpose hook that is almost never needed".

[0] https://groups.google.com/g/golang-nuts/c/qDhJbkE1QeY/m/JoV2...

I haven't really observed that at all.

One thing that is going on is there hasn't been a massive disruption while everyone stops to rewrite the world in generics, and generics are not suddenly everywhere, which is what some people had predicted would happen. I think part of the reason is that in some cases another solution (closures or interfaces or whatever) can be a better fit, and the evolutionary approach to generics that Go took means you can use generics in conjunction with non-generic libraries or other pre-existing approaches without suffering from an ecosystem split.

  # show the impact of cutting any package
  goda cut ./...:all   

goda has a bunch of other capabilities around dependency analysis, and was written by long-time Go contributor Egon Elbre. The examples in the README are the best way to get started after 'go install github.com/loov/goda@latest'.

[0] https://github.com/loov/goda