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

61–70 of 128 posts

Re: Rust 1.0: Status report and final timeline

#61

Post by comex »

yuriks wrote: post #27
doctoboggan wrote: post #23

Earlier quoted context omitted.

I am not a Rust user and maybe I am reading the post wrong but it seems that syntax has been deprecated: > Closures: Rust now supports full capture-clause inference and has deprecated the temporary |:| notation, making closures much more ergonomic to use.

What was deprecated is the explicit closure type specification, which is only the ":" part.

Right. IIRC, now your choices are, roughly:

    |args| expr // upvars captured by reference, can't be called after function has gone out of scope

    move |args| expr // upvars moved from function to the closure context (or copied if trivially copyable)
This is simple and good enough for most use cases. If you want more complex schemes, you have to implement them manually, e.g. to reference count the upvars, like Apple blocks do by default, wrap them in Rc and capture that.

Accepting closures is a bit more complicated though.

Re: Rust 1.0: Status report and final timeline

#62

Post by mike_hearn »

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 depends what you mean by "language" and what you include.

Rust and Go include the compiler, the runtime, some libraries, some package management and some tutorials.

Other things you might want include IDE support, static analysis tools, advanced garbage collectors, GUI toolkit (bindings), slick debugger support, monitoring and profiling engines. These will all add a large amount of time and money to the development of your new platform.

Re: Rust 1.0: Status report and final timeline

#63

Post by mbrubeck »

tomjakubowski wrote: post #60
mbrubeck wrote: post #29

Earlier quoted context omitted.

That's talking about something different. For a brief period, closures had to be annotated in certain cases like |&: args| or |&mut: args| or |: args| to determine whether they captured their environment by (mutable) reference or by value/move. Now that this is inferred in all cases, closure arguments can just be written as |args| in all cases, just as they were before the current Fn* traits were introduced.

> For a brief period, closures had to be annotated in certain cases like |&: args| or |&mut: args| or |: args| to determine whether they captured their environment by (mutable) reference or by value/move. That particular annotation controlled the access a closure has to its environment, not how it's captured. |&:|, |&mut: |, and |:| corresponded to the Fn, FnMut, and FnOnce traits, respectively. If you look at the si…

Thanks for the correction.

Re: Rust 1.0: Status report and final timeline

#64

Post by aturon »

tomjakubowski wrote: post #60
mbrubeck wrote: post #29

Earlier quoted context omitted.

That's talking about something different. For a brief period, closures had to be annotated in certain cases like |&: args| or |&mut: args| or |: args| to determine whether they captured their environment by (mutable) reference or by value/move. Now that this is inferred in all cases, closure arguments can just be written as |args| in all cases, just as they were before the current Fn* traits were introduced.

> For a brief period, closures had to be annotated in certain cases like |&: args| or |&mut: args| or |: args| to determine whether they captured their environment by (mutable) reference or by value/move. That particular annotation controlled the access a closure has to its environment, not how it's captured. |&:|, |&mut: |, and |:| corresponded to the Fn, FnMut, and FnOnce traits, respectively. If you look at the si…

> The way variables are captured from the environment into the closure is controlled by the "move" keyword. If the "move" keyword precedes a closure expression, then variables from the environment are moved into the closure, which takes ownership of them.

Note: if you don't specify `move`, then the captures are determined in the usual way:

`|| v.len()` captures `v` via an immutable borrow

`|| v.push(0)` captures `v` via a mutable borrow

`|| v.into_iter()` captures `v` by moving it

Re: Rust 1.0: Status report and final timeline

#65

Post by cygx »

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…

How did you come up with the 2 years figure for Rust? If I remember correctly, development started 2006-ish as a one-man private project.

Re: Rust 1.0: Status report and final timeline

#66

Post by mike_hearn »

pcwalton wrote: post #44
breckinloggins wrote: post #39

Earlier quoted context omitted.

I just wrote a comment on that issue with some half-baked ideas, but I really think that this is one of those "line in the sand" features that will determine (at least for me) whether rust is really staying true to its emerging identity or whether it's on the road to becoming another opinionated kitchen sink language. The thing about "efficient code reuse" is it probably requires dynamic dispatch. Once you have dynam…

> 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 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. Static languages like Rust and C++ require the programmer to explicitly state which methods can be virtual to try and control this cost, but that isn't the only way.

For example the JVM is capable of eliminating the virtual method dispatch overhead in almost all cases without requiring the programmer to manually specify which methods are virtual. In fact, the JVM can eliminate the vtable overhead for calls that could be virtual, but in fact at that specific call site are not, and even for calls which are only slightly virtual (e.g. there's only really two destinations). So it's possible that in a JIT compiled program you have way more virtual dispatch in theory, but less than the equivalent C++ program would in practice once the code is warmed up.

So vtable and GC performance are very complex topics which no longer reduce neatly down to our intuitions.

Re: Rust 1.0: Status report and final timeline

#67

Post by tomjakubowski »

mbrubeck wrote: post #63
tomjakubowski wrote: post #60

Earlier quoted context omitted.

> For a brief period, closures had to be annotated in certain cases like |&: args| or |&mut: args| or |: args| to determine whether they captured their environment by (mutable) reference or by value/move. That particular annotation controlled the access a closure has to its environment, not how it's captured. |&:|, |&mut: |, and |:| corresponded to the Fn, FnMut, and FnOnce traits, respectively. If you look at the si…

Thanks for the correction.

Fortunately with the annotations gone, I think there will be a lot less confusion! The "move" keyword on its own is pretty straightforward, at least once you've learned Rust's ownership model.

Re: Rust 1.0: Status report and final timeline

#68

Post by Gankro »

kibwen wrote: post #47
Artemis2 wrote: post #38

Earlier quoted context omitted.

Both Google and Mozilla have teams dedicated to their languages, but they represent a very small portion of the total number of contributors to the language. I couldn't find exact lists of the team members inside both organizations. In terms of volume of contributions, for Go, Google employees are by far the most active: https://github.com/golang/go/pulse . In this graph, the 7 top contributors to the project are Goo…

In the linked Rust graph, eddyb (the third-highest committer) is a volunteer (an unimaginably prolific one), not a Mozilla employee. kmcallister (the fifth-highest committer) is a Mozilla employee, but not actually on the Rust team (they work primarily on Servo (though there is a fair bit of spillover between the two projects)). Rust has a few other full-time Mozilla employees that aren't represented on that chart fo…

pcwalton, at least, has mostly been focusing on making Servo completely amazing. Not a lot on the rustc front these days. Sucks for us, great for Servo. (because pcwalton is fantastic)

Re: Rust 1.0: Status report and final timeline

#69

Post by breckinloggins »

kibwen wrote: post #55
breckinloggins wrote: post #48

Earlier quoted context omitted.

> Garbage collection and virtual dispatch are completely different things; having one in no way moves us closer to the other. Right, of course not. The comparison was philosophical rather than technical. My point was that I believe there's a "sweet spot" for a language that is expressive and convenient and modern, but also tries hard not to stray too far from C's spartan abstract machine model (and when it does, it e…

The best way to make that wish come true is to use Rust in a project where you would normally use C, and report your experience to help us discover the best ways to support that use case. :)

I think what personally got me excited about this direction were the many "OS kernel in rust" hobby projects [1, 2]. For some reason these strike me as a sort of reverse canary-in-a-coal-mine to judge whether a language is seen as a potential C replacement.

Prior to rust the hobby OS dev community was primarily C / asm with some honorable mentions for other languages. It's also something of a stand-in for the requirements of the professional embedded community.

For these use cases, it's just really cool to be able to use more and more "layers" of the language as you implement more of the underlying abstract machine model.

[1] http://jvns.ca/blog/2014/03/12/the-rust-os-story/ [2] https://github.com/rust-lang/rust/wiki/Operating-system-deve...

Re: Rust 1.0: Status report and final timeline

#70

Post by alextgordon »

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.

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