3 ms·

While I'm not sold on the premise even the most fervent Rust fan has to concede that idiomatic Rust changes several times a year which is nigh unsustainable for

While I'm not sold on the premise even the most fervent Rust fan has to concede that idiomatic Rust changes several times a year which is nigh unsustainable for any large codebase and no cargo fix is not a reasonable solution.

nicoburns 6y ago
Just leaving your code in the old style seems viable. My Rust code from 2017 still compiles just fine on the latest stable compiler. There are a bunch of ways I could simplify the code now (mainly enabled to non-lexical lifetimes), and I would if I needed to change the relevant section of code. But I definitely don't need to. The Rust compiler itself has lots of code in a really old style (much of it predates Rust 1.0, and originally used features that Rust no longer has). And it's generally considered to be maintainable code.
dijit 6y ago
Yes and no. Granted, I'm a little bit of a newbie; but there seems to be a fervent use of the 'nightly' compiler, which obviously changes frequently. Stuff that targeted stable seems to still work. But a frightening number of crates will only work on nightly. And I'm not sure if there was a "version" that ever worked on stable, as that information isn't immediately visible on crates.io.
- dathinab 6y ago
  The person is speaking about idiomatic rust code and seems to assume a large code base needs to always be updated to be in the most idiomatic stile. Most creates working on nightly only where tryfrom and async ones before that became stable. Now it's still common to find embedding and "crazy" creates (like there one which uses asm to hack in green threads) which work only on nightly. Most maintained creates work on stable by now, but it's not un-common to have some nightly only features. Honestly I haven't run into a created I wanted to use which requires nightly in a long time. The only crate which did cause me headaches in the recent year was ring (rustls,webpki) but that had gotten better.
  - gpm 6y ago
    > like there one which uses asm to hack in green threads Hey, I implemented that at one point (crazy is a good description)! But I didn't publish it on crates.io (just gitlab). Did someone actually publish a crate that does this?
- gpm 6y ago
  Honestly I find not that much needs nightly anymore, but > which obviously changes frequently. Not nearly as much as you would think. Everything that doesn't need a `#![feature(...)]` at the top of your crate never changes. Most `#![feature(...)]` flags enable things actually change pretty rarely - you can definitely go years on nightly without hitting a breaking change if you're conservative in your conservative in you feature set. > And I'm not sure if there was a "version" that ever worked on stable, as that information isn't immediately visible on crates.io. That would be a nice feature to have! But I bet that you would find that if a crate currently needs nightly, it needed nightly from basically the start.
dathinab 6y ago
It's idiomatic in rust not to chase some people's ideas about what idiomatic rust is, especially if that ideas include thinks like which libraries you use for what. If worked with rust (in a company) for over two years using rust for large code based is substainable. Sure at async fn's majorly changed for to do async IO, but that's basically it. Beside the async IO story other changes where often minor and fast to fix even without cargo fix. Also for a large code based there is zero reason to pedantically follow any new rust feature. It's actually idiomatic rust to not touch working/complete code just for some stile updates. And if you touch it anyway adding them cost you normally less than a minute. (Except async fn.)

nicoburns 6y ago

Just leaving your code in the old style seems viable. My Rust code from 2017 still compiles just fine on the latest stable compiler. There are a bunch of ways I could simplify the code now (mainly enabled to non-lexical lifetimes), and I would if I needed to change the relevant section of code. But I definitely don't need to. The Rust compiler itself has lots of code in a really old style (much of it predates Rust 1.0, and originally used features that Rust no longer has). And it's generally considered to be maintainable code.

dijit 6y ago

Yes and no. Granted, I'm a little bit of a newbie; but there seems to be a fervent use of the 'nightly' compiler, which obviously changes frequently. Stuff that targeted stable seems to still work. But a frightening number of crates will only work on nightly. And I'm not sure if there was a "version" that ever worked on stable, as that information isn't immediately visible on crates.io.

dathinab 6y ago
The person is speaking about idiomatic rust code and seems to assume a large code base needs to always be updated to be in the most idiomatic stile. Most creates working on nightly only where tryfrom and async ones before that became stable. Now it's still common to find embedding and "crazy" creates (like there one which uses asm to hack in green threads) which work only on nightly. Most maintained creates work on stable by now, but it's not un-common to have some nightly only features. Honestly I haven't run into a created I wanted to use which requires nightly in a long time. The only crate which did cause me headaches in the recent year was ring (rustls,webpki) but that had gotten better.
- gpm 6y ago
  > like there one which uses asm to hack in green threads Hey, I implemented that at one point (crazy is a good description)! But I didn't publish it on crates.io (just gitlab). Did someone actually publish a crate that does this?
gpm 6y ago
Honestly I find not that much needs nightly anymore, but > which obviously changes frequently. Not nearly as much as you would think. Everything that doesn't need a `#![feature(...)]` at the top of your crate never changes. Most `#![feature(...)]` flags enable things actually change pretty rarely - you can definitely go years on nightly without hitting a breaking change if you're conservative in your conservative in you feature set. > And I'm not sure if there was a "version" that ever worked on stable, as that information isn't immediately visible on crates.io. That would be a nice feature to have! But I bet that you would find that if a crate currently needs nightly, it needed nightly from basically the start.

dathinab 6y ago

It's idiomatic in rust not to chase some people's ideas about what idiomatic rust is, especially if that ideas include thinks like which libraries you use for what. If worked with rust (in a company) for over two years using rust for large code based is substainable. Sure at async fn's majorly changed for to do async IO, but that's basically it. Beside the async IO story other changes where often minor and fast to fix even without cargo fix. Also for a large code based there is zero reason to pedantically follow any new rust feature. It's actually idiomatic rust to not touch working/complete code just for some stile updates. And if you touch it anyway adding them cost you normally less than a minute. (Except async fn.)