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

Why Not Rewrite It in Rust? (2016)

transitiontech.ca

Post reply on HN
Print view View original

41–50 of 79 posts

Re: Why Not Rewrite It in Rust? (2016)

#41

Post by [deleted] »

steveklabnik wrote: post #25
_bxg1 wrote: post #24

Earlier quoted context omitted.

Tor is probably one of the better cases because of its stringent security requirements, but there remains an oft-ignored tradeoff of losing all that refinement work (and the fact that you can't just flip a switch to make it happen). It's a cost/benefit decision.

Totally; that's why it's not a wholesale re-write, it's slowly replacing old code bit by bit, or writing new code. Which is the only real way to migrate any codebase of significant size to a new language.

[deleted]

Re: Why Not Rewrite It in Rust? (2016)

#42

Post by dmix »

maeln wrote: post #13

There will always be inexperienced people who just learned about "cool language X" and go on a crusade everywhere they go about why Y is not written in X with obvious disregard on how difficult (and often useless?) rewriting a whole project is. I remember seeing a post on a Qt mailing list asking if there were plan to rewrite Qt in Erlang. At least it usually come from a good place and they tend to be polite about it…

Qt in Erlang is a good one.

Re: Why Not Rewrite It in Rust? (2016)

#43

Post by k__ »

jasonhansel wrote: post #31

My humble opinion: it is almost never worth rewriting a large codebase in a new language. The only exceptions are if (a) the old language is so old that it lacks an active community and is no longer being improved, or if (b) the old system needs so many changes that you might as well rewrite it anyway.

It's not worth rewriting it until someone does and somehow manages to steal your customers with it.

Re: Why Not Rewrite It in Rust? (2016)

#44

Post by vbezhenar »

lmm wrote: post #34
skocznymroczny wrote: post #2

As a D user, I am looking at Rust with curiosity, but haven't yet seen any reasons that would make me switch.

Sum types (and therefore a nice way to do e.g. validation or error handling). A better OO model (particularly when it comes to secondary concerns like serialization or comparison). Safe scoped resource management (with memory-safety without GC as a secondary benefit). A more standard/better-understood way of doing what D calls "compile-time reflection" (if I understand what D's doing there correctly).

Can you produce a string via compile-time functions and compile that string as a Rust fragment? That was incredibly flexible tool in D. The only thing that comes close is Lisp macroses.

Re: Why Not Rewrite It in Rust? (2016)

#45

Post by Covzire »

steveklabnik wrote: post #32
Covzire wrote: post #30

Earlier quoted context omitted.

The frustrating part was concatenation, it was surprisingly annoying to combine a few strings and an int into a single string.

The fastest and easiest way is to use format!. let cat = format!("{}{}{}", s1, s2, n);

That doesn't seem too bad (Though it's still no C# with the + operator), I'll check that out next time I'm in the Rust neighborhood. Thanks.

Re: Why Not Rewrite It in Rust? (2016)

#46

Post by steveklabnik »

Covzire wrote: post #45
steveklabnik wrote: post #32

Earlier quoted context omitted.

The fastest and easiest way is to use format!. let cat = format!("{}{}{}", s1, s2, n);

That doesn't seem too bad (Though it's still no C# with the + operator), I'll check that out next time I'm in the Rust neighborhood. Thanks.

No problem!

I personally only tend to use + when there's two or maybe three things at most, in any language, and then switch to an API like this if it exists for more complex things, no matter the language. I find it much easier to read. YMMV.

(And you can use + in Rust, but you'd have to call .to_string() on the integer first)

Re: Why Not Rewrite It in Rust? (2016)

#47

Post by nerdponx »

mrkeen wrote: post #39

I have some toy search technology (indexer and query processor). I started in C and did a series of rewrites, learning and changing something significant each time. On version 6 I switched to Rust (having only just started learning the language) and it feels pretty unlikely I'd switch back. The rookie mistake isn't to want a rewrite. It's to ridicule something you haven't tried in earnest.

Nobody is ridiculing Rust. They are ridiculing flippant requests by non-contributors to rewrite non-trivial software in another language.

Re: Why Not Rewrite It in Rust? (2016)

#48

Post by steveklabnik »

vbezhenar wrote: post #44
lmm wrote: post #34

Earlier quoted context omitted.

Sum types (and therefore a nice way to do e.g. validation or error handling). A better OO model (particularly when it comes to secondary concerns like serialization or comparison). Safe scoped resource management (with memory-safety without GC as a secondary benefit). A more standard/better-understood way of doing what D calls "compile-time reflection" (if I understand what D's doing there correctly).

Can you produce a string via compile-time functions and compile that string as a Rust fragment? That was incredibly flexible tool in D. The only thing that comes close is Lisp macroses.

Procedural macros take a list of tokens, and you give a list of tokens back, and they're then compiled.

https://doc.rust-lang.org/stable/book/ch19-06-macros.html#ho... (starts with derive, then moves on to attributes. Function-like ones aren't stable yet)

Re: Why Not Rewrite It in Rust? (2016)

#49

Post by carlmr »

lmm wrote: post #35
_bxg1 wrote: post #19

Earlier quoted context omitted.

Programmers, especially naive ones, tend to think asymptotically. We focus on what would be the most theoretically ideal and write off pithy concerns like "time" and "effort" as implementation details. I'm guilty of this myself. Rust is this unusual situation where a new language is in many ways a strict improvement over a very widely-used preexisting language. That is extremely rare. So I think that's where the reli…

> those projects also benefit from decades of refinement and bug fixes. Rewriting them means losing all of that. Not my experience at all, having spent a significant chunk of my career doing rewrites for scalability. Having the existing codebase makes it very easy to benefit from the accumulated knowledge, while at the same time doing a pass through that can catch a lot of outright errors. If you can rewrite a projec…

My experience as well. The key point here is the incremental part. This works especially well if you're adding regression tests incrementally as well. This necessitates a certain modularity & testability in the legacy project though, which often isn't the case. There's a certain threshold in technical debt (depending on the size of the project), at which point a complete rewrite may be better.

For most of the other projects Working Effectively With Legacy Code by Michael Feathers contains a good approach for slowly modularizing and testing the system, before exchanging parts.

Post reply on HN