How to not rewrite it in Rust • Hacker News Board

Re: How to not rewrite it in Rust

#71

Post by epage » Wed, Oct 23, 2019, 3:25 PM UTC

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…

Another reason I'd prefer things to be rewritten in Rust rather than using bindings is that calling out to external build systems introduces its own set of problems. I've run into the most problems with C-based dependencies (slower builds, OOM errors, confusion over static vs dynamic linking, etc) than any pure-Rust dependency.

Re: How to not rewrite it in Rust

#72

Post by monocasa » Wed, Oct 23, 2019, 3:27 PM UTC

bluGill wrote: post #48

steveklabnik wrote: post #7

Earlier quoted context omitted.

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

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

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

Re: How to not rewrite it in Rust

#73

Post by xwolfi » Wed, Oct 23, 2019, 3:32 PM UTC

jchw wrote: post #51

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

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

Re: How to not rewrite it in Rust

#74

Post by adrianmonk » Wed, Oct 23, 2019, 3:35 PM UTC

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

Re: How to not rewrite it in Rust

#75

Post by skrebbel » Wed, Oct 23, 2019, 3:40 PM UTC

xwolfi wrote: post #69

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

My life as an immigrant developer, therefore cheaper, hired to fix the shit of the elite quitters :D Sometime I catch them a few weeks before they quit and I get to ask why they developed a low level http server in java interpreting controller code written in javascript that nobody understand but them. "It's much more efficient than using php or nodejs or higher level java" "you benchmarked ?" "I have to go do more k…

I really like the phrase "elite quitters".

I wonder if, as a stereotype, it's unique to the software industry.

Re: How to not rewrite it in Rust

#76

Post by steveklabnik » Wed, Oct 23, 2019, 3:40 PM UTC

StreamBright wrote: post #44

Keats wrote: post #36

Earlier quoted context omitted.

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.

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.

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.

Re: How to not rewrite it in Rust

#77

Post by gatherhunterer » Wed, Oct 23, 2019, 3:44 PM UTC

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.

Re: How to not rewrite it in Rust

#78

Post by jchw » Wed, Oct 23, 2019, 3:45 PM UTC

xwolfi wrote: post #73

jchw wrote: post #51

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

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

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.

Re: How to not rewrite it in Rust

#79

Post by bernawil » Wed, Oct 23, 2019, 3:46 PM UTC

madmax96 wrote: post #40

mmaurizi wrote: post #19

Earlier quoted context omitted.

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.

>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 going going to share it between threads. Or whatever.

Re: How to not rewrite it in Rust

#80

Post by ncmncm » Wed, Oct 23, 2019, 3:47 PM UTC

pjmlp wrote: post #64

lmkg wrote: post #26

Earlier quoted context omitted.

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

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

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.