3 ms·

> C++ does not have an equivalent, it's completely decentralized which results in more messy situation. That is the role of the ISO C++ committee, is it not? T

> C++ does not have an equivalent, it's completely decentralized which results in more messy situation. That is the role of the ISO C++ committee, is it not? They are the major stakeholders. They would just have to care enough. They cared enough to release C++20, didn't they? It's not like they never get anything done, which seems to be the implication a lot of people make in this discussion. > Instead of a top down decision it's a negotiation between the various actors. My understanding is that the various committee members represent the disparate interests of the broader C++ community. I agree it would be very much like a negotiation. That doesn't mean that it can't be done. This whole thread is discussing things that have been done by the C++ committee: C++20. > But the last thing we need is for the C++ standards committee to standardize a package manager. That would take forever to do, would result in a messy tool that tries to compromise with all the actors in some ways, make it very hard and slow to evolve over time and would likely result in a lot of pain, etc. You just summarized my feelings about C++ in general. I would much rather people use Rust or Go or any number of other languages instead of C++, depending on project needs. Such opinions are rarely taken well in threads like this, though, so... I've been trying to be optimistic and point out that C++ could get package management. If the C++ committee process works well, then the package manager should also end up turning out well. I'll leave the reader to decide how well they think the long term direction and guidance of the C++ standard has been going and apply that to their feelings of a hypothetical future package manager.

vlovich123 6y ago
It's design by agreement vs design by decision. In the former you need people to agree. In a committee setting it means that not only do you have to make MSFT, Google, & Apple happy, it's also the various other people that happen to be part of that standard body (the group is large). You definitely pull from a larger group of experts, but it's mired in indecision hell & compromise. Often times a decision that solves 90% of problems is better than a decision that is perfect, but the way ISO is set up, decisions kind of have to be perfect. That being said, the C++ standards body (at least under Herb?) has done a decent job modernizing their process to fight some of the gravitational issues they were having. They've formalized deprecation rules & tried to get over disagreements. The design by committee issues haven't gone away though - the mess with coroutines, modules, & concepts is a great example of that. The ISO process of language papers precludes even simple additions to the STL where you not only have to navigate standardese, but also manage the review process (that's why you have to find a champion on the standards body to help guide your review through the rigamarole). My experience contributing to the Rust standard library by comparison was much easier - put up a drive-by diff adding a new (admittedly minor) API, some minor review comments, done & shipped. The whole process took 1-2 weeks, no standardese, no arguing with a large committee on the exact wording, etc.
- bluGill 6y ago
  > My experience contributing to the Rust standard library by comparison was much easier - put up a drive-by diff adding a new (admittedly minor) API, some minor review comments, done & shipped. The whole process took 1-2 weeks, no standardese, no arguing with a large committee on the exact wording, etc. this is off course all great until two people working in different parts of the language do things slightly differently. Either works alone, but the whole of the language is inconsistent and hard to learn. C++ has enough inconsistent parts already and so tries to be careful to make new things consistent with itself as best as possible. Even that has failed despite all the review of people looking for places to make things consistent. It is a hard problem to design a large language.
  - steveklabnik 6y ago
    So, a key difference here is that in Rust, the standard library and the language designers are two different teams, with two different standards. The parent is talking about the standard library; there's a reasonably low barrier to entry to add something, but it is added unstably, and the bar to getting it to stabilize is higher. The language does not accept additions by "drive-by PR", the barrier to getting something to land, even in an unstable way, is much, much higher. The whole language team has to sign off on these stabilizations and language additions, which is what keeps up that consistency you're talking about.
    - vlovich123 6y ago
      Yeah sorry. Should have been clear that I was talking about the standard library. I've got the chops to contribute standard library code - would never even think about trying to tackle implementing language changes. I don't have the time nor energy to deal with C++ standardese since the spec is an ancillary artifact describing the thing rather than the thing itself (the thing itself being the implementation & documentation). Granted, this isn't necessarily everyone's experience in std as the change I implemented is well-worn/adopted by any condition variable implementation. Something more controversial/exploratory may have been pushed off into a crate first. I'm still impressed that it only took ~2 weeks to get [1] reviewed & into unstable. I wasn't even involved in the stabilization work/cosmetic renaming that it took to close out [2] which was driven by a community ask & the std maintainers doing a pass to make things consistent. Rust's velocity seems to be that they can deliver changes a full 1 year faster than C++ can (& likely faster if the community really asks for it). In my book it's largely owing to having 1 compiler & 1 standard library & the latter having a much more streamlined RFC process. [1] https://github.com/rust-lang/rust/pull/67076 https://github.com/rust-lang/rust/pull/67076 [2] https://github.com/rust-lang/rust/issues/47960 https://github.com/rust-lang/rust/issues/47960

vlovich123 6y ago

It's design by agreement vs design by decision. In the former you need people to agree. In a committee setting it means that not only do you have to make MSFT, Google, & Apple happy, it's also the various other people that happen to be part of that standard body (the group is large). You definitely pull from a larger group of experts, but it's mired in indecision hell & compromise. Often times a decision that solves 90% of problems is better than a decision that is perfect, but the way ISO is set up, decisions kind of have to be perfect. That being said, the C++ standards body (at least under Herb?) has done a decent job modernizing their process to fight some of the gravitational issues they were having. They've formalized deprecation rules & tried to get over disagreements. The design by committee issues haven't gone away though - the mess with coroutines, modules, & concepts is a great example of that. The ISO process of language papers precludes even simple additions to the STL where you not only have to navigate standardese, but also manage the review process (that's why you have to find a champion on the standards body to help guide your review through the rigamarole). My experience contributing to the Rust standard library by comparison was much easier - put up a drive-by diff adding a new (admittedly minor) API, some minor review comments, done & shipped. The whole process took 1-2 weeks, no standardese, no arguing with a large committee on the exact wording, etc.

bluGill 6y ago
> My experience contributing to the Rust standard library by comparison was much easier - put up a drive-by diff adding a new (admittedly minor) API, some minor review comments, done & shipped. The whole process took 1-2 weeks, no standardese, no arguing with a large committee on the exact wording, etc. this is off course all great until two people working in different parts of the language do things slightly differently. Either works alone, but the whole of the language is inconsistent and hard to learn. C++ has enough inconsistent parts already and so tries to be careful to make new things consistent with itself as best as possible. Even that has failed despite all the review of people looking for places to make things consistent. It is a hard problem to design a large language.
- steveklabnik 6y ago
  So, a key difference here is that in Rust, the standard library and the language designers are two different teams, with two different standards. The parent is talking about the standard library; there's a reasonably low barrier to entry to add something, but it is added unstably, and the bar to getting it to stabilize is higher. The language does not accept additions by "drive-by PR", the barrier to getting something to land, even in an unstable way, is much, much higher. The whole language team has to sign off on these stabilizations and language additions, which is what keeps up that consistency you're talking about.
  - vlovich123 6y ago
    Yeah sorry. Should have been clear that I was talking about the standard library. I've got the chops to contribute standard library code - would never even think about trying to tackle implementing language changes. I don't have the time nor energy to deal with C++ standardese since the spec is an ancillary artifact describing the thing rather than the thing itself (the thing itself being the implementation & documentation). Granted, this isn't necessarily everyone's experience in std as the change I implemented is well-worn/adopted by any condition variable implementation. Something more controversial/exploratory may have been pushed off into a crate first. I'm still impressed that it only took ~2 weeks to get [1] reviewed & into unstable. I wasn't even involved in the stabilization work/cosmetic renaming that it took to close out [2] which was driven by a community ask & the std maintainers doing a pass to make things consistent. Rust's velocity seems to be that they can deliver changes a full 1 year faster than C++ can (& likely faster if the community really asks for it). In my book it's largely owing to having 1 compiler & 1 standard library & the latter having a much more streamlined RFC process. [1] https://github.com/rust-lang/rust/pull/67076 https://github.com/rust-lang/rust/pull/67076 [2] https://github.com/rust-lang/rust/issues/47960 https://github.com/rust-lang/rust/issues/47960