Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust 1.34.0

blog.rust-lang.org

Post reply on HN
Print view View original

41–50 of 149 posts

Re: Rust 1.34.0

#41

Post by bbatha »

pjmlp wrote: post #27
whatshisface wrote: post #19

Earlier quoted context omitted.

We will soon have async/await syntax which will replace some of the use case of callbacks, and (I assume) reduce the borrow bookkeeping tedium.

I don't think it covers GUI callbacks like on Gtk-rs, accessing internal widget data.

I think that's likely. async/await doesn't appear to map directly onto traditional OO GUI framework callbacks well, just like rust doesn't tend to map well to traditional OO. I believe that async/await will open up new architectural patterns that should be as ergonomic as traditional OO callbacks for GUIs. But these won't map well to existing code or existing frameworks.

Re: Rust 1.34.0

#42

Post by steveklabnik »

cornstalks wrote: post #40
steveklabnik wrote: post #33

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…

> There will not be a Rust 2.0. Isn’t Rust 2018 effectively Rust 2.0 (since it introduced new keywords and requires changes to old code if a user opts in to Rust 2018)? So the function could be made unsafe in Rust 2021 (or whatever it’s called).

No, because it is opt in. All existing code keeps compiling as-is.

The standard library cannot change with editions for exactly this reason. It’s compiled with a particular edition, like any other crate, and so can’t work differently in different editions.

Re: Rust 1.34.0

#43

Post by steveklabnik »

bbatha wrote: post #41
pjmlp wrote: post #27

Earlier quoted context omitted.

I don't think it covers GUI callbacks like on Gtk-rs, accessing internal widget data.

I think that's likely. async/await doesn't appear to map directly onto traditional OO GUI framework callbacks well, just like rust doesn't tend to map well to traditional OO. I believe that async/await will open up new architectural patterns that should be as ergonomic as traditional OO callbacks for GUIs. But these won't map well to existing code or existing frameworks.

There have been attempts, like relm, to map futures onto GTK. That means it would work with async/await too, as they’re fundamentally sugar for futures.

Re: Rust 1.34.0

#44

Post by agumonkey »

indentit wrote: post #15

It will be nice when Cargo dependencies can use pre-built binaries instead of having to compile the whole dep chain. One crate I contribute to has a 4 GiB target folder and takes 20 mins to compile from scratch...

reminds me of nixos early days, then they added binary channels, so much nicer

Re: Rust 1.34.0

#46

Post by korethr »

steveklabnik wrote: post #33
korethr wrote: post #20

Hmm, fn before_exec strikes me as a thing that should be gotten rid of entirely in favor of unsafe fn before_exec if the former indeed turned out to actually have the potential to cause undefined behavior. But that'd probably be a breaking change which would require a major version number bump, so deprecation is absolutely the right thing IMO. And it also sets the stage to get rid of it outright come the next major v…

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.

Totally the correct way to go about it, IMO. Thus my comment about deprecation.

>> There will not be a Rust 2.0.

>> Note that upon using it, you’ll get a warning, so everyone will at least be notified.

:/ That I've mixed feelings about. Why not? Is it because of the fiascos between Perl 5/6 and Python 2/3? Deprecations and warnings about using deprecated features are indeed the correct thing to do, but IMO, aren't the whole picture. I think to all the times I went to compile something, and got to watch a constant stream of warnings for it (or worse, got hit by bugs I shouldn't have because the programmer took time to finally suppress that annoying warning pointing to the flaw in his code). A (very occasional) major version bump to show "These things we found out were actually wrong and said that you shouldn't do N years ago? We meant that, those are gone now," strikes me as the Right Thing for a language with a major focus on correctness, like Rust.

But, since I'm here armchair quarterbacking here on HN, instead of getting my hands dirty building a major language, I'm willing to concede that my opinion might be different were it informed by experience.

Re: Rust 1.34.0

#47

Post by MaulingMonkey »

pjmlp wrote: post #25
servilio wrote: post #21

Earlier quoted context omitted.

Why binary dependencies, what for?

Compile speed, not compiling the same dependencies all over the time. Many commercial use cases require distribution of binary libraries, Rust community might care about winning those customers, or just let them go and leave them to keep using the languages that fulfil such use cases.

And if you have to drop down to looking at the disassembly, distributing binaries helps ensure everyone's looking at the same disassembly. Reasons for this include investigating codegen bugs, figuring out optimization issues, ensuring functions involved in cryptography aren't leaking information through timing side channels, etc...

Re: Rust 1.34.0

#48

Post by kibwen »

mintplant wrote: post #38
steveklabnik wrote: post #8

Earlier quoted context omitted.

The biggest one in the near future is async/await; you’ll see the precursors land in the next few releases. There will also be a blog post soon outplaying overall plans for the year, but const generics, GATs, and specialization are the likely big-ticket items. In general, this year of Rust will be about governance refactoring, finishing off long-desired features like the ones above, and general polish. There isn’t a…

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

To help people follow along, GAT stands for Generic Associated Types.

Re: Rust 1.34.0

#49

Post by mijamo »

sanxiyn wrote: post #37
steveklabnik wrote: post #8

Earlier quoted context omitted.

The biggest one in the near future is async/await; you’ll see the precursors land in the next few releases. There will also be a blog post soon outplaying overall plans for the year, but const generics, GATs, and specialization are the likely big-ticket items. In general, this year of Rust will be about governance refactoring, finishing off long-desired features like the ones above, and general polish. There isn’t a…

I think another big item is const fn and compile time function evaluation.

You mean expanding and improving const fn? Because the basis of const fn are already in stable since 1.31 and improved in 133.

Re: Rust 1.34.0

#50

Post by steveklabnik »

korethr wrote: post #46
steveklabnik wrote: post #33

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. Totally the correct way to go about it, IMO. Thus my comment about deprecation. >> There will not be a Rust 2.0. >> Note that upon using it, you’ll get a warning, so everyone will at least be notified. :/ That I've mixed feelings about. Why not? Is it because of the fiascos between Perl 5/6 and Python 2/3? Deprecations and warnings ab…

It’s partially that, it’s partially that systems people are very conservative, and it’s partially Rust’s own history before 1.0. People do view major breaking changes very differently these days due to those specific situations, and some people still think Rust changes daily. Systems languages tend to have a stability timeline of “forever.”

Rust does have a strong commitment to safety, but not an absolute commitment to correctness. These things happen very infrequently. Is it really worth taking an extreme action (which a major language version bump is, especially in the systems space) just to turn a few warnings into errors? Currently, we don’t think so. Maybe in 20 years, when (And if! :) ) there is more than one standard library API that suffers this problem, it would be worth it, but at the current time, it just doesn’t seem to make sense.

Post reply on HN