Comment by steveklabnik
7 years ago
I’m a huge fan of this strategy; we use it with Rust, for virtually identical reasons. Ruby also ships each Christmas.
7 years ago
I’m a huge fan of this strategy; we use it with Rust, for virtually identical reasons. Ruby also ships each Christmas.
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.
2 replies →
> There’s less pressure to put something in a specific release when they happen less frequently.
I think this phrasing contradicts your point. Do you mean "more frequently", or am I missing something?
1 reply →
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.
4 replies →
So maybe choose not to use the very newest features? That's what I've always done and it's worked quite well.
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.