Can't speak for Rust, and I imagine it makes more sense for them since it's a young language, but I wish the C++ folks would chill a bit and take their time a little more; it's getting kind of ridiculous. They don't need to move fast and break things (which they literally have; see e.g. result_of and invoke_result). By the time the tooling across various platforms has finally had a chance to take a breath, they've already got the next version of the standard out, and it's getting hard to keep up with all their changes. I feel there's a better balance between the 13 years ('98->'11; '03 wasn't really a new standard) and the 3 years we have now. Maybe every 5-6 years?
I don’t think that making the cycle time longer helps; I think making it shorter helps. There’s less pressure to put something in a specific release when they happen less frequently. You can, counter-intuitively, take your time.
I know less about the exact details, but I also think that having something to play with helps; I believe that this is what’s going on with with the move towards more TSes before shipping spec text, right? Being able to try things out in nightly helps us a lot.
If your goal is to help improve C++, sure, a shorter cycle time is better. If your goal is to use the language as a communication mechanism... having it change constantly underneath you isn't helpful in my experience. And it's not necessary to release a new standard to let people try things out; you can let people play around with new features without iterating on them as formal standards.
You’re missing one of the major points in the post: making release cycles take a long time means that small features aren’t finalized for that long period either.
You seem to be thinking that the compiler devs wait until a release is done to start implementing a release, which is not what happens. Part of the big benefit of releasing every three years is that it makes continuous development actually possible: compiler devs have a better idea of how stable things are, and so which things aren’t going to need to be completely reimplement in another 3 years.
I do not understand where you get a “catch their breath” mentality - none of the modern c++ compilers have a three year cadence, most run with approximately annual major releases.
No... there's more to programming than just having a shiny new compiler. VS2017 for example had problems that held me back at VS2015, so I couldn't upgrade until I got to VS2019, but meanwhile projects moved on. The 1-year period you're imagining was really a ~4-year period where the language syntax had changed, the stdlib had changed, and projects had moved on, so I couldn't even compile things. Heck, I couldn't even read the language anymore, let alone worry about all the new stuff in stdlib.
And it's not like they've been only adding small features every 3 years. If they were then my position would be different too. But small features being small, people can live without them. Not having them is a lot better than not being able to use the language at all.
You just said, 'I had a whole bunch of problems', and that's why I believe the standard should change more slowly.
You didn't actually say what those problems were, you didn't provide any evidence that any bugs you hit were as a result of an increased standardization rate.
You're also assuming that somehow spending more time with unstable language features will result in fewer problems, which is something where we know you're wrong. Because we've seen what happens when a longer cycle exists, we know your claim that the compilers will be less buggy is exactly wrong.
> you didn't provide any evidence that any bugs you hit were as a result of an increased standardization rate.
You misunderstood the argument. The claim was not that the VS problems were due to the increased standardization rate. They weren't C++-related at all. Rather, the problem was that I couldn't move onto 2017 due to unrelated VS problems, even though I needed to move onto it in order to be able to work on C++ projects that had already started using C++17.
> You're also assuming that somehow spending more time with unstable language features will result in fewer problems, which is something where we know you're wrong. Because we've seen what happens when a longer cycle exists, we know your claim that the compilers will be less buggy is exactly wrong.
Again, I was not saying compiler bugs increase when you rush the standard. See above.
That's exactly what I do on my end, but it's more than annoying when I have to deal with other projects and I suddenly can't even compile them anymore until I upgrade my toolchain and learn what's basically a new language.
