Hacker News Reader

Comment by nindalf | Hacker News Reader

Fish 4.0: The Fish Of Theseus (https://fishshell.com/blog/rustport/) is the full story of their rewrite from C++ to Rust.

Discussed on HN here - https://news.ycombinator.com/item?id=42535217 (906 points, 198 comments).

Highlights of the rewrite

- 1155 files changed, 110247 insertions(+), 88941 deletions(-) (excluding translations)

- 2604 commits by over 200 authors

- 498 issues

- Almost 2 years of work

- 57K Lines of C++ to 75K Lines of Rust 5 (plus 400 lines of C 6)

- C++–

View on HN

I'm surprised Rust took more lines. Perhaps formatter makes shorter lines due to method chaining? Or improved test suite?

Rust, IMO is a noisy language. So not surprising it took more lines.

Having to handle every case of every branch also probably balloons line count.

Efficient LOC is not a goal of rust at all anyway.

Efficient LOC shouldn't be a goal or metric anyway, readability trumps conciseness... except when conciseness improves readability.

Agreed. I would rather be forced to explicitly cover all match cases than accidentally run into problems that are hard to debug.

Exactly. I wish all languages implemented things like this, a bit more strictness (such as requiring all possible match cases to be handled across a set of inputs) goes a long way

Not all though. I am currently writing my own Lisp dialect, and as much as I wish and hope I will be able to force case/switch to be exhaustive, I don't see a direct way for that in a dynamically typed version.

I do plan to add something similar to Clojure's spec though, so the compiler can at least be advised about things and warning if stuff is missing.

But I do agree, any statically typed language should have that check and not just warn about it. It should be a hard error, no questions asked. And I love that Rust didn't relegate it to a warning that could be turned be into an error.

If conciseness improves readability then doesn't readability still win?

So is C++ though. But the "wasteful" (in terms of vertical space) formatting does indeed explain the difference.

Rust code defenitely takes more space with default formatter settings if you use functional paradigms. Every chained function call in many cases is one extra line. Default line width is not much anyway. Also if you handle all return types, lines will add up.

Since there are quite many contributors, it can be difficult to introduce some advanced macro requirements for the project, which could reduce the code.

According to the blog post (https://fishshell.com/blog/rustport/#fn:formatting):

> A lot of the increase in line count can be explained by rustfmt’s formatting, as it likes to spread code out over multiple lines [...] The rest is additional features. Also note that our Rust code is in some places a straight translation of the C++, and fully idiomatic Rust might be shorter.

Not surprising to me. While learning Rust, I rewrote in Rust several existing programs I had written in C++ and all of them were longer with default formatting.

First experiences with QEMU suggest ~10% more lines of code.

Beyond what others have said about superficial things like laying out code differently, remember that Rust encodes memory-safety-related information in types, function signatures etc that might not exist at all in a C/C++ "we hope you do it right, or it's UB" codebase.

Also, here's a code size tracker that counts tokens not lines, which is a better measure: https://github.com/rrethy/tcount

Reply on news.ycombinator.com