Hacker News Reader

Comment by mbrodersen | Hacker News Reader

I wonder how much of the benefits comes from the rewrite itself and not Rust. I have taken really bad hard to maintain very large code bases written in C++ and step-by-step refactored it into bug free maintainable code. In my experience bad code written in any language is hard to maintain. And good code written in any language is easy to maintain. I have worked with C code that was a joy to maintain and C code that was hell on earth. The difference was the skill of the original developers not the C language itself. Rust is a nice step forward but it is not magic. If it becomes popular enough then people will write massive impossible to maintain code in it. It is inevitable. The same goes for microservices BTW. A friend of mine is deep in coding hell trying to maintain a 20 years old 100+ microservices system. There ain’t no silver bullet.

View on HN

Original rust-minidump author here: I started out by doing a pretty straightforward port of Breakpad into Rust, which I had just started learning at the time. I figured that learning a new language by porting a codebase I was intimately familiar with for a content area that I knew extremely well would make it so only the new language was the hard part. (It worked out well!) I did try to make the API more idiomatic Rust in places, since there are parts of Breakpad's API that are fairly C++-centric. I was also using Rust 1.0 originally, so it didn't quite have all the niceties available in the current Rust release.

All that being said, I would choose Rust over C++ for any new development anywhere. If my boss told me we had to use C++ for a new project I would actually quit. I've worked on plenty of C++ codebases (including Firefox) in my career. Sure, you can write bad code in any language, but C and C++ are just bad languages.

(I also ported Mozilla's sccache tool from the original Python implementation to Rust, which was a fun exercise. The Rust version is in production use in a wide variety of places, and AFAIK is still the only ccache-like tool that can cache Rust compilation.)

> Sure, you can write bad code in any language, but C and C++ are just bad languages.

Let's give them credit for what we've achieved using them. I would definitely pick Rust over C++ any time, I respect C++ for all the cool things it gave us.

If they are bad languages then you should give most of the credit to the programmers that were using them.

I wish I could upvote this more than once :) The unsung heroes out there are the developers who takes over a garbage dump of a system and turn it around. That is way harder than writing a system from scratch.

Yep makes sense. My point was that the developers matter more than the language. However you are absolutely right that good developers with a better language will do better.

There are entire classes of bugs that cannot happen in (safe) Rust that can still happen in a “bug free” C++ code based. You’re correct that Rust isn’t a panacea, but it does eliminate certain concerns that C++ just can not remove from thought while developing with it.

The great thing about Rust is that it reduces the knowledge and skill a developer needs in order to write a stable and (usually) performant program. This is a good thing.

Unsafe Rust is inevitable to write in any real-world program that needs {O(log n) insertion-ordered collections instead of key-ordered like BTreeMap, intrusive collections, custom lock-free data structures, or non-tree-shaped object graphs where you cannot spare the performance, static analysis, and ergonomic penalty of RefCell and Cell doesn't work out}, and working with aliasing pointers is so difficult (a representative example is https://github.com/Storyyeller/stable_deref_trait/issues/15) that I'd rather write C++ than unsafe Rust.

You’re mixing up two different categories of development. There are plenty of libraries that provide safe BtreeMaps and lock-free data structures. These can isolate all unsafe code in their own crate and only expose safe APIs.

Programs on the other hand can be written in entirely safe Rust, and the vast majority of Rust developers never need to use unsafe Rust to do this.

In Rust, we try to isolate unsafe usage and test it excessively. In C++ you have no such option.

So far I have found no Rust insertion-ordered collections which supports removing items without scrambling items (necessary for editing a key-value INI file) with O(log n) reads/writes, though you can use a vector with O(n) accesses which takes O(n^2) to lookup every key, which is probably good enough in most cases.

And non-tree-shaped object graphs are not a library concern, but permeate entire applications; if you want to rewrite an app using shared mutability in Rust, you must either write code awkwardly with Cell/RefCell (and RefCell has runtime overhead), restructure the whole program in one Big Rewrite, or fallback to unsafe accesses (at this point, outside of multithreading C++ is a better Unsafe Rust than Unsafe Rust).

Please respond with a factual rebuttal before downvoting.

It seems that indexmap would fit your bill:

Repo: https://github.com/bluss/indexmap

IndexMap type itself: https://docs.rs/indexmap/latest/indexmap/map/struct.IndexMap...

It has amortized O(1) reads and writes, and it supports removal without maintaining order in O(1), or while maintaining order in O(n).

I was not initially aware of O(n) order-preserving shift_remove[...](). Although likely not a problem in practice, removing a large number of items one by one (eg. when a user is deleting a selection containing many file associations) can result in quadratic behavior. I found that you can avoid that by calling retain() (at the cost of being a higher-order function) to keep/remove every item in the list in a single pass (linear time is fast enough for INI files). So in retrospect IndexMap would be a workable choice, if used carefully.

There are entire classes of bugs that cannot happen in (safe) Java/Erlang/Scheme/etc. that can still happen in a "bug free" Rust code base.

Like? I know that you’re trolling, but looking at Java specifically, the error handling in Rust and RAII pattern in Rust ensures that things like file handles are cleaned up. Modern Java has made this nicer, but it still offers a lot of potential bugs around resource leaks.

Sticking with Java, Rust also offers a better story around thread safety, such that sharing mutable state across threads requires types that allow that to work.

Finally, Java’s exception handling and null usage generally allows a lot of low hanging fruit bugs to slip through where in Rust these types of errors are far less likely to happen.

I never said Rust is “bug free”, I’ve been working with software far to long to make such a provably wrong statement.

I completely agree with you. Rust seems to be a good step forward.

Reply on news.ycombinator.com