Rewrite Everything in Rust • Hacker News Board

Re: Rewrite Everything in Rust

#101

Post by roca » Tue, Feb 23, 2016, 4:49 AM UTC

hermanradtke wrote: post #98

daurnimator wrote: post #80

Rust has major unsafeness around low memory that make it unsuitable in this libc type role. See: https://www.reddit.com/r/rust/comments/2mthq2/how_would_a_ru... and https://lwn.net/Articles/644708/ Due to this issue that the rust authors seem unwilling to address, I fully recommend against rust for the precise roles it's intended to be good at.

Based on my reading, only the std library has the behavior unsuitable for a libc type role. I would think a libc replacement would use #[no std] and have the finer grained control.

Exactly.

Re: Rewrite Everything in Rust

#102

Post by kibwen » Tue, Feb 23, 2016, 4:54 AM UTC

_b wrote: post #67

C++ is getting compile time checks for type, bounds, and lifetime safety, which steals nearly all of Rust's safety thunder. See Herb Sutter's talk at CppCon: http://herbsutter.com/2015/09/27/my-talk-at-cppcon/ For most applications, moving to modern C++ is going to be a better option than rewriting in Rust.

I'll be thrilled when Herb finally releases his lifetime enforcement tool, but until then it's too soon to celebrate. The mystery surrounding the details of Herb's approach still raises unanswered questions regarding the soundness and practicality of such a tool.

It's also evident that Herb didn't bother trying to learn from Rust in the slightest back when devising this tool, see his own remarks on Reddit: https://www.reddit.com/r/cpp/comments/3m0d41/writing_good_c1...

Furthermore, the tool in question does nothing to improve C++'s capability for safe multithreaded programming, which IMO is Rust's actual (yet so often overlooked) ace in the hole.

Re: Rewrite Everything in Rust

#103

Post by bluejekyll » Tue, Feb 23, 2016, 4:54 AM UTC

rubiquity wrote: post #94

bluejekyll wrote: post #64

Earlier quoted context omitted.

> an avid Rust user puts their money where their mouth is There are lots of people doing this. Look at crates.io. I decided to write a new fully compliant DNS server and client, trust-dns. I work on it in my spare time (it's time not money), which is hard with two kids. I've learned a few things. It's hard to get it done. There's a lot to learn from the rfc's. Just because it's Rust, doesn't mean it's easy. There are…

Your entire post reinforces the idea that in my list of challenges to writing safe software that #1 is far more the issue than #2.

Yes. I'm agreeing that it's hard and takes a lot of energy. But people are doing it.

Re: Rewrite Everything in Rust

#104

Post by andrewprock » Tue, Feb 23, 2016, 4:55 AM UTC

tatterdemalion wrote: post #56

rubiquity wrote: post #18

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…

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

Once you admit unsafe blocks, you admit that Rust is unsafe. The value of porting from one unsafe language to another is probably only marginal.

Re: Rewrite Everything in Rust

#105

Post by iherbig » Tue, Feb 23, 2016, 4:56 AM UTC

shmerl wrote: post #99

_b wrote: post #67

C++ is getting compile time checks for type, bounds, and lifetime safety, which steals nearly all of Rust's safety thunder. See Herb Sutter's talk at CppCon: http://herbsutter.com/2015/09/27/my-talk-at-cppcon/ For most applications, moving to modern C++ is going to be a better option than rewriting in Rust.

C++ still can't prevent things like iterator invalidation which are impossible in Rust. While I like modern C++, Rust really addresses a lot of problems with the proper design from the ground up, which C++ can't do. What Rust so far lacks is better OOP mechanisms. C++ beats Rust in that. For instance Rust is still missing something like virtual structs. See https://github.com/rust-lang/rfcs/issues/349

Genuine question: What do virtual objects enable that cannot be done through the Trait system?

Re: Rewrite Everything in Rust

#106

Post by make3 » Tue, Feb 23, 2016, 5:00 AM UTC

ubernostrum wrote: post #84

_b wrote: post #67

C++ is getting compile time checks for type, bounds, and lifetime safety, which steals nearly all of Rust's safety thunder. See Herb Sutter's talk at CppCon: http://herbsutter.com/2015/09/27/my-talk-at-cppcon/ For most applications, moving to modern C++ is going to be a better option than rewriting in Rust.

For most applications, moving to modern C++ is going to be a better option than rewriting in Rust. I wouldn't bet on that. Companies which go with a language like C++ don't do it for "safety" or "performance" or reasons like that (at least, most of the time they don't). They go with it because they can get something written once, then run it for the next half-century and only have to spend engineering time on new fea…

I don't know that people don't choose C++ for performance reasons or for easy manipulation of low level stuff. Games, high performance computing, embedded and legacy software are the main applications of C++, aren't they?

Some people on this website seem to blow the python 2/3 transition fairly out of proporotions.. Python 3 is really extremely similar to Python 2, and there are great tools to convert Python 2 code to Python 3 and vice versa.

Re: Rewrite Everything in Rust

#107

Post by fabrice_d » Tue, Feb 23, 2016, 5:01 AM UTC

mahyarm wrote: post #7

How practical is rust for small processor IoT applications? Like the ESP8266 we saw recently? https://news.ycombinator.com/item?id=11148129 They often have horrible security, but are very small programs when you use them as wifi temperature sensors or similar. They are good targets for rewrites and greenfield applications. Right now it seems like ardunio C++ or some scripting language is the target.

unfortunately there's no LLVM backend for the xtensa cpu used by the ESP8266. There's a gcc backend though, so if someone has the time and skillset to port to LLVM, here's a way to become a hero ;)

Re: Rewrite Everything in Rust

#108

Post by shmerl » Tue, Feb 23, 2016, 5:01 AM UTC

iherbig wrote: post #105

shmerl wrote: post #99

Earlier quoted context omitted.

C++ still can't prevent things like iterator invalidation which are impossible in Rust. While I like modern C++, Rust really addresses a lot of problems with the proper design from the ground up, which C++ can't do. What Rust so far lacks is better OOP mechanisms. C++ beats Rust in that. For instance Rust is still missing something like virtual structs. See https://github.com/rust-lang/rfcs/issues/349

Genuine question: What do virtual objects enable that cannot be done through the Trait system?

Problems that Rust can't now address are listed in that RFC. Such as sharing of fields between definitions for instance. Traits don't address that.

Re: Rewrite Everything in Rust

#109

Post by Rusky » Tue, Feb 23, 2016, 5:02 AM UTC

iherbig wrote: post #105

shmerl wrote: post #99

Earlier quoted context omitted.

C++ still can't prevent things like iterator invalidation which are impossible in Rust. While I like modern C++, Rust really addresses a lot of problems with the proper design from the ground up, which C++ can't do. What Rust so far lacks is better OOP mechanisms. C++ beats Rust in that. For instance Rust is still missing something like virtual structs. See https://github.com/rust-lang/rfcs/issues/349

Genuine question: What do virtual objects enable that cannot be done through the Trait system?

Sharing data layout between implementations of a trait is much more manual and tedious in Rust than it is in something with inheritance. You can often change your design to avoid that issue, but Servo, for example, needs to implement the DOM, and that's just the best way to do it.

Re: Rewrite Everything in Rust

#110

Post by pcwalton » Tue, Feb 23, 2016, 5:13 AM UTC

wspeirs wrote: post #77

pcwalton wrote: post #52

Earlier quoted context omitted.

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

I'm not sure it would take "years and years" of static analysis research. You could use the data-flow analysis that is built into LLVM, then punt on the rest. It doesn't HAVE to produce Rust code that compiles 100% of the time. The goal would be to run it through the transpiler so you have a starting place to produce Rust code that compiles and works the same as the original C code. Again, this might be a terrible id…

Data flow has nothing to do with the hard problems you'd have to solve.