Get the top HN stories in your inbox every day.
tialaramex
pjmlp
Right now, Circle looks like the only Typescript like evolution path for existing C++, with a production quality compiler.
Unfortunately WG21 seems to have some issues with any ideas coming out from Circle, going back to its early days, and I don't see them being willing to adopt Sean's work.
Which is really a pity, as he single handled managed to deliver more than whole C++ compiler folks, stuck in endless discussions about the philosophical meaning of the word safety.
Maybe at least some vendor in high integrity computing domain does adopt his work.
jokoon
> Unfortunately WG21 seems to have some issues with any ideas coming out from Circle, going back to its early days, and I don't see them being willing to adopt Sean's work.
What reasons? Are those valid?
pjmlp
It was due to the metaprogramming capabilities, due to how Circle enables to use full C++ at compile time instead of constexpr/constinit/constval, David Sankel has a talk where he jokes with the WG21 decision process that was behind it,
"Don't constexpr All the Things", from CppNow 2021,
triblemaster
from what I understand, there's a price Sean is asking for his work which no one is willing to pay at this moment.
wrsh07
I'm very confused by the love for circle - there's a GitHub that hasn't been updated for 7 months that doesn't have a license.
When I first heard about it, a lot of the ideas seemed interesting, but are there users of it?
I think my biggest question is "what is the goal here?"
For carbon they're pretty explicit that it's a research prototype. If anything is to come if it, it will need to be usable at Google's scale (they have real issues with build times, they build from head so abi compatibility isn't required, etc)
Herb wasn't really designing cpp2 as a successor language so much as a playground to understand what features might make sense to propose for adoption in c++.
What is circle? It's more than just some project, but the ideas haven't been adopted in cpp and the compiler repository isn't being updated
steveklabnik
Circle is not open source, that’s correct.
dwheeler
I think that's automatically a dead end, then. People have inceasingly abandoned closed source compilers, they create a huge risk if the maker decides to stop maintaining it. Most languages that people pick up have an open source software implementation.
undefined
Vt71fcAqt7
>Carbon wants to ship a finished working Carbon language, then bolt on safety (somehow) but, only for some things, not data races for example, so, you still don't actually have Rust's Memory Safety
I'm not sure this is correct. As I understand it, Carbon's plan is to add a borrow checker like Rust's.
From a recent talk[0][1] by one of the lead developers:
>Best candidate for C++ is likely similar to Rust’s borrow checker
[0] slides: https://chandlerc.blog/slides/2023-cppnow-carbon-strategy/in...
[1] relevant timestamps:
tialaramex
Chandler has explicitly said that he doesn't see a reason to solve data races.
The borrow checker isn't enough on its own to solve this in Rust, Sean explains (probably deeper in Circle's documentation) that you need to track a new property of types which is infectious, Rust does this with the Send and Sync traits.
chandlerc1024
"Chandler has explicitly said that he doesn't see a reason to solve data races."
Er, the slide title says that solving this is highly desirable, just not a strict requirement for security purposes.
Not sure how that's the same as "doesn't see a reason to solve data races". I see lots of reasons. I just think it is possible to achieve the security goals without it.
FWIW, I'm hopeful we'll end up including this in whatever model we end up with for Safe Carbon. It's just a degree of freedom we also shouldn't ignore when designing it.
Vt71fcAqt7
You're right. In fact it was in the previous slide[0] from that same talk. Thanks for pointing that out.
jandrewrogers
Many of the criticisms are of the C++ standard library design and implementation rather than C++ the language per se, particularly with respect to undefined behavior. Much of this, in turn, is because the C++ standard library is very old and anything new added to it must be compatible and interoperable with all of the older parts, whether or not it is a good idea. Borrow checking is a separate matter.
Modern C++ provides all the tools to build an alternative standard library from the ground up with most behaviors and interactions being defined and safe. This always seemed like lower-hanging fruit for a first attempt than changing the language.
C++ is commonly used in contexts where object lifetimes and ownership are inherently unknowable at compile-time, safety can only be determined at runtime. This is why memory safety annotations like 'std::launder' exist in C++. Trying force these cases into compile-time memory safety box is a source of much friction when using languages like Rust. They handle the 80% case where compile-time safety, destructive moves, etc make things easy for the developer but then significantly worsen the complexity, and therefore safety, of the other 20%. This isn't necessarily a bad thing but it intrinsically creates a market for C++ which explicitly allows you to handle these cases in a reasonable way.
Systems programming is full of edge cases that break tidy programming language models. This has to be accommodated reasonably in languages that want to wear the mantle of "systems language". Zig is an example of a new systems language that does this well in my opinion.
112233
> Modern C++ provides all the tools to build an alternative standard library from the ground up with most behaviors and interactions being defined and safe.
It also goes to a great lenght to embed standard library into base language as deeply as it can, and forces unsafe constructs. Just see how many magic types from std namespace are emmited by compiler when you use range for, initializers, or, worst of all, coroutines. Lambdas with capture by reference replace old fashioned dangling pointers with much more modern dangling references (you are free to copy lambdas that reference local variables :smiling virus with thumbs-up emoji:).
There is no way to get "another library", without making it not-c++. Those guys cannot even make no-exceptions/no-rtti a part of the standard.
Gibbon1
The dependence of C++ is one of the reasons I think C and C++ need a divorce.
Because while you'll never be able to create a new standard lib for C++ it wouldn't be hard for C.
112233
It's more like C++ made by that ISO committee and C++ used by actual users of C++ needs a divorce. They are so far up in the clouds adding features to language that mostly only help them to write less embarrasing standard library code, it hurts to watch sometimes.
Remember discussions that led to std::bit_cast? How absolutely everyone who processes binary data is wrong, because object of type, say, "unsigned" does not exist before it is created, so everyone casting pointers to parse packets is wrong, and only commitee is right?
It is doubly sad to see them claim compatibility to C (C++ is absolutely not compatible to C) as a reason for some features, or single pass compilation as a reason for others...
[edit] To clarify, on one hand, a lot of terrible misfeatures are kept in the name of compatibility, e.g. "int x = x;" ("fixing that will break too many existing exploits") or not being able to add friends without editing source ("debugging? we think it is overrated"), but then they go and proclaim basically all existing code that processes structured binary data as non-conformant.
roca
The claim that Rust makes the safety of 20% of code worse requires some justification. It is utterly contradictory to my experience. Having to do a dynamic check (an array bounds check, or `Option::unwrap`) does not make code "less safe".
charleslmunger
This post makes a cogent argument that Rust's rules that are normally enforced by the compiler makes unsafe rust harder to write without UB than other languages that are not memory safe by default.
roca
In my Rust projects (including Pernosco, 200K lines), less than 0.1% of code directly uses "unsafe". It's a long way from there to 20%.
pcwalton
> They handle the 80% case where compile-time safety, destructive moves, etc make things easy for the developer but then significantly worsen the complexity, and therefore safety, of the other 20%.
Thankfully we have actual data on this, not just random numbers, and no, this is not the case in practice.
geertj
> Thankfully we have actual data on this, not just random numbers, and no, this is not the case in practice.
Mind to share that data? I think it would be hard to get quantitative data either way.
pcwalton
70% of high severity security problems in Chrome are memory safety bugs: https://www.chromium.org/Home/chromium-security/memory-safet...
You can find several papers about Rust in particular by searching for [rust memory safety analysis].
mike_hearn
See for example https://suslib.cc/
pjmlp
Zig is basically Modula-2 with a revamped syntax for C folks, plus compile time metaprogramming.
And yes, many of these issues were already solved by other system programming languages outside the UNIX linage of programming languages.
orf
> C++ is commonly used in contexts where object lifetimes and ownership are inherently unknowable at compile-time
What specific contexts are these?
jandrewrogers
For example, anything that pages live objects to disk from user space. This is a common feature of high-performance/high-scale database engines and other data intensive software. Modern storage is larger than the addressable virtual memory supported by silicon so you can't mmap() it, and even if you could you wouldn't want to because using virtual memory is significantly slower than doing it from user space.
A single memory address can contain several unrelated live objects depending on when you look; a single live object can appear at different memory addresses over its lifetime without being moved; and live objects may not have a memory address at all. The hardware implicitly owns read and write references to these objects, which are not visible to the compiler and free to ignore the ownership model.
Consequently, you need a way to tell the compiler that the object it thinks exists at an address no longer does, and that object has neither been moved nor destroyed, and that there may be an unrelated object at that address that was never constructed. In these cases, compiler optimizations can generate incorrect code based on a naive analysis based on what is visible at compile-time. C++ provides ways to give this a defined behavior and indicate to the compiler when its lifetime model is incomplete so that it doesn't produce incorrect code. You can build ownership models on top of this that incorporate ownership that is not visible at compile-time.
Some C++ devs don't know these features exist, other C++ devs use them routinely. But the point is that C++ has specific features to address the case when lifetime analysis cannot be correctly done by the compiler.
pcwalton
Userspace-paged data is a tiny fraction of the amount of data that C++ programs, taken as a whole, process, and is a very weak argument for dropping static memory safety. Besides, because of unsafe, any Rust-like language, like Circle C++, will have the features needed to deal with such data too.
LegionMammal978
> Consequently, you need a way to tell the compiler that the object it thinks exists at an address no longer does, and that object has neither been moved nor destroyed, and that there may be an unrelated object at that address that was never constructed.
If anything, Rust is even more expressive than C++ in this regard: it has no concept at all of "an object at an address". You can (unsafely) cast a pointer from any type to any other type and read it, as long as the underlying memory is properly initialized. And if you're in a context where you know it will always be valid, or if you can check the validity at runtime, you can put a safe wrapper over the conversion.
For instance, the safe function str::from_utf8() converts a byte-array pointer into a string pointer, after checking that the encoding is correct. Nothing in memory is changed, and the old and new pointers form two different views that can be used simultaneously. And it's not magic: you could copy its implementation yourself, and your function would be just as valid as the standard-library version. Contrast with C++, where all memory must have one single type at any time, regardless of how much laundering you do.
The only kinds of semantic "ownership" in Rust are access restrictions caused by the aliasing rules (which just depend on the pointers in use, not on objects in memory), and local variables and temporaries being dropped at the end of their scope (if they haven't been moved elsewhere). All the high-level lifetime rules of safe Rust are built on top of those semantic rules, and a smidgeon of unsafe Rust can subvert them as necsssary.
nextaccountic
> Modern storage is larger than the addressable virtual memory supported by silicon so you can't mmap() it
Larger than the 48 bits address space of most 64 bits architectures?
pornel
I think the "unknowable" lifetimes are C++'s own making.
It's like types in statically vs dynamically typed languages. Types are unknowable at compile time when the compiler doesn't force them to be static.
And similarly ownership and lifetimes are "dynamically typed" in C++, because the compiler doesn't force them to be rigidly declared like in Rust.
kccqzy
Unknowable lifetimes are a necessary evil. Rust has them too. It's called RefCell. Without RefCell there are very useful things that are impossible to write in safe Rust.
pornel
But this needs to be explicit, and doesn't undermine other statically-known lifetimes (pointers to the inner cell can't escape it).
Just like statically typed languages have some dynamic dispatch features, but despite that still most of their types can be known with certainty.
geertj
First came across this 2 days ago and found this extremely impressive. There's also a YouTube presentation where Sean goes over the main features of Circle's C++ memory: https://www.youtube.com/watch?v=5Q1awoAwBgQ.
This seems to be adding Rust borrow semantics and borrow checking to C++. The delivery vehicle seems to be a C++ compiler that the author has been working on for a number of of years. I couldn't find a ton more on the background of this.
From a technical perspective this looks promising as a C++ successor language. The project will have to attract other members in the C++ community though.
secondcoming
He’s active on the C++ Slack, regularly asking questions about the minutiae of the C++ spec. It seems like a massive headache.
KerrAvon
Haven’t read through it in enough detail yet to fully understand the language changes, but the authors are absolutely correct on some basic background that other folks don’t always understand:
> Memory-safe languages are predicated on a basic observation of human nature: people would rather try something, and only then ask for help if it doesn't work. For programming, this means developers try to use a library, and only then read the docs if they can't get it to work. This has proven very dangerous, since appearing to work is not the same as working.
100% 100% 100%
tialaramex
You already wrote "100%" enough times, so I'll add that Rust's technology, and Rust's culture, still aren't enough, you have to really put the work in counteract this very powerful danger. Rust's technology + culture should mean you won't blow your foot off with this (entirely human) approach in their language, but you can definitely give yourself a nasty splinter, destroy your customer's data, and a million other dumb things.
For example Rust provides types like core::cmp::Ordering, core::time::Duration and core::ops::ControlFlow so sometimes your API will be harder to misuse than in might have been because you know, your timeout parameter was a Duration, not an integer count of seconds (or was it milliseconds?)
But, although eventually Clippy will express doubts, Rust won't force you to rewrite that function which took N booleans and now after modification takes N+1 booleans, even though all your callers are probably a mess of true, false, true, true, false undecipherable flag nonsense and a re-factor was called for.
It's surprisingly hard to give new programmers the right instincts on this stuff. I'm pretty sure I was terrible (thirty years ago) too, so this isn't a humble brag it's just an observation.
dataflow
It's an elegant sentence but it's incorrect to say memory save languages are predicated on that? Even a room full of C++ experts who understand this completely and write their code strictly based on formal contracts will still eventually write memory bugs.
Memory safe languages are just predicated on the memory-safety problem being difficult to avoid for humans, because nobody has a 0% error rate. They would still be incredibly necessary and relevant even if nobody relied on "appears to work" as the measure of correctness.
pornel
I think the point is that Rust encodes more rules in its interfaces (ownership, lifetimes, thread safety). If you misunderstand how a Rust library works, your code most likely won't compile instead of silently causing UB.
The rules for safe interfaces are the same for all Rust programs, so users know what to expect. Whereas in C++ the library author has more to say what usage is supported and what isn't (e.g. Rust requires all globals to be thread-safe unconditionally, but a C++ library may say it's thread safe if you set a config option or it's your problem to synchronize access).
pizlonator
Nice to see Sean cite Fil-C, though he does it much more in passing than it deserves, considering that Fil-C gives you memory-safe C and C++ without requiring any annotations whatsoever. He cites it as a sanitizer and references undefined behavior, which isn't really how I would describe it (unlike a sanitizer, it catches all memory safety bugs, and also unlike a sanitizer, it turns a lot of what would have been UB in C++ into defined-but-safe behavior). It's a very different approach from Sean's.
For example, Circle implies broad overhaul to tooling and libraries while Fil-C implies no such thing. Also, Circle is all about not using existing compilers on the grounds that they are hard to experiment with, while Fil-C is a surgical change to clang/LLVM.
The main advantage of Circle over Fil-C is that if you pay the cost of that overhaul, you'll get performance that is better than what Fil-C could ever do even with a lot of optimization. Not obvious to me if that makes it net better, though.
tialaramex
For the performance, there are a bunch of people, some of them probably wrong and others definitely right, who believe they need the best possible performance from software.
You can sell these people something like Rust because you can very often either show why the "better performance" C++ they have is wrong (and if they wanted a wrong answer here's zero already, pay me) or sometimes actually worse performance. Not every time, but often enough to make a real difference. The Circle safety feature should be in the same ballpark.
You can't sell them anything that's just anyway going to have worse performance, if you could they'd be writing Java already. So that's counting against Fil-C.
pizlonator
Java is a totally different language, so it’s not even remotely a competitor in this space. Also Java is quite fast, even compared to C or Rust.
Fil-C is all about being able to run existing C/C++ code that nobody is going to rewrite, not even in a dialect like Circle, since the burden of annotations will be too great.
mike_hearn
For existing C++ just using a checked std::vector and Boehm GC can get you quite a long way.
_huayra_
Sean Baxter was on cppcast recently, highly recommend anyone interested to give it a listen: https://cppcast.com/safe-borrow-checked-cpp/
quietbritishjim
> There's only one systems-level/non-garbage collected language that provides rigorous memory safety. That's the Rust language.
Honest question: what about Ada? It was specifically designed to be a safe language for critical systems, and for a while was mandated for some military systems. Did the author not consider it, or are its protections just not as expansive as Rust's?
steveklabnik
I’m not the author, but there’s a few reasons Ada tends to be forgotten in these discussions:
Back when Ada was new, people just didn’t actually like programming in it much. Some did, of course, but many did not. This is the reason the Ada Mandate was abandoned.
This led into a situation with a small, walled off community that didn’t really communicate with the outside world much. This has a compounding effect over time.
Ada, while designed for safety critical systems, was not actually memory safe until fairly recently. Deallocating memory at runtime wasn’t, and in my understanding, may only be in the presence of SPARK? Hopefully someone can chime in here. Now, that fine for the systems Ada tended to be used for, which often have either no dynamic allocation or a singular allocation at program startup, but for inspiration for other language designs, given that it forgoes a hard problem, it’s not really as useful to those who are trying to solve those problems. This doesn’t mean Ada is useless for inspiration, but for “how do I implement memory safety,” it doesn’t have many unique uses things to offer.
None of this means Ada is a bad language, but these are the main contributing factors that I see with regards to your specific question.
pjmlp
That is the usual Ada outdated image, just like unsafe code blocks in Rust, those Unchecked Deallocation are wrapped in safe calls, and since Ada95 there are controlled types, allowing for RAII patterns.
Additionally, it is common to use arenas, and many types can be dynamically stack allocated with a retry operation in case there is not enough space, so that the call can be redone with a smaller size.
Memory Management with Ada 2012 from FOSDEM 2016,
https://archive.fosdem.org/2016/schedule/event/ada_memory/
Doesn't go much into SPARK related improvements though, given its date.
roca
Rust's affine types and borrow checking give safe Rust a lot more power than the safe subset of Ada95. A trivial getter method that returns a reference (i.e. pointer) to a field of its object is safe in Rust, but in Ada95 (and C++ and most other non-GC languages) in general you can't ensure the object outlives the reference.
It is true that Ada has a safe suitable-for-systems-programming subset that's much better than most languages. I think when people say "Rust is the first safe systems programming language" they implicitly mean "that is expressive enough for me to replace C++ with".
roca
How does "redo the call with a smaller size" possibly help you? If you could get by with less memory, you should have asked for less memory in the first place.
steveklabnik
Sure, none of that is particularly novel though, so in terms of citing it as something specifically to add to the conversation, there isn't any real reason.
tialaramex
Ada itself doesn't provide you the same guarantees as Safe Rust. You can use SPARK to grant Ada more memory safety capabilities. However as a language (rather than comments which may or may not be ignored by your Ada compiler) SPARK is from 2014, so now we're close to Rust's age.
I assume that the totality of SPARK's guarantees would get you to the same place as Rust but I don't know.
A big thing which counts against Ada (and SPARK) in practice is that it's not popular. You'll trip over Rust programmers everywhere, two of my friends are getting paid to write Rust, for completely unrelated companies, unrelated reasons, Rust seems like a reasonable fit so those companies picked Rust. You don't see that with Ada and SPARK.
bluGill
Rust gets the hype/talk. However there are a lot of Ada programmers out there who just do their 8 hours and go home and live their life. I doubt rust is anywhere near as popular as Ada, but I don't know how to measure that.
tialaramex
> I doubt rust is anywhere near as popular as Ada, but I don't know how to measure that.
I would have the reverse guess, but like you I can't think of a reliable way to get reliable numbers. Here's why I get my guess though: There just aren't that many defence IT people proportionally and only some of them are writing Ada. I saw no sign of non-defence Ada in noticeable quantities.
Sometimes people are just upfront, we're a defence contractor, all our clients are military, everybody who works here must get clearance. Sometimes they're a bit more shy, please come talk to our specialist recruiter, and fill out all these forms that are surprisingly interested in you as a person not an employee (because they're pre-screening you, you will get security cleared). Nobody was like "Ada has been so great for our CRUD web sites" or "Come join our team writing a trading platform in Ada" or anything like that.
So I think it just can't work statistically.
cardanome
I think Ada not being very popular shows that the need for a memory safe non-garbage collected language is kind of overstated. If there was really that much of a need, people would have flocked to Ada despite its shortcomings.
Most people solved the safety problem a long time ago by switching to garbage collected languages. As times go on and garbage collector designs get better while hardware gets beefier you can get away with using a garbage collected language in more and more cases. Case in point golang marketing itself as a system programming language and succeeding, not to even mention even the game dev accepting C# these days.
To be clear, there is a niche and need for safe and non-garbadge collected languages and there will always be. I am just saying the niche is much smaller than people might think.
I think it is mistake for Rust evangelists to market safety of the killer-feature of the language. Rust is not popular because of the safety but because it lowered the barriers of entry for a new generation of system programmers by providing excellent tooling, error messages and a type system that take at least the lower hanging fruits of the academic functional world. That is all cool stuff beyond the safety circle jerk.
burjui
> I think Ada not being very popular shows that the need for a memory safe non-garbage collected language is kind of overstated.
It only shows that Ada is very old and verbose.
madebydouglas
It seems like if this can be the next version of C++ that would be a good thing, but if it's just another C++ like language, such as Carbon (even with proposed benefits), aren't we just going in circles here?
Wouldn't a better approach be to instead focus on adding better C++ interop into Rust? Isn't that a more forward thinking approach?
On that line of thinking, what about Swift and its C++ interop? Or is Swift not ready for systems level programming?
zer0zzz
> On that line of thinking, what about Swift and its C++ interop? Or is Swift not ready for systems level programming?
A lot of swift behavior is dictated by the standard library. There have been Micro-Swift and embedded swift implementations to cut down overhead along with work on move only types.
I think swift could be a good candidate for a post-c++ language but despite the open community it is highly Apple dominated in its scope and direction. That’s probably my the biggest trouble with swift.
legobmw99
I think a challenge to this evolution path is the same as what motivated Sutter’s cpp2: defaults
I think the premise that a lot of experienced programmers can write good C++ is at least somewhat valid. They know to not use raw pointers, which APIs to use for bound checking, whatever. The issue is that new users don’t, and the defaults are bad.
If I have to write #feature on safety in every file, it becomes possible to forget. Opting in vs opting out
mgaunard
Memory-safe languages are IMHO a distraction from making people write bug-free code.
There are much more important bugs than memory safety bugs, including all sorts of performance bugs.
We need to address the whole spectrum instead of compromising all areas in order to tackle niche bugs that only matter in security-critical contexts.
sunshowers
This isn't true in practice.
When you don't have to worry about memory safety, your brain is freed up to worry about other kinds of bugs.
The other bit of good news is that the sorts of things Rust does to have memory safety also enable the systematic elimination of many other kinds of bugs. For example, iterator invalidation.
mgaunard
For example, the easiest way to make programs avoid use-after-free errors is to never free things.
Would you rather get a program that constantly use all of your RAM until you restart it, or one that consistently uses very little, but someone crashes in edge cases?
sunshowers
I'd rather use a program that uses as little memory as possible and that also never crashes. With Rust you can just have both.
leni536
Good luck not releasing stack frames.
umanwizard
It’s not true that memory safety bugs only matter in security-critical contexts. If a program segfaults, it’s going to make the user unhappy regardless of security implications.
Yoric
And don't forget that a segfault is the lucky case in matters of memory safety bugs. I've worked on many memory safety bugs that manifested themselves by silently corrupting data.
Yoric
What kind of niche bugs are you speaking of?
For what it's worth, Rust (and other languages of ML heritage) are really good at getting rid of huge categories of bugs, not just memory. Not all bugs, of course.
UncleMeat
The problem with memory safety bugs is that the capacity for unwanted behavior is much higher. This is why they are useful as security vulnerabilities when crafting exploits. They can turn your program into an unbounded one that can compute anything. It also means "uh, we just stored garbage data where there should be a key and now the entire encrypted blob is irrecoverable."
djur
> all sorts of performance bugs
A lot of code is written in safe, slow languages that could be written in a safe, fast language.
mgaunard
Making all vector accesses bounds-checked, as all memory-safe languages do, is a recipe for slow code.
UncleMeat
You can try turning on hardened libc++ and see what performance hit you get. It isn't really too bad. And a considerable portion of that is waste caused by other design choices in C++ making it difficult for the compiler to remove redundant bounds checks.
panstromek
The term "Memory safety" also heavily undersells what it actually implies in Rust.
kiitos
Memory safety bugs are second only to segfaults in terms of importance.
vitiral
Segfaults are a result of violating memory safety. They are the BEST case since you can actually detect the program yolo'd
Far worse is your program starts corrupting your data and suddenly you are executing a routine you had no intention of ever executing
kiitos
Not really. Not all memory safety violations result in segfaults, and not all segfaults are the result of memory safety violations.
logicchains
In terms of the actual bugs encountered when developing modern C++ applications, logic bugs vastly outnumber segfaults and memory safety bugs, which are quite rare when you're writing business logic.
bluGill
I fully agree. Memory safety issues are a small minority of C++ issues. Memory safety issues when you get them are very difficult to track down, and often have much broader/worse effects.
erik_seaberg
With an MMU, segfaults cause pretty abrupt and obvious failures for straying outside the heap or stack. Violating memory safety may cause subtle and unpredictable errors even in correct functions, which is a lot more dangerous.
kiitos
No argument there!
undefined
throwawayk7h
> Institutional users of C++ should be worried. The security community is baying for this language's extinction. The government is on our case about it, and legislation banning C++'s use in certain sectors looks like a possibility. I don't think nitpicking the NSA is a compelling response.
I am a bit worried about this. should I be?
Get the top HN stories in your inbox every day.
Sean (the author of Circle) is an impressive guy. He started pursuing this work at about the same point several of the "C++ Successor Languages" were created, but although all of them claimed to be about solving this problem, especially when first announced, they actually don't have a solution unlike this Circle work. Let me briefly enumerate:
Val (now HyLo) says it wants to solve this problem... but it doesn't yet have the C++ interop stuff, so, it's just really a completely different language nobody uses.
Carbon wants to ship a finished working Carbon language, then bolt on safety (somehow) but, only for some things, not data races for example, so, you still don't actually have Rust's Memory Safety
Cpp2 explicitly says it isn't even interested in solving the problem, Herb says if he can produced measurements saying it's "safer" somehow that's good enough.
It's interesting how many good ideas from Rust just come along free for the ride when you try to do this, do you like Destructive Move? Good news, that's how you make this work in Rust so that's how Circle does it. Exhaustive Pattern Matching? Again, Circles does that for the same reason Rust needs it.
It is certainly true that this is not the Only Possible Way to get Safety. It would be profoundly weird if Rust had stumbled onto such a thing, but "Let's just copy the thing that worked in Rust" is somehow at once the simplest possible plan that could work and an astonishing achievement for one man.