I don't know the situation now, but a while ago there were a lot of pushback using Next.js because it was not easy to use all features if not hosted on Vercel.
We used NextJS on a project hosted on AWS a while ago. We learned quickly it wasn't the best tool for what we wanted to do which is why we stopped using it. But it's an open source project whose purpose is to drive devs to Vercel. It doesn't surprise me that there are some features that work best with Vercel (but it does surprise me that only recently other providers started to need adapters).
Anyway, my point is that no one is forced to use NextJS and if they like NextJS but not Vercel they can always fork it or, apparently write an adapter.
Besides the way it maps server side code into serverless, it has a custom runtime, functions that expose cloud infrastructure, integration with multiple language runtimes for the backend.
You get to pick Vercel + headless CMS + assets managed + eshop, and you're done in terms of big corporations.
Might seem a lot in licenses, however it allows for smaller dev teams, which is what management floor cares about, all those salaries.
I don't use Zig (is not a language for me), but I like to read/watch about it, when you or others talk about the language design and the reasons behind the changes.
- Cranelift applies less optimizations in exchange for faster compilation times, because it was developed to compile WASM (wasmtime), but turns out that is good enough for Rust debug builds.
- Cranelift does not support the wide range of platforms (AFAIK just X86_64 and some ARM targets)
I am not expert in compilers, but in databases space there are multiple prominent projects which gain traction, create ecosystem and making Rust strong contender against C++ dominance.
You need a fault tolerant parser, tree sitter is a good example on how it works in practice, your compiler should have the ability to run a few steps (parsing, symbol resolution, type checking, etc) with an incomplete/invalid AST.
> isn't it generally impossible to recovery syntactic errors
AFAIK Zig was designed in such way that, in most cases, you can parse each line independently, like their strings by default are single line, you need a special syntax for multiline strings that still are per line basis.
I doubt it's possible to perform proper syntax recovery without messing the result. My approach with usage of some previous valid program state is more reliable and easier to implement.
> AFAIK Zig was designed in such way that, in most cases, you can parse each line independently
It can't be true. Basic stuff like opening/closing braces introduces some global syntax state, so that line-by-line parsing isn't possible. Do you mean something like tokenization instead? It is in many cases possible. But for true LSP it's almost useless.
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).
reply