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

81–90 of 128 posts

Re: Rust 1.0: Status report and final timeline

#81

Post by coldtea »

mike_hearn wrote: post #66
pcwalton wrote: post #44

Earlier quoted context omitted.

> The thing about "efficient code reuse" is it probably requires dynamic dispatch. Once you have dynamic dispatch, you suddenly have vtables. But who decides what those vtables look like? Where do they reside in memory? What's the layout of that? If a struct suddenly has an is-a pointer, where is that mentioned in the code? Now my struct isn't just a struct. 1. We already have vtables through trait objects (though no…

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

That's the whole idea.

Re: Rust 1.0: Status report and final timeline

#82

Post by hyperpape »

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…

I think Rust will be especially high because it's pushing hard to synthesize a lot of newish (not invented by Rust, but not often implemented outside of research languages) ideas. And it's has a huge focus on performance, so that makes things harder too.

A scripting language or a JVM language or a PyPy based language (or pick two of those) can make it to a 1.0 much faster.

Re: Rust 1.0: Status report and final timeline

#83

Post by cesarb »

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…

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 point in time these values don't exist anymore" is a powerful cryptographic primitive.

Re: Rust 1.0: Status report and final timeline

#84

Post by cesarb »

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…

It would be good to have a "secure" type modifier which tells the compiler "once a value with this type is dead, immediately overwrite it with garbage" (instead of the normal behavior of just leaving it around until the register/stack slot/memory area is needed for something else).

Re: Rust 1.0: Status report and final timeline

#85

Post by gnuvince »

alextgordon wrote: post #70
pcwalton wrote: post #17

Earlier quoted context omitted.

The natural thing to want in a C-like syntax is the "arrow function" closure syntax (like ES6 or C#), but that required too much lookahead to parse. Having a keyword discourages functional style, which would be a shame in a language with a powerful iterator library. So Rust went with the Ruby/Smalltalk-style bars, which are nice, concise, and easy to parse.

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

Re: Rust 1.0: Status report and final timeline

#86

Post by tarblog »

pcwalton wrote: post #17
drobilla wrote: post #15

I'm very happy to see Rust stabilize, about time we get a systems(ish) programming language with a half decent type system. With that said... I need to get some bikeshedding off my chest: I hate to let such a triviality lower my enthusiasm for a language so much, but I just can not get over that awful inconsistent closure syntax :/ I don't get it. Most everything else has a nice unique keyword syntax, fn uses (args,…

The natural thing to want in a C-like syntax is the "arrow function" closure syntax (like ES6 or C#), but that required too much lookahead to parse. Having a keyword discourages functional style, which would be a shame in a language with a powerful iterator library. So Rust went with the Ruby/Smalltalk-style bars, which are nice, concise, and easy to parse.

How much worse is it? Can parsing actually be so expensive that it dictates the syntax of the language?

Re: Rust 1.0: Status report and final timeline

#87

Post by TwoBit »

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.

Re: Rust 1.0: Status report and final timeline

#89

Post by dbaupp »

Gankro wrote: post #73
codys wrote: post #10

Earlier quoted context omitted.

There's a governance structure? That's news to me. I was under the impression that a few primary contributors (mostly/all mozilla employees?) are gatekeepers to merging anything. Having an "RFC" issue tracker isn't the same as having a governance structure. Edit: I suppose you could call the above a 'governance structure', but I'm having a hard time seeing anything impressive/different about it from other open source…

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

Re: Rust 1.0: Status report and final timeline

#90

Post by conradk »

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.

Most of the time, Rust's ownership system is helpful. Sometimes, it's a pain though. In these cases, you can actually work around the ownership system if you need too.

For instance, you can use Arc [1] to share memory between threads or Rc [2] to enable thread local GC for a specific variable or RefCell [3] to safely share mutable memory between threads. You can even use raw pointers: it's unsafe (and therefore has to be wrapped in an "unsafe { ... }" block) but possible. Finally, you can call C very easily from Rust [4].

[1] http://doc.rust-lang.org/std/sync/struct.Arc.html

[2] http://doc.rust-lang.org/std/rc/struct.Rc.html

[3] http://doc.rust-lang.org/std/cell/struct.RefCell.html

[4] http://doc.rust-lang.org/book/ffi.html

Post reply on HN