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

How to not rewrite it in Rust

adventures.michaelfbryan.com

Post reply on HN
Print view View original

91–100 of 231 posts

Re: How to not rewrite it in Rust

#91

Post by aswanson »

Franciscouzo wrote: post #68
asdfman123 wrote: post #46

> The first step in interfacing with a native library is to understand how it was originally intended to work. But reading code is hard, it's easier to project your sense of confusion onto your predecessor than own it yourself, and once you rewrite the code in Rust and start to understand the true complexity that the previous code had to work around, you'll leave for another job (this time with Rust on your resume).

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

RDD. That is effing hilarious.

Re: How to not rewrite it in Rust

#92

Post by aswanson »

royjacobs wrote: post #87
shantly wrote: post #83

Earlier quoted context omitted.

As long as companies keep expecting experience in very specific technologies (only at work—400 hours on a hobby codebase don't count for as much as 40 hours writing something at a job for determining competence in a language or framework or whatever, it seems) this will keep happening. It's really, really dumb, but there's little other choice for folks who want to keep their skills (=the names of tools & languages th…

At a previous job I worked with someone who didn't see a buzzword they didn't like. Since nobody was stopping them, they designed an incredibly convoluted system using all the latest tech. In the end we replaced it with a JVM server and a Postgres database. I occasionally check their LinkedIn and they're still spending 12-15 months every time at companies, being CTO or Big Data Strategist or whatever.

Ambition and incompetence. Nice combo.

Re: How to not rewrite it in Rust

#93

Post by jchw »

empthought wrote: post #90
jchw wrote: post #78

Earlier quoted context omitted.

No it’s not. You didn’t write it the first time, and grow from writing it the first time. Writing and shipping something in a new programming language is a fantastic way to learn both. This has only become contentious as people try to come up for a reason why rewriting things in Rust is bad, when really it is about as benign as trends go. I never heard the same complaints about rewriting things in Go (another languag…

Rewriting software written using Python, Java, and Ruby in Go is entirely different from rewriting software written using C and C++ in Rust. Go has easily quantifiable advantages over those other runtimes regardless of the original code's correctness.

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 supposed to learn?! People write NES emulators all the time even though they already exist. While most are purely for practice it doesn’t really matter: they wanted to write it, they wrote it, they learned. Discouraging people from writing something that they want to write is upsetting to me.

Re: How to not rewrite it in Rust

#94

Post by jaredtn »

Summary: - Rather than rewriting a C++ library in Rust (difficult and will introduce bugs), wrap it in a Rust interface.

This seems like the cleanest way to move a codebase forward without too much regression work. It reminds me of how TensorFlow 2.0 still contains tf.compat.v1 APIs so devs can write forward-facing code while maintaining existing modules.

Re: How to not rewrite it in Rust

#95

Post by cmyr »

resoluteteeth wrote: post #88
gatherhunterer wrote: post #77

The title of the article is “How to not RIIR”, not “How not to RIIR”. The article is about wrapping an API with a Rust interface so the title used here on HN does not fit the content of the article.

I don't see how the meaning of the phrases “How to not RIIR” and “How not to RIIR” is different.

It's subtle. The second phrasing ("how not to x") is idiomatic, and means, roughly, "some things that you should not do when you do x", or "an example of how you should not go about doing x."

So, an article titled, say, "how not to paint your house" would be expected to outline things to avoid when painting your house, and "how to not paint your house" could just be "go for a bike ride instead."

Re: How to not rewrite it in Rust

#96

Post by cliffcrosland »

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…

> But the biggest reason to RiiR is safety.

100% agree. We had a C++ service that made heavy use of libcurl. A particular release of libcurl introduced some memory safety problems that caused frequent segfaults for us. These memory safety bugs were eventually fixed in another release, but it scared us enough that we investigated rewriting the service in Rust.

After successful experimentation with some prototypes, we eventually rewrote the service in Rust, auditing the unsafe code in our dependencies (of which there was very little). No segfaults ever since.

Side benefit: Since Rust networking libraries tend to have strong async support, and since some of our C++ libraries performed synchronous networking operations, we saw a big improvement in performance. The number of threads needed dropped by 5x.

Re: How to not rewrite it in Rust

#97

Post by FreeFull »

resoluteteeth wrote: post #88
gatherhunterer wrote: post #77

The title of the article is “How to not RIIR”, not “How not to RIIR”. The article is about wrapping an API with a Rust interface so the title used here on HN does not fit the content of the article.

I don't see how the meaning of the phrases “How to not RIIR” and “How not to RIIR” is different.

I would expect "How not to RIIR" to be some study of RIIR gone wrong, and "How to not RIIR" to be a guide.

Re: How to not rewrite it in Rust

#98

Post by laputan_machine »

resoluteteeth wrote: post #88
gatherhunterer wrote: post #77

The title of the article is “How to not RIIR”, not “How not to RIIR”. The article is about wrapping an API with a Rust interface so the title used here on HN does not fit the content of the article.

I don't see how the meaning of the phrases “How to not RIIR” and “How not to RIIR” is different.

IMHO:

'How not to x' articles are typically self-deprecating articles that do x, but are critical of how they approached it and lessons learnt

'How to not x' is more explicit, i.e. How to avoid doing x

Re: How to not rewrite it in Rust

#99

Post by tyri_kai_psomi »

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.

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.

Re: How to not rewrite it in Rust

#100

Post by unlinked_dll »

shantly wrote: post #83
Franciscouzo wrote: post #68

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

As long as companies keep expecting experience in very specific technologies (only at work—400 hours on a hobby codebase don't count for as much as 40 hours writing something at a job for determining competence in a language or framework or whatever, it seems) this will keep happening. It's really, really dumb, but there's little other choice for folks who want to keep their skills (=the names of tools & languages th…

anecdata but I've only had terrible experiences with companies looking for specific technologies (e.g. a job listing of "$LANGUAGE Developer").

Mostly good experiences when it's a specialist gig that happens to require a specific technology. Like some parts of a stack aren't interchangeable and aren't easy to pick up overnight.

Post reply on HN