41–50 of 77 posts
[flagged]
Yeah, I agree, let's just rewrite all our system software in Javascript. Much better. (Well, except for your Javascript interpreter, that will still be written in C++, obviously.)
[flagged]
It's a shame as these things often begin well. Ie, if the lesson were instead learned, people might better stick to providing features in a rich ecosystem instead of endless feature-creeping of the core value-proposition to oblivion.
> In Go, I found that using an interface was not free: it can make the code slower. The Go version that was presented isn't equivalent though. In Go you are accepting an interface directly which will hide the value under some fat pointer for dynamic dispatch, in c++ you are using generics to monomorphise the function to specific types. If you want to compare the implementations fairly you should've used Go generics:…
Fair criticism, though I do wonder if it'd really make that much of a difference. Go doesn't really monomorphize generics either, and would end up with an equally if not more expensive lookup for the correct generic function at runtime. Some reading: https://github.com/golang/proposal/blob/master/design/generi... https://planetscale.com/blog/generics-can-make-your-go-code-...
Considering the progress Go compiler has gone through, I think it's reasonable to expect the optimized implementations will come few versions down the road.
Earlier quoted context omitted.
Fair criticism, though I do wonder if it'd really make that much of a difference. Go doesn't really monomorphize generics either, and would end up with an equally if not more expensive lookup for the correct generic function at runtime. Some reading: https://github.com/golang/proposal/blob/master/design/generi... https://planetscale.com/blog/generics-can-make-your-go-code-...
That's true at the moment, but still an implementation detail. I think I remember early versions of C++ compilers doing the same thing with templates. Considering the progress Go compiler has gone through, I think it's reasonable to expect the optimized implementations will come few versions down the road.
does this imply that type erasure via base classes will become a thing of past ?
Earlier quoted context omitted.
Rust is a serious contender is this space, and closing the gap quickly.
Including introducing new features on 6 weeks basics, just wait until Rust also gets 40 years of history.
Of course Rust's improvements are actually compatible, not only by fiat, but because Rust's automation extensively tests each of these six weekly releases against the vast field of Free Software out there written in Rust. Now maybe this is secretly happening for C++ and they're just very bad at it. Or, as seems more likely, it's not done, the results are the same either way, new C++ versions require extensively manual testing to upgrade your software before you can take advantage without too much fear.
† Rust knows that characters like 'A' aren't necessarily one byte, and it deliberately doesn't coerce them to fit in a byte, you'd need to convert them, so let ch: u8 = 'A'; won't compile. But ASCII characters can fit in a byte, so there is syntax to write that b'A'. My change means that the compiler will explicitly suggest you modify that earlier mistake to let ch: u8 = b'A'; which works, however it knows not to recommend nonsense like let ch: u8 = b'£'; the pound currency symbol isn't in ASCII so you keep the same diagnostic just explaining what's wrong with no suggestion.
Earlier quoted context omitted.
Including introducing new features on 6 weeks basics, just wait until Rust also gets 40 years of history.
It's true, improvements to Rust ship on a six week cycle, the next will be Rust 1.69. Nice. I was inspired to improve a compiler diagnostic earlier this year†, I benefit from that improvement already in the stable compiler today. Whereas if you "miss the train" with standard C++ you've got three years to wait each time, and of course the Powers That Be can ensure that oops, you just missed the train again... Of cours…
I doubt very much that Rust editions and backwards compatibility history will be able to survive 40 years with such diverse use cases, without introducing accidental complexity and corner cases along the way.
This assuming that we can still use Rust and not Crab , as if Rust also doesn't have its own show of politics.
Earlier quoted context omitted.
You know this is a red herring. Frequency of the release cycle is orthogonal to the amount of changes or even how long the changes are in development.
Just wait until Rust gets 40 years old. Pity I won't be no longer around to check on it, given average human life expectancy.
But "just wait until Rust will repeat C++'s mistakes" is just pure speculation. Language evolution doesn't have to make the language worse. Java, JS, C#, or Ada are pretty old now, and have been doing fine. Rust is well prepared for a 40-year lifespan with its edition system.
does this imply that type erasure via base classes will become a thing of past ?
In C++20, concepts don't really provide any new semantic feature that wasn't already available before. Just a nicer and cleaner syntax (often considerably so).
Earlier quoted context omitted.
In practice C++ Concepts don't do what you're suggesting. The C++ 20 Standard Library provides numerous concepts which have a very different semantic requirement than the syntax they're checking. If you violate the syntactic requirement of course that'll earn you a compiler error, but if you violate the semantic requirements that's silently an ill-formed C++ program, it has no meaning whatsoever and might do absolute…
I have been programming in C++ for almost 20 years [1] and I don't remember ever being bitten by accidental concept conformance. So I object to the "likely very common" description. Implicit conformance was very much an explicit design goal. [1] yes, concepts as an explicit language feature are new, but C++ has had de-facto concepts since Stepanov work on the original STL in the 90s.