[bluejekyll]

This is exactly my experience with Rust as well, people keep thinking C++ is an alternative to Rust with all the same features, but it’s not true. Rust is in many ways a simpler language than C++ and that can make it more productive, “To Kamp's assertion that developers should just use C++, Somers said that he was far more productive in Rust and his code had fewer bugs, too. He said he had used C++ professionally for 11 years, but was more skilled in Rust after six months. The problem, he said, was C++.”

[dvhh]

The point was also probably that there is already a C++ compiler in the base, vs adding new headaches for adding and maintaining a rust toolchain in the base.

[tialaramex]

But that's an interesting point. Why is there a C++ compiler in the base? Do I find a long discussion on the FreeBSD list about whether it should have a C++ compiler? If not, why not?

[BSDobelix]

Because the System has to be self-hosting, remember it's a whole OS and not just the Kernel, and as you can see ~25% of src is C++, 62% C etc.

Rewrite everything C++ is not a small undertaking with (maybe?) not allot plus-sides, and even then you still need C++ because of LLVM. LLVM and GCC are both C++, and you have to compile the Compiler (self-hosting), and even if your a 100% Rust or C OS, you still need C++ because of LLVM/GCC....well if you want a modern compiler ;)

https://github.com/freebsd/freebsd-src

[tialaramex]

But when you look what all that C++ is doing in Base, it seems like it's basically LLVM and then a lot of code that's just there to help you write more C++ code. Not a whole lot of the FreeBSD Base userspace, the uilities and so on - is actually written in C++ despite that. It's getting a free ride because the compiler uses it.

[BSDobelix]

>it seems like it's basically LLVM

Not important, you have to compile your Compiler fini, btw for Linux (just the Kernel) you need Perl ;)

[dvhh]

Because most C compilers also include a C++ compiler, or that the compiler toolchain of choice for freeBSD happens to be LLVM (it was an old version of GCC before because newer version use an incompatible license, and before that I think gcc replaced pcc in the original bsd unix, the discussion to pcc with gcc is probably lost in time) that includes C and C++ compiler.

I am guessing that performance of current standalone C compiler is not as good as the one produced by compiler suit.

Following the conversation thread, rust also use llvm under the hood, but a customized one. Which would force the base system to have two versions of llvm.

[steveklabnik]

It’s easy to build Rust with a stock llvm. You may just lose out on some back ported bugs that were patched in the fork the rust team maintains.

[andrewstuart]

>> "in many ways"

These words are doing a lot of work.

[woodruffw]

I think it’s accurate to say that Rust’s syntax and semantics are both simpler than those of modern C++. That isn’t to say that Rust is a simple language (it manifestly isn’t), only that being simpler than C++ is not a hard bar to clear.

(The proxy I use for this is the ratio of years spent programming to insane acronyms known. C++ has given me SFINAE, CTAD, SIOF, etc. so far, while Rust has only given me RPIT.)

[stingraycharles]

Don’t forget RAII and CRTP (Curiously Recurring Template Pattern).

As someone who has extensive experience in C++, Haskell, and Rust, I can confidently say that none of them is simple, it’s just that C++ has a mountain of legacy / technical debt that Rust has to deal with. If C++ were to be invented today, it would look a lot more like Rust.

[lifthrasiir]

> If C++ were to be invented today, it would look a lot more like Rust.

I'm not sure about this, because the world without C++ would have been quite different from today. The main complication comes from the fact that C++ was considered a much higher-level language than today, so its absence would have made other alternatives evolve differently.

[tialaramex]

To be fair RPIT is part of a family, but they're actually just a weird way to name a variety of features that it made sense to give similar syntax in Rust. "IT" in RPIT means "impl Trait" the syntax, but what that syntax does varies by position (the P).

https://www.youtube.com/watch?v=CWiz_RtA1Hw

Return Position Impl Trait is Existential Types, but Argument Position Impl Trait is just a simpler syntax for some Generics, same syntax, different meaning. This is actually one of the places where Rust is probably easier to pick up in use than to understand in theory. APIT and RPIT both "feel" right, but in type theory these are radically different features.

In that way it's like some natural languages, native English speakers don't notice a bunch of the grammar rules they learned as kids, those rules just "feel" right and not formally taught.

[recursivecaveat]

Don't forget the illustrious PPYP: pre-pooping your pants (:

[raybb]

Link for those who also would have to look it up https://cglab.ca/~abeinges/blah/everyone-poops/

[blub]

“Simpler” is so fuzzy that it doesn’t accurately express what’s going on. Rust doesn’t have the backwards compat baggage that C++ has, so it’s simpler.

However, I can today easily write clean C++ that’s easy to understand, and using containers, algos and smart pointers is also robust. This is what the C++ community has settled on, while pushing complexity into libraries.

The Rust community has settled on async, moves and references (with the lovely lifetime annotations) and other cognitive overhead, because they think that getting errors at compile time offsets all the mental overhead of those constructs. Then they gaslight all the beginners which complain about that mental overhead.

So in theory Rust may be simpler, but idiomatic Rust isn’t. It’s differently complex.

[vlovich123]

C++ has exactly the same async mechanism as Rust. Moves and references are much simpler in Rust - values only ever move and copies require an explicit clone unless the type is copyable in which case the compiler will implicitly clone if there’s conflicting ownership in the code.

This is orders of magnitude simpler than c++ overloading of copy/move assignment and constructors, even when you follow the rule of 0 (not least of which is that you don’t to teach people about it or how to keep code exception safe).

It’s kind of amusing to claim that c++ is simpler than Rust when it’s demonstrably not true - a new person to Rust is more productive after 6 months than a person new to c++. That implies the bar to getting proficient is low. A person can reach intermediate more quickly implying the bar to the next levels is lower. And it’s easier to maintain a rust project due to cargo meaning a usable easy build system out of the box that the entire community uses vs opinionated choices each project has to do, and macros that are easier to manage than preprocesser mess. So easier to maintain and easier to jump into any project. Oh and tests and mictobenchmarks out of the box and a very rich ecosystem of supporting libraries.

Idiomatic rust is simpler than idiomatic c++ and it’s clearer what constitutes idiomatic rust whereas c++ in practice is rarely idiomatic and there are going to be conflicting ideas on what is idiomatic.

This is ignoring the very real benefits of rarely to never dealing with a whole class of difficult to debug bugs (threading and memory safety) in the vast majority of code you’ll write .

[blub]

Only in Rust is the async use idiomatic, the C++ co_* is pretty new and not yet ready for prime time.

References are not at all simpler, they're memory-safe, which in conjunction with lifetimes makes them significantly more complex to understand and write. This is a known problem... In C++ I copy by default and move if I want to optimise. Moves also happen behind the scenes as an optimisation, this is how things should be, don't push the work on the programmer!

I don't agree with your claim that a new person to Rust is more productive. What's that based on? In my experience, a new person to Rust will write memory-safe code by default, which is good, but they pay the cost of Rust's lack of ergonomics forever. See https://news.ycombinator.com/item?id=40172033 which covers async, refactoring and design issues that plague even experienced programmers.

> Idiomatic rust is simpler than idiomatic c++ and it’s clearer what constitutes idiomatic rust whereas c++ in practice is rarely idiomatic and there are going to be conflicting ideas on what is idiomatic.

It's really not, because C++ copies by default which is typically both memory-safe and very easy. If using smart pointers and clone was idiomatic in Rust, you'd have a point, instead references and lifetimes are idiomatic.

Modern C++ has a pretty clear definition, albeit it's evolving as new things are added to the standard. C++ is moving too fast recently, but then again so is Rust.

> This is ignoring the very real benefits of rarely to never dealing with a whole class of difficult to debug bugs (threading and memory safety) in the vast majority of code you’ll write .

That, cargo and lack of historical baggage are the only real benefits of Rust compared to C++. The lack of ergonomics, slow compile times and to some extent the aggressive community make it far from a clear choice.

[penguin_booze]

> C++ has exactly the same async mechanism as Rust

Is this true? I ask because I've seen it mentioned that a C++ co_await suspends that call frame alone (thus the call returns to the caller and resumes immediately), where as Rust's .await suspends the entire call stack (all frames up to and including the caller). If true, in what sense are these mechanisms same?

[vlovich123]

Not the mechanism itself but the same in the context of this statement:

> The Rust community has settled on async, moves and references (with the lovely lifetime annotations) and other cognitive overhead

The rust community has settled on async in the same way that the C++ has - it's an optional keyword that is some syntactic sugar over compiler-generated stuff. The main unique "cognitive overhead" is that Rust forces you to write down lifetimes when they can't be inferred, but the rest is the same or worse in C++.

As for the async mechanism, I don't believe there's magic in Rust that suspends the entire call stack. It walks up the stack the same as in C++. If you don't await an async function call or one returning a future, then there's no suspension and the inner function is executed until the first suspension point if I recall correctly same as in C++. There's nuances in differences but at a high level they're very similar in that it's generating a state machine and nothing more; Rust does require a runtime whereas C++ can do without since the Rust picked generic futures that work on all runtimes whereas in C++ you have to have the runtime provide the future implementation (or have the future not be part of any runtime).

[lifthrasiir]

I have written and worked with a sizable C++ code base multiple times in my past career and I can't really agree.

> Rust doesn’t have the backwards compat baggage that C++ has, so it’s simpler.

C++'s "compat baggage" is mostly self-imposed, because it didn't have any working isolation system (including module systems) for a very long time, and the current C++ module system is still not fully isolating.

> [T]hey think that getting errors at compile time offsets all the mental overhead of those constructs.

This complaint might be true for some (but not all) people, but even in that case Rust will give a full memory safety (with some specific but reasonable definition). You can always use other languages if you don't find the memory safety that important---after all, there are many other axes of safety to consider and balance. But if you do need the memory safety for many good reasons, Rust is definitely a better language than C++ to achieve that.

Also C++ might be forgiving, but it takes much time to learn C++ to avoid many pitfalls and yet I regularly got tripped up by things that I do know but didn't have in mind at the time. I hate the "modern C++" argument; such argument is only reasonable when you are forbidden to write any legacy code without explicitly overloading. (Again, C++ has no real isolation to allow such mode switching.)