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

31–40 of 508 posts

Re: APT Rust requirement raises questions

#31

Post by dv35z »

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 & frustrations - overall the language has a "pseudocode which compiles" approach, which I appreciate. Similarly, I appreciate what Kotlin has done with Java. Is there a "Kotlin for Rust"? or another high quality system language we ought to be investing in? I genuinely believe that languages ought to start with "newbie friendliness", and would love to hear challenges to that idea.

Re: APT Rust requirement raises questions

#33

Post by mrob »

The announcement says:

>In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages and a stronger approach to unit testing.

I can understand the importance of safe signature verification, but how is .deb parsing a problem? If you're installing a malicious package you've already lost. There's no need to exploit the parser when the user has already given you permission to modify arbitrary files.

Re: APT Rust requirement raises questions

#34

Post by andsoitis »

simonask wrote: post #22
sidewndr46 wrote: post #8

Earlier quoted context omitted.

All compilers do anyways is translate from one language specification to another. There's nothing magical about Rust or any specific architecture target. The compiler of a "memory safe" language like Rust could easily output assembly with severe issues in the presence of a compiler bug. There's no difference between compiling to assembly vs. C in that regard.

The assumption here is that there exists an unambiguous C representation for all LLVM IR bitcode emitted by the Rust compiler. To my knowledge, this isn’t the case.

> The assumption here is that there exists an unambiguous C representation for all LLVM IR bitcode emitted by the Rust compiler.

> To my knowledge, this isn’t the case.

Tell us more?

Re: APT Rust requirement raises questions

#36

Post by [deleted] »

mmastrac wrote: post #29
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.

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...

[deleted]

Re: APT Rust requirement raises questions

#37

Post by NetMageSCW »

jvanderbot wrote: post #6
bakugo wrote: post #2

[flagged]

I think you'll experience some pushback on the assertion that that particular quote has a lot of arrogance or disdain in it. Building large legacy projects can be difficult and tapping into a thriving ecosystem of packages might be a good thing. But it's also possible to have "shiny object" or "grass is greener" syndrome.

“If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port.”

If that’s not arrogant, I don’t know what is.

Re: APT Rust requirement raises questions

#38

Post by forgotpwd16 »

petcat wrote: post #3

Interesting how instead of embracing Rust as a required toolchain for APT, the conversation quickly devolved into "why don't we just build a tool that can translate memory-safe Rust code into memory-unsafe C code? Then we don't have to do anything." This feels like swimming upstream just for spite.

>tool that can translate memory-safe Rust code into memory-unsafe C code

Fwiw, there're two such ongoing efforts. One[1] being an, written in C++, alternative Rust compiler that emits C (aka, in project's words, high-level assembly), the other[2] being a Rust compiler backend/plugin (as an extra goal to its initial being to compile Rust to CLR asm). Last one apparently is[3] quite modular and could be adapted for other targets too. Other options are continuing/improve GCC front-end for Rust and a recent attempt to make a Rust compiler in C[4] that compiles to QBE IR which can then be compiled with QBE/cc.

[1]: https://github.com/thepowersgang/mrustc [2]: https://github.com/FractalFir/rustc_codegen_clr [3]: https://old.reddit.com/r/rust/comments/1bhajzp/ [4]: https://codeberg.org/notgull/dozer

Re: APT Rust requirement raises questions

#39

Post by tcfhgj »

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…

what makes it unreadable for you?
Post reply on HN