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

351–360 of 508 posts

Re: APT Rust requirement raises questions

#351

Post by kstrauser »

aallaall wrote: post #181
steveklabnik wrote: post #41

Earlier quoted context omitted.

Syntax tends to be deeply personal. I would say the most straightforward answer to your question is "many people disagree that it is unreadable." Rust did build on the learnings of the past 20 years. Essentially all of its syntax was taken from other languages, even lifetimes.

There’s syntax that is objectively easier to both read and write, and there’s syntax that is both harder to read and write. For a majority. In general, using english words consisting of a-z is easier to read. Using regex-like mojibake is harder. For an concrete example in rust, using pipes in lambdas, instead of an arrow, is aweful.

> In general, using english words consisting of a-z is easier to read.

I’ve seen COBOL in the wild. No thanks.

But also, imagine reading a math proof written in English words. That just doesn’t work well.

Re: APT Rust requirement raises questions

#352

Post by pmarin »

creatonez wrote: post #227

I have never seen a program segfault and crash more than apt. The status quo is extremely bad, and it desperately needs to be revamped in some way. Targeted rewrites in a memory safe & less mistake-prone language sounds like a great way to do that. If you think this is a random decision caused by hype, cargo culting, or a maintainer's/canonical's mindless whims... please, have a tour through the apt codebase some day…

20 years on Debian. Not a single crash with apt

Re: APT Rust requirement raises questions

#353

Post by [deleted] »

Aurornis wrote: post #56
dv35z wrote: post #31

Every time I consider learning Rust, I am thrown back by how... "janky" the syntax is. It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years. Can someone help me understand this? Why are we pushing forward with a language that has a Perl-esque unreadability...? Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & fr…

> 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,…

[deleted]

Re: APT Rust requirement raises questions

#354

Post by mixmastamyk »

yoyohello13 wrote: post #348
mixmastamyk wrote: post #317

Earlier quoted context omitted.

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.

Maybe it's my math background but I honestly prefer symbols to keywords. It's more up front cost in learning, but it's much more efficient in the long run.

When you are doing multiple operations to multiple variables, and need to see it all at once, math-like syntax still has benefits.

But this is not the common case for most programming, which is about detailing business rules. Explicit and verbose (though not excessively) has been shown to be the most readable/maintainable. For example, one character variable names, common in math, are heavily discouraged in professional development.

There’s another level to this as well. To me, calculus notation looks quite elegant, while Perl and (parts of) Rust look like trash. Since they are somewhat similar, the remaining angle is good taste.

Re: APT Rust requirement raises questions

#355

Post by inetknght »

surajrmal wrote: post #209
inetknght wrote: post #104

Earlier quoted context omitted.

> the "new solver" currently lacks a testsuite To borrow a phrase I recently coined: If it's not tested then it's not Engineered. You'd think that core tools would have proper Software Engineering behind them. Alas, it's surprising how many do not.

Integration tests are still tests. There are definitely cases for tools where you can largely get by without unit tests in favor of integration tests. I've written a lot of code generation tools this way for instance.

> Integration tests are still tests.

I didn't say they're not. Integration tests definitely help towards "being tested".

> There are definitely cases for tools where you can largely get by without unit tests in favor of integration tests.

Very strong disagree. I think there are no cases where a strong integration test regime can allow a software project to forego unit tests.

Now, that said, we're probably talking the same thing with different words. I think unit tests with mocks are practically useless. But mocks are the definition of most people's unit tests. Not to me; to me unit tests use real code and real objects. To me, a unit test is what a lot of people call an integration test. And, to me, what I call an integration test, is often what people call system tests or end-to-end tests.

Re: APT Rust requirement raises questions

#356

Post by gpm »

tyfon wrote: post #204

I have a dual pentium pro 200 that runs gentoo and openbsd, but rust doesn't ship i586 binaries, only i686+. So I would need to compile on a separate computer to use any software that is using rust. There is already an initrd package tool I can't use since it is rust based, but I don't use initrd on that machine so it is not a problem so far. The computer runs modern linux just fine, I just wish the rust team would a…

> "We don't care about retro computers" is not a good argument imho,

It absolutely is. If you want to do the work to support for you're welcome to do so, but you aren't entitled to have other people do so. There's some narrow exceptions like accessibility support, but retro computing ain't that.

Re: APT Rust requirement raises questions

#357

Post by saghm »

SoftTalker wrote: post #207
saghm wrote: post #47

Earlier quoted context omitted.

FWIW sudo has been maintained by an OpenBSD developer for a while now but got replaced in the base system by doas. Independent of any concerns about Rust versus C, I don't think it's quite as unreasonable as you're claiming to consider alternatives to sudo given that the OS that maintains it felt that it was flawed enough to be worth writing a replacement for from scratch.

sudo had grown a lot of features and a complicated config syntax over the years, which ended up being confusing and rarely needed in practice. doas is a lot simpler. It wasn't just a rewrite of a flawed utility but a simplification of it.

Regardless of the exact terminology used to describe why it was done, my point is that assuming that people are "lunatics" because they want to replace sudo is not a particularly compelling claim, and that's what the comment I was responding to had said.

Re: APT Rust requirement raises questions

#358

Post by JuniperMesos »

dimgl wrote: post #132
dv35z wrote: post #31

Every time I consider learning Rust, I am thrown back by how... "janky" the syntax is. It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years. Can someone help me understand this? Why are we pushing forward with a language that has a Perl-esque unreadability...? Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & fr…

> Every time I consider learning Rust, I am thrown back by how... "janky" the syntax is. It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years. I said this years ago and I was basically told "skill issue". It's unreadable. I shudder to think what it's like to maintain a Rust system at scale.

The syntax has relatively little to do with how easy or hard it is to maintain a rust system at scale. If you get something wrong the compiler will alert you, and most of the syntax is there for good reasons that anyone maintaining any kind of software system at scale needs to understand (and indeed the syntax helps you be clear about what you mean to the compiler, which facilitates helpful compiler error messages if you screw something up when modifying code).

Re: APT Rust requirement raises questions

#359

Post by eggy »

razighter777 wrote: post #172
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…

Agreed. I think that announcement was unprofessional. This was a unilateral decision affecting other's hard work, and the author didn't provide them the opportunity to provide feedback on the change. It disregards the importance of ports. Even if an architecture isn't widely used, supporting multiple architectures can help reveal bugs in the original implementation that wouldn't otherwise be obvious. This is breaking…

I totally agree. In reality, today, if you want to produce auditable high-integrity, high-assurance, mission-critical software, you should be looking at SPARK/Ada and even F* (fstar). SPARK has legacy real world apps and a great eco system for this type of sofware. F* is being used on embedded and in other realworld apps where formal verification is necessary or highly advantageous. Whether I like Rust or not, should not be the defining factor. AdaCore has a verifed Rust compiler, but the tooling around it does not compare to that around SPARK/Ada. I've heard younger people complain about PLs being verbose, boring, or not their thing, and unless you're a diehard SPARK/Ada person, you probably feel that way about it too. But sometimes the tool doesn't have to be sexy or the latest thing to be the right thing to use. Name one Rust realworld app older than 5 years that is in this category.

Re: APT Rust requirement raises questions

#360

Post by radlad »

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.

systemd has been the de facto standard for over a decade now and is very stable. I have found that even most people who complained about the initial transition are very welcoming of its benefits now.
Post reply on HN