Hacker News Reader

Lots of answers to this, but

(1) Computing is growing as a whole. What was good enough in 1980 isn't good enough now. Computing is used for more problems, and by more people. Programs are bigger, so there is pressure toward compressing common code and idioms. Hardware is more capable and more complex: it's more heterogeneous, dynamic, has more sensors, etc.

(2) Different problems have different use cases. Your "wart and bloat" is another person's feature, and vice versa.

Multi-core, multithreading and GPU are major reasons that features have been added to C++, and those were less of a concern in 1980 when C++ was conceived. (especially GPU).

The "cycle" you lay out isn't accurate because languages in fact do make progress. We're not going around in a circle. Rust fixes a lot of things wrong with C and C++; Go and Swift are also improvements, etc. (I don't even use those languages, but I can recognize the improvements as someone who's been using C and C++ for a long time).

I recommend writing some C from scratch to get a feel for this. I do this on occcasion, because there are advantages. But you will also be extremely hard pressed to do anything that's interesting for a user. The gap to bridge is very large.

For example, try writing a web app in C (not for production). You can save a lot of code by using CGI, but even then it's not fun. (It IS still done; look at the source code to the modern cgit UI if interested.)

Also try to modify and understand source code from the 90's like GNU bash or CPython. (Interestingly, there is a pretty big difference between the codebases, despite being from similar eras.) Nonetheless it should be clear from that experience that we've made progress.

The progress isn't perfect, but freezing languages in time isn't a reasonable option, given the massive change in the problems being solved, and the environment.

> people wish could be fixed (but can't due to backwards compatibility)

This is actually not completely true. The only example I can think of right now is how C++20 deprecated some uses of volatile, but the standards definitely do deprecate features and break backwards compatibility. This is done with care, only when it makes sense. The standards and individual papers/proposals are public, so feel free to take a look, they include rationales in such cases.

> My question is why the need to keep adding features? Sure if something comes out that C++ is desperately lacking, add it in.

Well, that already is how it works. Just because you don't know about some change doesn't mean it wasn't worthwhile.

There are often some complaints regarding the standardization process itself though, I think that, e.g., the coroutines proposals situation with the multiple competing proposals was pretty controversial. But that's just how it is with C, C++ (and Ada, Pascal, Basic, ...). It seems like the days of ISO reigning over programming languages are over though, in that newer programming languages aren't given over to ISO.

When not ISO, it is ECMA.

Many industries won't touch a language if it doesn't come with a standard and multiple implementations.

Even languages like Java, C#, F#, have their standard documents, or foundation with working groups that are hardly any different from either ISO or ECMA, as means to be taken into those industries.

>My question is why the need to keep adding features? Sure if something comes out that C++ is desperately lacking, add it in. But it seems like that hasn't been the case for a while.

C++20 does address legitimate pain points of the language. - Modules alone can cut 30% off compile times, as well as solving some other corner cases. - Coroutines will make writing network code easier. - constinit and consteval greatly simplifies the horrible TMP hacks C++ programmers are already using. - The spaceship operator removes a lot of boilerplate when defining comparison operators. - Library additions like <format>, <bit>, <numbers>, std::jthread, etc, standardize widely used operations and libraries.

In contrast, it seems like most of the language features proposed for Python are to "keep up" with other languages, e.g. the pattern matching proposal. It's made even worse in Python's case because it has historically been sold as a simple and easy to understand language.

>I think the answer is probably yes, if it endures for a similar amount of time that C++ did

Maybe. But Rust is in a much better position to avoid C++ style complexity. Editions allow Rust to "clean up" the language without breaking existing code (C++ is trying to do the same with Epochs). And Rust doesn't try to maintain broad compatibility with another language like C++ does with C89. Other features, like powerful macro definition facilities, also help offload language features to libraries. And most of all, Rust can learn from the mistakes of C++, e.g. destructive moves are definitely the way to go.

Anyway, it does seem like programming languages are either destined to ossify, like C, or sprawl out of control, like C++. Although, this problem can be largely avoided if the language lets code leverage the compiler, such as Lisp macros.

I still don't buy into epochs at the industrial scale languages like C and C++ are used today.

It relies on using the same compiler for the whole project, no use of binary libraries, or language semantic changes, for the whole idea of mixing epochs to work out.

It happens to be the case today that Rust doesn't support binary libraries build by different compiler versions, but I don't see any way that editions could interfere with this.

Editions only include changes that are crate-local, and crates using different editions must always be interoperable. For example, the module system path changes in Rust 2018 change how you organize code within a crate, but there's no way for any user of the crate to possibly know or care about this. Rust 2018 adds the ? operator, but again there's no way for users of the crate to know or care about whether code in your crate uses ? or not.

Am I misunderstanding you, or could you share more details of how crates specifying different editions could rely on them all using the same compiler?

Are there any changes in the 2018 edition, or planned for the next edition, that would interfere with using different compilers, or binary libraries? What's a possible change that you imagine could be introduced as part of a Rust edition that would cause interoperability problems here?

Sure, imagine Rust in a couple years from now, with Rust Editon "C++20", so lets come up with 2015, 2018, 2021, 2024, 2030 as possible epochs.

Now imagine a scenario where everyone uses binary libraries, like plenty of corporations do with C, C++, Java, .NET, Swift and other compiled languages.

How can epochs ensure that a binary library compiled in edition 2018, will be able to take a callback using a lambda written in edition 2024 main application, calling into a function available in a edtion 2015 crate, and then statically linked into a common runtime?

The current answer is it can't, unless all libraries happen to be compiled with the same compiler, and linked with the same runtime version.

Yes, it is a problem hard to solve, which not even a stable API fully fixes, because having it stable it restricts the language evolution on what can be exposed at library boundary and runtime library expectations.

Long term editions won't be much different than a -source in Java or -std= in C, C++ and so on.

It works for the time being because 2018 is basically the only edition available, with 2015 being pre-1.0, the same compiler gets backports to have a runtime compatible with both versions and there are no breaking changes where the language semantics have changed.

Hey, thanks for the response. I still feel like I'm missing an assumption, or we're otherwise talking past each other.

Specifically, it sounds like you're assuming there is (or could be, or should be?) some relation between editions and ABI?

I agree that Rust's current answer to your scenario is that all of the crates must have been compiled with the same compiler, but that has nothing at all to do with editions, and it's the same answer for exactly the same reasons if all of the crates were using the same language edition.

Editions aren't relevant here because editions are very limited in the scope. Consider these quotes from the in-progress RFC "2021 Edition"[1]:

  Editions are used to introduce changes into the language that would
  otherwise have the potential to break existing code, such as the
  introduction of a new keyword.

  Editions are never allowed to split the ecosystem. We only permit
  changes that still allow crates in different editions to interoperate.

  The most important rule for editions is that crates in one edition
  can interoperate seamlessly with crates compiled in other editions.
  This ensures that the decision to migrate to a newer edition is a
  "private one" that the crate can make without affecting others,
  apart from the fact that it affects the version of rustc that is
  required, akin to making use of any new feature.

  The requirement for crate interoperability implies some limits on
  the kinds of changes that we can make in an edition. In general,
  changes that occur in an edition tend to be "skin deep". All Rust
  code, regardless of edition, is ultimately compiled to the same
  internal representation within the compiler.

Whatever stable ABI Rust might eventually get, I expect it to be completely edition-oblivious. There should not be any way to tell by inspecting a compiled artifact in a stable Rust ABI which edition its code was written in.

Having written all this, I'm now wondering if you might have instead been trying to express something about how Rust's editions are insufficient to handle the requirements that a stable ABI would address? If so, I completely agree, although I'd be confused by the comparison, as they're very different kinds of things.

[1]: https://github.com/nikomatsakis/rfcs/blob/edition-2021-or-bu...

> Editions aren't relevant here because editions are very limited in the scope.

Which is exactly my whole point, as language evolves they won't be able to cover all possible language changes and compromises will be required, specially regarding possible incompatible semantic differences across editions.

The ABI example is just one way to make this issue more visible.

Modules in theory for big source trees with a lot of small files and long include lists can reduce compilation time by factor of 5 as that time is dominated by repeated parsing of headers.

I don't think Python and C++ are really comparable here. Python was meant to be fairly minimalist from the start. I think if Python "feature froze" right now it'd still remain relevant for a long time. As you mention for its core use case you could argue that it's feature-complete already.

C++ on the other hand was never small. It was never an objective. C++ started as C with classes so it was really just a way to have proper OOP in C. Then it grew and grew and grew, adding more paradigms along the way.

C++ is in a relatively tough spot because it has to maintain backward compatibility all the way back to C89 while at the same time attempt to stay relevant when pitted against Rust, Zig, D and friends. You can't simplify anything because you'd lose backcompat and if you just feature freeze you're doomed to become irrelevant in the not-so-far future.

Unlike Python you can't really argue that C++ as it is now is feature complete. Dependency management is still a nightmare (as is the entire build system really, given that you don't have any standard C++ build system). Concepts are also a great addition to the language IMO that I've been missing for as long as I've used the language.

Coroutines are also fast becoming a standard tool for system programming (for better or worse, but that's a different discussion), and C++'s support in the standard is still experimental.

> C++ is in a relatively tough spot because it has to maintain backward compatibility all the way back to C89

C++ does not maintain backwards compatibility with any version of C. Almost any relatively large idiomatic C program will fail when compiled as C++ for a few simple differences (most commonly, in C it is idiomatic to write `int *c = malloc(sizeof(int))`, while this is a type error in C++).

> Dependency management is still a nightmare (as is the entire build system really, given that you don't have any standard C++ build system)

CMake sucks but it’s OK that CMake quickly became so dominant, because at least it’s everywhere. It’s also peculiar, unhelpful, and dangerous in the same sort of general way as C++. So, I find CMake to be very comfortable, and I like it, and I wouldn’t be entirely surprised if Bjarne announced one day that CMake is now the standard C++ build system.

I don't think that's true at all for Python. It's explicitly created as a "batteries included" language with a very large standard library. This is a quote from PEP 206:

"The Python source distribution has long maintained the philosophy of "batteries included" -- having a rich and versatile standard library which is immediately available, without making the user download separate packages."

Except Python is quite huge as well, and introduces breaking changes even across minor versions, people think it is simple, but that is actually quite deceiving.

I don't know what the situation is with the C++ development. But in general, based on my experience on standardization work, it's really hard to stop a committee from inventing new features when the members get paid to participate and make an impact. Maybe exaggerated but sometimes I got the feeling that some proposal existed only so that the presenter was able to justify a week in a nice meeting location like Hawaii.

> it's really hard to stop a committee from inventing new features when the members get paid to participate and make an impact.

This could also explain most awful, unnecessary GUI updates, unprovoked by any customers, throughout software.

The main issue I have with C++ is that you basically have to relearn it from scratch every time a standard comes out. C++11 threw away decades of best practices, and C++17 again changed so many things it's hard to keep track of them (for instance, stuff like `string_view` has had a _huge_ impact on how I write code and how I reason about strings, making `const char *` almost disappear from some of my codebases).

C++20 with concepts and ranges will revolutionise everything, again, because those features are so big and pervasive they make lots of patterns and "older" parts f the language suddenly feel like "legacy". For instance, I see concepts vastly reducing the need for inheritance in lots of cases, massively simplifying what lots of folks like me were already doing with SFINAE and templates.

As far as I understand, that is the whole point of many of these changes: there are patterns that people have to bend their code into and unsafe constructs that need to be used with care, and the newer standards seek to replace patterns with language features (e.g. concepts more or less instead of SFINAE), or bring safe alternatives to the previously necessary unsafe ones (string_view instead of `char*`).

Now, the major concerns that some have is that this will not be successful, and that instead of replacing X with Y, you'll be left with both X and Y in the language as still necessary constructs for new code, making the language ever more complicated even if you can disregard the legacy.

C++ already suffers somewhat from the strong ties between many of its features (for example, many people would like to use C++ without exceptions, but then you can't use `new` or constructors that can fail, and without constructors you can't use RAII, and so on).

Yes, that's definitely a possibility, but I think most of the time when two patterns keep existing, instead of a new one just replacing the old one, is most of the time due to people refusing to change the ways they write code.

For instance, `new` is basically nothing short of obsolete in modern C++, unless when used in "placement new". There are legally 0 reasons for ever writing `new T`, unless you are implementing `std::make_unique()` in the STL. Disabling exceptions is also IMHO a very poor choice - first, because there is no valid performance reason to do so, and second because it basically cripples half of the STL (and lots of other libraries). Using it becomes then tricky to use safely, because basically everything might just call std:: terminate () anywhere without any formal specification, or without being declared `noexcept`, by just changing compiler options.

C++ exceptions, when used sparingly and for, well, exceptional events, are not as bad as people think they are. What's very unfortunate is that they got a very bad rap in the 90s, and then countless developers have been mislead by Java's unfortunate design choices, so they often fail to understand that handling failures should always considered part of the ordinary code path, and not treated as exceptional at all.

I personally use exceptions as if they are a lighter version of assert, like `panic` from Rust or Go, in order to indicate that some basic code assumption has been violated, and thus executing a certain action is no longer possible (like, some parameter is malformed and you specifically asserted it's not, and such). Using them to represent normal runtime failures, such as IO errors, is sloppy design, and it's something that is much better accomplished by returning error values (which might also consist in enum classes or an error struct).

Just FYI

> but then you can't use `new`

You can certainly use new without exceptions, see https://en.cppreference.com/w/cpp/memory/new/nothrow or https://stackoverflow.com/a/15292148

> and without constructors you can't use RAII, and so on).

I think RAII is more about destructors (which must never throw exceptions). You can certainly write RAII style without throwing constructors. Generally, exceptions depend on RAII, but not the other way round.

> You can certainly use new without exceptions, see https://en.cppreference.com/w/cpp/memory/new/nothrow or https://stackoverflow.com/a/15292148

You can use new without exceptions, but you can't detect OOM then, if I'm not mistaken.

> I think RAII is more about destructors (which must never throw exceptions). You can certainly write RAII style without throwing constructors. Generally, exceptions depend on RAII, but not the other way round.

The whole idea of RAiI is that you Acquire a Resource in the constructor (during Initialization), so that the destructor can guarantee it gets de-allocated.

If you construct your object and then acquire a resource in it later, from a function that can return an error without throwing, then you introduce complexity in the destructor and may risk errors more.

> The whole idea of RAiI is that you Acquire a Resource in the constructor (during Initialization), so that the destructor can guarantee it gets de-allocated

Yes, that's the meaning of the acronym means, but unfortunately it's really a misnomer.

When we say RAII style programming, we rather mean scoped destruction to avoid manual resource management. A classic example would be using std::lock_guard over a raw std::mutex. Some RAII objects don't throw on resource acquisition failure (std::fstream) or they expect that resource acquisition can fail (std::unique_lock with std::try_to_lock tag). Other RAII objects might not require any resource in the constructor at al, instead their only job is to release the resource that is given to them, like std::unique_ptr.

> You can use new without exceptions, but you can't detect OOM then, if I'm not mistaken.

AFAIK `new (std::nothrow) T` returns nullptr if allocation fails, like std::malloc.

Exactly! It's worth pointing out that 'new (std::nowthrow) T' itself also performs a NULL check, so it doesn't call the constructor if the allocation failed.

> You can use new without exceptions, but you can't detect OOM then, if I'm not mistaken.

You can detect the same errors with and without exceptions - the nothrow variant returns nullptr on error. Due to overcommit, neither can be relied on to detect OOM in practice.

> If you construct your object and then acquire a resource in it later, from a function that can return an error without throwing, then you introduce complexity in the destructor and may risk errors more.

Not neccessrily, e.g. free and delete are both no-ops for nullptr.

> In my naive opinion, It seems to me that both C++ and Python have reached a point where most people are satisfied with the features the language has.

most definitely not. C++ still doesn't have reflection ffs, which I am reminded every time I have to type the name of an enum or class twice

Idle question, if you could toss everything added to C++ in the last 20 years in return reflection would that be worth it?

I'm of the opinion that powerful enough reflection + metaclasses (e.g. with the ability to synthesize almost arbitrary code ) would be able to transform a lot of language features (noexcept, coroutines, ...) into library features. But it's not possible for all, and you'll pry auto, range-based for, atomics semantics, lambdas, restructuring bindings, and brace-init... from my cold dead hands

Reflection is also one of the things I miss the most.

New features get added to C++ only when people vote for them. I believe anyone gets to cast a vote. You have to write a paper that explains the rationale for your idea.

So, features get added because they're considered good ideas.

I fear this is the road C# is on.