[jpc0]

There are so many different flavours of C++ put there that this guide doesn’t exactly do itself the credit it deserves.

There are easy ways to implement stuff like enums with members in C++, just put an anonymous enum inside a class/struct, its possible but marked as not possible.

Likewise when discussing modules in rust while completely ignoring the existence of modules in C++ that is actually support by modern tooling.

There are other places where there are similar issues I have with the text (you can just add a compiler flag and get the same behaviour. Don’t even try and argue “but rust just does it out of the box”, I would need to rewrite my entire codebase vs just adding a few bits of text to my build system, these things are not equivalent)

They didn’t discuss much about FFI at all, generally sayings “theres a crate for that and if there isn’t let us know”, in my experience the crates are not amazing for esoteric things (anything graphics’s related, ffmpeg is another one) and are actually significantly more painful to use that just writing in a restricted version of C++.

Rust has a happy path, and they are broadening it incrementally, but theres is a lifetime of history before rust even existed in C++ that isn’t that easy to sweep under the rug.

[pjmlp]

As someone that has been around C and C++ communities since 1990's, I also expect that in the long term Rust won't be able to escape this phenomenon, even with editions.

Like any other programming language that has made it into the top 10 over several decades of production code.

The happy path will get fuzzier, as more humans have their own opinion on what means to write code on the ecosystem, with various kinds of backgrounds and their own agendas, companies whose IT refuses to upgrade, the amount of implementations in the industry increases, teachers not bothering to keep up to date,...

[leoh]

Hasn't been the case the last 10y. If anything there has been convergence.

[eslaught]

Async vs. non-async is the main example today. There are libraries that support one or the other, or sometimes one library will have two usage modes (effectively two different code bases) because you can't really mix them.

In the future who knows, because we don't know what features will get added to the language.

[surajrmal]

std vs nostd is another big one. Within nostd there are a ton of tiny fragmented worlds. For example, the Linux kernel ecosystem will likely development its own flavor of rust, especially when it comes to memory model. Old Linux distributions will end up with fairly ancient compiler versions that require code to stick to older conventions. I doubt well end up with people stuck on targeting c89 sort of situations, but things may trend in that general direction.

If you develop that for servers or mobile/desktop applications it might look more homegenous, but their are a lot of segments beyond those out there.

[leoh]

Yikes. May we fare more with more ease than C++.

[m-schuetz]

Are C++ modules actually production ready now? Last I checked, they still weren't properly supported accross all major compilers.

[pjmlp]

Depends on which requirements one has.

If staying only on VC++ or clang latest, with MSBuild or CMake/ninja, they kind of are, on my hobby coding I have been using modules for quite a while now, check the C++ projects on Github.

Tip, for node native modules, which node-gyp probably will never support them, they are supported via cmake.js.

[psyclobe]

No…

[Toritori12]

C++ modules still not supported on VSCode, always pissed when I get notifications from this 5 y.o. thread [0].

0: https://github.com/microsoft/vscode-cpptools/issues/6302

[IshKebab]

Does Clangd support it? It's much better than Microsoft's C++ extension - and open source!

[jpc0]

Yes this.

Clangd-19 which is current stable has very good support for modules. The only issues I’ve encountered is with import std; which quite honestly is bleeding edge.

Your tooling (clangd+cmake) has to be pretty modern t those two are also the easiest to just upgrade since it’s dev time only. And obviously if it’s a discussion you have a C++20 compatible compiler. I’m happily using modules with gcc-14, clangd 19 and cmake 3.28 other than clangd 19 those are just packages you can install in Ubuntu 24.04 which is over a year old at this point.

[pjmlp]

Visual Studio and Clion are the ones currently with the best experience regarding modules.

And in VS could be much better, but EDG has other priorities.

VSCode isn't really that great option for C/C++.

[m-schuetz]

I prefer vscode simply because VS is excruciatingly slow. e.g. the file open pane in vscode pretty much instantly lists the file I'm looking for, while the counterpart in VS (ctrl+,) takes several seconds and intermixes search results for files and file contents, when I'm only interested in files.

[tom_]

DPack (free) has a useable file browser. I use Visual Assist (commercial) these days and that has one too. Both pop up pretty much instantly.

Both available from the extension marketplace.

[Toritori12]

Same here, those "mini" delays are not worth.

[NotCamelCase]

> VS (ctrl+,) takes several seconds and intermixes search results for files and file contents, when I'm only interested in files.

I hate this a lot. It's gotten so bad the last couple of releases to the point that I try and use VS Code more in lieue of VS except debugging.

How they could let such fundamental functionality get broken is beyond me.

[pjmlp]

Ctrl+, followed by f filename, you will get the file.

The only reasons I use VSCode are the plugins I cannot get on VS, like Powershell, Rust, Azure tooling, and for stuff like Next.js, better use an editor that is anyway a browser in disguise.

Performance has never been a part of my decision flowchart.

[m-schuetz]

I know it gets you the file...after several seconds. Vscode gives it instantly. I use this feature so often, it's basically a dealbreaker for VS.

I keep both editors open, but VS is basically just there to hit the compile button and for the occasional debugging.

[pjmlp]

Dunno, time to check your plugins slowing down the IDE.

Better not having Resharper around.

[dwattttt]

> There are easy ways to implement stuff like enums with members in C++, just put an anonymous enum inside a class/struct, its possible but marked as not possible.

This guide does exactly that in C++ for methods on enums.

For members, won't this result in all instances of an "enum" having all fields? That's not really comparable to Rust enums, if that's what you mean.

[jpc0]

> For members, won't this result in all instances of an "enum" having all fields? That's not really comparable to Rust enums, if that's what you mean.

Rust enums are not enums, they are tagged unions and there is a C++ equivalent, std::variant which was discussed. It’s not got nice tooling around it like match but it exists and can be used identically.