> Rust was designed to facilitate incremental rewrites of an existing C++ library
Do you have a source for this claim? Rust is a fine language (though its advocates can be a bit belligerent sometimes). But, as a matter of fact, Rust was not designed for a easy interoperability with C++ or to make gradual rewrites easy.
Correct. And if those projects exposed a C++ API, then rewriting them in Rust would be highly problematic, because Rust did not prioritize C++/Rust interoperability (for well-understood reasons). So, you can either have a C API and move to Rust or have a C++ API and create a Rust version of the library for Rust developers, but your original users of the C++ library will stick with the C++ version.
> If it was written in C++, there's a good chance it was so for performance reasons.
I agree. But imagine that games like Doom or Quake would have been unthinkable if they weren't fully written in C/C++. Now, however, we have 3D game engines like Unity that expose a C# API for game logic scripting, and it seems to work just fine. Performance is becoming less of a concern for more and more problem domains.
> My observation is most people who suggest Rust alternative don't use Rust.
This is a very condescending statement. In fact, for most software, when given the option of a full rewrite from C/C++ to another language, Rust is usually the least reasonable option. Fully automatic memory-managed languages should be considered first.
> People who actually use Rust known it is worth to rewrite C/C++ software in Rust, either the whole or part by part.
A full rewrite is not a feasible option for many large projects, and Rust does not make it easy to rewrite C++ code piece by piece, as the linked article clearly explains.
It's not true that developers don't like full rewrites. Most often, it's the path most developers would choose if they had enough time and funding. But in reality, you don't get either of those two.
And even if you are willing to do a full rewrite, your project probably has non-trivial dependencies on large, mature C++ libraries. You are not going to rewrite those. This is why more new projects are started in C++ every day than in Rust.
BTW, there are also other interesting, low-power RISC architectures that are used in millions of devices, but most people have never heard of them. For example:
* SuperH [0], 32bit only, now basically dead, but microcontrollers are still available
* AVR32 [1], 32 bit only, also quite dead
* ARC [2], 32/64bit, still quite popular in an automotive
> What's the appeal of this compared to a cheaper and more powerful N150 NUC, or a used mini PC
This is a very good question. The Pi 500+ is a beautiful product, but when compared in terms of price/value to the NUC and various other mini PCs, its value proposition is questionable.
Perhaps the target group are enthusiasts who had 8/16-bit "all-in-one" computers like Commodore64, Amiga, Atari, ZX Spectrum, Acorn etc., in their younger years and now want to buy something similar (non-x86) for themselves or force it on their kids. :)
I cannot give you proof for the line of political thinking. :)
> ...having a monopoly in one country is a strategic advantage over other countries.
Having a large, unified domestic market is a strategic advantage because it enables companies to grow to a size that makes them formidable global competitors [0]. The United States and China are examples of this phenomenon. The point isn't whether it's advantageous to allow such companies to become monopolies. Once these companies reach a certain size, politicians are reluctant to break them up because they don't want other global companies to take their place.
> the EU has the ability to fine foreign businesses for being monopolies too.
Specifically, the EU has no ability to fight foreign monopolies. Though, it has an ability to fine them and extort some pocket money from them. However, this hasn't had a tangible effect on creating more competition in those markets.
What would be an acceptable source for you? Which was the last US mega-corporation that the US government broke up? It certainly wasn't Microsoft or Google. Allowing huge companies to grow even bigger gives them more competitive power in the global market. This wasn't as important before we had super-globalized economies.
The reason governments no longer fight huge corporations or even clear monopolies is also due to heavy globalization. If one government destroys a monopoly (a global mega-corporation) in its country, it may strengthen the monopoly (and the global mega-corporation) in another country. So the line of thinking is, "We don't like this nasty monopoly, but at least it's our monopoly."
Nice article, but it was probably heavily machine-translated with little human intervention. There is a message that says "Code Language: JavaScript" all over the place, but the code examples are actually in Rust, and the last (unnecessary) one is in C++.
> Apple is quietly but surely increasing its control on macOS.
This is certainly happening. However, as long as you can still install your preferred browser with its own rendering engine or a different PDF reader, the situation isn't so bad.
> * Without an active OS development its only 1/2 of the puzzle.*
And this is an unfortunate state of the general purpose ARM64 computing. This board, with 16 GB of RAM and M.2 slot, would make the perfect Linux desktop machine. However, you only receive one or two major distribution updates from the hardware vendor, and then you're stuck with it.
From the article: Anthropic has been suffering from pretty terrible reliability problems.
In the past, factories used to shut down when there was a shortage of coal for steam engines or when the electricity supply failed. In the future, programmers will have factory holidays when their AI-coding language model is down.
The problem is that AI can generate answers and code that look relevant and as if they were written by someone very competent. Since AI can generate a huge amount of code in a short time, it's difficult for the human brain to analyze it all and determine whether it's useful or just BS.
And the worst case is when AI generates great code with a tiny, hard-to-discover catch that takes hours to spot and understand.
You must have confused Perl with another programming language. Perl has always been a memory-managed language with a reference-counted garbage collector.
The link you posted doesn't even mention Perl at all. It does say that:
Using a memory safe language can help prevent programmers from introducing certain types of memory-related issues. Memory is managed automatically as part of the computer language; it does not rely on the programmer adding code to implement memory protections.
Perl clearly fits the definition of a memory-safe language with automatic memory management. The funny thing is that this document lists Delphi/Object Pascal as memory-safe languages, even though there are clearly not.
Do you have a source for this claim? Rust is a fine language (though its advocates can be a bit belligerent sometimes). But, as a matter of fact, Rust was not designed for a easy interoperability with C++ or to make gradual rewrites easy.