Live data from Hacker News

Rewrite Everything in Rust

robert.ocallahan.org

51–60 of 242 posts

Re: Rewrite Everything in Rust

#51

Earlier quoted context omitted.

> A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that nobody has time to fix. The entire point is that you're not in the same situation regarding memory safety problems/vulnerabilities.

Memory safety problems are the low-hanging fruit of vulnerabilities. A re-write by unskilled programmers will not guarantee the code is safe, because they will introduce many other kinds of vulnerabilities.

Part of what makes Rust awesome is it forces correct ownership and architecture.

Re: Rewrite Everything in Rust

#52
post #34

Earlier quoted context omitted.

Isn't that just what a compiler is, where the target language is machine code?

I realize something like glibc would be the LAST set of source code to run through a transpiler, but how hard do folks think it would be to make a C -> Rust transpiler? I'd think you'd go about it by making Rust a target backend for LLVM. This way you let LLVM deal with the all C stuff (macros, etc), and just focus on the internal representation to Rust conversion. In theory, you'd get C++ to Rust as well. Chances is…

> how hard do folks think it would be to make a C -> Rust transpiler?

Why do you want to do that? The only way to make it work short of doing years and years of static analysis research to automatically translate ad-hoc memory management disciplines into those of Rust (that I think will not succeed anyway) would be to compile to unsafe code. And if you compiled to unsafe Rust code, there would be no gain.

Re: Rewrite Everything in Rust

#53
post #19

Is there a "glibrust" or equivalent standard library for Rust, yet?

Rust of course has a standard library[0] and it includes a libc, but (I might be wrong here) I think the libc portion is FFI into glibc or similar. I think the stuff written in rust is considerably more high-level, focusing more on data structures, concurrency, string manipulation, etc. [0]: https://doc.rust-lang.org/std/

We use glibc by default but provide MUSL builds for some platforms as well.

Re: Rewrite Everything in Rust

#54

Earlier quoted context omitted.

> A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that nobody has time to fix. The entire point is that you're not in the same situation regarding memory safety problems/vulnerabilities.

I think what GP is saying that you'll have problems in logic or other typical programming problems and that it isn't a lack of language features/safety but rather time/money being thrown at these libraries I imagine the top two reasons unsafe memory access happen is: 1) other complicated logic seeped into the memory sensitive area or causes programmer fatigue 2) memory management is hard Rust helps with #2 but let's…

OP article was specifically talking about Rustbelt as one tool you would be able to use in the future to mitigate the risks posed by the unsafe code you do have.

But in general, I think that entire idea is that as more code moves to memory-safe languages, the less need we have for unsafe sections.

Ideally, once the kernel itself can be written in a memory safe language, everything running on top of that wouldn't need much unsafe blocks. To be honest, this goal is probably decades away, but we should definitely be considering memory-safe languages for systems programming.

Re: Rewrite Everything in Rust

#55
post #19

Is there a "glibrust" or equivalent standard library for Rust, yet?

rust relies heavily on libc as far as I know

Some of the standard library does, but the core language does not. (libcore does not, and we've resisted putting libc specific things in core)

Re: Rewrite Everything in Rust

#56

Earlier quoted context omitted.

> A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that nobody has time to fix. The entire point is that you're not in the same situation regarding memory safety problems/vulnerabilities.

I think what GP is saying that you'll have problems in logic or other typical programming problems and that it isn't a lack of language features/safety but rather time/money being thrown at these libraries I imagine the top two reasons unsafe memory access happen is: 1) other complicated logic seeped into the memory sensitive area or causes programmer fatigue 2) memory management is hard Rust helps with #2 but let's…

> what percentage of a library like glibc would be spent in unsafe blocks?

Probably less than you think. What I think the limit is is that there are functions in glibc that present inherently unsafe interfaces. I'm not sure how many but it might be enough that writing libc in Rust is not that helpful.

Re: Rewrite Everything in Rust

#57

Earlier quoted context omitted.

I think what GP is saying that you'll have problems in logic or other typical programming problems and that it isn't a lack of language features/safety but rather time/money being thrown at these libraries I imagine the top two reasons unsafe memory access happen is: 1) other complicated logic seeped into the memory sensitive area or causes programmer fatigue 2) memory management is hard Rust helps with #2 but let's…

OP article was specifically talking about Rustbelt as one tool you would be able to use in the future to mitigate the risks posed by the unsafe code you do have. But in general, I think that entire idea is that as more code moves to memory-safe languages, the less need we have for unsafe sections. Ideally, once the kernel itself can be written in a memory safe language, everything running on top of that wouldn't need…

It's not decades away! Check out https://sel4.systems.

Re: Rewrite Everything in Rust

#58
post #34

Earlier quoted context omitted.

Isn't that just what a compiler is, where the target language is machine code?

I realize something like glibc would be the LAST set of source code to run through a transpiler, but how hard do folks think it would be to make a C -> Rust transpiler? I'd think you'd go about it by making Rust a target backend for LLVM. This way you let LLVM deal with the all C stuff (macros, etc), and just focus on the internal representation to Rust conversion. In theory, you'd get C++ to Rust as well. Chances is…

Generally the opinion is "it might work but it would be terrible Rust," and given that FFI into C has no overhead, replacing things a symbol at a time might be a better approach to this kind of problem.

Re: Rewrite Everything in Rust

#59

Earlier quoted context omitted.

Have you even looked at the source code to glibc? It's stuffed full of macros and #ifdef hell. Not to mention symbol versioning, the use of gcc-specific compiler extensions, and ancient-UNIX-beard performance hacks. You'd have more success teaching a chimpanzee to play the violin, than automatically translating glibc into anything.

I've seen a lot of weird preprocessor (ab)use in GNU code. The coreutils true/false (of all programs to invoke clever preprocessor tricks...) has this gem: in true.c (all told, an 80-line file): /* Act like "true" by default; false.c overrides this. */ #ifndef EXIT_STATUS # define EXIT_STATUS EXIT_SUCCESS #endif false.c, of course, contains only: #define EXIT_STATUS EXIT_FAILURE #include "true.c" On my current system…

If I write something and make it simple, how will people know what a jenius I am?

Re: Rewrite Everything in Rust

#60
post #41

Earlier quoted context omitted.

> A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that nobody has time to fix. The entire point is that you're not in the same situation regarding memory safety problems/vulnerabilities.

Yeah, I'm not saying that a rewrite is necessarily a bad idea or that it wouldn't improve things (though writing a drop-in replacement for something like glibc in Rust sounds pretty challenging to me). The situation I'm talking about is the one where no one has an incentive to improve the software day-to-day. If we really want to fix the problem, we should also look at how it got that way.

I think most well-funded commercial C software from that vintage isn't any better.
Post reply on HN