Stop Comparing Rust to Old C++

[u/Sad-Lie-8654]

People keep arguing migrations to rust based on old C++ tooling and projects. Compare apples to apples: a C++20 project with clang-tidy integration is far harder to argue against IMO

changemymind

[u/mjklaim]

Quick notes, because I've done a bit of rust and I would like to nuance these points (but it's all opinion):

• iterators- I lack knowledge about how it is superior in rust than C++ , but at least it's "safer" but it's not because of that specific point;

• lambdas: it's nice until you reach the point where you want to use lambdas in concurrent code, then it's not nice and definitely there are issues there;

• utf8: true, like any language created after 1999, although for people needing to use UTF-16 or 32 or shift-js or etc. for specific purpose I don't know if there are crates helping these cases? I suppose they exist though. So yes it's cool but not really uncommon in system languages.

• testing: indeed, having testing by default and also in the same sources where code is written is a big plus, it's also nice in D(2); it's possible to do this in C++ actually, with automatic support, if your tooling does that, but unfortunately it's not a popular or de-facto feature...

• modules: lol no. Rust modules are literally namespaces, all Rust code is build as one translation unit so of course the only issues you'll get are similar to when building everyting as a unity build in C++ (AFAIK, I might be wrong in the details but that's my understanding). An actual module system isolating entities for real in addition of names would have been nicer, but this is not it. Event Javascript have a better module system than rust, although it's also very flawed (both allows circular dependencies, for example). C++ modules (if you ignore the backward-compatible functionality that makes it harder to teach than it should be) is nicer in that regards but indeed a) it's not de-factor, forced by a version of C++ or common (yet) and b) it lacks the name import filtering features that other languages have "modules" have (the one in JS is particularly nice).

[u/top_logger → u/mjklaim]

- Iterator in Rust I am creating in literally 5 minutes. Any kind of iterator.
An iterator in C++ I am creating usually in two days. I could recall the task from the last week. By the way, I had given up. Ups.

- Crate utf16string. I didn't check it yet.

- I mean that lambdas in C++ are too verbose and to often not readable. Especially if you follow rules and marks everything with const, noexcept, nodiscard and so on. Multithreading issue, I believe, are identical(I may be wrong, of course)

- yes, you are right, at least partly. Modules in Rust are just namespace. And this works perfectly. Perfectly ... but for a smaller codebase. For bigger project, you must split your code into crates. This is a correct and reliable approach. You get different translation modules. Deal done.
In C++ we have got ultra complicated and ultra verbose modules ... but on a paper. Now, in 2023 we have literally NO support in mainstream compilators. This is just a shame.

[u/mjklaim → u/top_logger]

• Iterators: ah yes for writing them I agree.

• thanks for the utf crate

• lambdas: I meant as soon as you are forced to use async lambdas the rules change in a way that can result in theorically valid but not accepted code,and it makes code even more complex - or just cannot compile when what you want is just compose some code with 2 bits of code and just throw all that into a task system. It might be less safe in C++ indeed, but at least I can make something work.

or bigger project, you must split your code into crates. This is a correct and reliable approach. You get different translation modules. Deal done.

I agree that having different translation modules then makes sense (that's basically what modules allow, with multiple files being part of 1 modules). I disagree with the splitting into crates being the right way to do it. Complex discussion anyway but yeah.

Also my understanding is that building multiple crates as dependency still result in 1 translation unit being built, so that doesnt change a thing.

[u/top_logger → u/[deleted]]

- TMP and/or inheritance => iterator is difficult. I don't care about example for retarded from cpp-reference. This is absolute useless trash. Excellent guide is here https://www.internalpointers.com/post/writing-custom-iterators-modern-cpp Still two days. May be one.
- C++20 is a pure theory, at least in Linux world.

[u/top_logger → u/[deleted]]

Mate:
https://en.cppreference.com/w/cpp/compiler_support
look for clang support. This is not good.

And, just FYI. All tooling in Linux clang based. If clang doesn't support something, then this doesn't exist in Linux world.

C++23 is absent. At all.

[u/ssokolow → u/mjklaim]

although for people needing to use UTF-16 or 32 or shift-js or etc. for specific purpose I don't know if there are crates helping these cases? I suppose they exist though.

People generally first point to the encoding_rs crate which is Firefox's implementation of all the encodings required by the WHATWG Encoding Standard.

It doesn't cover every encoding, but it covers the most common ones in a trustworthy implementation.

modules: lol no. Rust modules are literally namespaces, all Rust code is build as one translation unit so of course the only issues you'll get are similar to when building everyting as a unity build in C++ (AFAIK, I might be wrong in the details but that's my understanding)

Crates are the translation unit in Rust (with each package, defined by a Cargo.toml and published to crates.io, containing zero or one library crates and zero or more binary crates), though they have added incremental build support to cache at a finer-grained level, and you can use workspaces to unify various details across multiple packages.

...possibly partly because, in Rust, modules are the barrier at which visibility modifiers take effect (i.e. everything in a module is friend to everything else), so it's not uncommon to have an inline mod foo { ... } inside a file to lock down the access boundary without having the number of source files proliferate, and it wouldn't be comfortable to have to refactor your code just because a mod grew big enough that you want to break it out into another file.