| ▲ | maxloh 6 hours ago |
| I think the problem is that C++ is a poorly designed language with a fundamentally flawed development process. Instead of letting compiler implementers decide which features to add and how to implement them, C++ employs a standards-first, top-down approach. Features are often defined by committee members who may not use modern C++ in their daily workflows, leaving it entirely up to the individual implementations to catch up. Some features were standardized back in 2023, yet not a single implementation supports them in 2026. https://en.cppreference.com/cpp/compiler_support https://cppstat.dev/ |
|
| ▲ | remix2000 5 hours ago | parent | next [-] |
| Rust is impl-first bottom-up and it's stuck with a single implementation and GCC for Rust is still in the works, meanwhile C++26 reflection is already in GCC trunk. |
| |
| ▲ | zamadatix 3 hours ago | parent | next [-] | | C++ has had it's own long periods of badly lagging/buggy implementations of the standards. It's better today but I'm not sure how much of that I'd credit/discredit that to the way the standards process works. So long as there is one quality implementation it doesn't matter much anyways. | |
| ▲ | bitwize 5 hours ago | parent | prev | next [-] | | Rust is also the systems programming language of the future. They're pretty much doing everything right. | | |
| ▲ | uecker 4 hours ago | parent [-] | | What IMHO Rust does not get right and why I do not use it: long compilation times, high complexity, its syntax, polymorphism based on monomorphization, the requirement for many dependencies to get anything done, an ecosystem susceptible to supply-chain attacks, no ISO standard. | | |
| ▲ | tialaramex 2 hours ago | parent | next [-] | | > no ISO standard I'm sure I could argue with you about the actual technical differences but this part in particular is very, very stupid. JTC1/SC22 † shouldn't exist at all. A committee structure is a bad way to do this work, and the practice of having periodic meetings - exclusively in person for much of the time these existed - actually makes it less rather than more useful. ISO mandates a bunch of rules and procedures which surely make some sense if you're agreeing on thread dimensions for oil pipelines but are completely inappropriate for this work and yet because they're ISO committees the WG14 and WG21 processes are captured. I don't think it makes good sense to use an SDO for this work, but if you must have an SDO for some reason beyond ego then you could do a lot better than ISO. Check out TC39 for example. † The C and C++ standards committees are respectively Working Groups 14 and 21 of the Sub-committee on Programming Languages, SC22, of the (First and only) Joint Technical Committee between ISO and the IEC. Yes it's committees all the way down. "This programming language standard could have been an email". | | |
| ▲ | uecker 25 minutes ago | parent [-] | | It doesn't have to be ISO, but some organization which follows some official rules and not some entity dependent on industry donations. |
| |
| ▲ | nicoty 4 hours ago | parent | prev [-] | | Out of curiosity, what do you think is wrong with monomorphization-based polymorphism? The other alternatives I'm aware of are 1. type-erasure via v-table based dynamic dispatch (which Rust also has in the form of the `dyn` keyword), which has performance and memory-allocation overhead and 2. macros, which Rust also has and, if used for polymorphism, would essentially be like compile-time monomorphization, but clunkier. Maybe I'm missing something though and there are other alternatives done differently in other languages? | | |
| ▲ | uecker 2 hours ago | parent [-] | | The correct choice IMHO is type-erasure. It does not necessarily have overhead, because optimizers can specialize or devirtualize. Of course, this my depend on how you implement your language, but in C this works nicely. The problem with monomorphization is that it leads to exponential expansion, which later passes of the compiler can not unify again (at least this is much harder than not expanding in the first place). It should also fundamentally limit what you can do, because expansion has to stop at some point, but I haven't thought about this too much. I also think that where you want monomophization, macro seem fine. I do not think this necessarily has to be clunky, but this is just a guess. |
|
|
| |
| ▲ | zarzavat 3 hours ago | parent | prev [-] | | Is that supposed to be a bad thing? I like having only one implementation. Multiple compilers is annoying for users, have to write "portable" code which can only target the lowest common denominator. Only when a feature ships in Clang, GCC and VC++ can you use it. Each compiler needs its own flags/project as well. Loosely coupling a language to its compiler is 20th century thinking for when programming languages were simple. It works for C because C is simple enough to be implemented over and over again. But for today's hyper complicated languages, multiple implementations is a pain for everyone. | | |
| ▲ | asddubs 3 hours ago | parent | next [-] | | It's a bad thing if you want your language to be truly portable and be able to work on anything | |
| ▲ | NooneAtAll3 2 hours ago | parent | prev [-] | | yes monopolies are always a bad thing | | |
| ▲ | zarzavat 2 hours ago | parent [-] | | A programming language with a reference implementation is not a "monopoly", it's a standard. By having a common implementation to write code against we can avoid wasting time on pointless minutiae such as which features are portable in practice and which are not. When a programming language community fractures into multiple incompatible implementations everyone is worse off. |
|
|
|
|
| ▲ | skrebbel 4 hours ago | parent | prev | next [-] |
| > committee members who may not use modern C++ in their daily workflows Are you sure about this one? I don’t know exactly who’s in the committee these days but last I checked they were all hardcore C++ programmers with decades of experience from the trenches. |
|
| ▲ | tardedmeme 3 hours ago | parent | prev | next [-] |
| I don't think that's true? Nothing gets in the standard without substantial actual experience on at least an experimental compiler branch first. It's just not always your compiler. |
| |
|
| ▲ | saalweachter 5 hours ago | parent | prev | next [-] |
| > Features are often defined by committee members who may not use modern C++ in their daily workflows, leaving it entirely up to the individual implementations to catch up. Eh, all of the committee members I've known are obsessed with modern C++, and "can this feature be implemented?" is definitely a blocker; numerous features got kicked down the road from C++0x to later versions because compilers weren't ready for them. |
|
| ▲ | einpoklum 4 hours ago | parent | prev | next [-] |
| C++ is a language with perfect 30-year backwards compatibility, and which mostly-maintains compatibility with another language it forked from (C), after 40 years of diverging development. Rust is a language which isn't backwards-compatible, and certainly not compatible with source code in other languages. Now, sure, Rust has its advantages, but - how can you fault C++ in the context of compatibility? |
| |
| ▲ | lepicz 4 hours ago | parent [-] | | this compatibility sucks sometimes. for example you want to add nice feature to c++ with nice syntax, but there is a similar syntax somewhere in C that nobody uses, but you have to support it. you end up with nice feature with horrible syntax. |
|
|
| ▲ | weinzierl 5 hours ago | parent | prev [-] |
| This is so true and it's a danger for other ecosystems too. Once the big corporations throw their weight in (be it in a committee or only informally) they make their use cases dominant regardless how niche they might be for the rest of the world. For example in Rust there is one big entity that currently pours a lot of energy into improving C++ interop. Now, this is not exactly a niche topic, but especially in a world where AI makes many rewrites possible that we wouldn't have daunted to think about a couple of years before, we shouldn't waste too much effort to save legacy companies enormous codebases at the detriment of our preferred language. |
| |
| ▲ | uecker 5 hours ago | parent [-] | | I think Rust has similar flaws as C++: too much unneeded complexity and abysmal compilation times. | | |
|
