From the link it seems that Ladybird architecture is very modular, in this case LibJS is one of the subsystems that has less external dependencies, said that they don't need to migrate everything, only the parts that makes sense.
Javascript is a self contained sub system, if the public API stays the same, then they can rewrite as much as they want, also I suppose this engine now will attract new contributors that will want to contribute to Ladybird just because they enjoy working with Rust.
Don't forget that the Rust ecosystem around browsers is growing, Firefox already uses it for their CSS engine[0], AFAIK Chrome JPEG XL implementation is written in Rust.
So I don't see how this could be seen as a negative move, I don't think sharing libraries in C++ is as easy as in Rust.
Not only is Firefox using it for their CSS engine but Mozilla created Rust to build Servo and sadly only the CSS engine and maybe some other parts is what they kept around when they offloaded Rust.
“the Rust ecosystem around browsers is growing” – in the beginning pretty much 100% of the ecosystem around Rust was browser oriented
Thankfully Servo is picking up speed again and is a great project to help support with some donations etc: https://servo.org/
Java garbage collection gets out of control when cramming 100+ poorly optimized mods together. The bedrock edition is great in theory but the proper mod API never appeared. Regardless, people have accomplished some really impressive stuff with commands, but it is an exercise in pain.
The other issue with bedrock is it is far from feature parity with java. If these two things were hit then java could be reasonably retired. However we are decades too late in it being acceptable to introduce a breaking change to mod loading. So it's java forever.
>Consider this, if the mod interface was C/C++, do you think those poorly optimized mods could be trusted to also not leak memory?
Of course. Because they would fail loudly and would have to be fixed in order to run. Garbage collection is a crutch which lets broken things appear not broken.
Memory leaks very often don't fail loudly. Especially if they are slower leaks which don't immediately break the application.
A lot of the memory problems that you can see without a GC are hard to find and diagnose. Use after free, for example, is very often safe. It only crashes or causes problems sometimes. Same for double free. And they are hard to diagnose because the problems they do create are often observed at a distance. Use after free will silently corrupt some bit of memory somewhere else, what trips up on it might be completely unrelated.
> A lot of the memory problems that you can see without a GC are hard to find and diagnose
The nastiest leak I've ever seen in a C++ production system happened inside the allocator. We had a really hostile allocation pattern that forced the book-keeping structures inside the allocator to grow over time.
To be fair, I've seen something similar with the JVM, though it recovers. G1GC when it was first introduced would create these massive bookkeeping structures in order to run collections. We are talking about off JVM heap memory allocations up to 20% of the JVM heap allocation.
It's since gotten a lot better with JVM updates, so much so that it's not a problem in Java 21 and 25.
> Consider this, if the mod interface was C/C++, do you think those poorly optimized mods could be trusted to also not leak memory?
Garbage collection does not solve memory leak problems. For example
- keeping a reference too long,
- much more subtle: having a reference to some object inside some closure
will also cause memory leaks in a garbage-collected language.
The proper solution is to consider what you name "poorly optimized mods" to be highly experimental (only those who are of very high quality can be treated differently).
> Garbage collection does not solve memory leak problems
It solves a class of memory leak problems which are much harder to address without the GC. Memory lifetimes.
It's true that you can still create an object that legitimately lives for the duration of the application, nothing solves that.
But what you can't do is allocate something on the heap and forget to free it. Or double free it. Or free it before the actual lifetime has finished.
Those are much trickier problems to solve which experienced C/C++ programmers trip over all the time. It's hard enough to have been the genesis of languages like Java and Rust.
There is no "must use GC" mode, as far as I'm aware, but the footguns you describe only exist if the programmers opt-out of the GC. It's somewhat similar to using JNI/FFM in Java: it's possible to escape the safety of the VM. Though it's much easier to do so in D.
I always had trouble running bedrock as a household server. Specifically it would stop accepting connections and required daily restarts. Java was much more reliable.
Skins, media packs, servers, hosted realms, upsales through all consoles, multiple copies for multiplayer with/between your kids… also a mass revolving shit tumbler of account stuff on the backend that invalidated lots of old accounts…
I bought during the beta for a lifetime of goodies, had to buy it again after the buyout, then again after an update to MS accounts wasn’t acted on, and then for the Switch. I’ve bought Minecraft 4 times, with another on the horizon if it keeps popular.
That was probably their intention, but Bedrock has proven to be full of papercut sized bugs, and maintaining 1:1 behaviour with Java has also proven really difficult. Redstone is notably different/broken with the exception of trivial circuits.
Until it's possible to convert your world to Bedrock and not have anything in your 'finished' world break, except maybe some giant Redstone machine or one or two known annoyanced, I doubt they'd do it. Mojang presumably still has some autonomy within Microsoft so long as the money keeps coming in, and Mojang presumably knows that pushing this too early is a bad idea. But Microsoft being Microslop, who knows, maybe they'll just do it anyway.
I don't think 1:1 behaviour with Java was ever the intent. Redstone works differently due to a combination of different design choices, like not breaking in water (although I can imagine that being an accessibility thing for console players) and less technical debt, making things like movable tile entities possible.
I don't know what you mean by media packs, but the server software is free, and I believe all of the skins and maps released by Mojang itself on Bedrock's marketplace are also free. It's the third-party stuff that costs money, although I assume Mojang takes their cut.
They do have a bunch of add-ons now with Realms notably, but I wonder if this revenue goes to Mojang or to another Microsoft branch for tax reasons. To say nothing of derived media, plushies, Legos etc.
Most of what the section "Why ROX exists" reminds me of Rust and Zig, where both are more explicit (but Zig even more where there aren't hidden allocations, while Rust hides it).
Said that I really miss all the i{8|16|32|64|128|size}, u{8|16|32|64|128|size} and f{32|64} in other languages, I think having num and num32 is a mistake (IMHO) and naming like them like Rust/Zig provides more clarity (and it's also more concise).
For the "repeat" keyword I find it odd, because most other languages uses "for" but I can understand the reason and might be able to get used to it.
Otherwise I find always interesting new programming languages, what new they bring to the table and the lessons learned from other PLs.
There still are lots of 32-, 16- and even 8-bits CPUs in active use. For those portable code that uses machine integers can make sense (and yes, it is harder to write because the integer limits will vary with the integer type used, but the added performance can be worth that).
I have my doubts on Jai, besides being built towards game development, from what I read/watched about it, it has 2 or 3 meta programming capabilities, like comptime, macros, etc it feels too much of the same, also Jai is not built towards correctness or safety, John mentality is that he knows what he is doing, so he doesn’t need those guardrails and he wants instead expressiveness.
Also Jai is like C++ in complexity, while Zig is similar to C, very simple language.
Carbon is vaporware so far, there’s no language that could be used yet, because they first need to solve the C++ interop and fast compilation times, that is what will shape the language, so no one is using it, because it doesn’t exist yet.
Remember that it was Jai that inspired all these new languages. When you talk about the capabilities like comptime, that's all from Jai and why John no longer does public presentations(as people keep stealing his unfinished ideas).
Your comment about gamedev focus makes no sense as that it the most hardcore segment of all the programming there is. So if a language is good for gamedev, it's good for everything else - with high performance.
I'm still in the GC camp with Go and don't see myself leaving any time soon but Zig is just rust-fugly and takes for ever to complete(it started 10 years ago, mind you). Odin is essentially complete, just lacks official spec. I like it but can' bring myself to use it as it lacks methods and I won' be going back to writing a procedural code like its 2002.
I'm curious to see Jai being released, despite having no use case for it. My initial post is merely about purposefulness, or the lack of, for named programming languages as nowadays John's name will carry more weight than Zig could ever have. so without Zig being 1.0 after a decade, and having no competitive advantage over Jai, it has no chance to survive after Jai is released. As I said, Odin will likely will as it is quite simpler, more niche language. Zig just goes directly against Jai and it will lose.
> When you talk about the capabilities like comptime, that's all from Jai
You really should learn a few new languages if you think that’s remotely true. For example, Lisp macros are the distant ancestors of most metaprogramming techniques, dating from the 60s. But there are many similar techniques that precede Zig comptime and Jai, like D’s mixins and templates, which together have very similar power to comptime. There are also Nim macros which I believe also precede Jai. Even the C preprocessor could probably be considered an inspiration for anyone creating a C competitor before we need to invoke Jai ideas.
The idea of languages "stealing" ideas from each other is not something anyone building a language cares about. I'll just charitably assume you've completly misinterpreted something he said.
Not sure why this is being downvoted, Blow started working on Jai in 2014, by which point Rust was already nearing stabilization with 1.0 shipping in 2015.
In fact Rust was specifically discussed as a possible alternative to the C++ status quo in Jon's initial "A Programming Language For Games" talk which roughly marks the inception of his current / upcoming language.
Good luck with that, it is basically Modula-2 with C like syntax, and we aren't even getting into the whole ecosystem that it is missing on.
Any C++ or C replacement will need to win the earths of mainstream OS and game console vendors, otherwise it will remain yet another wannabe candidate.
Those have already their own languages, alongside their own C and C++ compilers, and are only now starting to warm up to Rust.
Zig or any other candidate will have a very hard time being considered.
So no one should even try because they will never win over all of the C/C++ crowd so are doomed to fail and forever to be a wannabe? I think Andrew has gone about things in a good way, going back to C and exploiting hindsight, not trying to offer everything as quickly as possible. Extend C but keep C interoperability and do both better than C++ instead of trying to be the next big thing and he goes about it in a very deliberate and calculated way. He may not succeed, but the effort has given us a great deal.
One should try, while being aware of the realities of language adoption.
I disagree Zig is that great deal of a language, it would have been if we were talking about 1990's programming language ecosystem, not in 21st century.
Use-after-free problems should not be something we still need to worry about, when tooling like PurifyPlus trace back to 1992.
I don't think Andrew believes Zig is going kill C or C++, he probably has hope but I think he is aware of the reality. He found a way to make a living on something he was passionate about.
Use-after-free is a fact of life until something kills C, but the realities of language adoption are against that. Zig seems interesting and worthwhile in offering a different perspective on the problem and does it in a way more agreeable than Rust or the like for all those who love C and are adverse to large complex languages. The realities of language adoption are as much for as against Zig, large numbers of people are still getting drawn to C and Zig seems to do a better job addressing why so many are drawn to it than the alternatives.
Agreed! Many sites don't actually comply with the GDPR because they don't provide simple tools to control the cookies and instead force you through a flow. Part of my gripe with the law is the way those violations are not being systematically cited.
The thing with GPUI is that the library itself is very low level and their scope is limited (by design I suppose), the ui with components is a separate crate with GPL license, while GPUI license is Apache.
As far GPUI has a great foundation, the community can built the components themselves.
AFAIK they also were focusing on upstream the changes into the kernel [0], because the amount of downstream patches they were maintaining were making the work harder and harder.
Agree, it would be awesome to move all your mac windows all over the place instead of being constrained in a virtual display. That would cut the amount of displays you need o have in order to be able to see more without switching between stacked windows, I will be tempted to buy one, if that were possible.
I have 3 displays and I am tempted to replace them with a single one, but bigger (with something like the Samsung Odyssey Ark).
reply