Rust "makes programming fun again".

astyle said:
Reading about Rust, I'm beginning to actually like what they're trying to do in terms of Code of Conduct. Who wants to work with someone who places themselves to be unaccountable to anyone but themselves? I think that was very well put.
Click to expand...
They should migrate to the one based on LLVM like FreeBSD did. That CoC is based on the Contributor Covenant created by the same person who penned the Post-Meritocracy Manifesto. I have a deep distrust of all kinds of anti-meritocracy postures. PDVSA in Venezuela was explicitly meritocratic until Hugo Chávez came and destroyed it because "meritocracy". It led to all kinds of purges. We saw it with Python and the Kangaroo CoCourt vs. Tim Peters.

Read this article by the left-leaning Spanish newspaper:
english.elpais.com

Rampant corruption in Venezuela’s national oil company weighs down the economy

In the 1990s, PDVSA was a model state enterprise, but its politicization has become an albatross around the country’s neck
english.elpais.com english.elpais.com
 
Back to the topic: I think the problem is not so much the language but the ecosystem. For Bcachefs in Linux, which will be rewritten in Rust, you'll need a specific version and apparently this needs to have both Clang & GCC installed. It must be a bootstrapping and maintenance nightmare. Haven't tried it yet, though.
 
Don't forget, ALL PROGRAMMING LANGUAGES ARE FINALLY TRANSLATED INTO UNSAFE BINARY FORM FOR RUNNING CPU.
This means, unless unsafety is somehow mandatory (i.e., to support unsafely designed hardwares), unsafe languages can be used to code safe codes.

And more, evil developers in memory-safe language projects can put something to forcibly generate unsafe codes (break memory safety, put backdoors, ...) in translators (compiler, interpreter, assembler and code generator for IRs) for the language if the project is NOT sanely managed.
Thankfully, if the project is an open source project, there are chances that someone notices the evil fact.
 
There is no "safe"... The best you can do is design tools that attempt to mitigate common classes of bugs, giong all the way back to 'lint'. As far as I can tell, from the (very) limited reading I've done so far, Rust's main claim is to have moved the work for mitigating things like memory safety bugs, from run-time, to compile time. Which is a worthwhile innovation, provided it does not result in a programming language that becomes over-complicated, over-stuffed with features and burdonsome to learn and use.
 
cracauer@ said:
I just messed with pipewire, the new audio server. The oss API backend for it in written in Rust. The FreeBSD port uses 56 different crates. 26 of which have version numbers < 1.0. That's just one backend module, not the actual server.
Click to expand...
PipeWire doesn't have an OSS backend. What we have in ports is my OSS plugin for it (and another LLM-powered fork of said plugin), which is, unsurprisingly, written in a language I'm comfortable with. There are official Rust bindings for PipeWire, though.

You could also use ALSA with PipeWire if you wish.
 
Doesn't the OS and some mobo RAM init handle randomization of stuff in RAM? Does a memory-safe language accomplish something similar to OS/mobo?

I like speed :p

img.png
 
You must log in or register to reply here.
Back
Top