161–170 of 209 posts
After the talk, the activity on it is nearly zero since then, in a world where ideas are cheap, show me the code, this does not seem promising to me. On the other hand, carbon has been very actively developed since its announcement, which also claims to be a typescript-for-c++. Now it also wants to be a memory safe: https://www.youtube.com/watch?v=1ZTJ9omXOQ0 I'm forced to learn rust but I hope carbon will take off A…
Earlier quoted context omitted.
> The rate of safety defects between major C and C++ projects appears similar at first glance How come? Surely there would be fewer memory leaks in a code base with proper RAII than in C code with malloc and free all over the place.
Yes, this is a common theory, but I don’t see evidence for it in the hard numbers. Taking two of the most popular projects in each language, with a comparable LOC count, the numbers look surprisingly similar year over year: Linux kernel (C): https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm... Chrome (C++): https://www.cvedetails.com/product/15031/Google-Chrome.html?... There’s some variability year over y…
Earlier quoted context omitted.
That seems like missing the point of the article. What I understand the author to mean with Dart plan vs Typescript plan is the way these languages approached evolution of the base language (JavaScript). Dart aimed to replace JavaScript completely and isn’t very compatible with it, leading to issues like not being able to leverage the existing library ecosystem. While the Typescript approach enhances the base languag…
Herb would like to associate Cpp2 with Typescript (which is generally considered to have succeeded) and other 2022 C++ Successor Languages with Dart (not so much). Herb emphasises the way in which what he's done is like Typescript and de-emphasises ways in which it's entirely unlike Typescript. I guess that's smart positioning. But a big problem Herb has is that the real alternative isn't any of those 2022 C++ Succes…
In that sense, cpp2 might get to the point of being usable while having perfect interop with C++ (as in, you can use any C++ library trivially, and you can mix it with C++ in a codebase on a per file, maybe even within files, easily) before Rust or swift or Carbon.
Herb is infinitely more qualified to speak on the matter than I am, but I don't think I understand the point. We've had multiple decades to bring C++ under control for safe general purpose usage and it's still very loosey-goosey, to the point where people are rightly afraid to start work in it not because it's a bad or deficient language, but because keeping codebases sane is challenging and requires a lot of discipl…
I think the reality is that companies like Microsoft, Google, Apple want to write C++ but safer. The reason you're seeing Herb and Google's Carbon on the "ok fine well make a new language which has C++ interop instead of fixing C++" is because the C++ standards have been resistant to evolving the language into something that those companies want, to the degree that they may end up adopting Rust despite the absurdly h…
Earlier quoted context omitted.
> The rate of safety defects between major C and C++ projects appears similar at first glance How come? Surely there would be fewer memory leaks in a code base with proper RAII than in C code with malloc and free all over the place.
Yes, this is a common theory, but I don’t see evidence for it in the hard numbers. Taking two of the most popular projects in each language, with a comparable LOC count, the numbers look surprisingly similar year over year: Linux kernel (C): https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm... Chrome (C++): https://www.cvedetails.com/product/15031/Google-Chrome.html?... There’s some variability year over y…
Earlier quoted context omitted.
C++ adds so many additional security footguns over C, that I find this line of reasoning hard to accept. The problem with C++ is not that people are using C constructs with it, the problem is that the language design itself is deficient. Are you aware of any systematic review that shows evidence that C++ is safer than C? The rate of safety defects between major C and C++ projects appears similar at first glance, and…
C++ containers such as std::vector and std::array have bounds checking at least, though I have not saw them used very much. Bounds checking instantly eliminates buffer overflow related unsafety, but not having it as the default is not good.
Herb is infinitely more qualified to speak on the matter than I am, but I don't think I understand the point. We've had multiple decades to bring C++ under control for safe general purpose usage and it's still very loosey-goosey, to the point where people are rightly afraid to start work in it not because it's a bad or deficient language, but because keeping codebases sane is challenging and requires a lot of discipl…
I think the reality is that companies like Microsoft, Google, Apple want to write C++ but safer. The reason you're seeing Herb and Google's Carbon on the "ok fine well make a new language which has C++ interop instead of fixing C++" is because the C++ standards have been resistant to evolving the language into something that those companies want, to the degree that they may end up adopting Rust despite the absurdly h…
Herb's Cpp2 announcement on the other hand was clear from the outset that Cpp2 is not safe. It's aimed to be fifty times safer but that seems untestable, maybe even meaningless.
The immediate trigger for Carbon was P2137. Basically P2137 says "C++ should prioritise performance over safety, safety over compatibility" and WG21 is like "No, absolutely not". That's a set piece, nobody was astonished this happened, but getting it down on paper avoids executive argument. Google could have spent six years convincing non-expert people that C++ really isn't going to deliver, or it could secure a piece of paper which says they don't even want to and eliminate that whole discussion.
Apple have pretty clearly settled on Swift. I'm not convinced they can write all their bare metal stuff in a Swift dialect, or that they'll be able to in time to not need anything else long term, but clearly the vast bulk of new work at Apple will trend to Swift. Apple are quite good at single minded and "Write all new code in Swift" is a single minded idea. I have no idea why anybody would buy from a company like that, but they're very popular so what do I know.
Microsoft are much less single-minded. I doubt they could settle on Swift (or Rust, or even say sticking with C++) as a company wide policy even if they wanted to. But equally they're not interested in finding themselves as "last man standing" for C++.
Herb is infinitely more qualified to speak on the matter than I am, but I don't think I understand the point. We've had multiple decades to bring C++ under control for safe general purpose usage and it's still very loosey-goosey, to the point where people are rightly afraid to start work in it not because it's a bad or deficient language, but because keeping codebases sane is challenging and requires a lot of discipl…
It's extraordinarily difficult to build a significant C++ codebase without segfaults and UB. You end up wasting a huge amount of time debugging that stuff.
Any time I've lost fighting Rust's borrow checker has easily been paid off by not having to debug segfaults.
Earlier quoted context omitted.
Such a shame it isn't open source, so it's really impossible to eyeball QoI without actually investing a huge amount of time into the language. (Plus the usual bad things about closed source.) I have no doubts about the qualifications (or even intentions) of the author, but one feels that a language meant for serious things should have an open implementation and/or standard. Of course, I realize this may not align wi…
Once upon a time the only C and C++ compilers that one could get for free, were the ones available alongside UNIX tapes.
Neither TypeScript nor Dart are relevant technologies to people interested in C++. It's weird to refer to these arguably bad web technologies to market an unrelated initiative.
That seems like missing the point of the article. What I understand the author to mean with Dart plan vs Typescript plan is the way these languages approached evolution of the base language (JavaScript). Dart aimed to replace JavaScript completely and isn’t very compatible with it, leading to issues like not being able to leverage the existing library ecosystem. While the Typescript approach enhances the base languag…