Live data from Hacker News

How to not rewrite it in Rust

adventures.michaelfbryan.com

111–120 of 231 posts

Re: How to not rewrite it in Rust

#111
post #93

Earlier quoted context omitted.

People rewrite C and C++ software in Go too. In fact, unlike Rust, most Go software has no C dependencies at all. This is precisely the result of rewriting everything in Go. To be clear I’m not suggesting you should always rewrite something versus just wrap it, not at all. I’m just saying the reasoning for not doing it being “you didn’t write the original so what do you know” is very offensive to me; how are you supp…

People typically write NES emulators in their spare time, not on a job where others will be expected to maintain their science project.

Nothing in the article suggests it is addressing only work “on the job.”

Re: How to not rewrite it in Rust

#112
post #93

Earlier quoted context omitted.

People rewrite C and C++ software in Go too. In fact, unlike Rust, most Go software has no C dependencies at all. This is precisely the result of rewriting everything in Go. To be clear I’m not suggesting you should always rewrite something versus just wrap it, not at all. I’m just saying the reasoning for not doing it being “you didn’t write the original so what do you know” is very offensive to me; how are you supp…

Most of the common C dependencies were implemented in Go before its public release - https://golang.org/doc/go1 . These implementors are exactly the "better-equipped" original authors to which the blog post was referring. Most programmers are programmers for hire, and it would be a waste of everyone's time to re-implement (for example) libdispatch in Rust. If someone wants to write it on their own time for their own…

All of this has absolutely, truly, nothing to do with rewriting something in Rust. You could also rewrite the same library again in C and have the exact same conundrum.

Also, people build dependencies on effectively “hobby” projects all the time. Open source in particular works well this way because the dependents have a good reason to contribute back; the users become stakeholders and contributors. The same may not be true of internal software, but again, this has little to do with the concept of rewriting something in Rust.

This is really diverging into a discussion that has nothing to do with the original paragraph I addressed.

Re: How to not rewrite it in Rust

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

There is some concept[6] of converting Java to Rust, but it is far from being as useful as c2rust tool. Would be nice to integrate with c2rust somehow, if someone wants to help.

[1] https://github.com/immunant/c2rust

[2] https://c2rust.com/manual/c2rust-refactor/index.html

[3] https://github.com/tectonic-typesetting/tectonic/issues/459

[4] https://github.com/crlf0710/tectonic/tree/oxidize

[5] https://tectonic-typesetting.github.io/en-US/

[6] https://github.com/aschoerk/converter-page

Re: How to not rewrite it in Rust

#114
post #85

I don't think I've ever met a developer who didn't want to rewrite their predecessor's code and that includes the one I see in the mirror. Doing it in a different language would definitely be more interesting. Do we admit that this is a factor in the decision to rewrite vs. reuse?

"I don't think I've ever met a developer who didn't want to rewrite their predecessor's code and that includes the one I see in the mirror"

Allow me to introduce myself ;) I mostly work on new products and rewriting to me just a waste of time. I am interested in creating features that give actual ROI. The only time I rewrite a piece of code is if said piece presents a major problem (bugs, performance etc)

Re: How to not rewrite it in Rust

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

> But the biggest reason to rewrite it in Rust is safety.

This is not a good reason if there are cheaper ways to get safety (at least for existing codebases). Indeed, there are sound static analysis tools (like TrustInSoft) that guarantee no undefined behaviour in C code. Using them is not completely free, and it may even require adding annotations to the code or even changing the code, but it does seem significantly cheaper than a rewrite (in any language). Such sound static analysis tools are already being used for safety-critical systems in C, and I believe they are more popular than a rewrite in Rust in that domain (where there are reasons not to rewrite in Rust other than just cost, though).

Re: How to not rewrite it in Rust

#117
post #32

Earlier quoted context omitted.

I would like to add my 2 cents, TBH I don't see a future where RIIR every piece of software would make sense, and I think you sort of put it in there somewhere in your comments. But yes I do see that for many it would and for those, RIIR would IMHO be an incremental process of oxidizing your project to the point that there's nothing left but Rust. Writing something from scratch and waiting for it to finish is the big…

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

I agree that everything should be made in a memory safe-by-default language like Rust and I really need to see the Rust ecosystem really commit to this. Too many times will I come across a library with some very questionable uses of `unsafe`, which in my opinion has no place in things like HTTP request libraries or web frameworks.

Re: How to not rewrite it in Rust

#118

Earlier quoted context omitted.

It's called resume driven development, and the reason it's done is because it helps those who do it get jobs

Almost nobody is hiring rust devs right now.

I wouldn't be surprised if the ratio of competent Rust developers to Rust jobs were worse than 40:1.

Re: How to not rewrite it in Rust

#119
post #82

Earlier quoted context omitted.

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.

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

Re: How to not rewrite it in Rust

#120
post #59
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…

At least in what concerns C++ there are several ways to try its safety instead of bearing the cost of a full rewrite. Using standard library types, actually integrating sanitizers into CI, enable bounds checking (even on release builds) and above all avoid C style coding. Naturally this doesn't work out for third party libraries that one doesn't have control over. So from a business point of view it boils down how mu…

BTW there are garbage collectors for c++
Post reply on HN