Rust evangelists are tiresome. It's not gonna fix the tech debt problem, No matter how much rust crack you smoke. Disciplined use of c, with modern tools like valgrind, will give you safe code without having to lobotomize yourself into fighting the borrow checker for everything, even manifestly simple code.
Hard Rust requirements from May onward
501–510 of 797 posts
Re: Hard Rust requirements from May onward
#502Earlier quoted context omitted.
> But hasn't all that foundational code been stable and wrung out already over the last 30+ years? Not necessarily. The "HTTP signature verification code" sounds like it's invoking cryptography, and the sense I've had from watching the people who maintain cryptographic libraries is that the "foundational code" is the sort of stuff you should run away screaming from. In general, it seems to me to be the cryptography f…
Actual cryptography code, the best path is formally verified implementations of the crypto algorithms; with parsers for wrapper formats like OpenPGP or PKCS#7 implemented in a memory safe language. You don't want the core cryptography implemented in Rust for Rust's sake when there's a formally verified Assembler version next to it. Formally verified _always_ beats anything else.
> Formally verified _always_ beats anything else.
Formally verified in an obscure language where it's difficult to find maintainers does not beat something written in a more "popular" language, even if it hasn't been formally verified (yet?).
And these days I would (unfortunately) consider assembly as an "obscure language".
(At any rate, I assume Rust versions of cryptographic primitives will still have some inline assembly to optimize for different platforms, or, at the very least, make use of compile intrinsics, which are safer than assembly, but still not fully safe.)
Re: Hard Rust requirements from May onward
#503Earlier quoted context omitted.
Well, we are on a mission to create The Universal Operating System. So maybe. But I'm not sure. I think the new Rust dependencies are good. In an ideal world, the people who care about niche systems step up to help Rust target those systems.
> In an ideal world, the people who care about niche systems step up to help Rust target those systems. I’m actually the person who added the m68k target to the Rust compiler and was also one of the driving forces of getting the backend into LLVM. Generally speaking, getting a new backend into the Rust compiler is not trivial as it depends on LLVM support at the moment which is why asking someone to just do it is a b…
Sorry, I didn't mean to insinuate that there's anything minor about it, or that nobody is doing the work. I should have phrased myself differently.
I'll try to rephrase: if we never want to give up support for a platform we've supported in the past, then I think we only have two options: (1) never adopt new technology where support for said platforms doesn't come for free, or (2) leave it up to those who care about the niches to ensure support.
Neither is pain-free, but the first seems like a recipe for stagnation.
It's lovely to see the two alternative compiler paths for Rust moving forward though! Thank you!
Re: Hard Rust requirements from May onward
#504Can we please also have the hard requirement that code should run without warnings under Valgrind? Because that saves a lot of headaches down the line.
Would be good for memory safety and wouldn't need a rewrite of all software in a hyped language. No, we shouldn't do that ;)
Motivated people seem to prefer rewriting using a 13 years old programming language. Crazy.
Re: Hard Rust requirements from May onward
#505[dead]
Re: Hard Rust requirements from May onward
#506I've been trying to build a debian package recently. I didn't have any crashes but I couldn't work out how to do it especially with the unbelievably contradictory and confusing documentation. I'm so glad I mainly use makepkg on Artix which is MUCH easier. I struggle to believe that this is really about a call to improve quality when there seem to be some other huge juicy targets.
Are you sure you're not conflating documentation with random people's writings on the web? Because that there seems to be a helluva lot of cargo culting on this topic.
Re: Hard Rust requirements from May onward
#507Earlier quoted context omitted.
Who is still using these machines? Genuine question, not trolling. It looks like the last machines of each architecture were released: Alpha in 2007 HP-PA in 2008 m68k in pre-2000 though derivatives are used in embedded systems sh4 in 1998 (though possible usage via "J2 core" using expired patents) This means that most are nearly 20 years old or older. Rust target triples exist for: m68k: https://doc.rust-lang.org/ni…
Debian just cut i386, Wikipedia says the i386 was discontinued in 2007. These systems are all of the same vintage, so it does not seem a huge leap to be culled from the support list. [0] https://en.wikipedia.org/wiki/I386
The actual Intel 80386 processor was discontinued in 2007, but the i386 architecture -- ia32, 32-bit x86 -- lived on for longer in the semi-mainstream (there were 32-bit Intel Atoms introduced to the market as late as 2012, AMD Geodes were sold until at least 2019, and I believe some VIA C3/C7 derivatives made it into the 2010s as well) and is in fact still in production to this day for the embedded and industrial markets (Vortex86, etc).
Re: Hard Rust requirements from May onward
#508They’d be better off just compiling the package manager with Fil-C No changes required. Bringing up the fil-C toolchain on weird ports is probably less work than bringing up the Rust toolchain
Fil-C is amazing but is much more problematic than Rust at this point since it only supports amd64 at this time and is maintained by a single genius. It also doesn't help you to attract new contributors. With the changes we made over in Ubuntu to switch to rust-coreutils and sudo-rs, we have seen an incredible uptake in community contributions amongst other things, and it's very interesting to me to try to push APT m…
> since it only supports amd64 at this time and is maintained by a single genius.
That's easily fixable.
> It also doesn't help you to attract new contributors.
I don't understand this point.
Re: Hard Rust requirements from May onward
#509Earlier quoted context omitted.
Who is still using these machines? Genuine question, not trolling. It looks like the last machines of each architecture were released: Alpha in 2007 HP-PA in 2008 m68k in pre-2000 though derivatives are used in embedded systems sh4 in 1998 (though possible usage via "J2 core" using expired patents) This means that most are nearly 20 years old or older. Rust target triples exist for: m68k: https://doc.rust-lang.org/ni…
It’s usually a loud minority of trolls or hobbyists. It just takes one to spark a doubt. Here is one famous example of a dude who’s managed to get PRs merged in dozens of packages, just to make them compatible with ancient versions of nodejs https://news.ycombinator.com/item?id=44831811
Wow that was an interesting read. I find it amusing that nobody seems to really know who he is or what his motives are, yet his code is run on millions of machines every day.
Re: Hard Rust requirements from May onward
#510Earlier quoted context omitted.
Actual cryptography code, the best path is formally verified implementations of the crypto algorithms; with parsers for wrapper formats like OpenPGP or PKCS#7 implemented in a memory safe language. You don't want the core cryptography implemented in Rust for Rust's sake when there's a formally verified Assembler version next to it. Formally verified _always_ beats anything else.
> Formally verified _always_ beats anything else. Formally verified in an obscure language where it's difficult to find maintainers does not beat something written in a more "popular" language, even if it hasn't been formally verified (yet?). And these days I would (unfortunately) consider assembly as an "obscure language". (At any rate, I assume Rust versions of cryptographic primitives will still have some inline a…
With crypto, you really want to just write the assembly, due to timing issues that higher level languages simply cannot guarantee.