APT Rust requirement raises questions

Post by sedatk » Tue, Nov 25, 2025, 5:25 PM UTC

dontlaugh wrote: post #258

fn-mote wrote: post #20

The most interesting criticism / idea in the article was that the parts that are intended for Rust-ification should actually be removed from core apt. > it would be better to remove the code that is used to parse the .deb, .ar, and .tar formats [...] from APT entirely. It is only needed for two tools, apt-ftparchive and apt-extracttemplates [...] Another interesting, although perhaps tangential, criticism was that th…

It seems silly to say that it has no tests. If I had to pick between unit and integration tests, I'd pick integration tests every time.

Post by xscott » Tue, Nov 25, 2025, 5:25 PM UTC

steveklabnik wrote: post #260

xscott wrote: post #233

Earlier quoted context omitted.

This is some True Scotsman style counter argument, and it's hard for me to make a polite reply to it. There are people who program with a "fake it till you make it" approach, cutting and pasting from Stack Overflow, and hoping the compiler errors are enough to fix their mess. Historically, these are the ones your pages/books cater to, and the ones who think the borrow checker is the hard part. It doesn't surprise me…

The issue though is that this isn't a solvable "problem". This is how programming languages' syntax work. It's like saying that C's if syntax is bad because these are equivalent: if (x > y) { if ((x > y)) { if (((x) > (y))) { Yes, one of your co-workers may write the third form. But it's just not possible for a programming language to stop this from existing, or at least, maybe you could do it, but it would add a ton…

Post by echelon » Tue, Nov 25, 2025, 5:27 PM UTC

SoftTalker wrote: post #169

echelon wrote: post #128

Earlier quoted context omitted.

That's it exactly. Once you're writing Rust at full speed, you'll find you won't be putting lifetimes and trait bounds on everything. Some of this becomes implicit, some of it you can just avoid with simpler patterns. When you write Rust code without lifetimes and trait bounds and nested types, the language looks like Ruby lite. When you write Rust code with traits or nested types, it looks like Java + Ruby. When you…

This honestly reads like the cliche "you just don't get it yet" dismissals of many rust criticisms.

Post by cogman10 » Tue, Nov 25, 2025, 5:28 PM UTC

tyfon wrote: post #265

cogman10 wrote: post #252

Earlier quoted context omitted.

This sounds like it's fun. However, I have to ask, why should the linux world cater to supporting 30 year old systems? Just because it scratches an itch? You can grab a $150 NUC which will run circles around this dual pentium pro system while also using a faction of the power. You obviously have to do a lot of extra work, including having a second system, just to keep this old system running. More work than it'd take…

The system is actually running fine standalone since I have been able to avoid rust software. As to why it should cater to it, it's more that there is no need to remove something that already works just to remove it. It is possible to compile rustc on another system so it supports i586 and below. Just a small change in the command line options. And it doesn't degrade the newer systems. I have plenty of faster machine…

Post by xscott » Tue, Nov 25, 2025, 5:31 PM UTC

J_Shelby_J wrote: post #249

iknowstuff wrote: post #224

Earlier quoted context omitted.

Most likely let e = Vec::new() or let f = vec![] rustc will figure out the type

exactly. you specify types for function parameters and structs and let the language do it's thing. it's a bit of a niche to specify a type within a function... There is a reason the multiple methods detailed above exist. Mostly for random iterator syntax. Such as summing an array or calling collect on an iterator. Most Rust devs probably don't use all of these syntax in a single year or maybe even their careers.

    let i = 1;
    let j = 1;
    print!("i: {:?}\n", !i);
    print!("j: {:?}\n", !j);

    let v = vec![1, 2, 3];
    v[i];