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

Rust 1.0: Status report and final timeline

blog.rust-lang.org

Post reply on HN
Print view View original

121–128 of 128 posts

Re: Rust 1.0: Status report and final timeline

#121

Post by omega_rythm »

MichaelGG wrote: post #34
jarrettc wrote: post #11

Even though 1.0 isn't out yet, today you can use Rust for many real projects. I'm unsure whether I'd bet my business on it yet, but I'd be open to the idea. And I'm usually a very late adopter. I've been building a 3d game with Rust and OpenGL, ported from a C++ codebase. So far, my experience has been very positive. Despite Rust's supposed immaturity, it feels more polished than C++ in many ways. Forward progress ha…

I'm betting my business on it. I've written a network search engine in F# and it's in use on the VoIP arm of one of the public telcos. VoIP can generate terabytes of signalling data a day, even while not making much money. (In wholesale, many calls simply don't complete, so you've got a huge amount of data and transactions that pay you $0.) The challenge with F# is controlling memory usage. Even one extra allocation…

Did you give a shot at other languages in the same category as F#, like Haskell, Ocaml, Clojure or Elixir?

Re: Rust 1.0: Status report and final timeline

#122

Post by omega_rythm »

m_mueller wrote: post #98
pekk wrote: post #97

Earlier quoted context omitted.

Why can't you ensure it is zeroed in advance of destructor invocation?

because you don't know how 'intelligent' the compiler is. As long as there's no intrinsic you can't be sure that it works/keeps on working.

Which is a deficiency of compilers and languages they support: there should be a notion of "verbatim" code, where the compiler doesn't try to apply any code transformation changing the "literal" semantics (as opposed to "intended" semantics).

Of course this would only be possible for languages like C which don't make any advanced abstractions on the hardware arch.

Re: Rust 1.0: Status report and final timeline

#123

Post by dbaupp »

mike_hearn wrote: post #115
coldtea wrote: post #81

Earlier quoted context omitted.

> And vtable dispatch has a cost for any code that calls a virtual method. Yes, it's "opt in" but this can be misleading. You pay the cost of the virtual method call every time it's invoked. So you're basically repeating what he said -- I don't see how the "Not really" you begin with is justified. Of course you "pay the cost of the virtual method call every time it's invoked". And you don't pay it any time it's NOT i…

That's not quite what I said. In languages like C++ or Rust you pay the cost every time the method is invoked. With other types of compiler you may not pay the cost even if the method is marked as virtual, even if it's actually used virtually in other parts of the codebase, due to call site specialisation.

The CPU branch predictor can predict/"specialise" virtual calls too.

Re: Rust 1.0: Status report and final timeline

#124

Post by MichaelGG »

omega_rythm wrote: post #121
MichaelGG wrote: post #34

Earlier quoted context omitted.

I'm betting my business on it. I've written a network search engine in F# and it's in use on the VoIP arm of one of the public telcos. VoIP can generate terabytes of signalling data a day, even while not making much money. (In wholesale, many calls simply don't complete, so you've got a huge amount of data and transactions that pay you $0.) The challenge with F# is controlling memory usage. Even one extra allocation…

Did you give a shot at other languages in the same category as F#, like Haskell, Ocaml, Clojure or Elixir?

To replace the F# side of things? F# is pretty unique as far as performance/language/tooling goes. It's outclassed in specific cases, but overall it's a great package.

The alternatives you listed aren't known for being able to write top-performance idiomatic code (I've got something _working_ in F#, but it's ugly non-idiotmatic code). The overhead of a GC is just too much to pay when doing linerate networking. Rust allows me to keep nice, high-level, idiomatic style, without paying any overhead. I can account for almost every byte.

Re: Rust 1.0: Status report and final timeline

#125

Post by pslam »

tedunangst wrote: post #100
pslam wrote: post #72

Earlier quoted context omitted.

This keeps coming up, but I think it's a very, very bad idea . It's false security. If you are running in an environment where you don't trust code running in the same compartment/sandbox/process, then it's futile to zero out memory. The caller could have prepared things such that the memset doesn't work, if the key material went somewhere else. If you ever find yourself thinking you need to do this, what you instead…

Not false sense of security: suspending VMs to disk. The contents of previously used, free memory that has not been reused by the kernel are written to disk. Now it has a lifetime far longer than RAM.

So you're essentially trying to protect against a hypervisor attack? That's never going to work unless you put the primitives in the hypervisor. Assuming you own it.

Re: Rust 1.0: Status report and final timeline

#126

Post by pslam »

erickt wrote: post #95
pslam wrote: post #80

Earlier quoted context omitted.

Thanks - that's a good example of what I was trying to convey. The point is Rust already provides safety guarantees. If you don't trust the runtime, then why would you trust the built-in zero'ing? I get the "defense in depth" argument, but it feels a bit like doing this: { int a = secret; // Get secret. assert(a == secret); // Check "a" is actually that. a = 0; // Ensure "a" is zero'd on exit. assert(a == 0); // Just…

It is very probable that a sufficiently smart optimizer could see the assertion was always true and delete it. Then see no one reads "a" and delete it as well. In certain circumstances this can cause a secret to be leaked in, say a register, making our safe function unsafe. You need to be very careful writing secure code, and probably need to go down to the level of writing assembly to be sure the optimizer isn't tur…

Sorry, I wasn't clear enough that my code was intended as sarcastic. It's obviously silly to zero variables because the compiler is free to ignore you. The point is, the underlying machine is going to do the same.

There are many ways to dig out stale memory if you're running at sufficient privilege, for example. Direct cache introspection, for example, or bypass. Zero-izing alone is not sufficiently strong to mitigate the threats people imagine it works against.

Re: Rust 1.0: Status report and final timeline

#127

Post by tedunangst »

pslam wrote: post #125
tedunangst wrote: post #100

Earlier quoted context omitted.

Not false sense of security: suspending VMs to disk. The contents of previously used, free memory that has not been reused by the kernel are written to disk. Now it has a lifetime far longer than RAM.

So you're essentially trying to protect against a hypervisor attack? That's never going to work unless you put the primitives in the hypervisor. Assuming you own it.

No, I'm trying to protect against somebody grabbing my laptop off the table and scraping the hard drive for suspended VM RAM contents from last month.

Re: Rust 1.0: Status report and final timeline

#128

Post by pslam »

tedunangst wrote: post #127
pslam wrote: post #125

Earlier quoted context omitted.

So you're essentially trying to protect against a hypervisor attack? That's never going to work unless you put the primitives in the hypervisor. Assuming you own it.

No, I'm trying to protect against somebody grabbing my laptop off the table and scraping the hard drive for suspended VM RAM contents from last month.

That's exactly the threat full disk encryption is designed for.
Post reply on HN