Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let’s sunset C/C++

trevorjim.com

Post reply on HN
Print view View original

111–120 of 137 posts

Re: Let’s sunset C/C++

#111

Post by bbatha »

pmelendez wrote: post #109
steveklabnik wrote: post #103

Earlier quoted context omitted.

> So like C++ with unique_ptr, shared_ptr, and RAII? It is like that, but with stronger guarantees and less overhead.

> It is like that, but with stronger guarantees and less overhead. Smart pointers in C++ are very slim, which overhead are you referring to? And which are the stronger guarantees?

shared_ptr uses an atomic counter. In rust you can choose to use an atomic ref count or not. The type system is sufficiently smart to ensure that you do not use the non-atomic one in a thread unsafe context. C++ has no ability to do so, so it does not provide a thread unsafe version.

Additionally, in C++ there's nothing stopping me from wrapping a unique_ptr around a pointer that's aliased else where. This violates the guarantees of a unique_ptr and forces the user to make sure its invariants are held. In Rust the compiler ensures that your Box (Rust's unique_ptr) can never be owned more than once.

Re: Let’s sunset C/C++

#112

Post by JoeAltmaier »

piva00 wrote: post #98
JoeAltmaier wrote: post #81

Earlier quoted context omitted.

For pure Java perhaps. But native code is inevitable, and it has no such protection. So in practice Java is not a lot of protection.

I didn't understand how Java relates to his comment about JavaScript + Python.

Sorry, its because I'm an idiot. Anyway, secure languages use native code, and that's still a problem.

Re: Let’s sunset C/C++

#113

Post by steveklabnik »

bbatha wrote: post #111
pmelendez wrote: post #109

Earlier quoted context omitted.

> It is like that, but with stronger guarantees and less overhead. Smart pointers in C++ are very slim, which overhead are you referring to? And which are the stronger guarantees?

shared_ptr uses an atomic counter. In rust you can choose to use an atomic ref count or not. The type system is sufficiently smart to ensure that you do not use the non-atomic one in a thread unsafe context. C++ has no ability to do so, so it does not provide a thread unsafe version. Additionally, in C++ there's nothing stopping me from wrapping a unique_ptr around a pointer that's aliased else where. This violates t…

Arc vs Rc compared to shared_ptr was what I was going to say for overhead, as well as things like the lack of move constructors, which (should) make Vec faster than std::vec.

For stronger guarantees, I was going to point out that if you std::move a uniq_ptr, it becomes null, but Rust prevents using a Box that's been moved at compile time. Your example is good here too.

Re: Let’s sunset C/C++

#114

Post by dbaupp »

andresmanz wrote: post #88
gizmo wrote: post #49

Earlier quoted context omitted.

No need to panic, nobody is coming to take your precious pointer arithmetic away. If you want to write unsafe code, go ahead. But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. We're talking about classes of security bugs that just don't exist in managed languages. Bugs that can't happen in languages like Rust either because it forces programmers to indicate ownership…

> But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. Then you've picked the wrong profession. You write that like it was a fact, while it's obviously nothing more than a lack of skill (and maybe knowledge) on your side. If I chose a language primarily because it's 'safe', that would mean that either I'm pretty bad at writing safe code, or that I'm just unnecessarily la…

Maybe a single developer personally can write C/C++ code that is probably pretty safe (keeping in mind that most personal/small projects never get a proper security analysis/penetration test, so one may have a biased perception), but as soon as you have several people with non-trivial components that interact, it is quite to introduce serious problems accidentally. The evidence is unfortunately against C/C++: even the biggest tech companies in the world developing applications for which security is a critical feature (operating systems, web browsers) still regularly have bugs caused by memory safety issues, and they're almost certainly throwing every tool and a lot of CPU time at the problem.

Re: Let’s sunset C/C++

#115

Post by Nelson69 »

monochr wrote: post #58
gizmo wrote: post #49

Earlier quoted context omitted.

No need to panic, nobody is coming to take your precious pointer arithmetic away. If you want to write unsafe code, go ahead. But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. We're talking about classes of security bugs that just don't exist in managed languages. Bugs that can't happen in languages like Rust either because it forces programmers to indicate ownership…

>But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. You can't write safe code in any Turing complete language. That's the whole point of Turing completeness. The only reason why memory attacks are as common as they are is because C like languages are the most popular ones. If we replaced everything written with C to a "safe" language like, I don't know Haskell?, we'd h…

You cannot write safe code in any Turing complete language? That's a bold assertion that I don't believe is true. Surely you can use formal methods to develop software and maybe even prove it's correctness and security, it's costly in multiple ways but the language of implementation doesn't prevent you from doing this. It is possible to write secure code.

If we replaced everything in C with Haskell, we'd have an entirely different problem. The attack surface wouldn't involve buffer overflows and stack smashing, it would involve various DoS attacks. Those might be easier to address though.

Re: Let’s sunset C/C++

#116

Post by dbaupp »

steveklabnik wrote: post #106
zamalek wrote: post #59

Earlier quoted context omitted.

I've never actually used Rust myself - I'm just familiar with their goals: so I'm not entirely sure what you are referring to. Just keep in mind that the amount of work done on the various C++ compilers is most likely measured in man-decades, where Rust is probably still man-hours. Do you mean a directed graph or a graphical graph? I've implemented directed graphs in at least two different managed languages (which ar…

> Rust is probably still man-hours. It's nowhere near the amount of time put into various C++ compilers, but 1. We use LLVM, so all that time is working for us as well. 2. Mozilla has been paying at least 4 people for at least a few years to write Rust full-time, I would bet we're coming up on a person-decade of time for Rust. The project has existed for eight years in total, though four of that was just as a side pr…

I would guess that it's well past one decade for Rust (there's been 8 paid people on the team for at least a year).

Re: Let’s sunset C/C++

#117

Post by pmelendez »

steveklabnik wrote: post #113
bbatha wrote: post #111

Earlier quoted context omitted.

shared_ptr uses an atomic counter. In rust you can choose to use an atomic ref count or not. The type system is sufficiently smart to ensure that you do not use the non-atomic one in a thread unsafe context. C++ has no ability to do so, so it does not provide a thread unsafe version. Additionally, in C++ there's nothing stopping me from wrapping a unique_ptr around a pointer that's aliased else where. This violates t…

Arc vs Rc compared to shared_ptr was what I was going to say for overhead, as well as things like the lack of move constructors, which (should) make Vec faster than std::vec. For stronger guarantees, I was going to point out that if you std::move a uniq_ptr, it becomes null, but Rust prevents using a Box that's been moved at compile time. Your example is good here too.

> the lack of move constructors, which (should) make Vec faster than std::vec.

So you are saying that the lack of move constructors (hence copying the structure) will make Vec faster than std::vector? I don't follow that logic, wouldn't it actually be slower?

> I was going to point out that if you std::move a uniq_ptr, it becomes null

The original becames null because the semantic is actually tranfering ownership which might be desirable depending on the case. Also you need it in case you are using custom deleters.

http://stackoverflow.com/questions/13860219/what-are-the-dif...

Re: Let’s sunset C/C++

#118

Post by pmelendez »

bbatha wrote: post #111
pmelendez wrote: post #109

Earlier quoted context omitted.

> It is like that, but with stronger guarantees and less overhead. Smart pointers in C++ are very slim, which overhead are you referring to? And which are the stronger guarantees?

shared_ptr uses an atomic counter. In rust you can choose to use an atomic ref count or not. The type system is sufficiently smart to ensure that you do not use the non-atomic one in a thread unsafe context. C++ has no ability to do so, so it does not provide a thread unsafe version. Additionally, in C++ there's nothing stopping me from wrapping a unique_ptr around a pointer that's aliased else where. This violates t…

>C++ has no ability to do so, so it does not provide a thread unsafe version.

In which case would you like to enforce a thread unsafe version?

>Additionally, in C++ there's nothing stopping me from wrapping a unique_ptr around a pointer that's aliased else where. This violates the guarantees of a unique_ptr and forces the user to make sure its invariants are held. In Rust the compiler ensures that your Box (Rust's unique_ptr) can never be owned more than once.

True, nothing stops you to do that and it is nice to know it on compile time. But I fail to say how you would do this by accident. If you deliberately want to do this kind of things, then you are asking for trouble and it doesn't matter how awesome your language is, you would find a way to shoot your foot.

Re: Let’s sunset C/C++

#119

Post by planteen »

steveklabnik wrote: post #108
planteen wrote: post #74

Is there even an operating system not written in asm/C/C++ to run these "secure" non-C/C++ applications?

You only need a tiny bit of asm to have an operating system in Rust. No C required.

Is there an OS yet in Rust though? Google tells me about these projects: https://github.com/ryanra/RustOS http://scialex.github.io/reenix.pdf

Re: Let’s sunset C/C++

#120

Post by steveklabnik »

planteen wrote: post #119
steveklabnik wrote: post #108

Earlier quoted context omitted.

You only need a tiny bit of asm to have an operating system in Rust. No C required.

Is there an OS yet in Rust though? Google tells me about these projects: https://github.com/ryanra/RustOS http://scialex.github.io/reenix.pdf

There are a number of hobby projects, but nothing you'd want to use in production yet. That of course doesn't really change the amount of assembly needed.

(Also, there's been a lot of rumbling about MirageOS, see https://internals.rust-lang.org/t/unikernels-in-rust/2494 and the linked MirageOS mailing list thread)

Post reply on HN