From Carbon's README:
> C++ [...] is struggling to improve and meet developers' needs, as outlined above, in no small part due to accumulating decades of technical debt. Incrementally improving C++ is extremely difficult, both due to the technical debt itself and challenges with its evolution process. The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like modern generics system, modular code organization, and consistent, simple syntax.
Carbon will face the same issue as Dlang. Everyone agrees that Dlang is an improvement over C++ in many significant aspects, and a very impressive one at that, but in order to gain meaningful adoption the benefit has to be high enough to justify the pain of swimming upstream against the rest of the ecosystem. D never quite made it above that threshold, though perhaps in an alternate history where Google picked it up instead of pushing Go, it could have.
1. Being "C++ but nicer" is an awkward niche. It's not differentiated enough to overcome switching costs for C++ users. It's hard to justify risks of a new language, costs of hiring and/or code rewrites just for quality of life improvements.
At the same time being similar to C++ is a turn off for users who don't like C++ and look for something different.
2. D with a GC is not really competing with C++ in its core niche where C++ is irreplaceable, but rather with many many other GC languages for programs that can use almost any language. The idea of GC being optional is a hard sell, because it's an obvious switcheroo — without the GC you don't get all of the nice features, so GC-less D is even less differentiated from C++.
Carbon at least avoids the second problem. I'm not sure if Carbon's new syntax and semantic tweaks are different enough.
One unnoticed feature of D's GC is it enables safe memory allocation when doing CTFE (Compile Time Function Execution). This can be used even when the code being compiled for runtime does not link in the GC. It greatly increases the power of CTFE.
That is to say, if I want to use a third-party library, and that library was written to use the GC, and I want to _not_ use the GC, can I use said library? Or does using it require that I enable the GC for my code as well?
(Lots of D users use a mix of GC and explicit allocation. Each has their best use cases.)
May I ask what your concern is?
Hence, if you don't do GC allocations, or at least do not do them in your realtime loop, it will not pause.
D is not a GC language. It's a language with an optional GC. (It also does not have the code gen compromises that fully GC languages rely on, such as write gates.)
As soon as you disable the GC in D, you end up with a really awkward to use language, no closures, no exceptions, no dynamic arrays, I think you can't even use the common string in D without the GC.
People arguing that D can be used without a GC are just trying to sell you on something.
There is a flag to allocate them with malloc, and use RC.
> no dynamic arrays, I think you can't even use the common string in D without the GC.
Totally not true. You can't concatenate arrays (string are just arrays of char) with `arr1 ~ arr2` and you can't `new` them, but you can do pretty much anything else.
> People arguing that D can be used without a GC are just trying to sell you on something.
Of course, but C++ people have an unnatural aversion to GC also the D GC only ever collects if you allocate from it. No allocations == no collections.
For the most part, GC is a productivity enhancer, you can roll your own allocators, use malloc, etc. if you need to. You can statically ensure that some or all of your code doesn't use the GC and as expected there is a productivity/code maintenance price you pay for doing so.
If anything, D should stop pretending that it doesn't have a GC and stop trying to appeal to people who don't want a GC, it's a losing battle. D should just accept the fact that it is a GC'd language and start making the argument for why it's a better GC'd language than Java or C# or the host of other GC'd languages.
The vast majority of C++ developers do not want a GC'd version of C++, but it's possible that Java developers could be interested in a C++-like language that has a GC and good C compatibility.
GC is just one of the styles.
Yes, if you use "new" you get a GC allocation. But nobody makes you use "new". If you use the array concatenation operator, it uses the GC. But there are many ways to concatenate an array that don't use it.
As for closures, they get allocated on the GC only if they escape the stack frame. This is detected, and if you want to be told about it, annotate the function with @nogc.
What is that flag? Do you have a link to the documentation? I do remember talk about adding a feature that would allow exceptions to be allocated in @nogc code, but that was never ultimately implemented and looks to be postponed (to the best of my knowledge).
D is free to use for any purpose, being Boost licensed. We don't even keep track of who downloads it. Not that such info would do any good anyway, as anyone can host the distributions for download.
So yes, you can secretly use D at work, and we won't be able to tell on you!
To me optional GC is a major downside. Because the option to use the GC exists, I don't believe that the language and the library ecosystem will have first-class support for the no-GC users. For example, DUB's website doesn't have an option to search only for no-GC packages. I don't want to be restricted to the worse half of the language.
Doing everything that C++ can do is not a reason to switch away from C++. C++ can already do everything that C++ can do.
D has some nicer syntax, and neat little features like universal function/method call syntax, unittest blocks. But I can't go to my boss and say "Hey, we should rewrite our product in D. Why? Because the unittest block is a really cool idea".
Indeed, you should not change languages based on only one thing. It's also pedantically true that one can do anything in any Turing-complete language.
A much more interesting point is how productive one can be in different languages.
A little over a decade ago the industry (of people that cared about C++) were psyched about C++11. Today people don't really give a crap about C++20 other than checking that their code still compiles and people barely know what's in C++23. The air has been let out of the balloon, since other ecosystems have grown up and are easier/better to use than C++.
I know of multiple shops that would have "never" moved off C++ that have switched to C# or Go. The performance is there and the headaches aren't.
And frankly, C++ doesn't have an ecosystem. There's boost, abseil, folly, and to an extent Qt. Everything else is C and wrappers around C. Moving off C++ means adopting a language with a good standard library and/or an actual ecosystem that does useful things - which C++ massively lacks.
Rust is definitely in the wings and growing, it's just a shame that so much of the industrial use turned out to be crypto. Once C++ developers get over their irrational fear of generic programming and package management, Rust and it's ecosystem become extremely compelling.
C and C++ don't have a fear of package management. On the contrary, they're packaged in more ecosystems than probably anything else: gems, wheels, rpms, debs, nix, conan, vcpkg, you name it. The hard part of C and C++ packaging is making it easy for projects to integrate in all those ecosystems.
If carbon goes the same route as Rust, Go, etc. by standing up yet another hermetic ecosystem, it will be very clear that it's not really trying to replace C and C++; it will merely be trying to carve out a new niche.
I think one thing that Carbon has going for it is that it's bidirectionally compatible with C++, in the same way that Kotlin is with Java (or Swift with ObjC). If you have a massive C++ codebase, you're supposed to be able to just add new Carbon code, without changing any of your existing codebase. This should allow gradual adoption at whatever pace you want, which should help adoption a lot.
I'm waiting for some other shoes to drop here. There's some fine print in this promise that isn't widely grokked yet.
Code migration is part of the Carbon language requirements. Carbon is being designed because other existing langages didn't focus on this aspect.
The specific details and edge cases are probably to be determined.
It's clear that compatibility is a goal but it's clearly not a feature yet, so we should be careful to talk about carbon as if it has that feature, especially given how hard that feature will be to implement and support.
I'm more confident that Google will be able to meaningfully use carbon in its monorepo than I am that it will be a good replacement for C and C++ for any given non-Google project.
In practice, none of this really matters. For example, generics are just one way to do code organization, you can write codebases that are clear, maintainable, and reliable, without ever touching generics once.
This had very little to the discussion. Of course it can't be replaced. Code is created by humans, and as long as we have opinions nothing gets truly replaced. Just decreased usage over time.
> C++ and Switft just became "more dominant".
Yup, like this. Of course a general statement is no.
I have very little interest in this topic. But I seen this SAME comment a million times on anything thats new that attempts to challenge something. And as usual whether something "dethrones" something is less interesting than what changes or ideas that it offers.
Just like ALL those you listed, they didn't replace any of those, but they definitely challenged the ecosystems, or improved the old ones.
Naunce discussion is far more interesting.
For example, why do you think Carbon won't be able to gain dominance over time? I mean I think thats a huge hurdle too.
As "Unix haters handbook" says: C++ is to C, what lung cancer is to lung.
As they compile their C code using a compiler written in C++. (GCC and Clang are both written in C++).
I like C++ and Rust. If I meet a dev who likes Go, I can guarantee we won't agree on much.
70% of security bugs are memory safety issues. That's a lot of real problems.
> It has a lot of irks, but the problems people run into are problems that others already solved, a thousand times, over the last half century, in many different ways for many different iterations of the language.
People run into memory safety issues more often in new C++ code.
https://www.chromium.org/Home/chromium-security/memory-safet...
https://security.googleblog.com/2021/09/an-update-on-memory-...
https://github.com/microsoft/MSRC-Security-Research/blob/mas...
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
https://media.defcon.org/DEF%20CON%2030/DEF%20CON%2030%20pre...
https://advocacy.consumerreports.org/research/report-future-...
https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...
https://github.com/google/sanitizers/blob/master/hwaddress-s...
https://security.googleblog.com/2022/12/memory-safe-language...
Run your code in a WASM sandbox or on a GPU, problem solved.
- WASM will be available even more places than the JVM
- way more languages will target WASM than ever did the JVM
Personally, I cannot wait for a WASM future.
Being able to target WASM for the 90% of apps that it is fast enough for and being able to use the same language and libraries to target native when required….is going to be awesome.
I really like the CLR. A more widely adopted version of something similar ( WASM ) is attractive.
https://en.wikipedia.org/wiki/List_of_Java_virtual_machines
https://en.wikipedia.org/wiki/List_of_CLI_languages
And this ignoring all the bytecode environments that have existed since the 1960's.
Assuming your WASM sandbox is airtight, that would work. But there are still ways to break out or cause damage because within the sandbox, its like a flat address space with 0 modern protections like ASLR, stack canaries, page protection, etc. (unless you manually compile it in yourself). See [0]
* [0]: https://www.usenix.org/conference/usenixsecurity20/presentat...
I do think more things running in WASM or WASM-like VM's could help a lot, but I'm not sure what the GPU part is supposed to mean.
Are these really real enough problems, though? If you're defending against state level attackers it's a problem. But how much do these really impact Joe Schmoe average computer user?
People targeted by state level actors are people too, and software should protect them if it can, and not having mem related bugs is definitely possible :)
You don't have to be the final target to be a botnet node... you don't even need to be a specific target to get a keylogger that tracks your logins for financial websites.
Yes... it is REALLY REAL ENOUGH,
Because I think the answer is all of us.
Also, the targets of state level actors are using the same software as the rest of us. If ours is insecure, theirs is too. Have you seen the list of Open Source vulnerabilities the US Gov has not patched?
If you oppose change so much that you just shrug in the face of free 70% reduction of risk I don't know what to tell you.
It does not have many, but it has one and it's big. It's not memory safe.
Check out this talk by Herb Sutter, around minute 43:
This is the first time a government [see note] has actually issued guidance to industry broadly that was the barest paraphrase away from "where possible don't use C and C++"
[1] https://www.youtube.com/watch?v=ELeZAKCN4tY
[2] https://www.whitehouse.gov/briefing-room/presidential-action...
[3] https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
Modern C++ has made big inroads into removing memory safety issues though. Memory safety bugs are relatively uncommon in modern C++ compared to pre C++11 times.
You could argue that C++ is still "unsafe by default" and you'd be right. But most C++ programmers use smart pointers and unique pointers rather than raw pointers now, vectors instead of raw arrays, etc.. And it does make a big difference.
std::string foo = "foo";
const std::string foo2 = absl::StripAsciiWhitespace(absl::AsciiStrToUpper(foo)); // in Python: foo2 = foo.upper().strip()
std::cout << foo2; // garbage
Yeah, all technically the user's fault, but it gets pretty tiring worrying about this stuff when you're writing a high-level application and the few CPU cycles you save don't really matter. No matter how good you are, you will make mistakes, and the chance of one bug corrupting memory in your whole process increases exponentially with the LoC written. Also I have to point out the irony in a language being type-safe but not memory-safe.
Also, totally user error, but I didn't expect Java-looking class syntax to initialize member variables to garbage by default. That should at least be a compiler warning.
Misnomer aside, there is no contradiction. Type safety is much easier to reason about at compile time than memory management. So, it shouldn't come as a surprise. You need a rust like "borrow checker"-by-default functionality.
The contradiction is when the veteran SWEs I work with say we use C++ instead of Python for the added safety of compile-time type checks, treating dynamic typing like a bigger risk than memory trampling (never mind that Python has type-checking too if you really want it).
C++ does have issues. However few languages can handle complex problems well. (Rust is very intriguing for the possible ability to do things at the same scale)
If you use the wrong type in Python, you get an unhandled exception failing to find a property or something, that's about it. Maybe there's a contrived scenario where it'll succeed in a wrong way, but again that's a smaller blast radius
C++ has exceptions too, but I've never used them, so idk. The abseil statuses end up being used like DIY exception handling, and it's ok but a bit easier to mishandle something than in Python. And a segfault cannot(? or shouldn't) be caught and will crash the whole program.
For short programs Python works great, but it doesn't scale to large programs.
The problem is C++'s priorities. Priority #1 is performance, and if you look closely, nearly every single instance of this buggy-program hostile attitude comes down to the language and libraries absolutely refusing to do any kind of dynamic safety checking by default. UB can be traced directly from "it's too hard to reason about the implications of buggy programs" to "well, don't do that, stupid programmer".
I'm no expert in this, I'm just a guy who's sick of writing web backends in C++ for no reason.
No. It's not. It's designed by committee -- impossible to deprecate old misfeatures, trying to entertain everybody but please nobody.
<source>: In function 'int main()':
<source>:6:54: error: conversion from 'absl::string_view' {aka 'std::basic_string_view<char>'} to non-scalar type 'const std::string' {aka 'const std::__cxx11::basic_string<char>'} requested
6 | const std::string foo2 = absl::StripAsciiWhitespace(absl::AsciiStrToUpper(foo)); // in Python: foo2 = foo.upper().strip()
| ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
ASM generation compiler returned: 1
The garbage comes from AsciiStrToUpper returning a new std::string which StripAsciiWhitespace takes as a string_view (implicit conversion). By the time you print foo2, the string is already freed.
For those downvoting, please explain why you think string_view should take ownership of an rvalue string
I didn't downvote, btw. I don't do that in general.
Just turn people loose on your codebase without supervision and be really surprised that the hackers make off with your data?
You, sir, are arguing from bad faith as your obvious mission is to promote “rust in all the places”.
But sure, you can still make the error with expiclit types.
But "Herb Sutter says you should use it, he even gave it a catchy name/acronym" is as good as it gets. And he does so AFAIK in the same place he created the "Almost Always Auto" name: https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style...
Notice that he says "the main reasons to declare variables using auto are for correctness, performance, maintainability, and robustness—and, yes, convenience, but that’s in last place on the list.". He is arguing literally the opposite of what you do, that using auto avoids bugs ("for correctness").
I'm not going to argue in favour or against "Almost Always Auto". But I see no problem calling it "Modern C++".
* Herb Sutter being the convener of ISO WG21
Even if you use string_view on the LHS instead of auto, pretty easy to miss the bug here.
It's even better if your language has a way to express "the return value points to data from the input argument, so it's a compile error to pass a rvalue string to this function". The second we got a language able to do that, usable everywhere where C++ is, (yes, that one) the incapacity of C++ to express this became "a problem with C++". Our expectations have just increased.
Surely it can be catched via static analysis if you suppose the common case that the return value is a function of the argument, and not pointing to some static global data. But you will get false positives when somebody does the uncommon case. There is a lack of expressiveness in C++ here.
Last I remember, the lifetime profile stuff was there, but there was still no way to add your own annotations. For some reason, I didn't hear too much about any of this, it was
- clang is working on it
- clang is working on it
- clang is working on it
- Visual Studio has it
- clang is working on it
- Silence
gcc still has nothing, right?
There are so many details you need to keep track of, and eventually you make a mistake. Now, yes, i know what all of that does, and how they are supposed to be used, but it does not remove the cognitive load.
Many languages have a substantially lower cognitive load when doing something trivial, such as ToLower().ToUpper(), etc.
Let’s not make this a language war, there has to be some programming language that does low-level memory operations without batteries included for some types of technologies. When I write code in C++ and I want something like garbage collection or ref counting I can reach for a shared_ptr.
If you don’t want to concern yourself with types, values vs references, or manual memory management don’t choose C++. The default handling is sane if not necessarily intuitive. You shouldn’t create a ref or pseudo-ref (string_view) to data that is not on the heap and no longer allocated to the stack - seems sane. This problem could be easily caught by breaking function calls into separate lines and explicitly specifying the types at each step.
From Xerox point of view, yes. Unfortunely they lost to the UNIX workstation market.
Interlisp-D, Smalltalk and Mesa/Cedar.
Believing that one size fits all is a sure way to alienate a lot of people who don't fit that size. Right tool for the right job and giving the freedom for people to solve their problems in the best way is a better way to win people over.
Nothing to do with the technology.
Hence why I love why Android is so locked down to native code, and Apple is doubling down on Swift.
Google also has a lot of stuff in the middle where they're fine with sacrificing a little speed for a lot more safety, but Java etc are too slow. Golang was supposed to satisfy that, but it was too big of a leap from C++.
Is Cpp systems-level language? As I see, the problems arrives from the fact that Cpp is a multi-paradigm language, and as such contains a near endless wealth of features to combine. Also modern Cpp takes a clear direction away from low level to (relatively) more high-level language. The problem really comes from the combination of low level and high level paradigms in the same language/codebase, where the expectations of the behavior of each piece of code can vary wildly.
> ... will have these sharp edges handled differently
Perversely, plain C, often has a lower cognitive load than Cpp. This is because you must always manually handle pointers, types, object lifetimes, etc. Now, this does result in a high cognitive load, BUT, the cases as in Cpp where you might combine auto, with a temporary, with a pointer inside, referring to some unseen resource, cannot happen, because you cant do that in C. So the worst case in cognitive load is never as bad as in Cpp. The lack of features means less possible combinations to shoot yourself in the foot. (Though C does still have many, nor is C an ideal language)
> Let’s not make this a language war
Discussing the problems of Cpp is not language war. Nor is understanding the merits and problems of the Design of Cpp.
> If you don’t want to concern yourself with types, values vs references, or manual memory management don’t choose C++
But IF YOU DO write Cpp, there is no escaping them. Which is my point.
Now, if you wrote absl::string_view foo2 = etc., you'd have a dangling view for sure. In practical industrial usage, you'd build with an address sanitizer (it's built into clang: -fsanitize=address), which should catch that issue.
We use an address sanitizer in tests but not in production. IIRC we had one untested log output line like this that caused corruption in prod.
Note that std::vector's at() predates C++11, whereas std::span was added in C++20. It's a myth that C++ is getting more memory-safe; in many aspects it's actually regressing.
In a greenfield project where you control every line of C++ code, you can easily achieve very good safety using nothing but ancient C++ features.
Not just memory safety. I mean, you can make your own numeric types that do overflow checks and throw exceptions or whatever. It probably won't be very fast, but it will be solid.
People have used C++ (ancient C++) to make numeric types with units, where you can't add "kilograms per second" to "meters". I remember that from some talk thing I went to in 1999.
All three major C++ standard library implementations have an option to enable assertion checks in both std::vector and std::span operator[]. Enable them unless you are in such a resource limited environment that you can't afford the checks (unlikely). The only reason the standard doesn't require the checks is to allow C++ to be usable in those resource limited environments. You could argue the checks should be enabled by default, but that's not something for the standard to decide, complain to your standard library vendor.
Modern C++ adds new features that allows you to write code that doesn't have as many memory safety problems, but all the unsafety (is that a word?) that existed in the past still exists.
Removing features that allows memory unsafety will probably never happen, because one of the main reasons people use C++ is all the legacy code will still be used for decades.
It's great that you can write C++ using only the newest features, and that does increase safety. But that doesn't offer the same guarantees of languages designed to simply not have these kinds of problems, or that by design flag the points in the code where safety can't be guaranteed by the compiler.
If the code is small and doesn't change or doesn't have to last for too long, that's OK. But when it's changed over the years, it's pretty much impossible to guarantee that the unsafe parts are kept small and contained, especially as programmers leave and new ones come in.
So is there a compiler flag or external linting tool that can generate warning messages when you're using an older memory-unsafe technique where a safer and more modern technique could replace it?
I remember when people said the same thing about C++03. Plus ca change.
In C++98 you could develop a program with some unsafe core of whatever resource management you wanted, and then wrap it with the right classes so that it can't be misused.
After circa 1995, anyone struggling memory safety issues in greenfield C++ code that was completely under their control (no legacy) had to be a supreme goofball not to be leveraging the language to make that sort of thing go away.
The "Ragel" tool they used evidently generates C that uses raw pointers:
> The Ragel code is converted into generated C code which is then compiled. The C code uses, in the classic C manner, pointers to the HTML document being parsed, and Ragel itself gives the user a lot of control of the movement of those pointers. The underlying bug occurs because of a pointer error.
The bug in these Ragel-generated parsers was somehow hidden or compensated for by some buffering strategy, which they tweaked when introducing some new kinds of parsers "cf-html". Those didn't have the bug, but the different buffering turned on for them exposed the bugs in the Ragel based parsing.
https://web.archive.org/web/20170223233000/https://blog.clou...
I'm looking at the Ragel State Machine Compiler user guide. Chapter 5 (Interface to Host Program) makes it quite clear what sort of thing the Cloudfare people chose to grapple with. Ragel will write code for you planted into middle of any C function anywhere; you must provide numerous predefined variables, some of which are pointers to data, and so it goes. For some languages, there are safer interfaces: for Java and Ruby there is a buffer and instead of a pointer there is an index into it. Ragel could have been upgraded to have actual C++ support of some kind.
Cloudbleed was found out in C code, with the usual issues dealing with bounds in C.
The effort needed on tooling would be significant though. I don't see that happening and overtaking Rust.
(btw the correct spelling is Achilles, Achilleus, Akhilleus, Ἀχιλλεύς)
VC++ has some annotations on that sense, problems are two fold, get the vendors to agree, and the C subculture that security actually matters.
Thanks for the correction.
For example, with -Wold-style-casts you can diganose every use of the (TYPE) EXPR casting notation, which is often seen in the lower-level C-like C++ code for punning memory.
Somewhere in some commonly included header for the project you can write declarations for C functions that should not be used, marking them deprecated. Then if people introduce strcpy or malloc or whatever you don't want, that can be diagnosed (and can fail compilation, if desired).
> It does not have many, but it has one and it's big. It's not memory safe.
It's not as big as a deal as c++ opponents make it out to be. The ratio of memory bugs to other bugs at work is basically zero. The problems that are holding our product back have nothing to do with memory safety. Of the long list of problems we need to solve, that just isn't one of them. If the only thing a new language offered over c++ was that I don't have to think about that 0.01% of bugs anymore, but in exchange I get either a garbage collector or a borrow checker to fight with, I would not switch.
Enough of this already. Not going to discuss ancient code. I currently using modern C++ and it has enough features to keep one's code reasonable safe if that was the goal. And frankly I do not remember any reported bugs in my production caused by "memory unsafety". Just plain old logic errors every once in a while.
The computer isn't "memory safe." If you want a language that can express every function of the hardware it runs on, you expose this fact as well.
Careful management of "unsafe" blocks might be an answer, but I suspect we're going to have to dig way deeper until we find a truly "safe" solution. At that point, would it actually matter which language you use?
https://www.chromium.org/Home/chromium-security/memory-safet...
https://msrc.microsoft.com/blog/2019/07/a-proactive-approach...
You can see the clear conflict in the mentality of these new languages. "Fast and, somehow, safe!" It's missing the forest for the trees, much like your retort.
People are. Like on Android.
> In Android 13, about 21% of all new native code (C/C++/Rust) is in Rust. There are approximately 1.5 million total lines of Rust code in AOSP across new functionality and components such as Keystore2, the new Ultra-wideband (UWB) stack, DNS-over-HTTP3, Android’s Virtualization framework (AVF), and various other components and their open source dependencies. These are low-level components that require a systems language which otherwise would have been implemented in C++.
> To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
> We don’t expect that number to stay zero forever, but given the volume of new Rust code across two Android releases, and the security-sensitive components where it’s being used, it’s a significant result. It demonstrates that Rust is fulfilling its intended purpose of preventing Android’s most common source of vulnerabilities. Historical vulnerability density is greater than 1/kLOC (1 vulnerability per thousand lines of code) in many of Android’s C/C++ components (e.g. media, Bluetooth, NFC, etc). Based on this historical vulnerability density, it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production.
Source: Memory Safe Languages in Android 13 https://security.googleblog.com/2022/12/memory-safe-language...
But sure, keep telling yourself that it’s possible to write C++ code of this quality by being more careful or using some magical sanitizer or by hiring better developers or whatever.
Linus Torvalds - 2022
Even in my comment I quoted a passage that said "we don’t expect that number to stay zero forever". This is important. Although it has been successful so far, there will be bugs in it, even the odd memory safety bug.
That's still progress! Fewer bugs than before is progress, (mostly) eliminating a class of bugs is progress. I only addressed a person who was saying "there will still be some bugs, so there's no point tackling this at a language level". They're unable to grasp the idea of progress.
I can honestly say I've never known anyone who has written a lot of code in both C++ and some other language who has this opinion. I'd say, to the contrary, that almost every feature and characteristic of C++ is a problem - it's either a complete disaster in terms of programmer ergonomics or it makes it way too easy to create terrible bugs. It's _all_ wrong.
Once you understand lifetimes well C++ is a joy to write. 99% of all the complaints about C++ are 1. lack of automatic bounds checking, which is trivial to implement yourself 2. memory management problems because people have a poor mental model of how it works, which can be learned.
Well, so is Rust. You even have usable macros and templates that are't cancer to write.
While not a shot at your choice, a C++ dev that I follow a bit is the creator of SerenityOS. Many times and in many of his YouTube videos he has sung the praises of C++ and called it his favourite language. Presently, he is writing his own language, Jakt, to replace it. I find that interesting.
or memory management problems because Qt uses a different string type than glib uses a different string type than std, each with different ownership semantics, and by the way some of these claim to be thread-safe while others don’t say clearly one way or the other in the docs, except actually Qt’s copy-on-write implementation claims to be thread safe but assumes that the compiler inlines the mutation operators so if you forward-declare `struct QString` instead of #include <QString> then the operations might not be thread-safe…
i think the CoW problem might have been with Qt’s set type, not its string type, but you get the idea. it’s not just the language: it’s the library ecosystem too. it’s that any time i dive into contributing to a new C++ project i have to learn potentially a new memory model, one which is likely assumed instead of documented.
RAII presented an opportunity to normalize all this stuff; i’m not sure how significantly it’s unified things: i suspect it’s effective primarily in greenfield projects.
That doesn't make any sense. How is inlining going to affect thread safety? And (only) forward declaring a type won't let you do any mutations since at that point it's just an opaque name withoutout any known members.
glibmm
i’m sorry that i’m fuzzy on my Qt CoW issue. it was 8 years ago or so, i could probably dig up the ticket about it but the point was that thread-safety is just a thing you’re guessing at whenever you’re using C++. other languages have radically reduced that guesswork.
>> it’s not just the language: it’s the library ecosystem too.
> And a new language won't fix that - especially when your idea of the library ecosystem for C++ already includes C libraries.
that doesn’t match my experience. taking the C++ codebases i’ve contributed to, more use a non-std string type than do. e.g. LMMS uses QString, Stepmania uses its “rage” rstring type. neither of these are small projects, both have download counts in the multi-millions.
new languages do address these problems. when i see a project in Rust (or Go, Typescript, …) that i’m thinking of contributing to, i can be fairly confident it’s using the standard String type and that i can come up-to-speed on its memory model instantly — when i see that same project written in C++ i don’t know if it’ll take 10 minutes or 10 hours to understand its memory model, and believe me that uncertainty does impact which projects i choose to contribute to today.
But that has to be learned for each CPP file separately.
I wrote plenty of code in Qt and C++ (up to around C++11) and I don't think it was that bad. I then moved on to JS / PHP (purely for money) and now Rust.
C++ is not that bad. Templates can be a bit hairy and slow.
Now that we have Rust to compare, having safety would be nice. It wasn't an option back then. You were either shooting yourself with undefined in scripting languages or with null pointers in C/C++. Having a dependency manager a-la npm or cargo would be nice, but it was never an option in the past.
But things are mostly fine.
Be careful with that, because it only takes government to decide to heavily tax something or simply phase out something for it to go away. Eventually the minority cost rises so it becomes a self full-filling prophecy.
That, will not apply to C++ or languages in general.
Could countries that currently don't really have cars? Yeah, probably. In the same way that a market segment that doensn't use C++ can decide not to use C++. Could a country like Vietnam? Doubtful, but maybe. A market segment with low C++ penetration can probably decide they want to collectively move away from C++. Could China? Not anymore, no. C++ drives too much software in the market segment to make sense to replace, even if the grass is greener on the other side of the language fence. Could the US or the EU ban cars (and again: not ICEs, but cars, full stop)? Let's all try not to laugh.
How much ALGOL do you see out there?
There will be almost no Objective C at some point.
There will be almost no Visual Basic.NET at some point.
A C++ replacement may take longer than the rest of my life.
It is possible though that we may not be that many years away that, for new projects, it may be uncommon to choose an “unsafe” language.
Give it time. Unlike the other examples one company (Apple) has full control here. There is basically zero demand for Objective-C outside of development for Apple platforms.
Apple is already making Swift only features and APIs and is deprecating older things. Obj-C is arguably legacy already, but still works fine.
I’ll bet plenty of money there will find a day when Apple says “This is it, next release it’s out of the toolchain”.
Existing developers often have Obj-C code (I do), but the biggest user is Apple. So they can’t kill it tomorrow. But its days are numbered.
No one is in that kind of position with C/C++/JS/Java.
Just like Kotlin hardly matters outside Android.
So based on the article's own observation: no, of course not. The more interesting question is "will it stand on its own?" to which the answer is "only if it actually solves so many problems with the thing it's trying to supplant that it makes sense to give it a serious try".
And C++ just... doesn't have that many real problems. It has a lot of irks, but the problems people run into are problems that others already solved, a thousand times, over the last half century, in many different ways for many different iterations of the language.
Pretending you can replace C++ is like pretending you can replace cars. Not just "create EVs" but straight up replace cars. Good luck, you won't succeed if that's your goal, so hopefully you realise you need to focus on making a decent language that some folks might consider using instead of C++ for some of their work, instead of creating "the successor to C++".