Comment by nbaksalyar | Hacker News Reader

Comment by nbaksalyar | Hacker News Reader

Parent Full thread

To understand unsafe code you need to understand what's safe code and pointers first.

Basically, safe code is automatically managed to get rid of memory leaks [0], dangling pointers [1], null pointer dereferencing [2], race conditions [3], and many other memory management bugs.

You don't encounter any of these in JavaScript because it's a managed language, meaning there's a garbage collector [4] that looks after all your memory allocations.

Contrary to the managed languages, C & C++ are unsafe and "native" (meaning that they're very close to the hardware level) - it's a wild land where you manage memory manually yourself. If you miss a single deallocation, you're left with a memory leak. If you deallocate a memory region twice, you have a double free situation [5]. So you have to be very cautious when writing code in C & C++. There are many techniques to make it easier (e.g. smart pointers [6]), but not all developers use them.

Rust takes the middle ground: it combines safety with unsafety by using a know-how affine type system with a borrow checker, which allows values/variables to have only one owner. This system has properties of both managed and unmanaged code. "Unsafe" code in the context of Rust means that you consciously turn off the borrow checker, leaving on your own and managing memory deallocations manually, as in C. That makes it possible to interface your Rust code with the native code, at the cost of making you prone to all errors and bugs that are listed above. So it's a good thing to minimize usage of unsafe code, to allow the Rust compiler to check your code for safety.

[0] https://en.wikipedia.org/wiki/Memory_leak

[1] https://en.wikipedia.org/wiki/Dangling_pointer

[2] https://en.wikipedia.org/wiki/Null_pointer#Dereferencing

[3] https://en.wikipedia.org/wiki/Race_condition

[4] https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

[5] http://stackoverflow.com/questions/21057393/what-does-double...

[6] https://en.wikipedia.org/wiki/Smart_pointer

How does it relate to writing C++11 without using raw pointers. I.e. using uniq_ptr (single owner), shared_ptr (multiple owners), references (not-an-owner). Are there benefits beyond that; and does it have the capabilities C++ has regarding making classes, operator overloading; templates?

  > How does it relate to writing C++11 without using raw pointers.

Rust's safety features are similar to those, but even stronger in a number of ways. There's two aspects to this: 1. more guarantees. You can write code with uniq_ptr that segfaults, but you cannot with Box<T>. 2. safety allows for patterns that would be dangerous in C++. For example, shared_ptr uses atomics for thread safety. Rust has two variants, Arc<T> with similar atomics, and Rc<T> without. If you're not using multiple threads, you can use Rc<T>, safe in knowing that Rust will give you a compile-time error if you introduce multithreading. In other words, there are ways that you need to be defensive in C++ that you do not in Rust.

  > does it have the capabilities C++ has regarding making classes,

Rust does not really have OOP, exactly, we have structs and traits (concepts). One major difference is that we don't currently have inheritance, though proposals are being worked on. But since we already have the concept equivalent, we have extra power there. Tradeoffs.

  > operator overloading

Rust lets you overload certain pre-defined operators, but not create new ones.

  > templates?

AST based, hygenic macros, instead.

> AST based, hygenic macros, instead.

Well and generics & traits. 99% of the places where C++ programmers use templates, they would use generics in Rust. `template std::vector<T>` <-> `Vec<T>` etc.

It's only the niche metaprogramming ability of C++'s templates that would be replaced with macros.

Yes, thanks, that's a more complete answer.

You can still trigger plenty of undefined behaviour in C++11 with no raw pointers. Just one example--iterator invalidation:

    auto v = std::vector<int> {1, 2, 3}
    for (auto x : v) {
        if (x > 0) {
            v.push_back(-x);
        }
    }

The above may segfault, do what you expect it to, run forever etc. Unchecked indexing, branching on uninitialized data etc.

Rust frees you from _all_ of these things and offers a bunch of further advantages, most notably: data race freedom. You can actually share data between threads and keep your sanity.

Can someone explain why this was downvoted?

Rust's model is similar to a cleaned-up and guaranteed safe use of modern C++ smart pointers and references.

A few of the improvements that Rust offers are compiler enforced move semantics by default, so assigning, returning, or passing a Box<T> (similar to unique_ptr<T> in C++) will move the ownership to the new location and statically check that you never try to access the old location. In C++, you have to explicitly call std::move(), and checks to make sure you don't reference the old one happen at runtime.

Rust also does safer checking of use of references. In C++, it's possible to return a reference to a stack variable which is no longer valid. In Rust, the lifetimes of references are tracked statically, so you can never have a dangling reference.

So, while the RAII pattern, use of smart pointers, and use of references, will feel fairly familiar to someone familiar with modern C++, they are actually generally more convenient and more safe in Rust.

Rust does not have classes. You define plain old data structures, and use traits to provide polymorphic behavior. Traits are somewhat like interfaces which can contain default implementations of methods. Traits can be used to constrain types. Traits can be used to provide either static (compile time) dispatch, or runtime dispatch, depending on whether the object is monomorphized at compile time or accessed through a fat pointer that includes a vtable to dispatch at runtime.

Rust provides generics which fill a similar niche to templates in C++. In some ways, they are more powerful as arguments can be constrained by traits; in some ways they are less powerful than C++ templates.

For an introduction to traits in Rust, take a look at the book: https://doc.rust-lang.org/book/traits.html

Rust doesn't provide operator overloading directly, but use of operators is equivalent to just calling a method defined on a particular trait in Rust. So, "a + b" is will work for any types that implement the Add trait (https://doc.rust-lang.org/std/ops/trait.Add.html), and is equivalent to calling a.add(b).

One thing I'd miss from C++ are the alternative operator representations for && and ||, and and or.

> templates

The vast majority of C++ template usage is acheived by generics, and in a much more type safe and debugable manner.

Most of the remaining things can be achieved by Rust's hygenic macros (which are not like C++ macros, they're more like C++ templates in how they can be used and the guarantees they provide).

> . So you have to be very cautious when writing code in C & C++. There are many techniques to make it easier (e.g. smart pointers [6]), but not all developers use them.

Not everyone has security as a requirement. Some people jsut want to write something that is both fast, predicable. Most banks don't make any security demands of internal applications because they are not accessible to the internet. At which point safety is just a way to slow you do.

On the other hand, banks want numbers that actually add up properly, at least in the code that deals with money. If you use undefined behavior in C or C++, the languages do not guarantee that your bank account balances won't all be rounded down to the nearest prime number on Thursdays in odd numbered months in leap years.

>>Most banks don't make any security demands of internal applications because they are not accessible to the internet. At which point safety is just a way to slow you do.

This is a bad way of doing things. That means as soon as someone finds a way to get inside the network, the bank is wrecked. You need to look at security from the point of assuming the attacker somehow got inside because it'll happen one day.

http://digg.com/2015/ashley-madison-hack

""" MOTHERBOARD: How did you hack Avid Life Media? Was it hard?

The Impact Team: We worked hard to make fully undetectable attack, then got in and found nothing to bypass.

MOTHERBOARD: What was their security like?

The Impact Team: Bad. Nobody was watching. No security. Only thing was segmented network. You could use Pass1234 from the internet to VPN to root on all servers. """

Safe, also means that the application does not crash in funny ways with segmentation faults. Which is something that banks like a lot.

"Some people jsut want to write something that is both fast, predicable."

And debuggable? Not crashing in random places due to stack or heap corruption helps there.

Let me know which banks you've worked at with this attitude. I just want to check I have no accounts with them.

This most definitely is not the view taken at the financial companies I've worked in/with including a number of banks.

They take internal security very seriously. There's the obvious threat of some form of break-in (no-one I know seriously believes that an unbreachable connected system is buildable). But there's also the issues of insiders taking stuff, Chinese walls and regulatory restrictions on access. It simply doesn't make economic sense to take security lightly any more.

"Why do you rob banks?"

"Because that's where all the exploitable attack vectors in unsafe code are."

Others have commented that security type safety can be important even in applications that are not externally facing, but thats even sort of besides the point. When people talk about 'safety' in Rust, often times they are talking about the predictability that you mention. Highly threaded code can seem to run perfectly for some time before obscure bugs pop up. Rust's abstractions around thread and memory safety can help in those situations.

I'm going to have to disagree with your point about banking applications based on my experience (~15 years) in banking IT and security.

Whilst obviously Internet facing apps are treated with more caution, it's definitely not true in my experience to state that there are no security demands on internal applications. I would expect that most/all banks these days realise that there's no such thing as a fully trusted network...

Reply on news.ycombinator.com