183 karma · joined July 9, 2024
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.
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.
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.
* 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
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.
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.
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.
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.
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.
And the worst case is when AI generates great code with a tiny, hard-to-discover catch that takes hours to spot and understand.
I suppose there's a reason why kids are usually banned from using calculators during their first years of school when they're learning basic math.
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.
The original article already contains a note that "Some more recent x64 CPUs use 5-level paging, which would increase this number to 57 bits [0]"
Apparently server-level "Sunny Cove" Intel CPUs implement this extension [1].
[0]: https://en.wikipedia.org/wiki/Intel_5-level_paging
[1]: <https://en.wikipedia.org/wiki/Sunny_Cove_(microarchitecture)>
Perl is memory safe.
> loaded with security issues for over a decade.
According to CVE reports, it doesn't appear that Perl [0] is less secure than Python [1]:
[0]: <https://www.fudzilla.com/6882-nvidia-continues-comic-campaig...>
JavaScript was considered as a unstable and under-specified part of the Web in the "Dynamic HTML" era somewhere between 1997-2006, when Microsoft Internet Explorer implementation of DOM diverged from more standard Netscape/Firefox in many tricky ways. This has largely been solved by better standards, initiatives like Acid tests and (unfortunately) slowly spiraling into Blink engine monoculture.
For me, the fact that Windows 95/98 can't use the HLT instruction is a reason why I wouldn't use these legacy operating systems to run older software. Not that many programs ran on Win95/98 but not on Win2000. Perhaps except for DOS games, which are better served by DOSBox.
Yes, that's one (common) approach to dynamic programming. The recursive function call are memoized so that previous calculations are remembered for future function calls. Overlapping subproblems become trivial if you can reuse previously computed values. The recursion with memoization is top-down dynamic programming.