This makes sense, and explains why there's more Rust game engines than Rust games :)
Rust adds friction to quick prototyping, but OTOH it is particularly good at providing robust, safe library APIs (with machine-checked memory management, lifetimes, sharing across threads, and strong patterns for error handling). It's one of the reasons why Rust applications can easily use so many dependencies.
Rust intentionally makes it difficult to cut corners, and by default enforces all of its best practices around immutability, thread-safety, etc. This is annoying for quickly trying things out for gameplay purposes (central point of the "Leaving Rust gamedev" post), because exploration of gameplay ideas doesn't need bug-free code, it needs to iterate quickly.
But this focus on correctness is the right trade-off when building foundational components and libraries. Applications need to have a stable and reliable platform to build on, and to actually ship they can't have a "prototype-quality" engine.
I think the point is that Rust encodes more rules in its interfaces (ownership, lifetimes, thread safety). If you misunderstand how a Rust library works, your code most likely won't compile instead of silently causing UB.
The rules for safe interfaces are the same for all Rust programs, so users know what to expect. Whereas in C++ the library author has more to say what usage is supported and what isn't (e.g. Rust requires all globals to be thread-safe unconditionally, but a C++ library may say it's thread safe if you set a config option or it's your problem to synchronize access).
Unknowable lifetimes are a necessary evil. Rust has them too. It's called RefCell. Without RefCell there are very useful things that are impossible to write in safe Rust.
You have to set some baseline. We assume the CPU can divide numbers correctly, even though not all of them did.
Autoconf has set the baseline so low that everyone perpetually pays for the technical debt of ancient buggy platforms. Sometimes it's better to push a buggy platform to fix its own bugs, than to have everyone work around those bugs forever.
It's a hybrid with the engine ripped out - there's literally huge empty space under the hood, but they haven't even bothered to move things around to make a frunk.
Sure, but the state of the market means there’s nothing better. The reasonable competitors don’t have equivalent battery capacity and extra space under the hood, they have extra battery, which for my use is worse than empty space, it’s extra cost upfront plus extra weight to lug around.
MX-30 is not particularly light, nor spacious compared to other "city" EVs.
I get that Mazda has a reputable brand, but MX-30 is just an F.U. to the state of California. Mazda sells less than 10 of them per month. Not ten thousand. Just ten.
There are small-battery trims of many EVs in the similar price range, usually with faster charging and better range: Kona, MG4, e-C4, Zoe, e-208, Fiat e500, for a slightly higher price there's Volvo EX30. And among short-range difficult-to-charge cars Leaf is cheaper.
Again, to me, "more range" as a result of a bigger battery is a negative.
And just out of curiosity, I compared local pricing (CAD) - a Kona starts $47k after rebates and incentives and an MX-30 starts at $39k, so pretty hefty difference. For that matter, even the Leaf starts at $42k.
As for the Leaf, I wouldn't consider an EV without active cooling on the batteries unless the manufacturer included a lifetime battery warranty.
The talk of a light frugal battery is only a marketing spin. The range and usable capacity are small, but the gross battery capacity is only 11% smaller than in Leaf. MX-30 is heavier than Leaf, Kona, and even Tesla Model 3 SR/RWD.
> The talk of a light frugal battery is only a marketing spin.
I've literally never seen any such marketing. All I've done is look at the spec sheet.
> MX-30 is heavier than Leaf, Kona, and even Tesla Model 3 SR/RWD.
Not the Kona. Marginally heavier than the lowest trim of the Leaf.
But by having a smaller battery, the impression to me is that the weight goes to something useful, rather than battery, so I'm getting more car for the weight. (The base MX-30 is notably more featurful than the base Leaf.) Plus more car for the price, as I've previously mentioned.
You address the "personalization" misconception, but to people who don't have this misconception, but are concerned about data retention in a more general sense, this article is unclear and seems self-contradictory.
"ChatGPT and other LLMs don’t remember everything you say" in the title is contradicted by the "Reasons to worry anyway", because OpenAI does remember (store) everything I say in non-opted-out chat interface, and there's no guarantee that a future ChatGPT based on the next model won't "remember" it in some way.
In the sense of a chat bot that people are interacting with, it doesn't remember. That's an important distinction, regardless of what OpenAI does to save your interactions somewhere for whatever purposes they may have in mind.
This is a common misconception that if the kernel needs direct hardware access and such, then it all becomes unsafe.
Rust programming style is building safe (zero-cost) abstractions on top of unsafe primitives, turning all other code into safe "glue" code. If you design for it, you can have a lot of "boring" code even in a kernel.
A kernel will have more unsafe primitives to implement, but the safe/unsafe division still helps testing the unsafe parts, and still prevents bugs caused by misuse of these APIs.
The type system that gives safety in userspace still exists in the kernel space. So even if the allocators and threads are different, you still have the type system tools to write safer APIs for them.
Yes. Because it's popular and large the Linux kernel has problems where abstractions leak and a subtle implementation detail causes problems because you were supposed to just know that certain APIs don't do quite what it seems like they'd do from the name.
Rust's culture says you must mark abstractions that leak safety as unsafe. If this Rust function named "make_doodad" is labelled safe, it is not OK that I could run it without a doodad_manager, and yet in this case it blows up. Either somehow require me to prove I have a doodad_manager, or, mark it unsafe and document the requirement, or re-design the function so that it checks for a doodad_manager and fails cleanly when one is not present. In some cases you might decide all three are needed: make_doodad_with_manager(&manager) -> Doodad, unsafe make_doodad_unchecked() -> Doodad and make_doodad() -> Result<Doodad,Problem>
The downside with plugin hybrids is that they require having a charger at home. Otherwise they're annoying enough that people give up on charging them.
This is because smaller batteries take a long time to charge (usually AC only), and small capacity means they need to be charged frequently (often daily).
BEVs can have batteries 10x larger, which also allows them to charge at a 10x faster rate. The larger battery can last a whole week on a single charge. Quick infrequent charging makes them tolerable even without having a charger at home.
BEVs also don't cycle whole batteries that much, because driving 30 miles daily will use 10% of the battery, not 100%.
Rust adds friction to quick prototyping, but OTOH it is particularly good at providing robust, safe library APIs (with machine-checked memory management, lifetimes, sharing across threads, and strong patterns for error handling). It's one of the reasons why Rust applications can easily use so many dependencies.
Rust intentionally makes it difficult to cut corners, and by default enforces all of its best practices around immutability, thread-safety, etc. This is annoying for quickly trying things out for gameplay purposes (central point of the "Leaving Rust gamedev" post), because exploration of gameplay ideas doesn't need bug-free code, it needs to iterate quickly.
But this focus on correctness is the right trade-off when building foundational components and libraries. Applications need to have a stable and reliable platform to build on, and to actually ship they can't have a "prototype-quality" engine.