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

Why you should, actually, rewrite some of it in Rust

unhandledexpression.com

Post reply on HN
Print view View original

121–130 of 300 posts

Re: Why you should, actually, rewrite some of it in Rust

#121

Post by qznc »

bandook_raja wrote: post #109
dikaiosune wrote: post #96

Earlier quoted context omitted.

How much of the standard library works without GC enabled? How many community libraries do? D has a lot of great things (I am incredibly jealous of their metaprogramming facilities sometimes), but it doesn't seem like many people are successfully using it in the "fast and SAFE" sense as GP defined it.

> How much of the standard library works without GC enabled? How many community libraries do? Enough to be usable on virtually all platforms that rust is going to target in next 2 years. I hope I'll get proven wrong but that's it for now. And maybe along the time we'll see some decoupling of stdlib from GC too. OTOH some people like GC too :)

> along the time we'll see some decoupling of stdlib from GC

That is already happening. There is no measure, though. How should it be measured?

Related, a few days another blog post in the No-GC series was published: https://dlang.org/blog/2017/07/07/go-your-own-way-part-one-t...

Re: Why you should, actually, rewrite some of it in Rust

#122

Post by steveklabnik »

santaclaus wrote: post #119
pornel wrote: post #116

I've been programming in C for 17 years. Now I'm writing (and rewriting) image processing and encoders in Rust and I love it. It's not just memory safety. Rust has sweet error handling — the syntax is almost as noise-free as exceptions, but code flow is as predictable as error codes. In Rust I handle rare error cases that I wouldn't have bothered with in C (and thus my Rust programs fail in orderly fashion instead of…

> Rust has sweet error handling I feel like a lot of the cool things in Rust get obscured in the never ending safety dance. There is some rad stuff in Rust compared to its closest competitors (C and C++) -- cleaner error handling, a standard package manager, no aliasing -- I want to hear about what else Rust can do for me! More safety guarantees, ehhh, I'll take them but they aren't a huge win in our work.

We had a big community discussion about this topic last year: https://brson.github.io/fireflowers/

Re: Why you should, actually, rewrite some of it in Rust

#123

Post by pjmlp »

sqeaky wrote: post #43
lj3 wrote: post #29

Has anyone done any in depth explorations of the safety and security of rust code vs well written C or C++?

Well written the hard part there. I am riding on on the idiomatic C++11/14/17 train right now. Life over here is great, but I can the warts of the language looking backwards. The promised land in the future doesn't look quite as bright as the promises Rust offers. The only thing keeping me from trying it is the giant codebases in my current projects.

> I am riding on on the idiomatic C++11/14/17 train right now.

How do you see it?

Nowadays I only use C++ on hobby projects or when Java/.NET need some kind of integration work.

To me it seems that as code bases grow organically, it will become very hard to get which code is in which ANSI version, specially problematic given some of the changes that took place between standard revisions.

Re: Why you should, actually, rewrite some of it in Rust

#124

Post by rbehrends »

lobster_johnson wrote: post #12
hbbio wrote: post #8

You can also rewrite to C++, OCaml, Go... Each language has benefits and drawbacks, and there is good reason for each them to exist. Would your project benefit a lot from algebric datatypes -> OCaml is a great fit! You want to port as soon as you can: C++ is your friend. You plan to write HTTPS service nodes: Go has the best standard library out there.

If you read the article you'll notice that he proposes that Rust is a better language because it allows incremental rewriting, rather than a complete one; Rust doesn't have a runtime, doesn't have GC, and can fairly seamlessly/painlessly integrate with C (you can both call and be called from C easily). That changes the equation considerably, compared to something like Go where none of these benefits exists. For examp…

Incremental rewriting introduces the potential for new issues, as foreign function interfaces are inherently unsafe.

Rust also has its own costs. Its biggest limitation when it comes to mixing in code with that written in another language is probably its poor support for shared ownership (i.e. multiple references of the same object), while in most languages, shared ownership is the norm.

Multi-language setups (which you invariably get with an incremental rewrite) also generally create other interfacing issues when they share objects. How are you going to represent `std::shared_ptr` or `std::vector` in Rust, for example? They are opaque types, after all. Can you guarantee that Rust properly observes C++ semantics with regard to assignment, move assignments, and destructors when dealing with instances declared entirely in C++ code once you start mixing and matching C++ and Rust?

Re: Why you should, actually, rewrite some of it in Rust

#125

Post by iso-8859-1 »

atemerev wrote: post #64
falcolas wrote: post #19

Sigh. This again. Not all security vulnerabilities are due to pointer arithmetic or out of bounds execution or pick-your-rust-is-better-idiom. Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Could the affected parts be re-written in a way where the boundary c…

> It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Really? Validation and sanitization are the last, not the first line of defense. It is not about erecting barriers, it is about failure modes. All your software components, from core to border, should fail fast, safe and in a predictable way -- the exact opposite of what happens in C. In any sane programming language (e.g.…

Bounds checking is not customary because it is more work. It is more work because arrays in C degrade to pointers, which do not know their length. This is because C was designed on a PDP-7 with 8k RAM. Original Pascal had only fixed size arrays/strings and it was a problem.

http://cm.bell-labs.com/who/dmr/chist.html

Re: Why you should, actually, rewrite some of it in Rust

#126

Post by wbl »

anp wrote: post #81
rurban wrote: post #74

Earlier quoted context omitted.

I don't agree with the underlying thesis: In 15 years, I'll be heartbroken if we're still facing an endless stream of security updates and remote root compromises when all these projects were rewritten in a popular but unsafe language: Rust. There do exist fast and SAFE language out there. With guaranteed memory safety, null pointer safety, concurrency safety, dead-lock freedom, race freedom, and even with normal syn…

Can you be specific about which languages you include in the category of "fast and SAFE"?

Ada. Algol-60. The much maligned Pascal.

Re: Why you should, actually, rewrite some of it in Rust

#127

Post by sqeaky »

pjmlp wrote: post #123
sqeaky wrote: post #43

Earlier quoted context omitted.

Well written the hard part there. I am riding on on the idiomatic C++11/14/17 train right now. Life over here is great, but I can the warts of the language looking backwards. The promised land in the future doesn't look quite as bright as the promises Rust offers. The only thing keeping me from trying it is the giant codebases in my current projects.

> I am riding on on the idiomatic C++11/14/17 train right now. How do you see it? Nowadays I only use C++ on hobby projects or when Java/.NET need some kind of integration work. To me it seems that as code bases grow organically, it will become very hard to get which code is in which ANSI version, specially problematic given some of the changes that took place between standard revisions.

At both of my jobs, I am working way too much, I am working in pre-C++11 codebases which now allow C++11. Both are working to for -Werror everywhere and that helps a huge amount, and we can try to get more warning listed and make broad but subtle changes to the codebases.

At one place we are in a race before a tight deadline and at the other we are breaking a large monolith into smaller packages. At one place we implement a new practice for all our code, and at the other we implement all our best practices as we chop code out of the monolith. Both places are seeing a reduction in bugs. The place with the packages is probably reaping a larger benefit because they are aggressively re-working old code and have better test coverage and can do so with confidence.

Code bases do grow organically, but like places they can be tended and pruned to make impressive orchards or topiaries or left to the wild to become impassible jungles. Tools like RAII, exceptions, classes, etc... are just tools for managing this.

I think the tools in C++11/14 are at least as powerful as in any language except perhaps Rust. Every time I hear a C developer say "C can be just as safe..." I am imagine a person with nothing but a pocket-knife trying to manage a whole forest.

Re: Why you should, actually, rewrite some of it in Rust

#128

Post by marcosdumay »

ZoFreX wrote: post #105
steveklabnik wrote: post #103

Earlier quoted context omitted.

I thought it made the cutoff. I could be wrong. I was more worried about 1.15, which did get missed, ugh. Debian has made a tool, "debcargo", to automatically turn crates from crates.io into Debian packages, so it should be "just run this tool." I have not used it myself though.

I think it's fair to say that anyone releasing software written in Rust on Debian right now has extra work to do, and is likely to be treading new ground.

Is it really harder than making autotools work?

Anyone releasing software in C, Python, Haskell, Ruby, Lisp, or whatever language has extra work to do. I don't think there's any sizeable difference between any of them.

Re: Why you should, actually, rewrite some of it in Rust

#129

Post by biokoda »

santaclaus wrote: post #119
pornel wrote: post #116

I've been programming in C for 17 years. Now I'm writing (and rewriting) image processing and encoders in Rust and I love it. It's not just memory safety. Rust has sweet error handling — the syntax is almost as noise-free as exceptions, but code flow is as predictable as error codes. In Rust I handle rare error cases that I wouldn't have bothered with in C (and thus my Rust programs fail in orderly fashion instead of…

> Rust has sweet error handling I feel like a lot of the cool things in Rust get obscured in the never ending safety dance. There is some rad stuff in Rust compared to its closest competitors (C and C++) -- cleaner error handling, a standard package manager, no aliasing -- I want to hear about what else Rust can do for me! More safety guarantees, ehhh, I'll take them but they aren't a huge win in our work.

A huge win compared to C is fearless refactoring. Making changes to an existing codebase in C is a minefield. Refactoring in Rust is a breeze.

Re: Why you should, actually, rewrite some of it in Rust

#130

Post by bboozzoo »

biokoda wrote: post #92
mtgx wrote: post #71

We need Rust to have great support for ARM microcontrollers before the IoT industry really takes off.

The relatively low portability of rust programs is definitely one of its largest shortcomings.

Can you elaborate? Although haven't tried it myself, I was under the impression that it's quite possible to write low level code for at least for x86 and ARM (and AVR?).
Post reply on HN