Hacker News Reader

Comment by ncmncm | Hacker News Reader

Won't make them slower, anyway.

There are often performance bottlenecks you didn't know about, and had blamed on database (or whatever) interaction overhead. It will never feel worthwhile to dig into each candidate, because any payback seems too unlikely. Not having left scope for such bottlenecks means you can be confident they are not there. Re-implementing once is a lot less work than diving into each possible bottleneck. Improving your actual database operations, after, is more likely to have an effect when some other bottleneck doesn't mask the improvement.

You don't have to do it in Rust. Any optimization you could do in Rust is probably easier in C++, and also easier to find maintainers for.

View on HN

> Any optimization you could do in Rust is probably easier in C++, and also easier to find maintainers for.

At least the first part is not necessarily true. E.g., in C++, you might make defensive copies, whereas in Rust the lifetime system will track things for you.

Thus, "probably".

"Any optimization you could do in Rust is probably easier in C++"

I think this feeling comes from the fact that it takes longer to learn the basics of Rust compared to C++.

However, once one has learned C++ or Rust to a reasonable level, I would argue that Rust is actually easier to use.

This is not the same thing but many people make this claim.

Each is easier than the other, depending on where you look and where you come from.

But it is a fair bet that changes to C++ code to implement a point performance optimization will be smaller than the same sort of change would be for Rust code. For the latter, you are likely to need to re-architect that part of the system some to get your optimization and still satisfy the borrow checker. Having a borrow checker that demands satisfaction is a virtue, but there is no denying it adds cost in the small, where we're talking about, notwithstanding that such cost may be paid back at the system level.

> it takes longer to learn the basics of Rust compared to C++.

Does it really? For example I'd think that initialization of objects is a topic that should be in "basics", yet initialization of objects in C++ seems disproportionately complex compared to Rust (at least to me).

Yet, object initialization is not a thing anyone needs to pay much attention to. Yes, there are historical rabbit holes, but you need not go down them.

> object initialization is not a thing anyone needs to pay much attention to

So it's perfectly fine for me to leave objects uninitialized because of lack of attention?

It's perfectly fine to initialize them in the simplest and most obvious way.

> Any optimization you could do in Rust is probably easier in C++

That's kind of funny in light of the history that certain optimizations in web layout engines were attempted, unsuccessfully, in C++ multiple times and ultimately they invented Rust to make them easier.

That is how the marketing goes, anyway.

The facts on the ground probably have more to do with improvements to the C++ code being obliged work as deltas against existing C++ code, where the Rust code was a complete re-implementation, thus not constrained.

Both C++ and Rust are today different languages from when that project ran.

Another subtle consideration is that with long-lived, highly-backward-compatible languages like C++, you'll have a bunch of people on your project who still write C++ like it was ten or twenty years ago (because that's when they learned it), and so bring down the code quality of your project. Whereas choosing a new language (like Rust at the time) means that everyone who claims to be able to write it at all, is working from the same, recent set of language idioms.

Reply on news.ycombinator.com