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

51–60 of 79 posts

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

#51

Post by mamcx »

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…

I agree. I made rewrites all the time (and from lang to lang, to architecture to another). Rewrites are a net plus for me.

What is important is that $new_lang or $new_arch MUST help to cut in big ways problems and/or code.

To say something minimal, Rust eliminate (except when interfacing with $old) NULLs. Also, pattern matching make a lot of problems go away, FOREVER.

This mean, that is like have another developer also helping in cut work and at the same time increase quality.

This is not limited to compilers. For example, I work for business apps and use RDBMS a lot. Use a RDBMS well? It cut work and increase quality.

Rewriting queries, schemas and using indexes, views and ANY trick the RDBMS allow you (the idea "not use a DB at full because 'data independence' is poison if not VERY well justified) help by spades.

So:

- Naive rewriting = VERY BAD

- Move from $old to $new WITHOUT the help of a "improved" architecture, feature, tooling or concept = WASTED

- Move from $old to $new with better? TOTAL WIN.

P.D: I think move from too similar Langs probably will waste stuff. You see much more bang from your buck when move from imperative to functional, than from imperative to imperative. Not because functional is superior, but because it force to bring power (use of inmutable and algebraic types, for example) that before was dependent on discipline...

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

#52

Post by carlmr »

steveklabnik wrote: post #12
Leace wrote: post #11

Earlier quoted context omitted.

Rust may hopefully get better autocompletions if they work on their Language Server implementation. C# compiler was explicitly rewritten so that it is IDE friendly and I fully agree with this decision. That said even good, old Java has excellent tooling support that I do miss from all these hip languages (such as Rust).

The compiler team is planning on following in C#’s footsteps with the rust-analyzer project.

I can only recommend trying it out. It works comparatively well. The problem with RLS is that it always needs working code to compile in between and it always loses state. I think it's a design issue at the core of RLS. rust-analyzer does this a lot better and faster, but is still in an early stage.

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

#53

Post by maxxxxx »

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

They should do string interpolation like C# since C# 5. Really easy to use, type safe and avoids a lot of mistakes.

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

#54

Post by phkahler »

hu3 wrote: post #18

"rewrite in X" request is a comon sign of immaturity. I'm guilty of it but eventually I learned that A) rewrites are rarely worth it B) it's disrespectful to ask others to scrap their code and rewrite it in my favorite language

One of my favorite apps at the moment seems like it could benefit from a rewrite, in part because core pieces have long standing bugs that may only be solved by someone doing the very deep dive a rewrite would entail. I thought long term it might be nice if it were written in Rust. But rather than suggest RIIR I considered writing a component of it in Rust myself. That would be educational for me and would bring something new to the "Rust ecosystem". Having written similar code before (in C++) I realized just how huge a task rewriting just a core component would be. It could take a decade or more to rewrite an entire program in any language even with all devs working on it.

Look at Servo. Hey, they started building a browser in Rust! And some of those components are useful in Firefox. But Servo itself might never become a fully functional browser. And that's a project from the folks that created Rust and Firefox. So maybe a response to RIIR could be "Yeah, when is Servo going to be done?"

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

#55

Post by lmm »

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.

IMO the fully general version of that is too flexible to be maintainable; it's better to have more constrained/standardised functionality that lets you solve the problems you'd need it for. Generally there are two kinds of things that you would want to be doing at compile time: producing code to handle the fields of a structure in a generic way (which you can do with frunk), or producing delegating wrappers to handle cross-cutting concerns (which you can do up to a point via the combination of built in delegation and first-class functions, though the lack of HKT does make some cases impossible).

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

#58

Post by forty »

Everyone seems to act like the only option is to rewrite everything or nothing. Isn't possible to have rust and C talk to each other, and progressively rewrite the most relevant parts of the code in rust?

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

#59

Post by vbezhenar »

steveklabnik wrote: post #48
vbezhenar wrote: post #44

Earlier quoted context omitted.

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)

Thanks, that's similar, also I would argue that for inexperienced developer just producing desired text would be a simpler solution (but dangerous).

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

#60

Post by jsymolon »

geodel wrote: post #33
cp9 wrote: post #16

a reminder that "rewrite it in rust" is not usually a ground up rewrite, it's an effort to translate the c into a safer language as you go, it doesn't just burn it down, salt the earth and start over. Have a look at remacs [1] to see how this works in practice. 1: https://github.com/remacs/remacs

And it will all be well taken if RIIR folks show things they have done themselves instead of telling others what they need to do.

Exactly, stop evangelizing and start doing.
Post reply on HN