When I last played with it checking out its capabilities, I found the thing I was mostly missing to really make use of it was the thing referenced in this article, the Component Model. Without a type model and binary specifications, interop was made a lot harder than it'd have been otherwise. Now that that's in, it becomes a lot more useful.
I was mostly looking at it for its state as being a cross-platform supported output platform of bytecode that's fairly well sandboxed. That makes it an excellent target for things like running untrusted plugins in an application in a performant manner.
I'd argue that was what made Serenity good - a toy OS that anyone can code anything for. Want to spend ages working on a painting program? Make screensavers? Add drivers for your printer? Port Doom? Improve font support because it sounds fun? etc. It celebrated coding for coding's sake, which is the antithesis of AI. There's no point vibe coding features for Serenity because there is no real product there.
On the other hand, Ladybird is gearing up to become a production-ready browser for real users. Adding fun features for the sake of it, and hand-rolling code to parse PNGs and the like, has become a liability for the project.
They are adopting Rust (https://ladybird.org/posts/adopting-rust/) and use LLMs to help with the rewrite, but not all code was migrated yet. Also it's definitely not a big-bang-rewrite-the-world-with-Claude like Bun.
I'm going to be honest, this very much reads like an exciting new way to burn up as many tokens as possible. Large amounts of parallel agents that all have all their work double-checked by multiple other agents, and that keeps running for a longer period of time?
I feel like there are more efficient ways to tackle the issues given.
Possibly. But otoh one cannot complain that agents don't produce high quality code while at the same time not allowing them to thoroughly go through all the steps required to produce high quality code
The issue was less privacy concerns, and more "hey lets not hand over one of the most critical pieces of infrastructure to a potentially hostile state". DigID is the user authentication platform for basically every government site in The Netherlands. A foreign government could use sanctions to pressure Dutch individuals to comply by limiting access to it.
More broadly, I think it's "let's not hand over essential infrastructure to any foreign state". Friendly or not, it doesn't matter.
Private companies ought to have the freedom to do business with whomever they like, but for essential public services, better to assume essential public infrastructure simply must not be offshored at all.
I don't know about that. I don't think it'd have been a major issue in the country if it were a Belgian or German takeover. It may still not have been desirable, but I doubt the government would have stepped in like they did here.
That factoid always hides the real issue. The biggest reason that that factoid is true is that the 100 biggest companies includes a large amount of the fossil fuel industry, and that that industry produces most emissions in the world. A company like Saudi Aramco produce 4% of global emissions.
We need to reduce our dependency on fossil fuels.
For full clarity, it's also not the 100 biggest corporations that produce most emissions, but the 100 biggest companies. A massive amount of the global emissions are done by state-owned companies.
> We need to reduce our dependency on fossil fuels.
Unfortunately the United States is currently ruled by a death cult that sees any further push to renewables as capitulation to China and is dedicated to burning fossil fuels until they are fully gone.
And while this part is less explicitly stated, I'm convinced they aren't ignorant of the devastating results of this policy, they just intend to profit off it rather than mitigate the harms, thus the stated interest in taking Greenland, Canada, etc.
They know things are going to get really bad, but they also know their own wealth will at least in the short term shield them from much personal exposure to the harm that will increasingly immiserate everyone else.
Let's be real, a lot of organizations never actually finish that R&D phase, and just continue iterating on their prototypes, and try to untangle the spaghetti for years.
I recently had to rewrite a part of such a prototype that had 15 years of development on it, which was a massive headache. One of the most useful things I used LLMs for was asking it to compare the rewritten functionality with the old one, and find potential differences. While I was busy refactoring and redesigning the underlying architecture, I then sometimes was pinged by the LLM to investigate a potential difference. It sometimes included false positives, but it did help me spot small details that otherwise would have taken quite a while of debugging.
Thankfully they are actively working towards upgrading, Unity 6.8 (they're currently on 6.4) is supposed to move fully towards CoreCLR, and removing Mono. We'll then finally be able to move to C# 14 (from C# 9, which came out in 2020), as well as use newer .NET functionality.
One annoying piece of Unity's CoreCLR plan is there is no plan to upgrade IL2CPP (Unity's AOT compiler) to use a better garbage collector. It will continue to use Boehm GC, which is so much worse for games.
They just haven't announced any plans to do so yet. They might one day.
They will not be using .NET AOT probably ever though. Unity's AOT basically supports full C# (reflection etc) while .NET opted to restrict it and lean more on generated code.
For .NET only the old legacy .NET Framework, SqlClient was moved to a separate package with the rewrite (from System.Data.SqlClient to Microsoft.Data.SqlClient). They realized that it was a rather bad idea to have that baked in to your main runtime, as it complicates your updates.
I was mostly looking at it for its state as being a cross-platform supported output platform of bytecode that's fairly well sandboxed. That makes it an excellent target for things like running untrusted plugins in an application in a performant manner.
reply