
How to not rewrite it in Rust - yarapavan
http://adventures.michaelfbryan.com/posts/how-not-to-riir/
======
brendangregg
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.

~~~
orange8
> (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.

~~~
scottlamb
You can...and certainly cloning a git repo or hitting the "fork" button on
github is a normal part of the development workflow. If you're experimenting
those changes may be discarded. If you're contributing those changes go back
to upstream. But I don't think either of those are what the author means by
fork. Other folks have talked about this. [1] [2]

I think the author means: if you're maintaining changes in your fork
indefinitely and advertising this fork to others as superior to the original
to use or as a canonical place to file issues, you should have a good reason.
Communities are valuable; please don't divide them or throw them away lightly.
Try working with the original maintainer first.

[1]
[https://news.ycombinator.com/item?id=16600219](https://news.ycombinator.com/item?id=16600219)

[2]
[https://news.ycombinator.com/item?id=20001570](https://news.ycombinator.com/item?id=20001570)

~~~
chii
> 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.

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

~~~
carlmr
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.

------
adrianmonk
> _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 could be
improved, code is in a poor state, etc.), and you're deciding between
languages. In that case, a rewrite could be productive even if you didn't use
Rust.

(3) You have mature software that appears relatively free of obvious, known
bugs, but it's written in an unsafe language, and it would be valuable to have
the additional confidence that a safe language could provide. Security-
sensitive or other critical applications are where this is most likely to make
sense.

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

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

~~~
gameswithgo
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)

~~~
viraptor
Having everything available in Rust code also means you don't have to do lots
of extra work for cross-compilation.

~~~
saagarjha
How does Rust help you if you have to cross-compile?

~~~
viraptor
You can compile rust in one go. If you rely on native libraries, you need to
be able to link them during cargo build and that's painful to set up. Not
impossible... just really annoying to manage.

------
xvilka
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](https://github.com/immunant/c2rust)

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

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

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

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

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

~~~
svat
I wrote a comparison of the quality of this autogenerated C2rust code versus
the original sources (WEB code in this case), the last time this was posted:
[https://news.ycombinator.com/item?id=21176806](https://news.ycombinator.com/item?id=21176806)
(Though it's not a fair comparison as this particular automatic translation
itself started from automatically translated C code, for unclear reasons.)

~~~
xvilka
Probably because there is no automated translator from WEB? And unlikely there
will ever be.

------
sitkack
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 engineering, there are trade offs. RiiR can and often is a valid
choice. The author talks about "introducing bugs", under an engineering
approach to a rewrite, more like a language-port, rewrites can _find_ a lot of
bugs. One such way is as follows.

1\. keep the same interface in the new system, client code should work against
either system.

2\. have a body of integration tests, capture these from the field OR write a
small collection of orthogonal tests, somewhere between unit and integration.

3\. use the tooling, bindgen, etc and generate as much of the interface
programmatically as possible.

4\. iterate on the port, doing differential testing against both systems.

Doing a language port is comparable in work to long term maintenance and
refactoring of an existing codebase. As the tooling gets better, RiiR will be
more of a smooth oxidization.

If you own the C/C++ that could possibly get rewritten, I'd think one needs to
rationalize NOT RiiR. Better tooling (IDE, build), perf tooling is improving,
low bug count, increased team velocity, build is improved, etc.

But the biggest reason to RiiR is safety. Integrating a body of C/C++ code
into your rust codebase introduces a huge amount of unsafe code, much worse
than surrounding your entire rust program with unsafe { }.

At least do what is outlined in the article but ALSO compile the native code
into Wasm and run it from within a sandbox.

 __edit, something like a library for reading (parsing) a file format, should
absolutely be RiiR or run from a sandbox. Data parsing and memory corruption
vulnerabilities are excellent dance partners.

[1] see PCA
[https://en.wikipedia.org/wiki/Principal_component_analysis](https://en.wikipedia.org/wiki/Principal_component_analysis)

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

~~~
pjmlp
Apparently there is when reading ISO, Microsoft, Apple, Google, IBM,
Microsoft,... documentation.

Guess what, we even used to have a famous magazine called "The C/C++ Users
Journal".

~~~
makapuf
Agreed. There _Are_ differences between c and "c in c++" but no more than
python 2 and 3 or c++11 and c++17

------
smt88
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 likely to pay dividends by saving developers -- especially
ones who are new to the library -- a lot of time.

~~~
MichaelFBryan
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 product.

The original statement was deliberately opinionated and extreme, but I still
feel like the pragmatic approach of reusing existing libraries instead of
rewriting them is the best one for the short/medium term (jury's still out on
the long term costs/effects).

~~~
erik_seaberg
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.

------
asdfman123
> 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).

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

~~~
shantly
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 they've used to write something for pay) up
to date (=trendy high-paying buzzword compliant).

Doubly true if you're not all-in on one of the major Bigcorp silos (Java, C#).

~~~
royjacobs
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.

~~~
aswanson
Ambition and incompetence. Nice combo.

~~~
mannykannot
The Dunning-Kruger career path: persuade the people hiring to think that you
are more competent than you are.

------
jacobush
_" A much better alternative is to reuse the original library and just publish
a safe interface to it."_

I think I must reject the premise a bit, unless I misunderstand how Rust
works.

If you write a safe wrapper around unsafe code, is it not still the case, that
if the unsafe code bombs out, it will take the safe Rust down with it,
engulfed in shared flames?

(Unless you spawn unsafe code in its separate process or something elaborate
like that.)

(Then again, from a practical standpoint the reasoning may be good. Maybe,
even likely, the C library is very good and very battle tested. And very
likely, my novice would be re-implementation in Rust would _not_ be very
good.)

~~~
steveklabnik
Yes, this is an important distinction about "unsafe" in Rust.
[https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html](https://doc.rust-
lang.org/nomicon/safe-unsafe-meaning.html) is a good starting place for
learning about this.

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

~~~
zozbot234
> wrap it in a Rust interface

You'll need to do this anyway if you want an actual library that can be
independently packaged, because that means you have to use the system ABI in
the library itself. Rust does not provide a stable ABI.

------
HankB99
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?

~~~
FpUser
"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)

~~~
HankB99
Pleased to meet you!

------
mww09
Generating C/C++ bindings in Rust is unfortunately still quite a hassle from
my experience: Often C libraries end up with important functions as static
inline in header files (these do not get translated automatically by bindgen).
If the library uses the macro system to rename functions, these too won't show
up as symbols in your library (so you'd have to manually define those names
too). Then bindgen often pulls in too many dependencies and I end up manually
white/blacklisting what symbols I want/don't want (and track changes through
multiple versions). That being said, it's a hard problem and Rust has still
one of the better toolings for FFI from what I've seen in other languages.

------
kragen
Where are you getting your CHM files? If you're getting them from untrusted
sources — that is, people you wouldn't give your password to — you probably
don't want to pass them to a buggy C library. That's just _begging_ to get
pwned! The only way this seems like a reasonable idea is if your CHM files are
generated by your own software or by something like SafeDocs:
[https://www.darpa.mil/program/safe-
documents](https://www.darpa.mil/program/safe-documents)

Wrapping your buggy C library in Rust isn't going to give you the kind of
security against malicious data that a rewrite in Rust would give you.

------
lubesGordi
Here's another article that is maybe a little more terse about how to write
wrappers for C/C++ libs in Rust.

[https://medium.com/dwelo-r-d/using-c-libraries-in-
rust-13961...](https://medium.com/dwelo-r-d/using-c-libraries-in-
rust-13961948c72a)

------
dmm
> This may be problematic because it’ll require all users of our chmlib crate
> (and their users) to have Autotools installed.

Autoconf creates a portable shell script, right? No need to have it installed
just to build the project.

~~~
steveklabnik
"portable" to different Unices, right? I'm on Windows, for example.

~~~
bluGill
Autotools is rarely portable. I've been doing a lot of cross compiling
recently: the vast majority of autotools projects can't be cross compiled.
Sure autotools itself supports it, but something required to make it work
didn't get connected up and so you can't do it.

If you want to natively compile on a fairly recent linux with the common
standard libraries autotools works well. Even though autotools was written to
work around these differences, in most cases the developer didn't hook into
autotools detecting that difference and so it doesn't work.

~~~
monocasa
Cross compiling to what? Autotools is probably the most portable piece of
software out there as far as Unices are concerned.

~~~
bluGill
Embedded Linux on arm. Nothing very far out really. Note that I'm careful not
to blame autotools, it is the user's fault, there are a couple projects that
use autotools and cross compile easily. The vast majority do not.

CMake based projects almost always cross compile easily.

------
StreamBright
I still have issues with Rust string handling. Half of the time I have no idea
how to get strings out of libraries. I don't understand the intentions of the
language creators at all. Does anybody have a great intro to Rust for software
engineers who come from Python or something similar where high level types are
the norm?

~~~
steveklabnik
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.

~~~
StreamBright
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?

~~~
Keats
As mentioned by others, you need to convert the bytes to a String. `Sha2`
provides a helper function for that: `hasher.result_str()`.

EDIT: sorry I don't know which docs I was looking at, I can't find it in the
current version.

~~~
StreamBright
This is helpful but in general what is a problem of having strings and trivial
functions to convert something (like bytes) to strings? Maybe I am missing the
point.

~~~
steveklabnik
The process of "functions to convert bytes to a string" is called "encoding".
The problem is, there's no universal way to do it, so you need to choose one.
You need to know what the bytes mean, and then convert them into whatever
representation that you need.

It is unfortunate that you’ve been downvoted for asking a question.

~~~
StreamBright
Thank you very much. I am going to read up this because I think I am missing
out on crucial details.

It is unfortunate how HN is nowadays but I don’t care if I can still learn a
lot from people like you.

~~~
steveklabnik
Happy to help. Feel free to post questions on users.rust-lang.org as well;
people are super happy to elaborate on any question, no matter how big or
small.

------
jamil7
Archived link, I think HN knocked over the server:

[https://web.archive.org/web/20191023134247/http://adventures...](https://web.archive.org/web/20191023134247/http://adventures.michaelfbryan.com/posts/how-
not-to-riir/)

------
fmakunbound
> Rust gives you the power to do things which would be unheard of (or just
> plain dangerous) in other languages

What are examples of the unheard of things?

~~~
mmaurizi
Passing around pointers to objects on the stack.

In another language you'd risk having a pointer to invalid memory when the
function returns if the pointer escapes the function, and so it is advised to
use pointers to objects on the stack sparingly if at all.

In rust, the compiler will statically determine if a pointer to an object on
the stack could escape the function, and if so will fail to compile.

~~~
zeroxfe
> In another language you'd risk having a pointer to invalid memory when the
> function returns if the pointer escapes the function, and so it is advised
> to use pointers to objects on the stack sparingly if at all.

Just a nitpick, this is only true for non-garbage-collected (or refcounted)
languages. :-)

~~~
lmkg
Well, if you're gonna nitpick...

A garbage-collected language wouldn't let you allocate such items on the stack
in the first place.

GC languages tend not to let you choose where to allocate in the first place,
and have obligatory heap semantics for reference types. Some compilers
(including Go and Java, to my knowledge) will attempt to optimize the
implementation to stack allocation when possible using escape analysis, but
this is less precise, and more opaque, then Rust's allocation. And you won't
get feedback if it stops working.

So, by GP's comment of "unheard of (or just plain dangerous)", the "unheard-
of" applies to GC languages and "plain dangerous" would apply non-GC
languages.

~~~
pjmlp
Here goes a list from GC enabled languages that let you chose where to
allocate.

Modula-3, Oberon, Oberon-2, Active Oberon, Mesa/Cedar, Component Pascal,
Eiffel, Sing#, System C#, C#, Swift, D, Nim

~~~
ncmncm
I prefer the term "obligate-GC languages": you don't get to choose whether GC
runs. Otherwise, Rust and C++ count as "GC-enabled", and comparisons are
vacuous.

Reference-counting, a form of GC very commonly used in Rust and C++, is
inefficient compared to more intrusive schemes, particularly where there may
be contention for the count, but may be applied selectively, e.g. never on
critical paths, so that the inefficiency has zero impact on overall system
performance.

Obligate-GC advocates like to point at custom benchmarks showing overhead at a
small percentage. They are invariably lying, by reporting only the time that
the profiler says the program counter is pointing to GC code, and hiding the
much-larger results of loss of cache locality on the system as a whole.
Typically they don't even know they are lying, which should not give one much
confidence in their engineering judgment.

~~~
pjmlp
You mean custom benchmarks like Midori powering Bing for Asian requests, the
ixy paper, Android GPGPU debugger, Fuchsia TCP/IP stack, ChromeOS and Google
Cloud sandboxes.

Yep, really lying.

~~~
nickpsecurity
The pre-Cortana version of the speech service ran on Midori, too, with safer
code:

[https://www.reddit.com/r/programming/comments/3t50xg/more_in...](https://www.reddit.com/r/programming/comments/3t50xg/more_information_about_microsofts_oncesecret/)

They admit it wasn't quite full-GC stuff. It was close to the C++. It did use
the language safety and parallelism to its advantage on top of the Midori OS.
They ended up improving performance over the original.

Still worth mentioning even if not fully-GC. I mean, they could've always used
a real-time GC if that was important. There's already commercial and academic
ones. For some reason, these projects never try to do that. I think even those
developing GC'd systems might not know about RT designs.

------
ivoras
> Rust gives you the power to do things which would be unheard of (or just
> plain dangerous) in other languages

Ummm.... any pointers as to what the author is talking about?

------
jchw
> why would you be better equipped to write a library for some domain-specific
> purpose than the original author?

This is how you avoid growing as a programmer.

~~~
xwolfi
But that's how you grow as a software shipper.

Our job is not to program crap again and again, it's to deliver some value for
the high fees we charge. Rewritting a working library to migrate language is
really hard to defend...

~~~
jchw
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 language I love, btw) and even JS had less
naysayers somehow.

You may question the usefulness of having “x but in Rust” and that is fair.
However, people keep answering the reasons why you might do something like
this and yet like amnesia the same bad opinions come out again next time.

— Sincerely, someone who _also_ ships.

~~~
empthought
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.

~~~
jchw
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.

~~~
empthought
Most of the common C dependencies were implemented in Go before its public
release - [https://golang.org/doc/go1](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 edification and no other
purpose, fine -- but half-assed internal implementations of common
functionality are a significant drag on the lives of _other_ working
programmers.

~~~
jchw
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.

------
vast
The linked RIIR post pretty much described 2016 the behaviour of people shown
in this thread. It is hilarious that seeing the arguing for RIIR in this
context.

Rewriting in some language is a matter of skill and preference. To even
consider a rewrite there should be a rational reason, i.e. it is broken or
can't work in the ecosystem.

For fun and learning you can do what you want, of course.

------
gattr
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](https://github.com/GreatAttractor/libskry_r)

------
fouc
I find it interesting that Michael apparently keeps his git-backed projects in
~/Documents/. Does anyone else do this?

~~~
josteink
I think both VSCode and Visual Studio defaults to this if you clone a repo
using the editor GUI.

------
gatherhunterer
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.

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

~~~
cmyr
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."

------
adrusi
The title should be "how to not" rather than "how not to".

~~~
steveklabnik
It really depends on your opinion on split infinitives. Both are correct.

~~~
cannam
Surely "How Not To..." is typically used when you're talking of a bad way to
do something, or a way to fail - so this sounds like it's describing a bad way
to rewrite something in Rust, which is not the case.

It also isn't the wording used in the original article title.

~~~
steveklabnik
> so this sounds like it's describing a bad way to rewrite something in Rust,
> which is not the case.

I think this kind of title is trying to do exactly that, or at least, that's
how I took it.

> It also isn't the wording used in the original article title.

This is a good reason to switch it, for sure. I didn't realize this, if you
had led with that, I wouldn't have said anything :)

~~~
lmkg
> I think this kind of title is trying to do exactly that, or at least, that's
> how I took it

I took the exact opposite: This article is describing an alternative to RiiR,
so that RiiR is avoided when not needed.

~~~
steveklabnik
I don't disagree with you is that the thesis of the article is "don't re-write
something in Rust."

What I was trying to say is that I think the title is making a joke; it's
saying "how to re-write something in Rust badly", because well, it's not re-
writing it in Rust at all.

~~~
aidenn0
I thought the title was making a joke, but then I read the article and IMO the
actual article title of "How to not RiiR" is much more indicative of it's
content than the HN title of "How Not to RiiR"

------
mirekrusin
Oh no, it's not available, maybe you could rewrite your website in rust to
handle the load? ;)

...this is tongue-in-cheek comment. I do agree with the author, "rust rewrite"
alternative of wrapping c library is way better in many cases for well
established or legacy libs. However it depends on the momentum you can bring -
as pure rust implementation for widely used areas can benefit from compiler
grinding through it. I can see rust written low level libraries used across
all high-level languages in the near future.

