How to not rewrite it in Rust • Hacker News Board

Re: How to not rewrite it in Rust

#141

Post by peatmoss » Wed, Oct 23, 2019, 7:20 PM 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…

I’ve sort of wondered if there isn’t a possibility for ML driven decompilers that produce idiomatic source code from a given byte code.

Re: How to not rewrite it in Rust

#142

Post by gattr » Wed, Oct 23, 2019, 7:20 PM UTC

I have rewritten my small-ish image processing library [0] in Rust (from C) and liked it! I mainly wanted to learn, also Rust forced me to improve the API a bit.

[0] https://github.com/GreatAttractor/libskry_r

Re: How to not rewrite it in Rust

#143

Post by brendangregg » Wed, Oct 23, 2019, 7:21 PM UTC

The author touched on the value of the original author, and this is something missing from the RiiR projects I've encountered. An open source project is more than just code. It's the community: the original authors and maintainers and their years of experience in that problem space. If you don't have a plan to move the community over to Rust (and the RiiR projects I've seen did not) you're (A) duplicating effort, (B) ignoring the value of engineering experience, and (C) making a major decision for an open source project (rewriting it) without collaboration with the current maintainers. (C) is anti-collaborative, and an extreme measure that should only happen in extreme circumstances (not "just because it might be better").

At my employer, the number one reason (I'm aware of) to open source our internal software is to solicit collaboration from other companies. Take away collaboration, and it's going to be a harder sell to open source anything.

Re: How to not rewrite it in Rust

#144

Post by IshKebab » Wed, Oct 23, 2019, 7:22 PM UTC

bernawil wrote: post #79

madmax96 wrote: post #40

Earlier quoted context omitted.

>so it is advised to use pointers to objects on the stack sparingly At least in the C/C++ world, this is not true. Where possible, we prefer stack allocated objects. Stack allocation is fast and usually gives you better cache performance than heap allocation. Rust's lifetime/borrow checker provides compiler support for well-established best practices amongst professional C and C++ users.

looks like you are arguing what "sparingly" means in that context because the rest of the sentence is totally valid. Stack and Heap allocation in C serve different purposes and there's really no rule of thumb to choose one and there's not even one case more frequent than the other. Allocate objects in the stack, it's faster. Unless you need a reference in a function in another context. Or it's too big. Or you're goin…

There's pretty easy rules: stack unless it needs to outlive the current scope, or is very large. That covers 99% of cases.

Re: How to not rewrite it in Rust

#145

Post by erik_seaberg » Wed, Oct 23, 2019, 7:24 PM UTC

MichaelFBryan wrote: post #103

smt88 wrote: post #3

I think this is a clever concept and useful article. However, I have to disagree with the severity of this statement: > at best, the temptation to RiiR is unproductive (unnecessary duplication of effort) For tiny, mature libraries, this might be true. But a rewrite in Rust can also vastly improve maintainability. If a library is under heavy maintenance (and will continue to be), your investment in rewriting it is lik…

i'm more thinking about libraries like tensorflow, ssh, or libgit2. Yes you could rewrite them in Rust, but considering these are tools which are used all over the ecosystem and have massive momentum behind them, your time would be better spent building cool things on top of existing work than reinventing the wheel and trying to convert the ecosystem to something which will (initially, at least) be an inferior produc…

There's no way to write a safe interface for a C library like OpenSSH where critical vulnerabilities to malicious payloads have been found and exploited. All this stuff needs to be replaced if we're ever to to have a trustworthy foundation.

Re: How to not rewrite it in Rust

#146

Post by the8472 » Wed, Oct 23, 2019, 7:26 PM UTC

StreamBright wrote: post #20

steveklabnik wrote: post #8

Earlier quoted context omitted.

All of Rust's complexity for strings comes out of complexity due to UTF-8. Well, a tiny bit comes from the fact that Rust has pointers too, but most of it is UTF-8. Did you happen to read the book? We cover strings early because this is a common pain point. Also, if you have something more detailed than "get strings out of libraries", I can give better advice. It's tough to tell what the actual issue is.

Like this: use sha2::{Sha256, Digest}; fn main() { let mut hasher = Sha256::new(); hasher.input(b"hello world"); let result = hasher.result(); ?? } How do I get a string with the hash value? Which chapter of which book should I read?

This seems to be a conceptual mistake that often happens when coming from high level languages, I have seen similar confusion on stack overflow relating to packet based network protocols.

What many low-level data formats deal with are raw bytes ("byte strings" in some contexts). The output of a hasher is random binary data.

What most humans are accustomed to are some form of encoding that makes it easier to spell out the octets. Hex and base64 are common. But they are not the native representation that the machine deals with.

With almost everything being explicit in rust you need an explicit conversion from bytes to hex, base64, urlencode or some other format.

Those conversion methods (with their contract often expressed as a separate trait) may be provided by the same crate or you may have to pull them in from a different crate.

A hasher does not need to provide this itself because its output types can be enhanced by foreign traits.

Re: How to not rewrite it in Rust

#147

Post by bluejekyll » Wed, Oct 23, 2019, 7:31 PM UTC

chongli wrote: post #82

skrebbel wrote: post #75

Earlier quoted context omitted.

I really like the phrase "elite quitters". I wonder if, as a stereotype, it's unique to the software industry.

No, it also happens in professional sports. Star players leave the teams that drafted them to look for better opportunities. It seems to be an inevitability that small market teams draft and develop star players who then quit on the fans for a big contract or a chance to play with other stars in the big city.

Sports players have a limited amount of time to exploit their bodies.

Developers have a much longer lifetime of continuous learning, opportunities to get better, and focus on being the best they can be.

But at the end of the day, when a developer or player no longer offers their organization value, they will be cut loose. This is hugely destructive to that person's ability to care for themselves and their families. Is it any wonder that they want to do whatever they can to secure a stable future for themselves?

Re: How to not rewrite it in Rust

#148

Post by tyri_kai_psomi » Wed, Oct 23, 2019, 7:37 PM UTC

fjp wrote: post #119

tyri_kai_psomi wrote: post #99

Earlier quoted context omitted.

Don't forget the key ingredient in this recipe: they show a small burst of greatness or give a couple shining glimmers of hope and then capitalize on that small sample size.

I mean the incentives are the cause. If you could rewarded with an incredible salary for sticking at the same company for 10 years and making a great, reliable platform using "boring technologies" then more people would probably do it. Instead to raise your salary you gotta jump jobs every 2 years

> If you could rewarded with an incredible salary for sticking at the same company for 10 years and making a great, reliable platform using "boring technologies" then more people would probably do it.

> Instead to raise your salary you gotta jump jobs every 2 years

I believe the majority of America stays at their employers. It just seems to be the en vogue style for this group. I've made careers at my past two employers. I like to think I've made out very well by sticking to the same company for 4 years, going on 5, much better off than if i joined a startup working slave labor for much less total compensation only to have my shares diluted once an exit happens.

I've done it all at this point in my career, and sticking to a stable, cash-positive business is the best option at this point, IMO of course. Everyone likes to think they'll be the special 1% to make that big exit but then again our generation (millennials) were raised to believe we were special so it makes sense why people go chasing the dollar.

Your employer takes a little more time to adjust, but in the end, people end up where they should be over time.

Re: How to not rewrite it in Rust

#149

Post by gameswithgo » Wed, Oct 23, 2019, 7:38 PM UTC

zbentley wrote: post #135

Skunkleton wrote: post #128

Earlier quoted context omitted.

(4) You want to develop new components in rust, but it has to integrate with your existing components somehow.

Why not use ffi for this case? Many languages have robust support for linking to Rust code.

yeah sometimes that makes sense. if the lib in question in small enough it might be more valuable to port, so avoid having a multi language project, and avoid the effort of the ffi.

at least Rust -> C ffi is zero cost (usually)

Re: How to not rewrite it in Rust

#150

Post by hinkley » Wed, Oct 23, 2019, 7:46 PM UTC

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…

Or all of the above.

Mature software can have a bunch of hard to fix bugs that you can't motivate anyone to work on any longer. If you want to continue making progress you have to route around the damage somehow.