62 ms·

> Every time someone posts a cool Rust library, most of the time it makes use of nightly. Examples? Examples that aren't tools, that is. The main example I can

> Every time someone posts a cool Rust library, most of the time it makes use of nightly. Examples? Examples that aren't tools, that is. The main example I can think of is serde, and that works on stable (just works better on nightly). What's wrong with nightly for using tooling? You don't have to keep updating, you can pin to a nightly from a particular date. You can use rustup.rs to switch to stable locally if you need to. I said it's unfair, because gcc has worse issues here, and everyone probably agrees that gcc is "enterprise ready".

pjmlp 10y ago
Many companies let their IT control what toolchains one is allowed to use. Usually it is set in stone and only updated every few IT upgrade cycles. What the devs get on their machines is that and nothing more.
- Manishearth 10y ago
  Good, install rustup.rs, with one date-pinned nightly, and stable. Freeze the rustup.rs install directory. Done?
  - yazaddaruvala 10y ago
    Lol, you're joking right? With respect, the Rust community is extremely in-exposed to the majority of actual enterprise environments, and that's ok. Honestly the best path forward is to just acknowledge it, say "we are working on it" and you'll get your point across better. Again with respect, because you all do really amazing work, fighting it honestly makes you and the whole community come across ignorant.
    - Manishearth 10y ago
      I'm not joking. Did you miss the part where I said the situation is worse for gcc? I do understand that this is a problem. I also do understand that it is not specific to Rust. Besides, convincing IT to allow rustup with an access-controlled toolchain directory shouldn't be a big deal in many cases. If they allowed one compiler, why not two? (Rustup can also be installed without sudo/admin, but I assume you are talking about situations where they want to restrict the executables running, not just globally installed executables). Yes, I know that in some cases they may not want two, but again, in those cases the GCC solution won't work either. Note that tools like nvm etc are also quite necessary in their respective spheres for serious development. I was once in a situation where I couldn't even install node at a modern version without nvm. For clippy, we are working on it, yes. For afl a simple fix exists (write the analog of -Xclang) but that fix will only work nicely if we ship llvm headers too which clang does (which we can, but it is a decision that can't be taken lightly). So no, we are not working on it. It is an interesting idea, and I will ping the relevant people (there are plans to ship "optional components" that you can obtain with rustup or download directly), but there are no concrete plans. The general evolution of Rust is towards everything being done through rustup. If you want to install a cross compile toolchain, clippy, get stdlib sources, or a different compiler version, use rustup. All the solutions to the nightly problem involve rustup. I.e. instead of installing nightly and using clippy, you just `rustup install clippy` or something and the relevant clippy binary (or compatible source?) will be downloaded, one which will work even if you are on stable. Basically, rustup will be the thing you install when you want to use rust. This is good, but as far as enterprise is concerned, you are still installing rustup, not rust. I'm not really sure what's wrong with this, but I'm sure some enterprise shops will have issues with this. For those which don't; the solution of having nightly installed via rustup in a frozen directory is not that much different, just unweildy. I have worked in places where the computer is locked down for many teams. But not in a place where it would be locked down in a way that rustc would be okay but rustup would not. I'd love to hear more about such cases and discuss how it can be addressed, but I'd prefer email (username@gmail or @mozilla.com). Thanks :)
      - kbenson 10y ago
        > The general evolution of Rust is towards everything being done through rustup. The general evolution of Perl was towards everything being done through cpan (the client). Decades ago. That doesn't stop companies from rolling their own Perl packages (when not just using what the system shipped with) and CPAN module packages (when it doesn't already exist as a package for the distro, or in a trusted third party repo, or is not the right version your code needs). In many enterprise environments, when one or more production servers running your code fails, you want clueless intern #23 to be able to spin up a new box, running the default configuration for your distro, and pop the required packages on for your program, copy the relevant config or two that are needed for it to event start, start it up and expect it to "just work". Running rustup and remembering it needs to install a specific version to ensure everything turns out right is not conducive to that. Now, this is less of a problem since rust is used to build other stand-alone programs, not necessarily run itself on as many servers, but it we're talking about a QA or testing box that dies, and there's a critical fix waiting to go out, I think it's obvious where this still has some importance.
        Manishearth 10y ago
        This is local developer tooling we're talking about, however. It doesn't need to run on those machines.
        kbenson 10y ago
        You want your devs all running the exact same version of the compiler. The last thing you want is someone with a slightly different version than used by everyone else (and production!) which writes some code that compiles and runs fine without problems, but crashes or exhibits a bug in testing, QA, or worst case, production. Having something like that occasionally gum up your development pipeline is a good reason for pegging tool versions (depending on the type of tool). Having things use rustup is great. Don't assume that's sufficient for certain populations of users (and a populations you really may want, such as enterprise). At best, they'll use rustup as a basis to start some other packaging, but even that's risky because rustup is complex, and it's hard to contain all the variables unless you're very careful about exactly what version you use with it, so then you're packaging rustup, and then package what it created. Easier at that point to just skip rustup. It's all about reproducibility, which is king in enterprise. Rustup is about ease of use, and easy iteration. Enterprise already sacrifice that on the alter of reproducibility, so it's really not a selling point for them. It's great for everyone else, it just has less to offer for this subgroup.
- pcwalton 10y ago
  In that case, you can't use AFL in GCC either!
- bluejekyll 10y ago
  That sounds like a horrible work environment. Seriously, devs can't choose their favorite tools, or specifically use tools which improve their quality until IT approves it? I've worked in bad places where it was hard to upgrade to the latest version of a language, but at least that was always under full control of the Dev group.
  - pjmlp 10y ago
    Quite typical scenario doing consulting for enterprise level companies. You come in, develop the modules you were hired for, using the existing stack and leave for the next gig. This is why regardless how good someone might brag about his/her C and C++ skills, they don't scale in this type of environments.
  - berkut 10y ago
    Not without a good business case. Would you really want every developer installing their favourite tools/libs and having a complete free-for-all when you've got 200+ devs, each with their own opinions and preferences? IT have to support this stuff, they don't want to be rebuilding the software stack every six months or so.
    - kbenson 10y ago
      This is not about a tool to provides a syntax, or makes commits. It's a tool that runs an instrumented version, only on the location the dev specifies, and reports actual bugs. If your team has a difference of opinion on whether you should fix actual bugs, you have larger problems. That said, if your program only feasibly runs in a shared QA/dev environment, then yes, it can be understandable to prevent devs installing random tools and utilities there. But in that case, the problem is not so much hedonistic developers, but a lack of separating portions of the code base into individually testable components. Again, you probably have larger problems than whether your devs can install their own tooling (because it's of limited use in a lot of cases anyway). To be clear, there are good reasons for restricting certain classes of tooling. You don't want the absent minded dev installing some cloud based source code integration tool. Then again, the only way to really protect against this is to isolate the dev network, and not allow internet access. I imagine the loss in productivity is fairly great. I'm sure there's a happy (or not!) medium in there, individual to most companies.
- chongli 10y ago
  The solution to that is to dust off the old résumé and start pounding the pavement!
- deleted 10y ago
  [deleted]
stymaar 10y ago
mioco use to require nightly builds until 1.9. It's so recent the readme still says that : > Note: You must be using nightly Rust release. If you're using multirust, which is highly recommended, switch with multirust default nightly command.
- Manishearth 10y ago
  Huh, interesting. I would go and try to un-nightly it but looks like someone got there first :p
berkut 10y ago
Because a lot of companies, at least those that develop their own internal software (on Linux for example) often stick to the compiler the system ships with, e.g. CentOS, say. GCC is in that respect "enterprise ready" because it very likely was installed on the system already. And probably not the latest version either.
- Manishearth 10y ago
  In rusts case it sounds like we will ship rustup.rs in distros, since it is also intended to be how people obtain cross compilers and whatnot. I could be wrong about this -- I am aware of, but not directly involved in, the plans for rustup. If not via rustup, I would expect everything that can be fetched via rustup to be in the package repo. This solves the problem for clippy but not for afl, though there are solutions there too. The GCC plugin for afl requires you to find the right GCC sources and compile against those (unless you use the hacky, less-awesome assembly based afl). This solution is available to you for afl-rs too, just not documented because using a nightly is easier. This makes afl-rs just as bad as GCC in this aspect. afl-rs needs a nightly not because it only works on specific versions, but because it hooks into the compiler in a way that is only allowed on nightly. Thus it will work on any nightly, even that from a few weeks ago, but it must be a nightly. As I mentioned it is possible to get it to work if you are willing to do what GCC does.
  - kbenson 10y ago
    > In rusts case it sounds like we will ship rustup.rs in distros I sincerely doubt any enterprise level distribution will make that the primary source of obtaining a rust compiler. I would bet good money that Red Hat won't. It's counter to most of the reason enterprise distributions exist in the first place, which is a stable (often at the cost of many other feature) base on which to build and support. If they aren't doing this, they aren't an enterprise distribution. This goes as far as Red Hat back-porting bug-fixes to 7 year old versions of utilities and libraries, because any change .needs to be backwards compatible at all cost. Additionally, there's the question of ensuring that all relevant portions of the rust install are removed on package removal. At the same time, getting the source and every patch applied to it, and the complete compile instruction for a package is generally very easy. It's meant to be repeatable. For Red Hat, you just get the appropriate srpm instead of rpm, and that unpacks a source tarball and any associated patches separated, along with an rpmbuild config that contains all the info used to build an rpm package from them. Every single thing, including the kernel is built this way. That's not to say rustup won't possibly be shipped as an extra utility, in one of th emain rust packages or as a separate one, but it definitely won't be the primary method most distributions provide for rust development (in the case of the non-enterprise distros, because it's just not as convenient as saying "install rust" and having it just be there, in a confirmed tested version that works with whatever other packaged tooling they provide. There are downsides to this, but there are also many benefits.
deleted 10y ago
[deleted]

pjmlp 10y ago

Many companies let their IT control what toolchains one is allowed to use. Usually it is set in stone and only updated every few IT upgrade cycles. What the devs get on their machines is that and nothing more.

Manishearth 10y ago
Good, install rustup.rs, with one date-pinned nightly, and stable. Freeze the rustup.rs install directory. Done?
- yazaddaruvala 10y ago
  Lol, you're joking right? With respect, the Rust community is extremely in-exposed to the majority of actual enterprise environments, and that's ok. Honestly the best path forward is to just acknowledge it, say "we are working on it" and you'll get your point across better. Again with respect, because you all do really amazing work, fighting it honestly makes you and the whole community come across ignorant.
  - Manishearth 10y ago
    I'm not joking. Did you miss the part where I said the situation is worse for gcc? I do understand that this is a problem. I also do understand that it is not specific to Rust. Besides, convincing IT to allow rustup with an access-controlled toolchain directory shouldn't be a big deal in many cases. If they allowed one compiler, why not two? (Rustup can also be installed without sudo/admin, but I assume you are talking about situations where they want to restrict the executables running, not just globally installed executables). Yes, I know that in some cases they may not want two, but again, in those cases the GCC solution won't work either. Note that tools like nvm etc are also quite necessary in their respective spheres for serious development. I was once in a situation where I couldn't even install node at a modern version without nvm. For clippy, we are working on it, yes. For afl a simple fix exists (write the analog of -Xclang) but that fix will only work nicely if we ship llvm headers too which clang does (which we can, but it is a decision that can't be taken lightly). So no, we are not working on it. It is an interesting idea, and I will ping the relevant people (there are plans to ship "optional components" that you can obtain with rustup or download directly), but there are no concrete plans. The general evolution of Rust is towards everything being done through rustup. If you want to install a cross compile toolchain, clippy, get stdlib sources, or a different compiler version, use rustup. All the solutions to the nightly problem involve rustup. I.e. instead of installing nightly and using clippy, you just `rustup install clippy` or something and the relevant clippy binary (or compatible source?) will be downloaded, one which will work even if you are on stable. Basically, rustup will be the thing you install when you want to use rust. This is good, but as far as enterprise is concerned, you are still installing rustup, not rust. I'm not really sure what's wrong with this, but I'm sure some enterprise shops will have issues with this. For those which don't; the solution of having nightly installed via rustup in a frozen directory is not that much different, just unweildy. I have worked in places where the computer is locked down for many teams. But not in a place where it would be locked down in a way that rustc would be okay but rustup would not. I'd love to hear more about such cases and discuss how it can be addressed, but I'd prefer email (username@gmail or @mozilla.com). Thanks :)
    - kbenson 10y ago
      > The general evolution of Rust is towards everything being done through rustup. The general evolution of Perl was towards everything being done through cpan (the client). Decades ago. That doesn't stop companies from rolling their own Perl packages (when not just using what the system shipped with) and CPAN module packages (when it doesn't already exist as a package for the distro, or in a trusted third party repo, or is not the right version your code needs). In many enterprise environments, when one or more production servers running your code fails, you want clueless intern #23 to be able to spin up a new box, running the default configuration for your distro, and pop the required packages on for your program, copy the relevant config or two that are needed for it to event start, start it up and expect it to "just work". Running rustup and remembering it needs to install a specific version to ensure everything turns out right is not conducive to that. Now, this is less of a problem since rust is used to build other stand-alone programs, not necessarily run itself on as many servers, but it we're talking about a QA or testing box that dies, and there's a critical fix waiting to go out, I think it's obvious where this still has some importance.
      - Manishearth 10y ago
        This is local developer tooling we're talking about, however. It doesn't need to run on those machines.
        kbenson 10y ago
        You want your devs all running the exact same version of the compiler. The last thing you want is someone with a slightly different version than used by everyone else (and production!) which writes some code that compiles and runs fine without problems, but crashes or exhibits a bug in testing, QA, or worst case, production. Having something like that occasionally gum up your development pipeline is a good reason for pegging tool versions (depending on the type of tool). Having things use rustup is great. Don't assume that's sufficient for certain populations of users (and a populations you really may want, such as enterprise). At best, they'll use rustup as a basis to start some other packaging, but even that's risky because rustup is complex, and it's hard to contain all the variables unless you're very careful about exactly what version you use with it, so then you're packaging rustup, and then package what it created. Easier at that point to just skip rustup. It's all about reproducibility, which is king in enterprise. Rustup is about ease of use, and easy iteration. Enterprise already sacrifice that on the alter of reproducibility, so it's really not a selling point for them. It's great for everyone else, it just has less to offer for this subgroup.
pcwalton 10y ago
In that case, you can't use AFL in GCC either!
bluejekyll 10y ago
That sounds like a horrible work environment. Seriously, devs can't choose their favorite tools, or specifically use tools which improve their quality until IT approves it? I've worked in bad places where it was hard to upgrade to the latest version of a language, but at least that was always under full control of the Dev group.
- pjmlp 10y ago
  Quite typical scenario doing consulting for enterprise level companies. You come in, develop the modules you were hired for, using the existing stack and leave for the next gig. This is why regardless how good someone might brag about his/her C and C++ skills, they don't scale in this type of environments.
- berkut 10y ago
  Not without a good business case. Would you really want every developer installing their favourite tools/libs and having a complete free-for-all when you've got 200+ devs, each with their own opinions and preferences? IT have to support this stuff, they don't want to be rebuilding the software stack every six months or so.
  - kbenson 10y ago
    This is not about a tool to provides a syntax, or makes commits. It's a tool that runs an instrumented version, only on the location the dev specifies, and reports actual bugs. If your team has a difference of opinion on whether you should fix actual bugs, you have larger problems. That said, if your program only feasibly runs in a shared QA/dev environment, then yes, it can be understandable to prevent devs installing random tools and utilities there. But in that case, the problem is not so much hedonistic developers, but a lack of separating portions of the code base into individually testable components. Again, you probably have larger problems than whether your devs can install their own tooling (because it's of limited use in a lot of cases anyway). To be clear, there are good reasons for restricting certain classes of tooling. You don't want the absent minded dev installing some cloud based source code integration tool. Then again, the only way to really protect against this is to isolate the dev network, and not allow internet access. I imagine the loss in productivity is fairly great. I'm sure there's a happy (or not!) medium in there, individual to most companies.
chongli 10y ago
The solution to that is to dust off the old résumé and start pounding the pavement!
deleted 10y ago
[deleted]

stymaar 10y ago

mioco use to require nightly builds until 1.9. It's so recent the readme still says that : > Note: You must be using nightly Rust release. If you're using multirust, which is highly recommended, switch with multirust default nightly command.

Manishearth 10y ago
Huh, interesting. I would go and try to un-nightly it but looks like someone got there first :p

berkut 10y ago

Because a lot of companies, at least those that develop their own internal software (on Linux for example) often stick to the compiler the system ships with, e.g. CentOS, say. GCC is in that respect "enterprise ready" because it very likely was installed on the system already. And probably not the latest version either.

Manishearth 10y ago
In rusts case it sounds like we will ship rustup.rs in distros, since it is also intended to be how people obtain cross compilers and whatnot. I could be wrong about this -- I am aware of, but not directly involved in, the plans for rustup. If not via rustup, I would expect everything that can be fetched via rustup to be in the package repo. This solves the problem for clippy but not for afl, though there are solutions there too. The GCC plugin for afl requires you to find the right GCC sources and compile against those (unless you use the hacky, less-awesome assembly based afl). This solution is available to you for afl-rs too, just not documented because using a nightly is easier. This makes afl-rs just as bad as GCC in this aspect. afl-rs needs a nightly not because it only works on specific versions, but because it hooks into the compiler in a way that is only allowed on nightly. Thus it will work on any nightly, even that from a few weeks ago, but it must be a nightly. As I mentioned it is possible to get it to work if you are willing to do what GCC does.
- kbenson 10y ago
  > In rusts case it sounds like we will ship rustup.rs in distros I sincerely doubt any enterprise level distribution will make that the primary source of obtaining a rust compiler. I would bet good money that Red Hat won't. It's counter to most of the reason enterprise distributions exist in the first place, which is a stable (often at the cost of many other feature) base on which to build and support. If they aren't doing this, they aren't an enterprise distribution. This goes as far as Red Hat back-porting bug-fixes to 7 year old versions of utilities and libraries, because any change .needs to be backwards compatible at all cost. Additionally, there's the question of ensuring that all relevant portions of the rust install are removed on package removal. At the same time, getting the source and every patch applied to it, and the complete compile instruction for a package is generally very easy. It's meant to be repeatable. For Red Hat, you just get the appropriate srpm instead of rpm, and that unpacks a source tarball and any associated patches separated, along with an rpmbuild config that contains all the info used to build an rpm package from them. Every single thing, including the kernel is built this way. That's not to say rustup won't possibly be shipped as an extra utility, in one of th emain rust packages or as a separate one, but it definitely won't be the primary method most distributions provide for rust development (in the case of the non-enterprise distros, because it's just not as convenient as saying "install rust" and having it just be there, in a confirmed tested version that works with whatever other packaged tooling they provide. There are downsides to this, but there are also many benefits.

deleted 10y ago

[deleted]