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

381–390 of 508 posts

Re: APT Rust requirement raises questions

#381

Post by estebank »

cactusfrog wrote: post #160
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…

Could the rust code be transpired to readable C?

> readable

No, because some things that are UB in C are not in Rust, and vice versa, so any codegen has to account for that and will result in additional verbosity that you wouldn't see in "native" code.

Re: APT Rust requirement raises questions

#382

Post by morshu9001 »

WD-42 wrote: post #116
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…

I’ve been writing python professionally for over 10 years. In the last year I’ve been writing more and most Rust. At first I thought the same as you. It’s a fugly language, there’s no denying it. But once I started to learn what all the weird syntax was for, it began to ruin Python for me. Now I begrudge any time I have to go back to python. It feels like its beauty is only skin deep, but the ugly details are right t…

JS ruined Python for me, cause it serves similar purposes but handles them better. Rust is a different thing, it ruined C and C++ for me.

Re: APT Rust requirement raises questions

#383

Post by metaltyphoon »

jamespo wrote: post #167
mmastrac wrote: post #29

Earlier quoted context omitted.

sudo is not fully battle tested, even today. You just don't really see the CVEs getting press. https://www.oligo.security/blog/new-sudo-vulnerabilities-cve...

Neither of those vulnerabilities look like rust would necessarily help however

Thats not the point OP was mentioning as in “battle tested” doesn’t mean free of bugs.

Re: APT Rust requirement raises questions

#384

Post by zanellato19 »

nofunsir wrote: post #244
zanellato19 wrote: post #229

Earlier quoted context omitted.

Nonsense. I know and talk to multiple Engineers all the time and they all envy our position of continuing to fix issues in the project. Mechanical engineers having to work around other component failures all the time because their lead time is gigantic and no matter how much planning they do, failures still pop-up. The idea that Software Engineering has more bugs is absurd. Electronic engineers, mechanical, electric,…

Not nonsense. Don't be reductive.

I think you are being reductive on your original comment. The idea of cycling planning and implementation is nothing new, and quite used on the other disciplines. Saying that agile is the problem is misguided and pointing to other engineering disciplines for "they do it better" is usually a sign that you don't talk to those engineers.

Of course we can plan things better, but implementation does inform planning and vice versa and denying that is denying reality.

Re: APT Rust requirement raises questions

#385

Post by estebank »

steveklabnik wrote: post #275
dragonwriter wrote: post #270

Earlier quoted context omitted.

Well, the solution usually isn't in syntax, but it often is solved by way of code formatters, which can normalize the syntax to a preferred form among several equivalent options.

I certainly would support rustfmt turning those redundant forms into the simpler one.

I suspect rustfmt would consider this out of scope, but there should be a more... "adventurous" code formatter that does more opinionated changes. On the other hand, you could write a clippy lint today and rely on rustfix instead

Re: APT Rust requirement raises questions

#386

Post by steveklabnik »

xscott wrote: post #366
steveklabnik wrote: post #303

Earlier quoted context omitted.

It hasn't been my job to work on Rust in for years now. And even then, it was not to "defend" Rust, but to write docs. I talk about it on my own time, and I have often advocated for change in Rust based on my conversations with users. If you're being overly literal, yes, the s are needed here for this exact syntax. My point was not about this specific example, it's that these forms are equivalent, but some of them ar…

> For this specific issue, if square brackets were used for generics, then something else would have to change for array indexing The compiler knows when the `A` in `A[B]` is a type vs a variable.

A compiler could disambiguate, but the goal is to have parsing happen without knowing if A is a type or a variable. That is the inappropriate intertwining of parsing and semantics that languages are interested in getting away from, not continuing with.

Anyway, just to be clear: not liking the turbofish is fine, it's a subjective preference. But it's not an objective win, that's all I'm saying. And it's only one small corner of Rust's syntax, so I don't think that removing it would really alleviate the sorts of broad objections that the original parent was talking about.

Re: APT Rust requirement raises questions

#387

Post by Surac »

my biggest problem with rust is. i can't read it. i never know what this symbol means. is it a keyword? a type, a variable, a constant or a macro? Sure loading it into a IDE with a language server may help understanding the code.

Re: APT Rust requirement raises questions

#388

Post by crote »

eggy wrote: post #359
razighter777 wrote: post #172

Earlier quoted context omitted.

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…

> Name one Rust realworld app older than 5 years that is in this category.

Your "older than 5 years" requirement isn't really fair, is it? Rust itself had its first stable release barely 10 years ago, and mainstream adoption has only started happening in the last 5 years. You'll have trouble finding any "real-world" Rust apps older than 5 years!

As to your actual question: The users of Ferrocene[0] would be a good start. It's Rust but certified for ISO 26262 (ASIL D), IEC 61508 (SIL 4) and IEC 62304 - clearly someone is interested in writing mission-critical software in Rust!

[0]: https://ferrocene.dev/

Re: APT Rust requirement raises questions

#389

Post by pjmlp »

crote wrote: post #373
pjmlp wrote: post #336

Earlier quoted context omitted.

I fully agree, and in what concerns command line utility applications I see no benefit of using Rust's borrow checker. At most if a rewrite would happen, it makes much more sense in a compiled language with automatic resource management.

Command line utilities often handle not-fully-trusted data, and are often called from something besides an interactive terminal. Take for example git: do you fully trust the content of every repository you clone? Sure, you'll of course compile and run it in a container, but how prepared are you for the possibility of the clone process itself resulting in arbitrary code execution? The same applies to the other side of…

None of that requires a borrow checker.

Any memory safe compiled managed language will do.

Re: APT Rust requirement raises questions

#390

Post by SAI_Peregrinus »

move-on-by wrote: post #301
SAI_Peregrinus wrote: post #201

Earlier quoted context omitted.

> It is possible the deb package is parsed to extract some metadata before being installed and before verifying signature. Yes, .deb violates the cryptographic doom principle[1] (if you have to perform any cryptographic operation before verifying the message authentication code (or signature) on a message you’ve received, it will somehow inevitably lead to doom). Their signed package formats (there are two) add extra…

Sorry in advance if this is a dumb question, but isn't Rust's 'Cargo' package manager one of the draws of Rust? While I follow along that Rust's memory safety is a big benefit, does not the package manager and the supply chain attacks that come along with it take away from the benefits? For reference, NPM has had no shortage of supply chain security incidents. How would adding Rust to such core dependencies not intro…

Cargo defaults to downloading from `crates.io` but can easily be configured to get its dependencies elsewhere. That could be an alternative registry run by a Linux distribution or other organization, or even just overriding paths to dependencies to where local copies are stored. I'd expect a distro like Debian to mandate the use of an internal crate registry which mirrors the crates they're choosing to include in the distro with the versions they're choosing. This adds supply chain attack opportunities in the same way that adding any software adds supply chain attack opportunities, the use of `cargo` instead of `curl` to download sources doesn't change anything here.
Post reply on HN