Live data from Hacker News

Rewrite Everything in Rust

robert.ocallahan.org

121–130 of 242 posts

Re: Rewrite Everything in Rust

#121
post #106

Earlier quoted context omitted.

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 t…

Is there a great tool to convert Python 3 to Python 2?

I've tried Pasteurize (part of python-future) but it just leaves the "yield from" statements in place, giving syntax errors. And 3to2 does even less, and seems to mostly be a framework for building tools like Pasteurize.

I know this isn't easy, but JavaScript people do it with ES6 transpilers, and ES6 is more different from ES5 than Python 3 is from Python 2.

Re: Rewrite Everything in Rust

#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 others can understand and imho, it trumps all other reasons. Not trying to underplay the value of type safety. It is fantastic. My Haskell programs have much much less bugs and I tend to get it to work, much faster than when I do C/C++ code. I would expect some of that goodness to be in Rust programming as well.

It would have been fantastic, if Rust took only a few steps further from Cyclone. I also wish that Rust authors stop adding more and more features. The target audience, namely low level system programmers, tend to work close to hardware and think along those lines, so bombarding them with type theory concepts is only going to shoo them away.

Just my 2 cents.

Re: Rewrite Everything in Rust

#123
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…

And as a Rust and Python programmer, I find C++ hard to read (I can never shake the feeling that the ampersands are always in the wrong place), and I'm nearly hopeless at deciphering Haskell. :P I suppose this is just something that comes with experience.

Re: Rewrite Everything in Rust

#124
post #95
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 feel like C++ has turned into programming language Katamari Damacy. I wonder what it will look like when it rolls up Lisp?

This is one of the psychological barriers that keeps me from even trying to learn C++ - every time I hear friends talking about new C++ developments I can't help but feel that modern C++ is so incomprehensibly large that I'm just left paralysed.

Re: Rewrite Everything in Rust

#125

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…

If someone wants to pay me to rewrite glibc in Rust, I'd gladly do it, as I'm sure lots of other devs would. It's actually something I've thought about doing as a hobby, but there are a million other hobbies above it on the list.

Re: Rewrite Everything in Rust

#126
post #62

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.

You mean other than the fact that it's still running on top of a kernel, BIOS, and other firmware that was ALL written in C or Assembly? Yeah, totally safe /s.

Historical accident.

I used to do systems programming back when the only OS written in C was UNIX.

C wasn't the first systems programming language.

Burroughs B5500 was written in Algol 68 with zero lines of Assembly. Just one example from many others in the pioneering days of computing.

There are other approaches to writing OSes.

If UNIX community ever wants to divorce from C there is a way, but there needs to exist a will as well.

Re: Rewrite Everything in Rust

#127
post #102
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://ww…

It is available to VS 2015 Update 1 users.

Re: Rewrite Everything in Rust

#128
"[Other safe languages] require complex runtime support that doesn't fit in certain contexts (e.g. kernels)."

Complex runtimes are also unsuitable for libraries. If you write a great openssl replacement in Haskell, it's only useful for Haskell applications. Because nobody wants to link the Haskell runtime into many of the applications that use openssl.

For widespread libraries, the choices are basically C, C++, and now (hopefully) rust.

Re: Rewrite Everything in Rust

#129
How I wish people understood this when we were comparing Ada, Modula-2, Modula-2+, Modula-3, Pascal dialects, Oberon, Oberon-2, Active Oberon, Component Pascal,... to C.

Apparently we were the fools.

But this will never happen in UNIX OSes.

The culture is married to C, regardless how many memory corruption exploits per days might get a CVE entry.

However I hope to be proven wrong.

Re: Rewrite Everything in Rust

#130
post #89

Earlier quoted context omitted.

>We need to have incentives for maintaining this foundational software. It's my opinion that contributing to free software is a public good, and so we should have state-funded employees whose full-time job is to work on this software. I think something like this is already done in places like France and Europe, but to my knowledge the majority of paid-for American contributions to FLOSS comes from corporations.

How would we decide what specific projects are actually worked on?

How does the NIH decide what research gets funded?
Post reply on HN