6 ms·

>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

>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.

fpoling 5y ago
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.
pjmlp 5y ago
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.
- tene 5y ago
  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?
  - pjmlp 5y ago
    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.
    - 5y ago

fpoling 5y ago

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.

pjmlp 5y ago

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.

tene 5y ago
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?
- pjmlp 5y ago
  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.
  - 5y ago