ATProto is closer to how RSS works than ActivityPub. In the same way talking about "RSS instances" makes little sense, the same goes for "ATProto instances".
It makes sense to talk about “RSS aggregators”. Especially it makes sense to talk about “RSS aggregators that speak a specific vocabulary on top of RSS, host 99% of content using that vocabulary, and if you host your own RSS feed with said vocabulary they’ll show it in their aggregator but can ban it any minute”.
Did I just describe Apple Podcasts? Huh. Regardless, yeah, there’s no “ATProto instances” technically, but there are ATProto apps and the single biggest one now owns the trademark to the protocol name.
i guess that's fair, but i've never listened to a podcast from a non-foss app; i'm not really "in" the podcast sphere, but from where i'm sitting it seems podcasting would survive and migrate just fine if apple podcasts had to go away suddenly
I guess that’s fair, too. I’m not really into podcasts either, and the ecosystem seems healthy enough. Many FOSS podcast clients use Apple for discovery, which I guess make sense; but there’s probably other databases, and the contents themselves aren’t usually hosted by Apple, just the metadata.
So yeah, podcasts are in good shape. In fact, they are probably the most used decentralized media right now (apart from torrents, maybe). I hope Bluesky gets to that point, and I do wish them luck, but we’ve got to see the incentives are not that well aligned. As for the trademark... it’s surely weird, it’s not the end of the world if they continue to hold it, but setting up a non-profit (not in US, perhaps) for the protocol itself would probably be more appropriate down the road.
The thing with ATProto is, there is little incentive in creating apps that speak the app.bsky vocabulary. If I understand correctly, there is one other full-fledged app that does that, Blacksky [0]. By full-fledged, I mean they host a PDS, a relay, an app view, a moderation service, and a bunch of feeds and other doodads. If Bluesky goes down, Blacksky will probably be fine. They are, however, yet another US company [1], which is not ideal.
I would go further and say that anyone who doesn't immediately identify this either isn't thinking clearly about this, or is intentionally ignoring it. I have no horse in this race AT ALL and this is _obviously_ the advantage.
Except that writing safe rust often requires designing the architecture around rust's ownership model, meaning a file by file, line by line translation doesn't necessarily leave you much closer to safe rust than you were at the start.
You can also do one by using `unsafe` liberally, especially if you're flexible about actually upholding rust's rules (as the bun team just did). But either way, you're still stuck with a code base that's going to need extensive refactoring if you want to actually take advantage of rust.
Which is still a step ahead of Zig, which requires an entire rewrite to have the tiniest shred of RAII or borrow checking. What's your point, that if we can't do everything perfectly in one step we can't do it at all?
First off, you seem to be under the impression I'm a rust hater. Noting could be further from the truth. Rust is easily my favorite language at this point, I reach for it for basically everything (except quick scripts). While I do like a lot of zig's philosophy, I think at the end of the day the empirical evidence is overwhelming that manual memory management isn't sufficient.
> What's your point, that if we can't do everything perfectly in one step we can't do it at all?
My point is exactly what I initially said: you typically aren't much closer to a (mostly) safe rust codebase if you've done a line by line port to (partially unsafe) rust than you were to start with. Getting to safe rust is very likely to require substantial refactors either way. This doesn't mean you shouldn't do it (on it's own), but it does mean that the bun team's strategy/assumptions are more questionable than they appear to realize.
I didn't say they made a good, safe port. I literally said the opposite ("especially if you're flexible about actually upholding rust's rules"). You can get a line by line port to compile by just wrapping the parts that violate rust's ownership rules in `unsafe`. You won't have fixed the problem, and it won't be memory safe, but you can do it.
Well, only if Clone/Copy is compatible with the semantics of the API. I.e., the called function doesn't need to modify anything. No &mut params (or data members) except perhaps `&mut self` (which would refer to definitions the same file).
That's usually the case for Rust programs because the language encourages it. Are Zig programs like that?
To be fair, you can throw an Arc<Mutex<_>> or Rc<RefCell<_>> at it if you're starting from something that has multiple "mutable borrows", but that adds runtime cost and complexity.
This is not done by blindly porting Zig code 1:1 and calling it a day. You do have to make conscious decisions about code architecture to manage Unsafe code, since you need choose the right invariants for your Safe Rust code to conform inside the module (Note that unsafe pollutes the whole module containing it, not just the code inside the unsafe block!)
No one involved in the port proposed "blindly porting Zig code 1:1 and calling it a day". From the first blog post the creator said:
> We can gradually refactor it to reduce unsafe usage and look more like idiomatic Rust after Bun v1.4 ships.
What the rewrite does is make the unsafe code greppable, which is a necessary first step to eliminating it and one that's actually achievable rather than going straight to idiomatic.
Every successful refractor takes this form of stepwise changes that leave the behavior intact. It just so happens that in this case the first stepwise change was the implementation language.
Is quite a hell of a statement, when memory management issues are highly nonlocal and need some careful design upfront in order for you to nail it.
Unsafe isn't something that you can gradually clean up. Even one single flawed usage of unsafe (an ill-assumed invariant) can poison the whole program in scary ways, and might require a total refactor of your codebase to fix it.
So if I use Zig, I need to do all of that perfectly from day one and I don't get any help from static analysis to do it. Or else I've poisoned my whole program in scary ways and will require a total refactor where I still won't have any help and once again can't make a single mistake.
Except the blog post shows that they fixed a hundred or so known issues, patching several memory leaks and making the project viable for Prisma Compute's adoption - which it wasn't before. It's now running in production in two places just fine.
Can you point to an equal number of issue tracker tickets showing novel bugs or regressions in the canary build?
Yes, they have introduced (at least) several times more memory safety issues by violating the rust specific rules. Check how most of their unsafe blocks are unsound and worse, how many are straight up incorrect with a total bs // SAFETY above it, leaving no sensible usage without invoking UB.
We often ensure a project holds water against miri. This one doesn't even pass for clippy.
You realize that what you're describing is inherent complexity in memory management? This is not something that you can dodge by using Zig, it's just part of the domain.
The difference is that in Rust you get strong guarantees for everything that is not inside of unsafe and clearly demarcated areas where things might go wrong. Even if you never eliminate a single unsafe block, the clear demarcation is valuable as an artifact in its own right.
The art of Unsafe Rust is marking the right demarcation with the right set of invariants that Safe code must adhere to inside the module that uses Unsafe. If you do this incorrectly, then even Safe code outside the unsafe block can cause undefined behavior.
Which is why having unsafe code without exactly specified invariants is practically useless: the Bun rewrite code has too many SAFETY comments that are incorrect and misleading, so most of the unsafe demarcations aren't helpful in achieving UB-free code.
This is nonsense. There is quite a subset of C which is perfectly safe and an even larger one which can easily be safe with tooling. You could argue that unsafe keyword is easier to spot than the unsafe features of C, so that makes it somewhat easier to screen for issues. But if you screen for memory safety only, this is problematic anyhow.
Is there a "Rust compiler's rule" you can point to that's harder than avoiding UB in C or C++ in similar circumstances? They strike me as very similar beasts.
You do have to inevitably use unsafe because of FFI (Bun uses existing C++ modules like JavascriptCore for most functionality). Optionally also for performance (at least if you want to win Deno on that front)
Nevertheless, it's also React team that came up with prefixes like __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED in their codebase because people couldn't stop messing with the internals. So any documentation about the new compiler would be anything but rejected by the community.
> Coding language is just an implementation detail
Sure, but what machine model do the public contract docs and RFCs target ? While the specific coding language is a detail, programming languages target a precise machine model. There is no machine model for english prompts and spec docs. So expect fuzziness - he-said-she-said bugs in your code - things that the LLM made up because the RFCs were not precise. And by the time you add precision to the specs, it has morphed into a new programming language with a machine model. In this usecase, since it is a port, the impact is mitigated because it is a clone of some existing functionality.
i feel like ppl have magical beliefs about type systems. just because it's _probably_ (did it use unsafe?) memory-safe doesn't mean it does what you want it to do
That's obviously true. On the other hand its also true this is more likely to work because it is rust compared to python or js for example. And that's not only because of memory safety. It's because static typing gives an automatic proof of a certain level of correctness of the code. That correctness is correlated with correct business logic bugs. So it is valid argument to make.
Of course that doesn't mean that there are no businesses logic bugs.
Your argument is just as applicable on human code reviewers. Obviously having others review the code will catch issues you would never have thought of. This includes agents as well.
They’re not equal. Humans are capable of actually understanding and looking ahead at consequences of decisions made, whereas an LLM can’t. One is a review, one is mimicking the result of a hypothetical review without any of the actual reasoning. (And prompting itself in a loop is not real reasoning)
I keep hearing people say "but as humans we actually understand". What evidence do you have of the material differences in what understanding an LLM has, and what version a human has? What processes do we fundamentally do, that an LLM does not or cannot do? What here is the definition of "understanding", that, presumably an LLM does not currently do, that humans do?
Well a material difference is we don’t input/output in tokens I guess. We have a concept of gaps and limits to knowledge, we have factors like ego, preservation, ambition that go into our thoughts where LLM just has raw data. Understanding the implication of a code change is having an idea of a desired structure, some idea of where you want to head to and how that meshes together. LLM has zero of any of that. Just because it can copy the output of the result of those factors I mention doesn’t mean they operate the same.
I'm so sick of these performance benchmarks. I understand it's easy to spin them up to show that one framework is faster than another, but in general all these frameworks are fast enough for 99.9% of use cases.
Where frameworks lack today, in my opinion, are in providing the right tools further optimize the UX of interacting with web sites. It's a constant struggle of loading spinners and flicker and loss of scroll positions.
The only framework I see that actually tries to resolve these very hard problems is React, through their work on new asynchronous primitives like startTransition. Yes, they are currently hard to understand how to properly use, but I so wish the discourse would be around how to best resolve these actual UX issues than who can create 50M divs the fastest.
IMO, we desperately need standards or tooling to make frameworks easier to swap out and interoperate. Web Components was supposed to be this, but it's not quite there yet and requires awkward wrappers around everything.
No framework will stand the test of time. I encourage everyone to, at the very least, own your state and router libraries, as you'll be able to extend them when you want to jump ship in a more incremental fashion. Going all in on a single framework's state, router, and view libraries will create a ton of inertia...
At this point just ditch the browser and instead have a browser with html css and lua, maybe that will help the world (satire but I genuinely want the world to somehow move to this if it ever becomes popular)
Would this make me a bad guy if I tried but couldn't find the link? oof. wait for sometime so that I see the list of my github stars because its hidden somewhere in there...
To me the only framework that has really pulled this off is Phoenix live view and spinoffs, because they solve the fundamental problem: pipelined latency. The frontend has to request object A, wait for the result, then it has to request object B, then wait, etc, etc. There's too many combinations of objects, so it would be impossible to have an endpoint per specific request (I suppose graphql has sort of done this, but it's still not flexible enough for complicated transforms). Live view solves this problem by not really solving the problem, but moving everything server-side so pipelined latency is dramatically lower.
Yeah I agree, these benchmarks are basically meaningless. E.g. they acclaim Vue's binding based approach as being faster, but it also leads to spaghetti code. React was specifically designed to avoid that so you can build big apps that aren't buggy.
Also isn't Preact meant to be a faster option if you really need performance?
Arent buggy? React had to introduce a compiler because the masses only write buggy code. The reason they likely waited so long to do it is because they felt like it was a waste to write software to fix something that theoretically has “no flaws” because it’s “just JavaScript”.
Literally every other JS framework figured this out years and years ago and some over a decade ago. Compilers help to raise the floor for everyone so we don’t need to worry about making a dumb mistake and drastically slowing down our programs. Compilers are the evolution of software.
> I'm so sick of these performance benchmarks. I understand it's easy to spin them up to show that one framework is faster than another, but in general all these frameworks are fast enough for 99.9% of use cases.
Yes, any framework is fast enough. At this point, everybody probably knows already. Nobody would ever say React is not appropriate because it's slower than Svelte. No sane person would ever argue for a migration from React to Svelte based on this benchmark.
But being against the performance benchmark is such a weird take. It's so strange that many times there are hidden agendas.
Many times because a person advocates for X over Y at Company Z. Then, there's some random benchmark saying Y is faster. Now the person needs some way to cope. The best way is to refute the benchmark in some ways, but this would take a huge amount of time and effort. The second best way is to simply say "it doesn't matter. I hate this useless benchmark. There are more important problems to solve!"... as if everyone on the planet has to always solve the most important problem first ... only one problem and no more. Haha
Most of that latency is coming from back ends across most major sites, anyway, so it's the wrong place to test.
As an addition to the general commentary here, "The Toilet Paper" is an unfortunate choice of label for this article, and maybe also indicative of the quality of the writing.
It really isn't - a ui framework should be able to properly handle backend latency and provide a great experience while waiting for a backend response with no flicker while not locking the entire ui. It's just way harder to set up good benchmarks for this.
The difficulty to deploy Next.js is greatly exaggerated in my opinion. It's mostly if you care about some of the more advanced features, like image optimization and hosting static assets on a different origin it can become difficult, but these are features no Next.js alternative generally provide anyway.
> hosting static assets on a different origin it can become difficult
What's the alternative? Hosting the static assets on the same place as the backend? Usually adding the CORS headers is enough to solve that (on the backend side), the frontend is still just HTML,CSS and JS running from nginx.
Is it common to do a different type of deployment with Next.js? It's a pretty basic deployment scenario (having the frontend on a different origin than the backend it communicates with), so not sure why that'd be so difficult with Next.js compared to basically anything else.
It's the opposite, it's extremely easy to do that with Next.js - pretty much free - but only if you're deploying to Vercel. If you want to host somewhere else then you have to do that semi-manually the same way you would with any other framework.
Even with the optimizations it's not that difficult in my experience. Not terribly well documented (not worst-in-class either) but not that hard and mostly just works once you have a pipeline up and running. We set ours up about two years ago now and have had to make minor modifications maybe three times since then.
Same. I've deployed a half dozen or so Next.js apps and it's no more difficult than any other node app unless you're using some of the more advanced features. In fact, if you only need something static and can do SSG then it's far easier than other node apps because all you need is nginx.
reply