Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewrite Everything in Rust

robert.ocallahan.org

Post reply on HN
Print view View original

161–170 of 242 posts

Re: Rewrite Everything in Rust

#161

Post by Manishearth »

unscaled wrote: post #90
dikaiosune wrote: post #72

Earlier quoted context omitted.

But the core guidelines are optional -- which means that you'll still have the entirety of C/C++ footgun hell to watch out for, and decades of outdated teaching and learning materials. And very large codebases which could not be easily ported to a compiler that enforced those guideines. I will be happy if Rust's main impact on history will have been to showcase how to get those safety features into a practical langua…

Looking at the presentation it looks like you can borrow a non-const reference (in rust parlance) several times, so there's no concurrency guarantee. You would have to break compatibility with too much existing code to get the same level of strictness as Rust, so that's reasonable, but yeah, it's hard to imagine that C++ will be as safe as Rust. I'm glad these features are being pushed through though.

> there's no concurrency guarantee.

Doesn't even have to do with concurrency. This leads to iterator invalidation and many other problems in single threaded code. In fact, Rust's "standard" concurrency guarantee (with regular, non-scoped threads) doesn't deal with the mutable aliasing rule; it works with the ownership rule more or less exclusively. Even if mutable aliasing was allowed in Rust, you could still build the same safe threading system assuming that borrows are still scoped[1].

The mutable-alias guarantee is more of a "don't let the rug be pulled out from under me". While this is something that's more obviously a problem in threaded situations where a mutation from a different thread can pull the rug out from under you, a function call in complex code that mutably aliases can cause the same issue. The classic example of this is iterator invalidation; but it works with any type which contains a variable amount/type of things, and severe logical (non-memory-safety) issues can be caused with anything with invariants.

See: http://manishearth.github.io/blog/2015/05/17/the-problem-wit...

[1]: When I say "safe", I'm assuming that in this situation (the lack of rules against) mutable aliasing itself isn't causing any unsafety elsewhere that transitively leaks down and causes thread safety to go kablooey. As such it's a necessary and mostly sufficient system of rules; removing one rule will probably make the whole house tumble. However, the point was that Rust's thread safety doesn't directly derive from the mutable aliasing rule.

Re: Rewrite Everything in Rust

#162

Post by progman »

Don't waste your time rewriting almost unmaintainable legacy stuff. Perl actually died because the Perl 6 developers made the mistake to retain compatibility with Perl 5 which was not possible due to its unmaintainability. At first it looked promising but later on it turned out to be impossible. Rust could fall into the same trap by retaining dependency on C/C++.

I would use Rust for a complete startover. Open source development should shift its mentality to support open hardware. This could ensure safety of both hardware and software in the future, and it would attract many developers who want to contribute.

We already have the tools for open hardware: free IP cores, 3D printers, free CAD, equipment for DIY PCB/SMD boards, etc. ... and Rust for bare bone programming.

Re: Rewrite Everything in Rust

#163

Post by Manishearth »

CyberDildonics wrote: post #31
na85 wrote: post #19

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

rust relies heavily on libc as far as I know

No, not heavily. libstd depends on it some (we allow both glibc and musl libcs).

libcore (the baremetal library) and the language don't need libc at all.

Re: Rewrite Everything in Rust

#164

Post by Manishearth »

wspeirs wrote: post #34
pcwalton wrote: post #10

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…

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

Easy. But it won't be too useful.

Rust isn't a compiler that magically finds memory errors. Transpiling C code to Rust will not find those memory errors unless you have a really good transpiler that can detect the overall structure and design of the C code. It will just give you a ton of Rust error messages; probably none of which relate to an actual memory error. (Or you transpile to `unsafe` rust, in which case, what was the point?).

Rust works with a set of rules, and these rules enforce some things in your programming/software design style. This enforced style (i.e. the discipline around memory usage) is what gets us memory safety. This style is not the same as the style used in programming C/C++; so a dumb transpilation won't work. You need to write a transpiler that can figure out what logic the code (and not just for a function, for a larger unit) was trying to encode, and write that in Rust. That's ... a nontrivial problem to solve with a transpiler, probably requiring AI skills. It's a mostly trivial thing to do as a human, since mostly such "transpilation" involves noticing a few key issues (related to highly-shared structs and whatnot) and fixing them (leaving most of the code the same).

Re: Rewrite Everything in Rust

#165

Post by ktRolster »

vvanders wrote: post #51
ktRolster wrote: post #22

Earlier quoted context omitted.

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.

  > Part of what makes Rust awesome is it forces correct...architecture.
If you believe that, and follow it, then you will end up with a lousy architecture. A correct architecture cannot be designed without knowledge of the problem domain.

That's the problem with security too: if you believe the language will keep you safe, and stop thinking about security, your software will be less secure than before. There's plenty of insecure Java code out there.

Re: Rewrite Everything in Rust

#166

Post by pjmlp »

roca wrote: post #158
pjmlp wrote: post #155

Earlier quoted context omitted.

Have you seen the CppCon presentation? About 1% of the audience answered affirmatively to Herb's question about who was using some kind of static analysis tools. Outside HN and Reddit circles, very few C and C++ developers, at least the typical enterprise ones, don't really care about such tools. Back on my C++ days, just one company cared to pay for Insure++ and I was probably the only one using it. This is way I am…

Extra-lingual static analysis tools are OK at finding bugs. They're not good at proving the absence of whole classes of bugs; that is what we should be striving for, and what Rust and other languages can provide. So what I'm looking for from Herb Sutter is not just a set of good guidelines and tools to check for them, but also a proof --- or at least an argument --- that if the tool finds no errors in a piece of code…

I agree, the biggest issue with extra tools is that they require additional effort to use them.

After all, lint was created to compensate for C's unsafety in 1979 and up until clang's introduction of static analysis, barely unused in the industry.

Still C++ isn't going anywhere and is the only native language with first class support in all mobile SDKs, so anything that helps improve its use is welcome.

Re: Rewrite Everything in Rust

#167

Post by kibwen »

gnu wrote: post #122

Rust is nice. But the article miss one important point. Modern software engineering is a collaborative effort (well, it has always been, afaik). I write code for others to understand. I find Rust code significantly hard to read (I am saying this as an experienced C/C++ programmer and as an intermediate haskeller). Yes, one can write write-only code in any language. I think it is extremely important to write code that…

  > I also wish that Rust authors stop adding more and more 
  > features.
I'm not sure what this is referring to. Rust hasn't added any features since the stable 1.0 release last May, and I also don't believe it added any features in the six-month beta period prior to that. And it's not an especially feature-heavy language in the first place, likely comparable in size to Python (e.g. a medium-sized language).

Re: Rewrite Everything in Rust

#168

Post by fiveop »

na85 wrote: post #19

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

There is the library 'libc' which is a collection of interfaces to (g)libc functions together with the necessary constants and structs [1].

There is the library 'nix-rust' [2], which aims to provide a wrapper of 'libc' in idomatic Rust.

Unlike 'libc', 'nix-rust' does not have a consistent code quality and organization yet. However, Both are missing various bindings for various platforms.

[1] https://github.com/rust-lang/libc [2] https://github.com/nix-rust/nix

Re: Rewrite Everything in Rust

#169

Post by kibwen »

daurnimator wrote: post #141
brandonbloom wrote: post #132

Earlier quoted context omitted.

From second link: > Obviously on OOM you usually want to abort _something_. It's just not always the entire thread or process. Surely you want to abort _some dynamic extent_. The fact that it's (currently) a full C thread is an implementation detail that can hopefully be improved. Requiring manual OOM handling on every single operation is not a scalable solution and will lead to bugs due to laziness or fatigue. Excep…

Rust's OOM handler calls abort(). This kills the process, and cannot be caught. i.e. to run rust code that uses the standard library without the chance of abort() on low memory, you need to run it in it's own process.

  > you need to run it in it's own process
Assuming that you can detect OOM in userspace at all, which usually isn't the case on Linux (or any other system with overcommit).

Re: Rewrite Everything in Rust

#170

Post by Manishearth »

ktRolster wrote: post #165
vvanders wrote: post #51

Earlier quoted context omitted.

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

> Part of what makes Rust awesome is it forces correct...architecture. If you believe that, and follow it, then you will end up with a lousy architecture. A correct architecture cannot be designed without knowledge of the problem domain. That's the problem with security too: if you believe the language will keep you safe, and stop thinking about security, your software will be less secure than before. There's plenty…

I think the parent is talking about architecture around memory, not the entire program design.

> if you believe the language will keep you safe

safer != safe.

Post reply on HN