[HN Gopher] Safe C++
___________________________________________________________________
Safe C++
Author : matt_d
Score : 49 points
Date : 2024-09-13 04:56 UTC (18 hours ago)
(HTM) web link (safecpp.org)
(TXT) w3m dump (safecpp.org)
| yosefk wrote:
| why isn't this getting traction? it's a pretty big deal. it's the
| most safe of proposed C++ safety extensions by far
| acheong08 wrote:
| Do you see this realistically getting implemented?
| steveklabnik wrote:
| It is implemented in Circle already.
| edward28 wrote:
| It just looks like an ugly version of rust.
| ramon156 wrote:
| I love Rust but it didn't invent memory safety. This is a
| weird take
| fithisux wrote:
| Jean-Yves Girard
| steveklabnik wrote:
| Your parent didn't suggest that it did. But Sean is very
| clear that these ideas were inspired by Rust.
| foresto wrote:
| What do you think is beautiful about Rust, and why?
|
| How do you think this proposal's equivalents are uglier?
| kasabali wrote:
| Wait, there's a beautiful version?!
| rurban wrote:
| If it would work, it would gain traction. Guaranteed.
| missblit wrote:
| C++ is a very slow moving language. There are various rumblings
| about making it memory safe, but if we get a proper memory safe
| C++ it'll probably be in the '30s.
| Night_Thastus wrote:
| Because C++ is big and old and everyone wants it to be
| something different. Functional programmers want it to be more
| functional, OOP developers want more object oriented, etc. And
| the syntax must look familiar. And everything must be
| backwards-compatible and all older legacy code needs to work
| fine. And it must have next-to-no runtime cost. Etc.
|
| Making any changes to C++ is a slow process - as it is for any
| older and larger language.
|
| Plus...I think memory safety is a pretty low priority area for
| C++, frankly. It's harder to shoehorn in at this point, C++ has
| never prioritized it over raw performance or flexibility.
| pjmlp wrote:
| Well, back in the pre C++98 days, compiler provided
| frameworks used to be safer by default than what got
| standardised.
| jujube3 wrote:
| There's no point. Rust can already be added incrementally in an
| existing C++ or C project. Like how Servo was in Firefox, or
| Rust in the Linux kernel.
| jujube3 wrote:
| Why was this downvoted? It's not just another generic
| "rewrite it in Rust" comment. I was making a specific point
| that incremental rewrites of existing C++ code are very
| possible in Rust. And that process would not be that
| different from rewriting the code in a "safe" dialect of C++.
|
| If it makes you feel better you can rename the Rust language
| to "C++2.0" but the rewrite process itself will be the same
| in both cases. You keep expanding the amount of safe code you
| have within the codebase over time, one module at a time.
| steveklabnik wrote:
| Your first sentence comes across as incredibly combative,
| and not everyone agrees. Personally, that's why I downvoted
| it. It would be a much better comment if it was the same
| thing without it.
|
| For example, one advantage of this strategy as opposed to
| an incremental Rust re-write is that you would retain a
| single toolchain, whereas that would require having two.
| jacoblambda wrote:
| It's not that it isn't gaining traction. Rather it's just a
| massive, herculean undertaking that Sean and co have been
| working on in the background. Hell Sean only just a few months
| ago started posting demos on twitter of their C++ borrow
| checker proof of concept finally working in moderately non-
| trivial examples.
|
| This isn't to say that their progress isn't going well. Rather
| they've been making incredible progress at a rate nobody really
| thought possible but this is just a truly Herculean effort.
|
| Also this proposal is literally only 2 days old. The work has
| been in progress for years but this is to my knowledge the
| first time it has actually been proposed formally.
| steveklabnik wrote:
| This is correct. Sean has been working for something like two
| years implementing these ideas to make sure they're feasible,
| and only recently turned to actual advocacy for them, now
| that the experiment appears successful.
| fuhsnn wrote:
| Aside from "making C++ safe", the design looks like a good
| opportunity to have better Rust interop, if a standardized FFI
| with clear object lifetime semantics can be established between
| C++ and Rust, it's a win for everyone.
| fithisux wrote:
| Or the "other" languages
|
| Zig/Nim/D/Go (or even scripting languages R, Julia, *Lisp, TCL,
| Ruby, Scilab, Python ...)
|
| at last.
| cashsterling wrote:
| Also add Ada... we tend to forget Ada but it was doing what
| Rust is before it was cool.
| Ygg2 wrote:
| Ada Spark goes beyond safety guarantees of Rust. However
| how many here want to prove their invariants hold for their
| UI?
| fithisux wrote:
| "Over the past two years,"
|
| suddenly they remembered to make it safe!!!
|
| Seems others used their backdoors.
| sigmaprimus wrote:
| Considering my city Is still running 16 bit Operating systems Off
| floppy drives For some of the infrastructure... Well I don't
| know, Maybe that makes it more secure? I have no idea How These
| systems haven't been hit yet. Or maybe they have?
| amluto wrote:
| Even without all the safety parts, this is amazing:
|
| > The new choice type is a type safe discriminated union. It's
| equivalent to Rust's enum type.
| omoikane wrote:
| I believe this is Circle C++ with a new domain name. See also:
|
| https://news.ycombinator.com/item?id=40553709 - Circle C++ with
| memory safety (2024-06-02)
|
| https://news.ycombinator.com/item?id=23086227 - Circle - A C++
| compiler with compile-time imperative metaprogramming
| (2020-05-05)
|
| https://news.ycombinator.com/item?id=19224176 - Circle: The C++
| Automation Language (2019-02-22)
| captainmuon wrote:
| I think this is really interesting work, and as others have said
| it is a herculean undertaking by Sean Baxter to try to rework
| C++.
|
| That being said, I'm not sure I like the direction. C++ is
| already more than complicated enough. And I'm not a big fan of
| the "mut XOR shared" principle taken from Rust, because I don't
| really have the problem of accidentially mutating something that
| was shared. Well, maybe I don't get the point because I'm a "Blub
| programmer" :-).
|
| The example that is presented here and in many introductory
| articles about Rust is mutating a vector while iterating it. But
| why can't we just have a vector type that tolerates that and does
| something well-defined? What if we actually want to modify the
| list while iterating, because we are filtering the list for
| example?
|
| I think one forward for C++ would be to define a safe subset.
| Deprecate a lot of features when using this subset, and make sure
| with a linter that they are not used. Hide raw pointers as much
| as possible. Ban UB as much as possible or give it some safe
| default. If you need some "UB" for optimisations (that is, you
| need the compiler to be able to make certain assumptions), then I
| want the compiler to tell me:
|
| > "Could optimize further if we assume `a` and `b` are not
| aliasing, please add annotations to allow optimisation or to
| suppress this message".
|
| Finally we need a new boring standard lib, closer to Java and Qt
| than the gnarlyness of the STL. The spirit should be like that of
| Java or Go, boring, efficient enough, productive for the average
| developer, not to many ways to shoot yourself in the foot.
| steveklabnik wrote:
| > But why can't we just have a vector type that tolerates that
| and does something well-defined? What if we actually want to
| modify the list while iterating, because we are filtering the
| list for example?
|
| This adds overhead that's not always desired. And sometimes,
| this ends up being a logic bug. There are languages where this
| produces a result instead of being UB, but it's almost always
| shown off as a "can you believe this wacky behavior" because
| it's not intuitive. From a random search I just did:
| https://stackoverflow.com/questions/12232788/adding-to-an-ar...
| BiraIgnacio wrote:
| I absolutely love this, not just because of the safety aspect
| but because of how expressive it seems to be.
| Animats wrote:
| It's nice, but it's about the tenth attempt to make C/C++ safe.
| I've been down that road myself. To succeed, this needs some
| major organization, something the size of Microsoft, Google, or
| the U.S. Government, pushing it hard. Someone has to fund
| retrofits of important trusted code, such as OpenSSL.
|
| When you're all done, it will be at least as crufty as C++.
| gpderetta wrote:
| This is (or is going to be) a standard proposal I think, not
| just a dialect .
|
| Of course it still need buy in from the major compilers to have
| a chance to be accepted.
| favorited wrote:
| There are competing "safe C++ syntax" projects being
| advocated by people on WG21 (as well as some members who seem
| to be opposed to any memory or concurrency safety tools
| beyond guidelines and linters). It's going to be up an uphill
| fight for any of them to gain traction, but at least some
| people are putting in the effort.
___________________________________________________________________
(page generated 2024-09-13 23:01 UTC)