Our great sponsors
-
-
creusot
Discontinued Creusot helps you prove your code is correct in an automated fashion. [Moved to: https://github.com/creusot-rs/creusot] (by xldenis)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
- Limited support for `impl Trait` with different return types, by returning an enum on traits where all methods can be trivially implemented (see https://crates.io/crates/auto_enums)
- Explicitly assert trait variance, and unsafely override trait variance.
- Improved compile-time support. In particular, enough support so that you can write functions that generate other functions at compile-time, e.g. `const fn pull_factory(repo_url: &str) -> impl Fn(&mut Repository)`
- Remove restriction on `Self` parameters in trait objects, or at least allow `self: &Rc` and `self: &Arc`, as `self: Rc` and `self: Arc` are allowed
- Allow generics in trait objects if the generic parameter is only accessed / returned behind references and raw pointers, as then the compiler should be able to implement by generating 2 specialized variants: one for thin pointers and one for fat pointers.
- More declarative macro support, e.g. more types of ASTs as metavars
- Partial borrows: https://github.com/rust-lang/rfcs/issues/1215
- Mutability variance: e.g. write `fn index<&a>(&a self, idx: Idx) -> &a T`, instead of needing to write `fn index(&self, idx: Idx) -> &T` and `fn index_mut(&mut self, idx: Idx) -> &a mut T`)
- Built-in unit types (e.g. write `#[unit(ms)] pub struct Milliseconds(usize)`, and then you can write `128ms` => `Milliseconds(128)`)
> No support for using something like separation logic within Rust itself to verify that unsafe code upholds the invariants that the safe language expects.
I think this is something we might see in the future. There are a lot of formal methods people who are interested in rust. Creusot in particular is pretty close to doing this - at least for simpler invariants
https://github.com/xldenis/creusot
> Never mind that this is a blatant opportunity to make supply-chain attacks. I don't know why these are treated as distinct names in crate names, and if there are any conflicting crates out there in the wild right now they should probably all be forced to rename.
crates.io already disallows crates differing only in underscore/hyphen choice. I can't easily find documentation to this effect, but users have reported it returning an error (e.g., [0]). It seems that it internally folds all crate names into underscore-only canonical names.
[0] https://github.com/rust-lang/crates.io/issues/166
I think it's more a reflection of how Rust evolved, and the techniques and approaches known and understood at the time and the strangeness budget they were (understandably) willing to take on at the time as opposed to something inherent. And also sometimes having separate, complicated features for similar things (as opposed to simple features that compose powerfully) can be useful pedagogically as well.
At any rate, this is something I'm interested in, and so that's why it appears so high up on my list. Often you really do want sub-languages for different purposes, but managing how they interact and work together, what is the same and what is different, and how that impacts usability is interesting (and difficult) part. I feel like it should be possible to do this, but it's going to take some work and there's still lots of unknowns.
In technical terms, I'm interested in dependently typed module systems, multistage programming[1], graded modal type theory[2], elaborator reflection, and two level type theory[3]. These all sound pretty intimidating, but you can actually see glimmers of some of this stuff in how Zig handles type parameters and modules, for example, something that most programmers really like the first time they see it!
I do feel like there is the core of a simple, flexible, powerful systems language out there... but finding it, and making it approachable while maintaining a solid footing in the theory and being sensitive to the practical demands of systems programming is a nontrivial task, and many people will be understandably skeptical that this is even a good direction to pursue. Thankfully the barrier to entry for programming language designers to implementing languages in this style has reduced significantly in just the last number of years[4], so I have hope that we might see some interesting stuff in the coming decade or so. In the meantime we have Rust as well, which is still an excellent language. I'm just one of those people who's never content with the status quo, always wishing we can push the state of the art further. This is why I got excited by Rust in the first place! :)
[1]: https://github.com/metaocaml/metaocaml-bibliography
[2]: https://granule-project.github.io/
[3]: https://github.com/AndrasKovacs/staged
[4]: https://github.com/AndrasKovacs/elaboration-zoo/
I think it's more a reflection of how Rust evolved, and the techniques and approaches known and understood at the time and the strangeness budget they were (understandably) willing to take on at the time as opposed to something inherent. And also sometimes having separate, complicated features for similar things (as opposed to simple features that compose powerfully) can be useful pedagogically as well.
At any rate, this is something I'm interested in, and so that's why it appears so high up on my list. Often you really do want sub-languages for different purposes, but managing how they interact and work together, what is the same and what is different, and how that impacts usability is interesting (and difficult) part. I feel like it should be possible to do this, but it's going to take some work and there's still lots of unknowns.
In technical terms, I'm interested in dependently typed module systems, multistage programming[1], graded modal type theory[2], elaborator reflection, and two level type theory[3]. These all sound pretty intimidating, but you can actually see glimmers of some of this stuff in how Zig handles type parameters and modules, for example, something that most programmers really like the first time they see it!
I do feel like there is the core of a simple, flexible, powerful systems language out there... but finding it, and making it approachable while maintaining a solid footing in the theory and being sensitive to the practical demands of systems programming is a nontrivial task, and many people will be understandably skeptical that this is even a good direction to pursue. Thankfully the barrier to entry for programming language designers to implementing languages in this style has reduced significantly in just the last number of years[4], so I have hope that we might see some interesting stuff in the coming decade or so. In the meantime we have Rust as well, which is still an excellent language. I'm just one of those people who's never content with the status quo, always wishing we can push the state of the art further. This is why I got excited by Rust in the first place! :)
[1]: https://github.com/metaocaml/metaocaml-bibliography
[2]: https://granule-project.github.io/
[3]: https://github.com/AndrasKovacs/staged
[4]: https://github.com/AndrasKovacs/elaboration-zoo/
I think it's more a reflection of how Rust evolved, and the techniques and approaches known and understood at the time and the strangeness budget they were (understandably) willing to take on at the time as opposed to something inherent. And also sometimes having separate, complicated features for similar things (as opposed to simple features that compose powerfully) can be useful pedagogically as well.
At any rate, this is something I'm interested in, and so that's why it appears so high up on my list. Often you really do want sub-languages for different purposes, but managing how they interact and work together, what is the same and what is different, and how that impacts usability is interesting (and difficult) part. I feel like it should be possible to do this, but it's going to take some work and there's still lots of unknowns.
In technical terms, I'm interested in dependently typed module systems, multistage programming[1], graded modal type theory[2], elaborator reflection, and two level type theory[3]. These all sound pretty intimidating, but you can actually see glimmers of some of this stuff in how Zig handles type parameters and modules, for example, something that most programmers really like the first time they see it!
I do feel like there is the core of a simple, flexible, powerful systems language out there... but finding it, and making it approachable while maintaining a solid footing in the theory and being sensitive to the practical demands of systems programming is a nontrivial task, and many people will be understandably skeptical that this is even a good direction to pursue. Thankfully the barrier to entry for programming language designers to implementing languages in this style has reduced significantly in just the last number of years[4], so I have hope that we might see some interesting stuff in the coming decade or so. In the meantime we have Rust as well, which is still an excellent language. I'm just one of those people who's never content with the status quo, always wishing we can push the state of the art further. This is why I got excited by Rust in the first place! :)
[1]: https://github.com/metaocaml/metaocaml-bibliography
[2]: https://granule-project.github.io/
[3]: https://github.com/AndrasKovacs/staged
[4]: https://github.com/AndrasKovacs/elaboration-zoo/
> `async` to make fake generators.
Genawaiter[0] is one of them.
[0]: https://github.com/whatisaphone/genawaiter
There's also an effort to get generators into the stable language, but it is currently gated on multiple open questions on the async iteration story, including what traits are to be involved (will it be `trait AsyncIteratorItem`? will it wait until GATs and/or async fn in traits and "keyword generics"/"maybe async" functions?), but you can see some explorations of the syntax aspect at https://github.com/estebank/iterator_item/
The proc-macro is written in such a way that it tries to parse as much as possible, so that you can try things out mixing and matching from the different alternatives that I've thought of: https://github.com/estebank/iterator_item/tree/master/tests
Like for example:
fn foo() => i32 {
> - Raw-pointer equivalent to lifetime parameters (`GenericStruct<>`, converts `&'a T` into `const T` and `&'a mut T` into `*mut T`)
How would that work? References and pointers are fundamentally different types, and the primary operation on references (`Deref`) isn't available for pointers. Any methods implemented on the struct wouldn't be able to do anything with the "reference" field, since it might actually be a pointer instead - it would be like having a `struct Foo(Vec);`, and then specifying `Foo` (imaginary syntax) if you actually want a `Box` instead of a `Vec`. You can't just treat a `Box` like a `Vec`.
> - `impl Trait` for associated types. This lets you workaround async trait functions without boxing the returned futures and also return anonymous closures from traits
You're probably already aware, but for the bystanders, that seems to be close to happening: https://github.com/rust-lang/rust/issues/63063
> - Mutability variance: e.g. write `fn index<&a>(&a self, idx: Idx) -> &a T`, instead of needing to write `fn index(&self, idx: Idx) -> &T` and `fn index_mut(&mut self, idx: Idx) -> &mut T`)
I think that's something the Keyword Generics (aka "totally not effects") Initiative[1] is looking into.
> - Built-in unit types (e.g. write `#[unit(ms)] pub struct Milliseconds(usize)`, and then you can write `128ms` => `Milliseconds(128)`)
Making sure that doesn't turn into a name collision nightmare would probably needs some work. It might also make it very hard to figure out what type you're actually dealing with just by looking at such a number. The current solution to this problem, defining an extension trait on integers, produces only moderately more verbose code, with the benefit of not requiring any additional syntax: `128.ms()`.
[1]: https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-ge...