5 ms·

One thing I'm less clear on is what will happen after 1.0. Is there a "post 1.0 wishlist" somewhere?

steveklabnik 12y ago
Funny you should ask: https://github.com/rust-lang/rfcs/labels/A-wishlist https://github.com/rust-lang/rfcs/labels/A-wishlist We have not done any scheduling for what comes after 1.0. I've been doing a huge amount of triage to move over issues that used to be in rust-lang/rust to be under that label, too, and to make it more detailed than just 'wishlist.' We'll figure out exactly what's next shortly before the first post-1.0 cycle actually begins. http://users.rust-lang.org/t/most-coveted-rust-features/324 http://users.rust-lang.org/t/most-coveted-rust-features/324 was a thread created recently, asking people what they want the most. You might find that interesting too.
- breckinloggins 12y ago
  Thank you!
kzrdude 12y ago
A feature that has already seen many proposed rfcs and long discussions is "Efficient code reuse" (a.k.a some kind of inheritance), summarized here: https://github.com/rust-lang/rfcs/issues/349 https://github.com/rust-lang/rfcs/issues/349 It was explicitly postponed until after 1.0.
- wrl 12y ago
  This is the big one I'm waiting on before betting the farm on Rust, and I suspect I'm not the only one.
- breckinloggins 12y ago
  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 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. I love the rust idea that tons of modern language design still allows for zero-cost abstraction. Inheritance in dispatch starts getting into the land of "putting a lot more stuff in my binary than I asked you to", and I would argue that it's this property more than anything else that keeps embedded programmers and kernel guys safely in the minimalistic land of C. It would be nice to have a new C, finally. But the more a language has an opinion on runtime layout, behavior, and symbol names, the less C-like it becomes. Rust got this right when it decided that GC was NOT the correct default behavior for a language. The reason you see people playing with OS kernels in rust and not as much in D is, I think, mainly due to this decision. I think rust should continue carrying this torch. If not for the ability to have the best of both worlds (a modern language and access to to-the-metal programming with a controllable runtime layout and deterministic performance profile), where exactly is the value in learning how to use the borrow checker?
  - steveklabnik 12y ago
    Rust already supports dynamic dispatch[1], and the 'code re-use' proposals may not look like traditional inheritance. [2] Furthermore, they're being driven _by_ those low-level requirements: it's about being able to efficiently represent things that truly need it, like the DOM. 1: http://doc.rust-lang.org/book/static-and-dynamic-dispatch.html http://doc.rust-lang.org/book/static-and-dynamic-dispatch.ht... 2: http://www.reddit.com/r/rust/comments/2j78oh/i_heard_that_rust_will_get_inheritance_soon_but/cl9261m http://www.reddit.com/r/rust/comments/2j78oh/i_heard_that_ru...
    - breckinloggins 12y ago
      In the book, you mention that "the std::raw modules contains structs with layouts that are the same as the complicated built-in types". I suppose what I'm asking for is some way for std::raw (plus some contract-like traits and other things) to somehow be the complicated built-in types. I know that's a hard ask, but the upside would be that anything in the language that's represented by a complex layout + behavior could in principle be replaced by another implementation that preserves the size and behavior contracts. If an implementation is not provided, those features of the language are unavailable. This kind of takes the "you can't use x and y until you give me an allocator" approach and turns it up to 11.
  - kibwen 12y ago
    Rust has had dynamic dispatch via since time immemorial, because there are a few things that static dispatch can't express (the original motivating factor was having an array full of different types that all implement the same interface). It is achieved by leveraging a feature of the traits system known as "trait objects": http://doc.rust-lang.org/book/static-and-dynamic-dispatch.html#dynamic-dispatch http://doc.rust-lang.org/book/static-and-dynamic-dispatch.ht... But you are correct in that one of the loudest objections to the potential inclusion of inheritance in Rust is that people don't want two ways of achieving dynamic dispatch, because suddenly then you're in the same boat as C++ where you must decide which incompatible subset of the language to use in your codebase.
  - pcwalton 12y ago
mbrubeck 12y ago
This is not an official list, but it's one developer's opinion on post-1.0 priorities: http://featherweightmusings.blogspot.com/2014/12/my-thoughts-on-rust-in-2015.html http://featherweightmusings.blogspot.com/2014/12/my-thoughts... It also links to the list of RFCs that have been postponed until post-1.0: https://github.com/rust-lang/rfcs/issues?q=is%3Aopen+is%3Aissue+label%3Apostponed https://github.com/rust-lang/rfcs/issues?q=is%3Aopen+is%3Ais...
larsberg 12y ago
Since last July or so, Servo has been tracking all of the major features we'd like to see that have been postponed to post-1.0: https://github.com/servo/servo/issues/2854 https://github.com/servo/servo/issues/2854

Funny you should ask: https://github.com/rust-lang/rfcs/labels/A-wishlist https://github.com/rust-lang/rfcs/labels/A-wishlist We have not done any scheduling for what comes after 1.0. I've been doing a huge amount of triage to move over issues that used to be in rust-lang/rust to be under that label, too, and to make it more detailed than just 'wishlist.' We'll figure out exactly what's next shortly before the first post-1.0 cycle actually begins. http://users.rust-lang.org/t/most-coveted-rust-features/324 http://users.rust-lang.org/t/most-coveted-rust-features/324 was a thread created recently, asking people what they want the most. You might find that interesting too.

breckinloggins 12y ago
Thank you!

kzrdude 12y ago

A feature that has already seen many proposed rfcs and long discussions is "Efficient code reuse" (a.k.a some kind of inheritance), summarized here: https://github.com/rust-lang/rfcs/issues/349 https://github.com/rust-lang/rfcs/issues/349 It was explicitly postponed until after 1.0.

wrl 12y ago
This is the big one I'm waiting on before betting the farm on Rust, and I suspect I'm not the only one.
breckinloggins 12y ago
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 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. I love the rust idea that tons of modern language design still allows for zero-cost abstraction. Inheritance in dispatch starts getting into the land of "putting a lot more stuff in my binary than I asked you to", and I would argue that it's this property more than anything else that keeps embedded programmers and kernel guys safely in the minimalistic land of C. It would be nice to have a new C, finally. But the more a language has an opinion on runtime layout, behavior, and symbol names, the less C-like it becomes. Rust got this right when it decided that GC was NOT the correct default behavior for a language. The reason you see people playing with OS kernels in rust and not as much in D is, I think, mainly due to this decision. I think rust should continue carrying this torch. If not for the ability to have the best of both worlds (a modern language and access to to-the-metal programming with a controllable runtime layout and deterministic performance profile), where exactly is the value in learning how to use the borrow checker?
- steveklabnik 12y ago
  Rust already supports dynamic dispatch[1], and the 'code re-use' proposals may not look like traditional inheritance. [2] Furthermore, they're being driven _by_ those low-level requirements: it's about being able to efficiently represent things that truly need it, like the DOM. 1: http://doc.rust-lang.org/book/static-and-dynamic-dispatch.html http://doc.rust-lang.org/book/static-and-dynamic-dispatch.ht... 2: http://www.reddit.com/r/rust/comments/2j78oh/i_heard_that_rust_will_get_inheritance_soon_but/cl9261m http://www.reddit.com/r/rust/comments/2j78oh/i_heard_that_ru...
  - breckinloggins 12y ago
    In the book, you mention that "the std::raw modules contains structs with layouts that are the same as the complicated built-in types". I suppose what I'm asking for is some way for std::raw (plus some contract-like traits and other things) to somehow be the complicated built-in types. I know that's a hard ask, but the upside would be that anything in the language that's represented by a complex layout + behavior could in principle be replaced by another implementation that preserves the size and behavior contracts. If an implementation is not provided, those features of the language are unavailable. This kind of takes the "you can't use x and y until you give me an allocator" approach and turns it up to 11.
- kibwen 12y ago
  Rust has had dynamic dispatch via since time immemorial, because there are a few things that static dispatch can't express (the original motivating factor was having an array full of different types that all implement the same interface). It is achieved by leveraging a feature of the traits system known as "trait objects": http://doc.rust-lang.org/book/static-and-dynamic-dispatch.html#dynamic-dispatch http://doc.rust-lang.org/book/static-and-dynamic-dispatch.ht... But you are correct in that one of the loudest objections to the potential inclusion of inheritance in Rust is that people don't want two ways of achieving dynamic dispatch, because suddenly then you're in the same boat as C++ where you must decide which incompatible subset of the language to use in your codebase.
- pcwalton 12y ago

mbrubeck 12y ago

This is not an official list, but it's one developer's opinion on post-1.0 priorities: http://featherweightmusings.blogspot.com/2014/12/my-thoughts-on-rust-in-2015.html http://featherweightmusings.blogspot.com/2014/12/my-thoughts... It also links to the list of RFCs that have been postponed until post-1.0: https://github.com/rust-lang/rfcs/issues?q=is%3Aopen+is%3Aissue+label%3Apostponed https://github.com/rust-lang/rfcs/issues?q=is%3Aopen+is%3Ais...

larsberg 12y ago

Since last July or so, Servo has been tracking all of the major features we'd like to see that have been postponed to post-1.0: https://github.com/servo/servo/issues/2854 https://github.com/servo/servo/issues/2854