[klodolph]

This is what the "modules" feature in C++20 addresses. People are complaining about modules a lot, I think because the spec is a little complicated... but the spec is a little complicated because the problem is a little complicated, and you can't pretend that complexity doesn't exist when you're writing the spec. (There are some other complaints about the modules system. It wasn't going to please everyone.)

New dialects and features were getting added to JS all the time, but what happens is people writing JS libraries or tooling would watch how far these features spread in their users' browser compile base, and many of these various features would never even make it into popular JS runtimes, while others are everywhere now.

I think it's a reasonable model for development--lots of people trying to improve things, the community slowly sifts it out, and the standards are the most conservative of all.

[forrestthewoods]

People complain about modules because they only exist on paper.

Not a single compiler supports the standard library as a module. No compiler has full support for modules.

Modules are a C++20 feature that isn't usable in real projects in 2022. And there's no signs that modules will be ready anytime soon.

[klodolph]

Is there something I'm missing? People are complaining because modules aren't supported yet? Isn't it reasonable to address this complaint by adding module support to compilers, and isn't this what's already happening?

[throwaway-blue2]

As I understand it modules support goes beyond just compilers - yes you need support there, but also in libraries (std library still is still not available as a module yet but apparently in progress) as well as build tools (CMake, Bazel, etc.).

People are complaining because it’s 2022 and support for modules is seemingly not there or incomplete in all these places, and modules are talked about in some C++ communities as if they’re a thing that is actually usable (for example Bjarne’s talk at Cppcon a few days ago).

[humanrebar]

> People are complaining because it’s 2022 and support for modules is seemingly not there or incomplete in all these places...

So they're complaining on the internet about not getting free stuff fast enough.

They could work with the maintainers of their toolchains instead. If everyone that used xcode complained to apple, C++ modules would be done there already. MS likewise would probably put more resources on it. Open source is a little more complicated, but Red Hat and Canonical do have paid products.

[forrestthewoods]

> So they're complaining on the internet about not getting free stuff fast enough.

This is a very weird take.

Visual Studio isn't free for professional use. Xcode is free, but publishing for macOS/iOS is not. Both tools exists to serve platforms owned by the first and third largest companies in the world by market cap. Microsoft and Apple don't spend tens of millions of dollars a year on employee salaries for these tools out of the goodness of their heart.

In any case, the issue isn't with the toolchains. The issue is the C++ committee created a specification that has turned out to be problematic. Your next response may be to join the committee and fix it from the inside! Google tried that and rage quit to create Carbon. Sutter hasn't quit, but I think Carbon and Cppfront getting announced the same summer is not an accident.

[humanrebar]

Yeah, fair.

Very Online engineers complain about slow progress on free stuff for the open source toolchains. And they don't bother to light up ticketing systems on paid products. Microsoft and Apple don't spend as much on these things as you would expext. Because relevant management thinks we don't really care that much. But the common thread is that sitting back and expecting the world to come to you isn't reasonable.

Incidentally, Google is a big place. Some Googlers are still involved in the ISO committees. Certain Googlers, admittedly influential ones, lost patience and started betting their reputations that certain dramatic moves would be a better choice.

I personally don't think ISO is the presidency of C++. C++ culture focuses on language design way too much and engineering (good third party libraries, supporting implementation, empirical evidence, etc.) not nearly enough.

[nine_k]

People are still feeling the pain, and are still complaining.

I suppose when GCC and MSVC will both support modules in an interoperable way, these same people will enjoy and praise this development.

[colejohnson66]

The fact that it also took until 2020 to admit it’s a problem worthy of solving (by WG21) is also not a good look

[zhxshen]

> because the spec is a little complicated

Patching over the old work--hopefully without breaking anything--always is. I'm just stating that much of the hostility toward C++ comes from the fact that we have so many superior options to choose from now--options which profited from the lessons C++ learned the hard way, and incorporated them into v1 instead of patching them in as options at v23.

And this is not to strikeforce anyone with a "Rewrite it in Rust!", but to suggest that C++ is maybe not the best choice for new work in 2022.

[bsder]

> This is what the "modules" feature in C++20 addresses.

This is the perennial "If you only used modern C++, you'd be fine."

Sorry. People have been repeating this for 15 years, and it hasn't gotten any more true.

For example, C++ still doesn't have a useful string type--everybody rolls their own. How do you interoperate when 2 different C++ libraries can't even agree on something as basic as what a "string" is? The existence of "header-only" libraries and the contortions they go through is a tacit admission that compiling and linking C++ is still a disaster. C++ still doesn't have a stable, documented ABI--so everybody defaults to C (thus throwing away any theoretical usefulness C++ might have). Embedded shuts down 90+% of C++ beyond "C with classes" because they can't use exceptions and can't allocate memory dynamically. The preprocessor is a brain parasite that has grown with C/C++ and can't be removed anymore without killing the host. etc.

In fact, I would argue the lack of stable ABI is the only thing propping C++ up. Because the C++ ABI is so shitty, you have to make the top-level code C++ which then calls into the other libraries and subsystems which actually have useful, stable and documented ABIs and interfaces.

If C++ had an ABI that didn't suck, you could invert that, drive the C++ from the better language, and everybody would relegate C++ to increasingly tinier libraries until they could excise the remaining code and throw it into the trash.

I feel for the people who put in their entire lifetime trying to "improve" C++. However, it's time to admit that C++ can't be fixed and move on.

How amazing would it be to have people like Stroustrup and Sutter being paid to work on a language that doesn't start with unfixable suckage?

[klodolph]

To be clear, I’m in the “C++ sucks” camp. But I don’t agree that C++ “can’t be fixed”. I’d rather say that some problems with C++ can’t be fixed, but others can be.

People will still use it, and that is entirely sensible and rational, and it makes sense to improve it. Long-term, maybe C++ will fade into the same kind of sunset that Fortran and Cobol currently occupy.

I’m not gonna make fun of Fortran users, or tell them to move on. There’s even a Fortran 2018.

Trying to allocate people to only the “best” possible work—say, replacing C++—is just poor allocation of resources.