Hacker News Reader

Comment by Underqualified | Hacker News Reader

I always felt that if you wanted the same functionality as c++ in terms of performance, flexibility and power of abstraction, you'd end up with something as complex as c++.

Modern c++ shows there was/is room for improvement, but it does not fundamentally simplify the language imo.

View on HN

Only if it need to have backward compatibility. Rust doesn’t so it can be vastly simpler.

How is Rust simpler than C++?

Are you talking about grokking the language and its more excotic concepts or writing code on it?

I have almost 30 years of C++ experience and about 6 months of Rust. My gut feeling is that the languages are equally difficult to understand but that the experience of writing code in them is very different.

I'm sure Rust will have its own set of surprises as I keep using it.

But I can't believe they will be nearly as bad as those that C++ comes with. ;)

Rust is a much smaller language and stdlib than C++ (though still quite large). Rust makes an effort to make many things explicit that are implicit in C++, such as numeric type conversions. Rust's traits are conceptually simpler than classes, especially if you want multiple inheritance. Rust's templates/generics are much closer to the core language than C++'s template language.

And then there are all of the safety features of Rust; while there is a learning curve, it is much easier to learn the concepts of lifetimes and ownership when the compiler is helping to enforce proper usage.

I love Rust. Especially for emudev and embedded development (fields I would traditionally use C or C++). However, it still performs worse than C++ in most cases [1].

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

A number of those C++ benchmarks are "cheating" by using SIMD intrinsics, which was only stabilized in Rust about two weeks ago.

1) Specifically which of those C++ programs? Innuendo is not OK.

2) Even with cheating in scare quotes, name-calling is not OK.

It's not innuendo when you consider the inherent problems with benchmarks. Once you have an algorithm, it's so hard to define what an objective benchmark is that you should assume the implementation is cheating, even if you wrote it.

I say this from personal experience; in one case I was doing timing studies to solve performance problems, and wound up fooling myself by measuring the wrong thing!

In this case, is it fair to use SIMD intrinsics? It depends on what you're trying to measure. I think that's why "cheating" is in scare quotes, because what would be cheating in one context might be useful information in another.

For instance, if C++ is providing SIMD intrinsics, it's going to beat other languages, and if I just want current performance statistics, that's the question I want to answer.

If the question is, "what's the overall quality of the code delivered by the compiler / optimizer" then using specific tricks doesn't give me a good answer.

> …when you consider the inherent problems with benchmarks…

dralley's comment does not do that.

There's nothing difficult here: simply say that those X of N leading C++ programs use SIMD intrinsics, when the corresponding Rust programs do not.

dralley might even say that SIMD intrinsics have been available in Rust nightly for years.

dralley might even say that someone has contributed a Rust program that does use SIMD intrinsics, but that program was slower than other Rust programs:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Perhaps if C++ [or Rust] is providing SIMD intrinsics that is not in-itself a magical silver bullet.

Reply on news.ycombinator.com