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