Hacker News Reader

Comment by petcat | Hacker News Reader

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.

View on HN

>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

Also there is a rustc codegen backend that uses GCC, so you can just skip the C part:

https://github.com/rust-lang/rustc_codegen_gcc

That's not what the comment said. It said, "How about a Rust to C converter?..." The idea was that using a converter could eliminate the problem of not having a rust compiler for certain platforms.

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.

We need lisp, cobol, and java in apt, too. and firefox.

Is the apt package manager a pointless place? It seems like a pretty foundational piece of supply chain software with a large surface area.

The author of the rust software did not solve the platform problem, as a result it is not a solution. Since it is not a solution, it should be reverted. It's really that simple.

I seem to remember going through this with systemD in Ubuntu. Lots of lessons learned seemed to come back as "didn't we fix this bug 3 years ago?"

Converting parsers to Rust is not "pointless". Doing string manipulation in C is both an awful experience and also extremely fertile ground for serious issues.

apt is C++

Issues that are battle tested from ages.

Sure, which is highly valuable information that hopefully made its way into a testing / verification suite. Which can then be used to rewrite the tool into a memory-safe language, which allows a lot of fixes and edge cases that were added over time to deal with said issues to be refactored out.

Of course there's a risk that new issues are introduced, but again, that depends a lot on the verification suite for the existing tool.

Also, just because someone did a port, doesn't mean it has to be adopted or that it should replace the original. That's open source / the UNIX mentality.

It’s very easy to write a string library in C which makes string operations high level (both in API and memory management). Sure, you shouldn’t HAVE to do this. I get it. But anyone writing a parser is definitely skilled enough to maintain a couple hundred lines of code for a linear allocator and a pointer plus length string. And to be frank, doing things like “string operations but cheaply allocated” is something you have to do ANYWAY if you’re writing e.g. a parser.

This holds for many things in C

> a pointer plus length

What would length represent? Bytes? Code points?

Anyway, I think what you are asking for already exists in the excellent ICU library.

And it's not a very easy thing to maintain. Unicode stuff changes more often than you might think and it can be political.

This is just a variation of the "skill issue" argument.

If it were correct, we wouldn't see these issues continue to pop up. But we do.

I think it is more a matter of convenience. There are countless string implementations for C, some tiny projects, others part of larger frameworks like Glib. At the end of the day a C developer has to decide if they are going to pull in half of gnome to handle a few lines of IO or if they are just going to use the functions the C standard conveniently ships with. Most people are going to do the later.

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.

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.

Calling it pointless comes across as jaded. It's not pointless.

Supporting Rust attracts contributors, and those contributors are much less likely to introduce vulnerabilities in Rust when contributing vs alternatives.

to introduce certain common vulnerabilities ...

not vulnerabilities in general.

And seatbelts and airbags do not prevent all harm, yet they are still universally used.

It's a pedantic point admittedly, but I think it's important to be realistic and clear that Rust isn't a panacea.

Cue for all those battle tested programs that people keep finding vulnerabilities several decades after they got considered "done". You should try looking at the test results once in a while.

And by the way, we had to replace almost all of the basic Unix tools at the turn of the century because they were completely unfit for purpose. There aren't many left.

> 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 better. And with time it will also become battle tested.

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.

> My point is against rewrites of critical software for the point of rewriting it insert my favorite language.

In this specific case we are talking about the maintainer adding a new language into the existing codebase.

I think refactoring parts of the software in the new language is what you call "rewrite" here, correct?

So what improvements does it bring? You actually answered it yourself:

> it's not just a matter of pretty types and memory safety

So indeed, stricter/stronger type system and additional automatic compile time and runtime checks are a major improvement.

> platform

As already mentioned in this thread: neither of the platforms lacking Rust were supported officially anyways.

> language stability

Rust is extremely stable and backwards compatible - 1.0 code still compiles without any issues on 1.90 and will continue to do so for the forseeable future.

> skill and expertise of the authors

The same developers continuing to contribute and newcoming developers have more checks in place to prevent bugs.

> development speed

I guess you imply here that developing in C++ is faster. It's in fact not if your aim is to produce correct software. There are so many more things to keep in mind and take care of with C++, you have fewer automatic checks being done by the compiler and the type system.

About Zig: it's a nice language and much more comfortable to use than C/C++ IMO, but compared to Rust it lacks in strictness and safety, so added benefits are smaller and fewer if you put away subjective preferences.

> My point is against rewrites of critical software for the point of rewriting it

Because you're replacing a real point with a made up one, the reason for rewriting is to get the critical benefits for critical software, which battle testing has shown can't be had in the current language, not "my favorite"

> Zig community is not obsessed

They don't even have a 1.0 language? You're also ignoring the critical difference in the level of safety

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?

For one, signed integer overflow is allowed and well-defined in Rust (the result simply wraps around in release builds), while it's Undefined Behavior in C. This means that the LLVM IR emitted by the Rust compiler for signed integer arithmetic can't be directly translated into the analogous C code, because that would change the semantics of the program. There are ways around this and other issues, but they aren't necessarily simple, efficient, and portable all at once.

You guys seem to be assuming transpiling to C means it must produce C that DTRT on any random C compiler invoked any which way on the other side, where UB is some huge possibility space.

There's nothing preventing it from being some specific invocation of a narrow set of compilers like gcc-only of some specific version range with a set of flags configuring the UB to match what's required. UB doesn't mean non-deterministic, it's simply undefined by the standard and generally defined by the implementation (and often something you can influence w/cli flags).

> You guys seem to be assuming transpiling to C means it must produce C that DTRT on any random C compiler invoked any which way on the other side, where UB is some huge possibility space.

Yes, that's exactly what "translating to C" means – as opposed to "translating to the very specific C-dialect spoken by gcc 10.9.3 with patches X, Y, and Z, running on an AMD Zen 4 under Debian 12.1 with glibc 2.38, invoked with flags -O0 -g1 -no-X -with-Y -foo -blah -blub...", and may the gods have mercy if you change any of this!

Do you see the problem?

Source-to-source translation will be very hard to get right, because lots of things are UB in C that aren’t in Rust, and obviously vice versa.

Rust has unwinding (panics), C doesn’t.

One can do a direct translation from Rust AST/IR to C. Many functional languages do that, C++ started as a compiler to C.

The gigantic difference is that assembly language has extremely simple semantics, while C has very complex semantics. Similarly, assembler output is quite predictable, while C compilers are anything but. So the level of match between the Rust code and the machine code you'll get from a Rust-to-assembly compiler will be much, much easier to understand than the match you'll get between the Rust code and the machine code produced by a C compiler compiling C code output by a Rust-to-C transpiler.

Reply on news.ycombinator.com