71–80 of 149 posts
Earlier quoted context omitted.
We are really waiting for it in Prisma and might need to start working with the unstable soon until it lands.
Is Prisma releasing a client library for Rust?
Earlier quoted context omitted.
I am not conflating anything. The compilation model of the language does not permit such a thing, independently of implementations of any of those pieces. This is a crucial aspect of the design of the language and the edition system. Think of it this way: crate A uses edition 2015. Crate B uses edition 2018. There’s only one copy of the standard library. It can’t be compiled both ways. If, in theory, we let you have…
With all due respect, I do think you're conflating the way things are with the way things have to be. glibc has a similar commitment to never breaking user code, and yet symbols have been removed from glibc! The trick is to use "symbol versioning"; code compiled against old versions of glibc is transparently rewritten to use the old versions of symbols, while code compiled against new versions is rewritten to use the…
I think what you’re saying is “it is possible to do this with the correct design” and what I’m saying is “that design has not been proposed nor accepted and so the answer today is “that’s not possible”.” Does that sound about right?
Earlier quoted context omitted.
With all due respect, I do think you're conflating the way things are with the way things have to be. glibc has a similar commitment to never breaking user code, and yet symbols have been removed from glibc! The trick is to use "symbol versioning"; code compiled against old versions of glibc is transparently rewritten to use the old versions of symbols, while code compiled against new versions is rewritten to use the…
Maybe we’re just speaking at odds here. The current design of the language does not allow this. A different design may make it possible, but that’s a completely different question. I think what you’re saying is “it is possible to do this with the correct design” and what I’m saying is “that design has not been proposed nor accepted and so the answer today is “that’s not possible”.” Does that sound about right?
It feels like Rust is now 'stable'. Are there any major language related things in the pipeline?
Earlier quoted context omitted.
> GATs Oh, fantastic! I realize I'm probably in a very specific minority here, but I've been waiting on this one for literally years.
For people confused like me: GAT in this case means "Generic Associated Types" https://rust-lang.github.io/rfcs/1598-generic_associated_typ...
The history of TryFrom/TryInto has spanned 3 years, from when it was originally proposed as an RFC in 2016. For a seemingly simple API, it's gone through a lot. Especially unusual was that it was stabilized a few releases ago and then had to be destabilized when a last-minute issue was discovered with the never type (`!`). The never type had been the primary blocker for stabilizing these APIs for the last year or so,…
>> Can you eli5 why TryFrom and TryInto matters, and why it’s been stuck for so long ? (the RFC seems to be 3 years old)
> If you stabilise Try{From,Into}, you also want implementations of the types in std. So you want things like impl TryFrom for u16. But that requires an error type, and that was (I believe) the problem.
> u8 to u16 cannot fail, so you want the error type to be !. Except using ! as a type isn’t stable yet. So use a placeholder enum! But that means that once ! is stabilised, we’ve got this Infallible type kicking around that is redundant. So change it? But that would be breaking. So make the two isomorphic? Woah, woah, hold on there, this is starting to get crazy…
> new person bursts into the room “Hey, should ! automatically implement all traits, or not?”
> “Yes!” “No!” “Yes, and so should all variant-less enums!”
> Everyone in the room is shouting, and the curtains spontaneously catching fire. In the corner, the person who proposed Try{From,Into} sits, sobbing. It was supposed to all be so simple… but this damn ! thing is just ruining everything.
> … That’s not what happened, but it’s more entertaining than just saying “many people were unsure exactly what to do about the ! situation, which turned out to be more complicated than expected”.
https://this-week-in-rust.org/blog/2019/03/05/this-week-in-r... https://www.reddit.com/r/rust/comments/avbkts/this_week_in_r...
Earlier quoted context omitted.
Maybe we’re just speaking at odds here. The current design of the language does not allow this. A different design may make it possible, but that’s a completely different question. I think what you’re saying is “it is possible to do this with the correct design” and what I’m saying is “that design has not been proposed nor accepted and so the answer today is “that’s not possible”.” Does that sound about right?
Yes, absolutely! (Although note that I'm not the OP.)
Earlier quoted context omitted.
We can’t get rid of it because we have a commitment to not breaking users’ code. There will not be a Rust 2.0. There have been some small soundness holes in the typesystem that we have fixed, resulting in breakage, but since that’s in the language, that’s the only way. A library API is different. There haven’t been many of these though. We did have some point releases which immediately fixed some library errors that…
We can’t get rid of it because we have a commitment to not breaking users’ code. There will not be a Rust 2.0. This is interesting. The C Standard people have, for example, removed “gets” from the C11 standard. Go, too, has exceptions to its Go 1 Compatibility Promise[1], which include security, unspecified behaviour, and bugs, both in the language and in the standard library. I don't remember for sure, but I think t…
Earlier quoted context omitted.
> For me the best releases will be when it matches D/Delphi/Ada/Eiffel/.NET Native compile times [..] Any ideas on when this will be? There has been talk about faster compile times for years now without that much apparent progress.
> There has been talk about faster compile times for years now without that much apparent progress. Really? What makes you say that? Have you tried it? $ git clone git://github.com/BurntSushi/ripgrep $ cd ripgrep $ git checkout 0.4.0 $ time cargo +1.12.0 build --release real 1:09.13 user 2:06.08 sys 2.839 maxmem 359 MB faults 1292 $ cargo clean $ time cargo +1.34.0 build --release real 22.484 user 2:32.66 sys 3.380 m…