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

111–120 of 128 posts

Re: Rust 1.0: Status report and final timeline

#111

Post by erickt »

nostrademons wrote: post #91
gnuvince wrote: post #85

Earlier quoted context omitted.

As far as I know, Rust now has an LL(1) grammar, which means that writing parsers for it can be done by hand (or with the more powerful LALR(1) and LR(1) parser generators). This is very important for humans too, because it means more people are likely to write tools to process Rust code. If you hope to have automatic indentation, auto-completion, refactoring, formatting tools, etc. keeping the syntax simple is reall…

Can't they just expose the parser as a library? Actually, it looks like they did, with the rustc crate. Hand-writing a parser for some other language leads to madness - just ask the folks who've done SWIG, GDB, or most IDE syntax-checkers. You'll inevitably get some corner-cases wrong, or the language definition will change underneath you long after you've ceased to maintain the tool. Instead, the language should jus…

We are not quite ready to support users of libsyntax and librustc as we are very serious about keeping our stable api stable, and freezing those apis would really impact the future development of the compiler, so it will not be exposed in rust 1.0. We want to eventually get something for this purpose though.

Re: Rust 1.0: Status report and final timeline

#112

Post by dbaupp »

Gankro wrote: post #96
dbaupp wrote: post #89

Earlier quoted context omitted.

FWIW, the Rust-push team doesn't match the set of reviewers (people to which the integration bot bors will react and merge a PR). Being on that list offers powers like issue tagging and the ability to push to the 'try' branch, but manually merging a PR or pushing straight to master is essentially banned (and would be reverted immediately).

Huh. I thought it was basically a bijection, though?

There is an injection from the set of reviews to the rust-push team (Or, at least, there should be), but e.g. people have got privs because they've been doing a lot of triage or need try push, without having review powers.

Re: Rust 1.0: Status report and final timeline

#113

Post by moonchrome »

I'm excited by what Rust will eventually bring to the table if it ever gets popular - a higher level C++ (tools for writing safe native code) replacement without the legacy crap (header files...)

At the same time I don't think I would use Rust 1.0 in production for two reasons :

* the language doesn't seem to be mature enough to be highly productive, for eg. the type system isn't powerful enough to express stuff like Iterable or VectorTN and I'm sure there is plenty of tedious stuff like that along with pains from ownershinp systems

* tools and libs are obviously not there

So I guess I'll wait for early adopters to write the libs and give feedback on their painpoints to the devs.

I've said this before - I think Rust 1.0 is something that I could use (ie. working and stable) but I don't think it's something that I'd want to use yet.

Re: Rust 1.0: Status report and final timeline

#114

Post by iso8859-1 »

duaneb wrote: post #75
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…

Well, heartbleeed is a fiasco that would have been avoided by this—a vulnerability that rust shares without these secure destructors.

The heartbleed "issue" in Rust involved code that passed the same array to two functions, making it apparent that the array was never getting destroyed. Since they used a custom memory allocator, secure destructors won't help you since your array might not even get destroyed. Lessons: Don't use custom allocators.

Re: Rust 1.0: Status report and final timeline

#115

Post by mike_hearn »

coldtea wrote: post #81
mike_hearn wrote: post #66

Earlier quoted context omitted.

GC has performance costs, while trait objects and symbol names do not, as long as they're opt-in. Not exactly. Any program even in a GC'd language can allocate non-GCd data. Even in Java, there is the Unsafe class that can do manual mallocs/frees. C# integrates it with the language. If you do a big pile of work on the non-GC heap then no GC would be triggered and GC is effectively "zero cost" for this code. And vtabl…

> 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.

Re: Rust 1.0: Status report and final timeline

#117

Post by ponce »

nostrademons wrote: post #91
gnuvince wrote: post #85

Earlier quoted context omitted.

As far as I know, Rust now has an LL(1) grammar, which means that writing parsers for it can be done by hand (or with the more powerful LALR(1) and LR(1) parser generators). This is very important for humans too, because it means more people are likely to write tools to process Rust code. If you hope to have automatic indentation, auto-completion, refactoring, formatting tools, etc. keeping the syntax simple is reall…

Can't they just expose the parser as a library? Actually, it looks like they did, with the rustc crate. Hand-writing a parser for some other language leads to madness - just ask the folks who've done SWIG, GDB, or most IDE syntax-checkers. You'll inevitably get some corner-cases wrong, or the language definition will change underneath you long after you've ceased to maintain the tool. Instead, the language should jus…

That's what D does, it has infinite look-ahead in cases and there are still multiple parsers available as libraries.

Re: Rust 1.0: Status report and final timeline

#118

Post by nostrademons »

jpgvm wrote: post #104
nostrademons wrote: post #91

Earlier quoted context omitted.

Can't they just expose the parser as a library? Actually, it looks like they did, with the rustc crate. Hand-writing a parser for some other language leads to madness - just ask the folks who've done SWIG, GDB, or most IDE syntax-checkers. You'll inevitably get some corner-cases wrong, or the language definition will change underneath you long after you've ceased to maintain the tool. Instead, the language should jus…

You missed the whole point. By making the language simple you can easily implement your own parser. This opens up the ability to write native parsers in other languages, say vimscript. By keeping it super simple there -are- no corner-cases. There are many benefits to this (like the formatters etc that others have alluded to) from things like IDE integration (imagine lifetime elision visualisation, invalid move notifi…

The vim formatters/syntax checkers I've used that actually try to parse the language - other than Lisp, which is the limiting case - are generally terrible. They all miss some corner case that makes them useless for daily work, since they generate too many false-positives on real code.

The ones I actually use all call out to the actual compiler - Python, Go, or Clang for C++.

Just because people write their own parsers doesn't make it a good idea. It may've been necessary when most compilers were proprietary and people didn't have an idea how to make a good API for a parser. But now - just don't do it. You'll save both you and your users a lot of pain.

Re: Rust 1.0: Status report and final timeline

#119

Post by AlyssaRowan »

cesarb wrote: post #83
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…

Zeroing memory protects against future compromise. Sure, if you were already compromised, you already lost; but if you don't zero cryptographic material and you are compromised in the future (which can even be a physical attack like cold boot), you lose. It's the same idea as in "forward secrecy": once the key material is discarded, it's gone, and no future compromise can bring it back. Being able to say "after this…

This: exactly this. Zeroisation is a fundamental cryptographic primitive, probably the most fundamental. Conceptually simple, but very easy to screw up, and has catastrophic consequences if the assumption is violated.

I want to be able to have an ephemeral secret, and then trust the code to do its very best to get rid of it when it's no longer needed. That doesn't mean just leave it rotting on the heap and promising it doesn't get accesed again, it means burning it to make sure. That's the underpinning of any possible proof of forward security.

Sure, you say, I want a helper process? Fine idea: compartmentation. Now that helper process needs secure zeroisation. And since I want it to be secure, surely I want to write that process in Rust. See where I'm going here?

Whether 'safe' code I trust within my environment can read it again is totally irrelevant, if the machine later gets rooted or booted, nonstopped or whatever.

Re: Rust 1.0: Status report and final timeline

#120

Post by AlyssaRowan »

astrange wrote: post #53
MichaelGG wrote: post #35

Earlier quoted context omitted.

I know nothing about writing crypto core code. But... Rust supports inline assembly, so after you're done, you could always zeroize every register, right?

Since the compiler can do whatever it wants, you can't be sure it hasn't put any part of the key anywhere on the stack, and there isn't sufficient information for the asm to know which registers contain tainted values. Unless you can actually prove all parts of the compiler's data transforms going down to assembly I think the safest thing to do is sandbox your key-handling process so nobody else can examine it.

Great. Now your sandbox needs secure zeroisation.

Yes, actually proving all parts of the compiler's data transforms going down to assembly kind of is what I'm after, if we can get it…

Post reply on HN