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

Rust and the Future of Systems Programming [video]

hacks.mozilla.org

Post reply on HN
Print view View original

461–470 of 511 posts

Re: Rust and the Future of Systems Programming [video]

#461

Post by staticassertion »

erikbye wrote: post #41
enqk wrote: post #4

Although I am not against improving the safety of languages we use for system programming, the model that Rust advocates are pushing of "preventing mistakes" as a way to make systems secure doesn't convince me. Mistakes (and security breaches) happen. A system should be written in such a way as mistakes are few, indeed, however it is essential to also efficiently protect our users' assets (data) first, assuming that…

Reading your comment made me think of Erlang, where the guiding principle is the opposite: large systems will contain errors, and will fail. That is what fault-tolerant is, you design your software (language, libraries and end program) in a way that will handle unforeseen errors and failures. Because in large systems there will always be bugs. http://erlang.org/download/armstrong_thesis_2003.pdf

I'm also a fan of this approach, and am currently learning Erlang because of it. However, I do not feel that the approaches are exclusive.

Erlang is dynamically typed and it is robust because Actors act as isolation boundaries and are managed by supervisors. So the approach is "bugs happen, always recover". You can also use type annotations in Erlang to get "bugs happen less, always recover".

Re: Rust and the Future of Systems Programming [video]

#462

Post by akiselev »

naasking wrote: post #398
akiselev wrote: post #360

Earlier quoted context omitted.

>> Not true, soft and hard realtime garbage collectors exist. Your runtime simply needs to bound the amount of reclamation work done at any given time. That doesn't change anything! You're just choosing a garbage collector with a default deterministic pathological case, which is a guarantee you can make about almost any GC by carefully tailoring your memory usage to your scenario and choice of algorithm. That's all r…

> That doesn't change anything! You're just choosing a garbage collector with a default deterministic pathological case, which is a guarantee you can make about almost any GC by carefully tailoring your memory usage to your scenario and choice of algorithm. The fact that you don't have to tailor anything is precisely the point. Latency is a property of a runtime, not a language. This has been my point all along. C/C+…

> C/C++ or Rust don't guarantee low-latency realtime properties, and introducing tracing GC doesn't guarantee high-latency non-realtime properties.

We completely agree.

> Great, but it doesn't guarantee any properties of code you haven't written, so it still can't achieve the global properties I've been talking about.

How is this any different from C/C++? They do not give you any guarantees that Rust takes away in this regard. Any library that uses Box::new or vec! is exactly the same as a C library that calls malloc/free internally and you can implement the same heap allocation free algorithms in Rust as you can in C/C++.

I don't understand what global properties you expect a low level systems language to guarantee. They definitely can't guarantee that code you haven't written doesn't heap allocate, you have to check that they don't call malloc/free yourself.

Re: Rust and the Future of Systems Programming [video]

#463

Post by z3t4 »

lmm wrote: post #432
z3t4 wrote: post #414

Earlier quoted context omitted.

There are advantages to GC, even Rust has runtime GC. But where is the memory freed ? You don't have to think of that at all in JavaScript. Also when something goes wrong with types in JavaScript the worst case scenario is "2"+2 turns into "22" witch is easy to avoid, compared to a silent overwrite/overflow. Even if the types in JavaScript is very loose, they are much safer.

> There are advantages to GC, even Rust has runtime GC. If you want GC there are any number of good languages to pick with it (e.g. OCaml). > Also when something goes wrong with types in JavaScript the worst case scenario is "2"+2 turns into "22" witch is easy to avoid, compared to a silent overwrite/overflow. It's memory-safe but it's not safe. What if an error like that happens in your permission-checking code? I a…

The problem here is that + is used for both addition and concatenation. Most of the time you know what you are doing though (smile) and string is the default. When I started out with JavaScript I used -- (minus minus) for addition just to be safe. If you where to compare "22" == 22 ? it would be true, so the type doesn't really matter. If you want to do arithmetics on a string, no problem! Even null behaves like a teddy bear compared to other languages where it can bite you hard. Also note that this child toy language can run on embedded systems, and doing memory safe IO concurrency is so easy it's hard not to, like oops I did ten thousand concurrent request, but it finished in less then a second, because this is 2016 and not 1986 and computing performance and memory has grown exponentially since. Don't get me wrong though, systems languages has their place in lower level where the bits, bytes and performance matters. Someone once told me that JavaScript is a lot like assembly because you are so free, there is no one telling you "No, you shouldn't do it that way" like in Rust.

Re: Rust and the Future of Systems Programming [video]

#464

Post by braveo »

tatterdemalion wrote: post #456
braveo wrote: post #452

Earlier quoted context omitted.

> I think the contention is that, unless you're applying NASA style rigor, you don't end up in the same place without verifying the safety automatically, because in practice it's too expensive to verify the safety manually (without getting squeezed out of the space by your competitors.) That's a claim that has yet to be shown to be true. Maybe it is true, and maybe it isn't, but C++ compilers tend to give pretty good…

With no `unsafe` blocks, show me how you could use the `Vec` type to break Rust's memory safety guarantees.

That's the point, there are plenty of things that flat cannot be done without using inherently unsafe operations, even in rust.

This is why it has still yet to be shown that rust is actually safer than C++.

Re: Rust and the Future of Systems Programming [video]

#465

Post by tatterdemalion »

braveo wrote: post #464
tatterdemalion wrote: post #456

Earlier quoted context omitted.

With no `unsafe` blocks, show me how you could use the `Vec` type to break Rust's memory safety guarantees.

That's the point, there are plenty of things that flat cannot be done without using inherently unsafe operations, even in rust. This is why it has still yet to be shown that rust is actually safer than C++.

That's not the point. Array types in Ruby and Python are implemented in C. No one goes around saying those languages are actually no more memory safe than C++ (or maybe you do?).

Re: Rust and the Future of Systems Programming [video]

#466

Post by [deleted] »

enqk wrote: post #62
SkyMarshal wrote: post #39

Earlier quoted context omitted.

The name of the game for the software industry is to continually create better tools that systematically, inexorably reduce the attack surface of apps built with them. Haskell does this in an interesting way by quarantining all side-effect code into Monads and preventing data races with immutability. Rust does it by making memory errors and race conditions impossible via its ownership mechanism. Think of it as guider…

Nevertheless these language specific solutions are completely opaque to an end user. These are software developer centric. As an end user I cannot inspect how these were applied and therefore develop trust in the end product. There's always an element of trust at the root of running a piece of software on my machine. I wish I could quickly inspect and be sure that say, the audio engine that mozilla firefox is running…

[deleted]

Re: Rust and the Future of Systems Programming [video]

#467

Post by dbaupp »

braveo wrote: post #452
MaulingMonkey wrote: post #322

Earlier quoted context omitted.

> It doesn't really matter if they both end up at the same place, which is safe software. I think the contention is that, unless you're applying NASA style rigor, you don't end up in the same place without verifying the safety automatically, because in practice it's too expensive to verify the safety manually (without getting squeezed out of the space by your competitors.) SaferCPlusPlus's goals are noble, but approa…

> I think the contention is that, unless you're applying NASA style rigor, you don't end up in the same place without verifying the safety automatically, because in practice it's too expensive to verify the safety manually (without getting squeezed out of the space by your competitors.) That's a claim that has yet to be shown to be true. Maybe it is true, and maybe it isn't, but C++ compilers tend to give pretty good…

> C++ compilers tend to give pretty good warnings that you can treat as errors

They miss far too many simple cases for this to possibly be a sensible claim, e.g. neither gcc -Wall nor clang -Weverything warn about the two massive problems in the following code:

  #include

  int &foo() {
    std::vector v{ 0, 1, 2, 3 };

    int &x = v[0];
    v.clear();

    int y = x; // dereferencing dangling pointer!
    (void)y;

    return x; // escaping a dangling pointer!
  }
Rust is clearly a step up since it does actually catch these. The Rust compiler is the "third party" tool that helps get better code, unlike C and C++, the static analysis is built-in.

Re: Rust and the Future of Systems Programming [video]

#468

Post by steveklabnik »

tatterdemalion wrote: post #456
braveo wrote: post #452

Earlier quoted context omitted.

> I think the contention is that, unless you're applying NASA style rigor, you don't end up in the same place without verifying the safety automatically, because in practice it's too expensive to verify the safety manually (without getting squeezed out of the space by your competitors.) That's a claim that has yet to be shown to be true. Maybe it is true, and maybe it isn't, but C++ compilers tend to give pretty good…

With no `unsafe` blocks, show me how you could use the `Vec` type to break Rust's memory safety guarantees.

and not just you, but also show http://rust-lang.org/security.html

Re: Rust and the Future of Systems Programming [video]

#469

Post by steveklabnik »

quotemstr wrote: post #453
steveklabnik wrote: post #450

Earlier quoted context omitted.

Are you talking about Rust's or C++'s? Name conflict :) In Rust, std::string::String is not a "value type", and by that, I mean it's not Copy.

C++'s.

Then I won't comment, though I wonder if the parent is thinking of things like https://groups.google.com/a/chromium.org/forum/#!msg/chromiu...

Re: Rust and the Future of Systems Programming [video]

#470

Post by braveo »

tatterdemalion wrote: post #465
braveo wrote: post #464

Earlier quoted context omitted.

That's the point, there are plenty of things that flat cannot be done without using inherently unsafe operations, even in rust. This is why it has still yet to be shown that rust is actually safer than C++.

That's not the point. Array types in Ruby and Python are implemented in C. No one goes around saying those languages are actually no more memory safe than C++ (or maybe you do?).

> No one goes around saying those languages are actually no more memory safe than C++ (or maybe you do?).

It's unfortunate that you've chosen to try and make the scope smaller by referring specifically to "memory safety".

As a result, this will be my last response to you, I just don't have the energy to go back and forth with someone who isn't willing to be honest in this discussion.

But to answer your question, those languages are no safer than C++. I can write a C plugin in both that contains memory leaks and various safety issues. And in fact, both projects have had their own security problems.

Post reply on HN