Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

APT Rust requirement raises questions

lwn.net

Post reply on HN
Print view View original

311–320 of 508 posts

Re: APT Rust requirement raises questions

#311

Post by chillingeffect »

influx wrote: post #282
vablings wrote: post #274

Earlier quoted context omitted.

>I know intellectually, that there are sane/pragmatic people who appreciate Rust. For the most part that is almost everyone who works on rust and writes rust. The whole coreutils saga was pretty much entirely caused by Canonical, The coreutils rewrite project was originally a hobby project iirc and NOT ready for prod. for the most part the coreutils rewrite is going well all things considered, bugs are fixed quickly…

It really makes me upset that we are throwing away decades of battle tested code just because some people are excited about the language du jour. Between the systemd folks and the rust folks, it may be time for me to move to *BSD instead of Linux. Unfortunately, I'm very tied to Docker.

Even worse, the license requirements (gpl->mit) will be less beneficial to the community than the rust replacements.

Re: APT Rust requirement raises questions

#312

Post by Aurornis »

mixmastamyk wrote: post #299
Aurornis wrote: post #56

Earlier quoted context omitted.

> Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & frustrations - overall the language has a "pseudocode which compiles" approach, which I appreciate. I think this is why you don’t like Rust: In Rust you have to be explicit by design. Being explicit adds syntax. If you appreciate languages where you can write pseudocode and have the details handled automatically for you,…

> Being explicit adds syntax. Not what they are talking about. Rather better to use words instead of symbols, like python over perl. Instead of “turbofish” and , there could be more key words like mut or dyn. Semicolons and ‘c’har are straight out of the seventies as well. :: not useful and ugly, etc. Dunders avoid namespace collisions and are not a big problem in practice, all one char, and easy to read. I might rem…

This is just personal preferences and familiarity

Python using indenting to convey specific programming meaning feels janky and outdated to people not familiar with Python, but Python familiar programmers don't think twice about it.

Re: APT Rust requirement raises questions

#313

Post by adastra22 »

morshu9001 wrote: post #109
Aurornis wrote: post #56

Earlier quoted context omitted.

> Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & frustrations - overall the language has a "pseudocode which compiles" approach, which I appreciate. I think this is why you don’t like Rust: In Rust you have to be explicit by design. Being explicit adds syntax. If you appreciate languages where you can write pseudocode and have the details handled automatically for you,…

Both Python and JS evolved by building on top of older versions, but somehow JS did a way better job than Python, even though Py forced a major breaking change. Agree about Rust, all the syntax is necessary for what it's trying to do.

JS is not something I would hold up in high regard.

Re: APT Rust requirement raises questions

#314

Post by epolanski »

anarki8 wrote: post #133
epolanski wrote: post #11

Earlier quoted context omitted.

The problem is that rust is being shoved in pointless places with a rewrite-everything-in-rust mentality. There's lunatics that want to replace basic Unix tools like sudo, etc, that are battle tested since ages which has been a mess of bugs till now. Instead Rust should find it's niches beyond rewriting what works, but tackling what doesn't.

> The problem is that rust is being shoved in pointless places with a rewrite-everything-in-rust mentality. > There's lunatics ... I think the problem is people calling developers "lunatics" and telling them which languages they must use and which software they must not rewrite. Battle tested is not bulletproof: https://cybersecuritynews.com/sudo-linux-vulnerability/ Applying strict compile time rules makes software…

My point had nothing to do with languages.

My point is against rewrites of critical software for the point of rewriting it *insert my favorite language*. Zig is also a safer language than C, so are many other alternatives, yet the Zig community is not obsessed in rewriting old software but writing new one. And the Zig compiler has excellent C interop (in fact it can compile C/C++), yet the community is more focused in writing new software.

There are many factors that make software reliable, it's not just a matter of pretty types and memory safety, there's factors like platform/language stability, skill and expertise of the authors, development speed and feedback.

Re: APT Rust requirement raises questions

#315

Post by kstrauser »

vablings wrote: post #274
travisgriggs wrote: post #243

Earlier quoted context omitted.

> I love and use rust, it is my favorite language and I use it in several of my OSS projects but I'm tired of this "rewrite it in rust" evangilism and the reputational damage they do to the rust community. Thanks for this. I know intellectually, that there are sane/pragmatic people who appreciate Rust. But often the vibe I’ve gotten is the evangelism, the clear “I’ve found a tribe to be part of and it makes me feel s…

>I know intellectually, that there are sane/pragmatic people who appreciate Rust. For the most part that is almost everyone who works on rust and writes rust. The whole coreutils saga was pretty much entirely caused by Canonical, The coreutils rewrite project was originally a hobby project iirc and NOT ready for prod. for the most part the coreutils rewrite is going well all things considered, bugs are fixed quickly…

I agree with everything you've said here, except that the reality of speaking with a "rust first" developer is making me feel suddenly ancient. But that aside, the memory safety parts are a huge benefit, but far from the only one. Option and Result types are delightful. Exhaustive matching expressions that won't compile if you add a new variant that's not handled are huge. Types that make it impossible to accidentally pass a PngImage into a function expecting a str, even though they might both be defined as contiguous series of bytes down deep, makes lots of bugs impossible. A compiler that gives you freaking amazing error messages that tell you exactly what you did wrong and how you can fix it sets the standard, from my experience. And things like "cargo clippy" which tell you how you could improve your code, even if it's already working, to make it more efficient or more idiomatic, are icing on the cake.

People so often get hung up on Rust's memory safety features, and dismiss is as through that's all it brings to the table. Far from it! Even if Rust were unsafe by default, I'd still rather use it that, say, C or C++ to develop large, robust apps because it has a long list of features that make it easy to write correct code, and really freaking challenging to write blatantly incorrect code.

Frankly, I envy you, except that I don't envy what it's going to be like when you have to hack on a non-Rust code base that lacks a lot of these features. "What do you mean, int overflow. Those are both constants! How come it didn't let me know I couldn't add them together?"

Re: APT Rust requirement raises questions

#316

Post by jancsika »

Aurornis wrote: post #171
geerlingguy wrote: post #5

I remembered reading about this news back when that first message was posted on the mailing list, and didn't think much of it then (rust has been worming its way into a lot of places over the past few years, just one more thing I tack on for some automation)... But seeing the maintainer works for Canonical, it seems like the tail (Ubuntu) keeps trying to wag the dog (Debian ecosystem) without much regard for the wide…

> I think the whole message would be more palatable if it weren't written as a decree including the dig on "retro computers", but instead positioned only on the merits of the change. The wording could have been better, but I don’t see it as a dig. When you look at the platforms that would be left behind they’re really, really old. It’s unfortunate that it would be the end of the road for them, but holding up progress…

> The wording could have been better, but I don’t see it as a dig.

He created (or at least re-activated) a dichotomy for zero gain, and he vastly increased the expectations for what a Rust rewrite can achieve. That is very, very bad in a software project.

The evidence for both is in your next paragraph. You immediately riff on his dichotomy:

> It’s unfortunate that it would be the end of the road for them, but holding up progress for everyone to retain support for some very old platforms would be the definition of the tail wagging the dog.

(My emphasis.)

He wants to do a rewrite in Rust to replace old, craggy C++ that is so difficult to reason about that there's no chance of attracting new developers to the maintenance team with it. Porting to Rust therefore a) addresses memory safety, b) gives a chance to attract new developers to a core part of Debian, and c) gives the current maintainer a way to eventually leave gracefully in the future. I think he even made some these points here on HN. Anyone who isn't a sociopath sympathizes with these points. More importantly, accidentally introducing some big, ugly bug in Rust apt isn't at odds with these goals. It's almost an expected part of the growing pains of a rewrite plus onboarding new devs.

Compare that to "holding up progress for everyone." Just reading that phrase makes me force sensitive like a Jedi: I can feel the spite of dozens HN'ers tingling at that and other phrases in these HN comments as they sharpen their hatred, ready to pounce at the Rust Evangelists the moment this project hits a snag. (And, like any project, it will hit snags.)

1. "I'm holding on for dear life here, I need help from others and this is the way I plan to get that help"

2. "Don't hold back everyone else's progress, please"

The kind of people who hear "key party" and imagine clothed adults reciting GPG fingerprints need to comprehend that #1 and #2 are a) completely different strings and b) have very different-- let's just say magical-- effects on the behavior of even small groups of humans.

Re: APT Rust requirement raises questions

#317

Post by mixmastamyk »

Aurornis wrote: post #312
mixmastamyk wrote: post #299

Earlier quoted context omitted.

> Being explicit adds syntax. Not what they are talking about. Rather better to use words instead of symbols, like python over perl. Instead of “turbofish” and , there could be more key words like mut or dyn. Semicolons and ‘c’har are straight out of the seventies as well. :: not useful and ugly, etc. Dunders avoid namespace collisions and are not a big problem in practice, all one char, and easy to read. I might rem…

This is just personal preferences and familiarity Python using indenting to convey specific programming meaning feels janky and outdated to people not familiar with Python, but Python familiar programmers don't think twice about it.

No, it’s not only familiarity. I learned C/C++ in the early 90s, before Python.

It’s well studied that words are easier to read than nested symbols.

Re: APT Rust requirement raises questions

#318

Post by xscott »

gpm wrote: post #250
xscott wrote: post #165

Earlier quoted context omitted.

I'm not sure which of the dozen Rust-syntax supporters I should reply to, but consider something like these three (probably equivalent) syntaxes: let mut a = Vec:: ::new(); let mut b = >::new(); let mut c = >::new(); let mut d: Vec = Vec::new(); Which one will your coworker choose? What will your other corworkers choose? This is day one stuff for declaring a dynamic array. What you really want is something like: let…

This is like complaining that in C you can write a->b (a->b) (*a).b ((*a).b) Being able to use disambiguated syntaxes, and being able to add extra brackets, isn't an issue. PS. The formatting tooling normalizes your second and third example to the same syntax. Personally I think it ought to normalize both of them to the first syntax as well, but it's not particularly surprising that it doesn't because they aren't thi…

> This is like complaining that in C [...]

It's really not. Only one of my examples has the equivalent of superfluous parens, and none are dereferencing anything. And I'm not defending C or C++ anyways.

When I was trying to learn Rust (the second time), I wanted to know how to make my own types. As such, the macro `vec!` mentioned elsewhere isn't really relevant. I was using `Vec` to figure things out so I could make a `FingerTree`:

    let v: Vec = Vec::new();  // Awfully Java-like in repeating myself

    let v = Vec::new(); // Crap, I want to specify the type of Vec

    let v = Vec::new();  // Crap, that doesn't compile.
And so on...

Re: APT Rust requirement raises questions

#319

Post by adastra22 »

fainpul wrote: post #173
ModernMech wrote: post #119

Earlier quoted context omitted.

But Swift is not "Kotlin for Rust" though, I can't see the connection at all. "Kotlin for Rust" would be a language that keeps you in the Rust ecosystem.

The commenter I replied to seems to like Kotlin. Swift is extremely close to Kotlin in syntax and features, but is not for the JVM. Swift also has a lot of similarities with Rust, if you ignore the fact that it has a garbage collector.

A Kotlin for Rust would be a drop-in replacement where you could have a crate or even just a module written in this hypothetical language and it just works. No bridging or FFI. That’s not Swift.

Re: APT Rust requirement raises questions

#320

Post by astrobe_ »

geerlingguy wrote: post #5

I remembered reading about this news back when that first message was posted on the mailing list, and didn't think much of it then (rust has been worming its way into a lot of places over the past few years, just one more thing I tack on for some automation)... But seeing the maintainer works for Canonical, it seems like the tail (Ubuntu) keeps trying to wag the dog (Debian ecosystem) without much regard for the wide…

> I think the whole message would be more palatable if it weren't written as a decree including the dig on "retro computers"

Yes, and more generally, as far as I am concerned, the antagonizing tone of the message, which is probably partly responsible for this micro-drama, is typical of some Rust zealots who never miss an occasion to remind C/C++ that they are dinosaurs (in their eyes). When you promote your thing by belittling others, you are doing it wrong.

Post reply on HN