How to not rewrite it in Rust • Hacker News Board

Re: How to not rewrite it in Rust

#201

Post by duneroadrunner » Thu, Oct 24, 2019, 4:29 AM UTC

xvilka wrote: post #113

There is an automated tool - c2rust[1], automating a huge chunk of the translation from C to Rust. Moreover, it has a refactoring tool[2] that is scriptable in Lua. One of the good examples of such conversion (still not finished though), while still producing the same output is a rewrite[3][4] of XeTeX engine to Rust (as part of Tectonic[5] engine). It is able to parse arXiv articles dump and generate valid PDFs stil…

Last time I looked at it, c2rust translated from C to unsafe Rust, right? I'll point out a (neglected) project[1] to (partially) auto convert from C to a safe subset of C++. For example, if you need a png encoder/decoder library written in C++, perhaps the safest one is here [2].

[1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

[2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

Re: How to not rewrite it in Rust

#202

Post by UncleMeat » Thu, Oct 24, 2019, 5:01 AM UTC

otabdeveloper4 wrote: post #86

sitkack wrote: post #14

This article is wonderful and I hope as a setup for second article, "How to Rewrite it in Rust"! > However at best, the temptation to RiiR is unproductive > A much better alternative is to reuse the original library and just publish a safe interface to it. Just as models are a lower dimensional representation of a more complex problem, [1] I have to re-iterate that there are no truth(ism)s in software and as in all e…

There's no such thing as a "C/C++".

The abi meaningfully binds them.

Re: How to not rewrite it in Rust

#203

Post by pjmlp » Thu, Oct 24, 2019, 5:13 AM UTC

dbaupp wrote: post #169

pjmlp wrote: post #152

Earlier quoted context omitted.

More than Rust in multithreaded scenarios, actually. Not only they have automatic memory management, they have an industry standard memory model for hardware access, adopted by C and C++ standards, used as inspiration for std:atomic on CUDA. While you keep being baffled, where is Rust's memory model specification?

There's a good argument to be made that Rust is safer in multithreaded scenarios than the JVM or .NET. Rust statically prevents inappropriate unsynchronized accesses for arbitrary APIs (for instance, the compiler will emit an error when attempting to mutate a non-concurrent object/data structure from multiple threads). Those VMs make unsynchronized mutations of individual memory locations work just enough to not be u…

Yes, it is one less failure point to worry about, but in my experience using the respective task libraries in distributed applications, most of the multithreaded access bugs lie on external resource usage, and those Rust does not prevent.

Not saying that it isn't important though.

Re: How to not rewrite it in Rust

#204

Post by idnefju » Thu, Oct 24, 2019, 5:19 AM UTC

brendangregg wrote: post #186

orange8 wrote: post #170

Earlier quoted context omitted.

> (C) is anti-collaborative, and an extreme measure that should only happen in extreme circumstances (not "just because it might be better"). I agree with A and B, but C just feels like gate-keeping. Open source license do not require collaboration with the original authors. You can freely fork any opensource codebase and modify it as you wish without asking someones permission.

You are free to fork, but that doesn't make it right. Imagine a well-funded startup trying to make a name for themselves decided to fork the top 10 emerging open source projects, put their company name on them, and then spend millions in PR/marketing so that (A) it seems like they invented them, and (B) they fork the community. Are they free to? Is it right? What will it mean for the original authors and experts who…

Forking for whatever reason is in the spirit of open source. Asking if something is right is nonsense. From an ethical point of view, it follows the license of the project so there is no issue.

If the author of the original source had an issue with the above scenario, they would've chosen a more restrictive license that didn't make it possible.

Re: How to not rewrite it in Rust

#205

Post by RustyRussell » Thu, Oct 24, 2019, 5:45 AM UTC

nullc wrote: post #185

adrianmonk wrote: post #74

> at best, the temptation to RiiR is unproductive I think there are probably three cases here: (1) You have perfectly good software and your only motivation to rewrite is infatuation with how great Rust seems. In this case, yes, that's unproductive. (Infatuation-driven design is poor engineering and is a fairly widespread problem in the software industry.) (2) You already have other reasons to want to rewrite (design…

> (2) You already have other reasons to want to rewrite (design could be improved, code is in a poor state, etc.), and you're deciding between languages. It would be wise to ignore the language distraction and remember that most urges to rewrite are just flat out wrong. The standard and well respected advice about rewrites doesn't go out the window just because of a fad language, if anything they apply more strongly.…

Andrew Tridgell once said "you never need an excuse to rewrite something".

But I usually append that quote with "but then again, you're not Tridge" :)

Kernighan and Plauger said "don't patch bad code: rewrite it". That is definitely true. And there's a lot of bad code.

Re: How to not rewrite it in Rust

#206

Post by dralley » Thu, Oct 24, 2019, 5:53 AM UTC

brendangregg wrote: post #186

orange8 wrote: post #170

Earlier quoted context omitted.

> (C) is anti-collaborative, and an extreme measure that should only happen in extreme circumstances (not "just because it might be better"). I agree with A and B, but C just feels like gate-keeping. Open source license do not require collaboration with the original authors. You can freely fork any opensource codebase and modify it as you wish without asking someones permission.

You are free to fork, but that doesn't make it right. Imagine a well-funded startup trying to make a name for themselves decided to fork the top 10 emerging open source projects, put their company name on them, and then spend millions in PR/marketing so that (A) it seems like they invented them, and (B) they fork the community. Are they free to? Is it right? What will it mean for the original authors and experts who…

The situation with dstat was a little more subtle than that

https://news.ycombinator.com/item?id=19986646

Re: How to not rewrite it in Rust

#207

Post by pjmlp » Thu, Oct 24, 2019, 5:54 AM UTC

makapuf wrote: post #177

pjmlp wrote: post #168

Earlier quoted context omitted.

Android ships a subset of it enabled in production.

Interesting, I could not find any links do you have some ?

Sure,

https://source.android.com/devices/tech/debug/asan

https://android-developers.googleblog.com/2019/05/queue-hard...

Also FORTIFY has been being enabled across the codebase and will become default going forward.

https://android-developers.googleblog.com/2019/10/introducin...

Future Android devices on ARM will make use of memory tagging.

https://security.googleblog.com/2019/08/adopting-arm-memory-...

Re: How to not rewrite it in Rust

#208

Post by carlmr » Thu, Oct 24, 2019, 6:56 AM UTC

Aeolun wrote: post #183

chii wrote: post #182

Earlier quoted context omitted.

> you should have a good reason And what constitutes a good reason? The epitome of open source is that you don't need to explain of your fork is really superior, the users will come.

Creating a wrapper around an existing library will never be superior to a native rust library to me.

It may be superior if there's ongoing maintenance and improvements on the original code.

RiiR certainly has it's place though. Ripgrep for me as a user is vastly superior to grep and a large reason for that I see is in the safe optimizations allowed by the borrow checker. They're certainly possible in C, but it wouldn't be maintainable.

Also I'd look at how stable the library is you're wrapping and the size of the code base. It may be lower effort to rewrite than to wrap.

Re: How to not rewrite it in Rust

#209

Post by carlmr » Thu, Oct 24, 2019, 7:23 AM UTC

sitkack wrote: post #61

nicoburns wrote: post #54

Earlier quoted context omitted.

> TBH I don't see a future where RIIR every piece of software would make sense It doesn't necessarily have to be Rust, and it's a process that may take decades. But I really do think that absolutely everything should be rewritten in a memory-safe language (i.e. not C/C++). The vast majority of security issues are either stupid misconfigurations or memory-safety issues. And currently most security initiatives are unde…

Exactly, when we talk about RiiR, we are saying, "I would like to have the guarantees that Rust provides". If the Rust ecosystem depends heavily on C/C++ libraries, then the system has the properties of the union of all the flaws and the properties of the language do not translate into a quality of the ecosystem. That said, I think containing C/C++ to a Wasm sandbox that can be integrated transparently with Rust woul…

>"I would like to have the guarantees that Rust provides". If the Rust ecosystem depends heavily on C/C++ libraries, then the system has the properties of the union of all the flaws and the properties of the language do not translate into a quality of the ecosystem.

Of course ideally you get rid of all C/C++, but that may not be feasible. Combining Rust with some C/C++ still adds the benefit of Rust safety to the new code you write. The contained C/C++ is like the unsafe section of Rust code, a place where you have to be more vigilant, but you're slowly constraining the space where these issues can arise. And you can iteratively only replace those parts that cause a lot of issues.

Re: How to not rewrite it in Rust

#210

Post by dbaupp » Thu, Oct 24, 2019, 10:05 AM UTC

pjmlp wrote: post #203

dbaupp wrote: post #169

Earlier quoted context omitted.

There's a good argument to be made that Rust is safer in multithreaded scenarios than the JVM or .NET. Rust statically prevents inappropriate unsynchronized accesses for arbitrary APIs (for instance, the compiler will emit an error when attempting to mutate a non-concurrent object/data structure from multiple threads). Those VMs make unsynchronized mutations of individual memory locations work just enough to not be u…

Yes, it is one less failure point to worry about, but in my experience using the respective task libraries in distributed applications, most of the multithreaded access bugs lie on external resource usage, and those Rust does not prevent. Not saying that it isn't important though.

Ownership/affine typing does allow modelling that, within a single program.

For instance, the type representing a handle to the external resource can have limited constructors and limited operations, that will enforce single threaded mutations or access (including things like "this object can only be destroyed by the thread that created it").