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

91–100 of 128 posts

Re: Rust 1.0: Status report and final timeline

#91

Post by nostrademons »

gnuvince wrote: post #85
alextgordon wrote: post #70

Earlier quoted context omitted.

It seems like the human parser should be given priority over the computer parser, when considering what is easy and what is hard. The machines work for us!

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 just expose its compiler front-end as a library, and then you can either serialize the AST to some common format for analysis outside the language or build your tools directly on top of that library.

Re: Rust 1.0: Status report and final timeline

#92

Post by steveklabnik »

TwoBit wrote: post #87

Some language guy told me that Rust's ownership system is untenable. He said that researchers tried the same thing years ago and it was concluded to be impossible to work well. I know that's vague, but he claimed to know what he was talking about.

You should ask him to get in touch. If something's broken, we want to know about it.

Re: Rust 1.0: Status report and final timeline

#93

Post by pcwalton »

TwoBit wrote: post #87

Some language guy told me that Rust's ownership system is untenable. He said that researchers tried the same thing years ago and it was concluded to be impossible to work well. I know that's vague, but he claimed to know what he was talking about.

Rust goes a lot farther than academic languages that used regions like Cyclone or the ML Kit. In particular, Rust's regions are only used to enforce stack discipline, and the basic memory management is taken from C++. This way, we avoid the well-known limitations of "classical" region-based memory management.

Besides, consider the fact that we've written hundreds of thousands of code for working, non-toy projects in the language, including the Rust compiler, crates.io, Servo, etc.

Re: Rust 1.0: Status report and final timeline

#94

Post by nnethercote »

q2 wrote: post #25

Is it possible to estimate the amount of manpower and time required to develop a new language from scratch till it is stable and reasonably production ready? Adoption of language is different topic, since it depends on users. Rust and Go are two reasonably new languages. I understand scope and priorities of each language may be different but my idea is to get some approximation/thumb rule for any one before starting…

> It seems developing new language and bringing it to reasonable level is not trivial effort.

That is correct :)

Re: Rust 1.0: Status report and final timeline

#95

Post by erickt »

pslam wrote: post #80
mbrubeck wrote: post #77

Earlier quoted context omitted.

No, it wouldn't. For example, the "Heartbleed in Rust" blog post [1] re-used a buffer without freeing it. No destructor runs in between the two uses, so a zeroing destructor could not possibly prevent the bug. Maybe zeroing destructors make sense as defense-in-depth, but I don't see how they can fix a Heartbleed-style exploit in Rust. In code where the buffer is freed and its destructor runs, Rust's memory safety gua…

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 turning your safe code into unsafe code.

We actually have an interesting project in rust where someone is writing a syntax extension to take rust like code and generate assembly [0]. It's probably unsafe to use right now but if sufficiently well implemented it could be the foundation of a lot of interesting cryptography work.

[0]: https://github.com/klutzy/nadeko

Re: Rust 1.0: Status report and final timeline

#96

Post by Gankro »

dbaupp wrote: post #89
Gankro wrote: post #73

Earlier quoted context omitted.

In addition to what aturon said, for actual patches these are the people who decide on merging: https://github.com/orgs/rust-lang/teams/rust-push Maybe a third to a half are Mozilla employees (although it's infamously hard to tell who actually works at Mozilla and is just weirdly into maintaining Rust).

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?

Re: Rust 1.0: Status report and final timeline

#97

Post by pekk »

AlyssaRowan wrote: post #22

Rust looks interesting. One thing I'm not clear on it if can do, and that I'm interested in, is secure destructors. Say I'm handling crypto, and I'm carting around an ephemeral key. When this goes out of scope, I definitely no matter what, want this zeroised by its destructor - as opposed to just having it (or a temporary copy made by a compiler optimisation!) zombling around the heap, stack or forgotten unused xmm r…

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

Re: Rust 1.0: Status report and final timeline

#98

Post by m_mueller »

pekk wrote: post #97
AlyssaRowan wrote: post #22

Rust looks interesting. One thing I'm not clear on it if can do, and that I'm interested in, is secure destructors. Say I'm handling crypto, and I'm carting around an ephemeral key. When this goes out of scope, I definitely no matter what, want this zeroised by its destructor - as opposed to just having it (or a temporary copy made by a compiler optimisation!) zombling around the heap, stack or forgotten unused xmm r…

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.

Re: Rust 1.0: Status report and final timeline

#99

Post by sitkack »

kibwen wrote: post #13
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…

Here's a company using Rust to sandbox executable financial contracts: https://codius.org/blog/codius-rust/ . The blog post is unfortunately light on details, but I'm hoping to hear more from them soon. I'd also love to see wycats or carllerche weigh in on Skylight.io's use of Rust from within a Rubygem.

Much of the codius code is on github https://github.com/codius

Re: Rust 1.0: Status report and final timeline

#100

Post by tedunangst »

pslam wrote: post #72
AlyssaRowan wrote: post #22

Rust looks interesting. One thing I'm not clear on it if can do, and that I'm interested in, is secure destructors. Say I'm handling crypto, and I'm carting around an ephemeral key. When this goes out of scope, I definitely no matter what, want this zeroised by its destructor - as opposed to just having it (or a temporary copy made by a compiler optimisation!) zombling around the heap, stack or forgotten unused xmm r…

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.
Post reply on HN