Go modules did not get rid of vendoring. You can do 'go mod vendor' and have been able to do so since Go modules were first introduced.
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):
ok, 1) so would it be fair to modify my statement that it basically tries to cache forever unless its can't determine that its legally allowed to cache forever?
2) you're right, glanced at kubernetes (been a long time since I worked on it) and they still have a vendor directory that gets updated regularly.
> They may be an expert in Go, but from their writing they appear to be misunderstanding (or at least misrepresenting) how things work in other languages
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:
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.).
> but then AFAICT Filippo or others chime in to explain how he is in fact not misunderstanding.
I don't get this impression. Rather, as you say, I get the impression that people are talking past each other, a property which also extends to the author, and the overall failure to reach a mutual understanding of terms only contributes to muddying the waters all around. Here's a direct example that's still in the OP:
"The lockfile (e.g. uv.lock, package-lock.json, Cargo.lock) is a relatively recent innovation in some ecosystems, and it lists the actual versions used in the most recent build. It is not really human-readable, and is ignored by dependents, allowing the rapid spread of supply-chain attacks."
At the end there, what the author is talking about has nothing to do with lockfiles specifically, let alone when they are applied or ignored, but rather to do with the difference between minimum-version selection (which Go uses) and max-compatible-version selection.
Here's another one:
"In other ecosystems, package resolution time going down below 1s is celebrated"
This is repeating the mistaken claims that Russ Cox made years ago when he designed Go's current packaging system. Package resolution in e.g. Cargo is almost too fast to measure, even on large dependency trees.
> 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.
The arena experiment was essentially placed on indefinite hold:
> 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:
Bluesky and atproto seem to be built to be hackable.
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):
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]
I was contemplating coming over, but this comment is the most convincing to me.
I think one of the fatal flaws tech companies have been making is locking things in. But what made the computer so great, what made the smartphone so great, was to make them hackable. You build environments, you build ecosystems. Lockin only slows you down. I mean how long would it have taken for smartphones to have a flashlight if it weren’t for apps? A stopwatch? These were apps before they were built into the operating systems.
Had to make an account to just echo this sentiment. I recently joined bluesky and holy hotdog as a developer it feels good that you can actually build stuff, data wrangling or whatever you might feel inspired to do.
The word "tweet" itself came from a 3rd party developer:
> The Iconfactory was developing a Twitter application in 2006 called "Twitterrific" and developer Craig Hockenberry began a search for a shorter way to refer to "Post a Twitter Update."
Wasn't the @ also invented by users?
I remember it was fascinating to watch this network self organize and create conventions of its own, that are now used everywhere.
Seems to me like Jarkko Oikarinen or one of his crew invented hashtags, no? Denoting the context of your communication with something like #warez or #hack significantly predates web2.0.
Rather I think Twitter-style hashtags take inspiration from IRC channels in the format of #topic
Because channel names are not hashtags. The syntax is purely because IRC is a text-based protocol, so you need a special way to distinguish channel names from regular text.
That use— to define IRC channels— seems distinctly different than Twitter hashtags to tag individual posts. I wouldn’t be surprised if hash tags started as a nod to that, perhaps even jokingly, but I don’t think you could consider them a descendent.
Yep, we intentionally built it to be hackable! We believe that social media will improve when people are free to build on it, change it, fork it, and remix it. Bluesky and the atproto ecosystem can evolve as fast as users and developers want them to.
The Twitter bot situation only seems to have got worse since they shut down free API access. LLM engagement farming bots everywhere in replies, hordes of scam bots replying if you use certain keywords, porn bots following and DMing everyone non-stop...
Evidently the people running the bots don't really care whether or not you give them an API to work with.
I think that coincided with them removing phone number verification for accounts. Probably due to my browser looking unusual (content blocker, linux user-agent string, other addons) any time I set up a new account and used it for a few minutes a few years ago, it'd lock the account and redirect every logged in page to one demanding SMS verification to unlock the account.
I would usually get support to manually unlock it after a few days by emailing them and mentioning why I didn't want to give them a phone number. Now the process only involves solving captchas. (and maybe some hidden waiting)
Check out bluesky's "labeling services", I think it will be a very simple matter to crowdsource lists of obvious bots and prevent their having any reach. You can create bots that make as many posts as you want, but bots aren't entitled to being included in any feed. It comes down to the posts that the relay choose to aggregate, and what the appview chooses to display according to user preferences.
One of the nice things that make Bluesky different is that there isn't really a single central algorithm that everyone is forced to use. This combined with the many novel moderations tools like feeds and labellers mean it's pretty trivial to filter out entire categories of spam/botting.
As an example my feed is completely free of US politics, allowing me to curate an experience where I can go to enjoy myself instead of constantly being exposed to ragebait.
> you can simply forbid pointers into the stack. This means that your GC doesn't need to be moving. I believe that's what Go does
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:
(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).
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.
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