721–730 of 731 posts
Earlier quoted context omitted.
I don't get the impression they care that much about performance. Besides, it would limit the number of platforms it could run on if it requires a recent GPU.
Using Rust means they’ve limited the number of platforms already… so I doubt they care.
Earlier quoted context omitted.
Same here. I had Claude write me a web based RSS feed reader in Rust. It has some minor glitches I still need to iron out, but it works great, is fast as can be, and is easy on the eyes. https://github.com/AdrianVollmer/FluxFeed
Rust is the final language. Defect free. Immaculate types. Safe. Ergonomic. Beautiful to read. AI is going to be writing a lot of Rust. The final arguments of "rust is hard to write" are going to quiet down. This makes it even more accessible.
Earlier quoted context omitted.
Isn't the reason simply that they want to code in C++? This is a passion project.
> Isn't the reason simply that they want to code in C++? I don't know that that is the reason, given the opening lines of the article: We’ve been searching for a memory-safe programming language to replace C++ in Ladybird for a while now. We previously explored Swift, but the C++ interop never quite got there, and platform support outside the Apple ecosystem was limited. Rust is a different story. The ecosystem is fa…
> We will continue developing the engine in C++, and porting subsystems to Rust will be a sidetrack that runs for a long time. So, even though they want the code base to be in Rust, they will continue writing new code in C++ and then translating it to Rust later to remove the C++ they just added. There must be a really good reason for this, such as Rust doesn’t interop well with C++, otherwise this seems like a poor…
Yea, I'd bet it's that. Ideally, you'd want to stop writing C++ and continue with Rust on all new code, but Rust has stricter semantics, so the interop is somewhat "easy" in one direction, but very hairy in the other direction.
This means that in practice, you want to start porting from leaf components and slowly grow closer to the root, which stays in C++ for quite some time and just calls into Rust through C API (or something close to it).
If you're curious about the topic, there's a interop library called Zngur (https://hkalbasi.github.io/zngur/), which is built on this assumption. They have a pretty good explanation of the concrete problems on the homepage.
> We previously explored Swift, but the C++ interop never quite got there, and platform support outside the Apple ecosystem was limited. Why was there ever any expectation for Swift having good platform support outside Apple? This should have been (and was to me) already obvious when they originally announced moving to Swift.
[1] Swift was first created in 2010, 16 years ago and officially launched in 2014, 12 years ago, by a huge multi-billion dollar corporation. The same corporation has launched hundreds of products and services in the same time period. If they really wanted Swift to be cross platform at a competitive level (Java, .Net, Python, JS, etc), they would have done it by now.
Earlier quoted context omitted.
The reason folks still use c/c++ is because of ecosystem. Chances are you have a lot of code you depend on and don't have straightforward ways to port it (and all the transitive deps). Especially in the case of larger enterprise software where there are 10s of millions of lines keeping you entrenched. Foundational things like your threading model, async executor, etc can make it difficult. If you're operating in a mi…
I assumed new projects but I just realised that I didn’t write it. But still disagree: we have cbindgen.
Earlier quoted context omitted.
Rust is the final language. Defect free. Immaculate types. Safe. Ergonomic. Beautiful to read. AI is going to be writing a lot of Rust. The final arguments of "rust is hard to write" are going to quiet down. This makes it even more accessible.
Rust may be the darling of the moment, but Erlang is oft slept on. As AI makes human-readable syntax less relevant, the Erlang/Elixir BEAM virtual machine is an ideal compilation target because its "let it crash" isolated process model provides system-level fault tolerance against AI logic errors, arguably more valuable than Rust’s strict memory safety. The native Actor Model simplifies massive concurrency by elimina…
We spend quite a lot of time conceptualizing around safe self mod and to build apps that can change at runtime. We ended up using custom Lua VM, type system to catch mistakes, declarative homogenous infrastructure and actor model (erlang inspired).
Actor model provides not just a good isolation but also it's much easier for AI to reason (since most of components are not that large), we already able to use it to write quite complex systems with ease.
Another upside - in actor model you don't really need any of this fluff with cron jobs, queues and etc, all the logic naturally maps to indended architecture, making implementation of agents _very_ easy.
https://wippy.ai/en/tutorials/micro-agi It takes 4-5 files to create mini sandboxed AI agent at top of actor model with ability to modify own toolkit while having system guardails and no access to core filesystem.
Earlier quoted context omitted.
Rust may be the darling of the moment, but Erlang is oft slept on. As AI makes human-readable syntax less relevant, the Erlang/Elixir BEAM virtual machine is an ideal compilation target because its "let it crash" isolated process model provides system-level fault tolerance against AI logic errors, arguably more valuable than Rust’s strict memory safety. The native Actor Model simplifies massive concurrency by elimina…
I can't comment on production viability today but if you assume that language itself is irrelevant then it becomes clear that runtime and engine level is the way to go. We spend quite a lot of time conceptualizing around safe self mod and to build apps that can change at runtime. We ended up using custom Lua VM, type system to catch mistakes, declarative homogenous infrastructure and actor model (erlang inspired). Ac…
i had high hopes for ladybird to become an alternative browser anyone with a working C++ compiler could build on whatever platform.
Earlier quoted context omitted.
I'd argue Ladybird itself is a "hype" project.
Anything trying to break the browser monopolies in a meaningful way deserves the hype, IMO.
> monopolies