42 ms·

A brief history of Rust at Facebook

234 points by tomduncalf 6y ago

superkuh 6y ago
Rust releases only last about 5 months before they're so out of date you can't compile something written $today. I suppose this is a perfect fit for Facebook though since they control their entire stack and rebuilding the world is a-ok. It's not so okay if you're trying to write something you expect other people to be able to compile and run.
- dijit 6y ago
  Stop using +nightly. Stable rust hasn't broken in my experience.
  - superkuh 6y ago
    I don't. I use rust from debian repos. In Debian 11 (bullseye), a distro which has not even been released yet, it has Rust 1.48 from 2020-11-19. This already is out of date and was unable to compile the two 1.50 targeting applications I wanted to try out. And don't go saying I should use rust-up. That's a symptom of the very problem I'm describing. What other compiler is only usable if you install from some website instead of your repos? I can't think of any.
    - csomar 6y ago
      This might be a case of a dependency that doesn't respect SemVer? Did you post this incidence? Edit: Just re-read your comment. Maybe ping the guys in Debian to update their repos?
    - foota 6y ago
      Typescript and node?
    - jacobolus 6y ago
      So your complaint is that Rust library authors are too excited to use new stable features as soon as they are available, and your preference would be for them to wait e.g. a year before adopting new language features, so that their code keeps working with old compiler versions? Hard to see this as a problem with the language per se. What is the language supposed to do, ship working features but ask people politely not to use them? Not ship new features even if they solve acute problems? As a library consumer, if you want you can just stick to >6 month old versions of all the libraries you depend on, and they should work fine with your 6 month old compiler version.
      - rhn_mk1 6y ago
        It's not a problem with the language directly, but with its culture. People being excited to use new feature is a nice thing for them, but the trade off is that the consumers of their work may suffer.
        mijamo 6y ago
        It is actually a problem with the language as well because it is still missing a lot of important things, so releases actually change your productivity and you use the shiny new features because they solve real pains. And this is far from over because there's still a lot of pain in rust development and a lot in the work to fix it. The same could have been said about JS/typescript where so many things were annoying that people rushed to use the new features. This is getting a bit calmer now because the new annual features are less life changing. Eventually maybe in 5 years Rust will have it's major pains solved and things slow down a bit. Maybe then the release schedule will actually change as well? Who knows
        nindalf 6y ago
        What are the features you expect Rust to gain between now and 5 years from now? As for major language features I remember async await from a year ago, const generics recently and that’s it. If you can remember more features that fundamentally changed how we write code, please let us know. I don’t think many features are expected in the near future apart from maybe generic associated types. But not any time soon either. I think you might be seeing releases every six weeks and assume that each of these bring massive changes. They don’t. Each is a small iterative improvement. Take a look at the Rust release notes if you like.
    - the_mitsuhiko 6y ago
      I maintain a project which has _a bunch_ of dependencies and tests im CI that it can compile on 1.41. That’s a lot of dependencies: https://crates.io/crates/insta/1.7.1/dependencies https://crates.io/crates/insta/1.7.1/dependencies
    - deleted 6y ago
      [deleted]
    - da_big_ghey 6y ago
      i am not rust user, but many language are use its own pacage managing. making pacage first through language then through distro are two layer of review it must pass, so are always slow. i am not hearing persons complain on ruby, python, javascript, go, r, perl, ... use own pacage manage. rust are not a different here. in future maybe it stabalize and we are then having fewer update for to manage.
    - howinteresting 6y ago
      Plenty of C++ code can't use modern C++ features because of Linux distributions holding everyone back. I think this is a bad thing and don't want these concerns to seep into Rust as well (outside of "fundamental" libraries.) Safety-critical systems may need these guarantees, but I object to them externalizing the costs they need to bear on the whole community. Almost everyone should be on up-to-date compilers, assuming the compilers promise that they won't break old code. The more we move towards that world the better.
    - ogoffart 6y ago
      Yeah, this is a problem that the distribution packaged rust compiler is quickly out of date compared to what most of the ecosystem expect. However there is hope for a better future: https://github.com/rust-lang/rust/issues/65262 https://github.com/rust-lang/rust/issues/65262 will allow crates to specify a minimum supported rust version (MSRV), this way, we can imagine cargo resolving algorithm taking the installed rust version into account when picking the version of a crate to download so it would pick the last version of the crate that still compile on your system. Another thing is the Sealed Rust / Ferrocene initiative [https://ferrous-systems.com/ferrocene/ https://ferrous-systems.com/ferrocene/]. The idea is to have a version of rust supported for a long time, and it is likely that many core crates from the ecosystem will decide to keep compatibility with that LTS version.
      - ogoffart 6y ago
        Relying to myself to mention another thing: https://github.com/rust-lang/rust/issues/64796 https://github.com/rust-lang/rust/issues/64796 is adding support for a #[cfg(version(x.y))] tag that will allow crates to more easily provide additional feature when using newer compiler, while still being compatible with older rust versions.
    - hctaw 6y ago
      It's becoming less sane to use any systems package management to handle tool chains and libraries with each passing day. The recommended way to manage your rust installation is rustup. It makes it trivial to set up and manage tool chains, globally or otherwise. > what other compiler is only usable if you install from some website instead of your repos? What compilers' recommended installation is some 3rd party package manager that lags behind the latest stable release by months? Rustup is a useful tool, it's dumb to ignore it.
      - disgruntledphd2 6y ago
        > It's becoming less sane to use any systems package management to handle tool chains and libraries with each passing day. And this is a terrible development that we should all try to resist, as it leads to a combinatoral explosion of dependencies and problems, as soon as you introduce another language. So then we end up using docker to encapsulate things because they are hard to manage on one box. It just seems crazy, but I don't really have much of a solution, tbh. Perhaps we could just install the build tool (in this case rustup) for supported languages and stop trying.
        hctaw 6y ago
        I don't think it's terrible. Modern package management just works on a different assumption - the dependencies and their artifacts are required at build time, and for libraries they cannot assume the version required by the software exists outside the build environment or in deployment. If all of software respected those assumptions then we wouldn't need containerization nearly to the degree we have it today.
        disgruntledphd2 6y ago
        It's all fine until you start needing multiple language package managers, each with their own C/C++ dependencies, and then it gets a lot trickier. I mean, I know how to handle it, but it's pretty depressing that I need to do it, when in the past one could rely on relatively recent versions of everything existing with a system package manager. I always need C/C++/Java dependencies in DS, so maybe I just feel the pain points more.
    - jen20 6y ago
      I see this complaint a lot. The answer is not for people to not use modern features of tools with frankly very reasonable cadence, but instead for distributions to adapt to a world where things are not distributed on CDs any more.
    - akiselev 6y ago
      The problem is that you chose a Linux distro with an explicit stability guarantee and a slower release cadence than Rust. If you had chosen a rolling distro like Arch, you wouldn't have to use Rustup.
    - sophacles 6y ago
      > And don't go saying I should use rust-up. That's a symptom of the very problem I'm describing. What other compiler is only usable if you install from some website instead of your repos? I can't think of any. Lets see... i had this problem with python all the time, the system python version was notoriously old and out of date on macos, redhat, debian, etc. This is how pip and pyenv and a dozen other tools were born. Similar things with node. Or when the distro gcc has a bug that your code hits. Go has this problem too - e.g. the pain around moving from nothing -> dep -> modules was real (if not widely publicized). The language provided version/package manager solves a very real problem. That problem is a mismatch in what a system package should be vs what a development package should be. In some sense containers, nix/guix stye package management, and language specific dependency managers are different approaches to solving the problem: what my computer runs for daily use should be relatively stable and generally I won't need the latest and greatest package features in software I use - upstream developers have generaly dealt with various library deficiencies bugs in their dependencies. In software I develop though, I regularly hit api bugs and sure would like to just use version+1 instead of spending time developing around it. Particularly when the output of my development is a binary that is running in a container on some server.
  - deleted 6y ago
    [deleted]
- pizza234 6y ago
  I've just taken a snapshot of a non-trivial project of mine, from exactly 5 months ago: builds fine. Last snapshot with significant changes: 4 months ago, builds fine as well.
  - steveklabnik 6y ago
    I think your comment is good, but also, your comment and the parent comment highlight a situation that makes this discussion hard: you're both talking about two different things. You're talking about using a current compiler to build old code, aka, backwards compatibility. We put a lot of time and effort into this, because it's important, and we're not perfect, but we're pretty darn good at it, it seems. The parent is talking about using an older compiler to build newer code, aka, forwards compatibility. Basically no programming languages I'm aware of provides this today, but they release on a much slower schedule, which means that in practice, it is likely to happen less often. Because Rust ships so often, and because it's so easy to upgrade Rust, the community tends to adopt newer features faster than in other language ecosystems, meaning that forward compatibility becomes more of an issue if you do not want to update the compiler.
    - swsieber 6y ago
      To build on this, there are parts of the ecosystem that explicitly outline their Minimum Supported Rust Version. Sometimes it's short (e.g. last two stable releases), and sometimes it's longer (6+ most recent stable releases). What's not well expressed is that is that certain releases prompt a bunch of people to upgrade the newest libraries to require the latest stable release. And these releases are not easily visible or predictable from outside the community. This is driven by Rust releases that stabilize significant features; I'm talking about stuff like async, min const generics, impl trait, proc macro support. So support for older releases tends to wax and wane depending on how recently a big feature was stabilized. There is one other contributing factor - cargo tries to pick the most recent version of library (that's SemVer compliant), not the earliest one, and MSRV changes aren't at this point considered a breaking SemVer change (as far as I know)
    - returningfory2 6y ago
- csomar 6y ago
  That's really weird. So far Rust has been the most stable thing I have worked with. Working with Cargo was a pleasant experience knowing that I will compile any program and the compilation will go smoothly (vs. Python where I have multiple times figure out what went wrong).
- otabdeveloper4 6y ago
  Don't blaspheme against the FOTM gods. Today is the year of the Rust. Wait until next year when $language is the next shining beacon of not-having-to-deal-with-legacy and Rust itself goes to the dustheap where Cobol and Fortran and Python 3.6 now live.
  - dave_sid 6y ago
    Rust was doomed to fail from the start.
    - yjftsjthsd-h 6y ago
      Why?
- reificator 6y ago
  I don't understand your concern. You're upset that new features are not backported to older compiler versions? If you have some reason to not update your compiler, then don't use those new features, and use dependency versions that also don't use those features. Go back a few releases if you need to. If you do need those features though... Then just upgrade your compiler? I'm not aware of any compilers/interpreters that work the way you want here. Maybe Python 2 for that painful decade of overlap...
- mamcx 6y ago
  I have done more than dozen of languages and consider Rust the best experience for both "get new shinny things" and "keep old quiet". But the Rust experience IS cargo. No (other) package managers. Rust is cargo centric. With it, you are free to pin to versions and keep things working for very long. BUT also if you are coming cold to any library is to be EXPECTED to be "new". This is a good thing: The community at large move forward in tandem as if it were a coordinated army! But that don't mean I can't work with older code, is that if you see a crate RIGTH NOW you see te forward momentum at large. If you wanna use something older you can pin to a back version. However, this also point to a fair problem: Is not easy to correlate to which version of Rust each crate(version) relate to.
  - deleted 6y ago
    [deleted]
- carlosdp 6y ago
  That's just blatantly false. Rust takes extreme pains to be backwards compatible. When they wanted to make breaking changes to support some new language features, they literally spun up a separate compiler front-end behind a cargo.toml flag to make sure they didn't break any existing code. Compiler changes are tested against a bunch of libraries in the crates.io repository to ensure nothing breaks. It's just exceedingly rare that a new Rust version would break older code.
  - ithkuil 6y ago
    I think GP meant forward compatibility. New code will use new features and won't compile on old compilers (like other languages)
    - Ar-Curunir 6y ago
      If you updated old compiler with new features, aren't they new compilers?
      - ithkuil 6y ago
        the most charitable reading of GP is not that nobody can ever implement new features in a language but that the 5 month release cycle is causing new features to come in too fast.
- serial_dev 6y ago
  Backward compatibility doesn't mean that you write code with the latest features, then go back to a version that's a year old than expect it to work. No language or software does that. The promise is that if you have code you didn't touch for a year, you can update Rust, and it will still compile. You got it backwards.
atom_arranger 6y ago
Not mentioned here but FB is rewriting the Relay compiler in Rust as well. Will be interesting to see how well it works. https://github.com/facebook/relay/issues/3180 https://github.com/facebook/relay/issues/3180 Personally I've had trouble with the Relay compilers watch mode not picking up file changes but that might be a Watchman issue not a Relay compiler issue.
- atom_arranger 6y ago
  Should have mentioned that I only mentioned watch mode issues because that’s the only issue I’ve had with the JS compiler. It’s been fast enough, although the app I’m working on is relatively small.
throwastrike 6y ago
Did they release any Rust-related libraries for their crypto project?
TechBro8615 6y ago
> As one significant example of that growth, Rust is the leading language in the development of the Diem (formerly Libra) blockchain, which is overseen by the independent Diem Association. Facebook, through its digital wallet Novi, is a member of the Diem Association. I'm always amused by the contortionist double-speak of Facebook communications. They put so much effort into distancing themselves from Libra when they launched it, but now they have a chance to take some credit for the work behind it, all of a sudden it's a kinda-sorta Facebook project. Totally off-topic but I can never resist a jab at Facebook. Anyway – great news for Rust. Despite my distaste of FB, I can't deny the value of their open source contributions.
- xrikcus 6y ago
  It's not really a contradiction to take credit for the effort behind something, but also make an effort to allow that thing to be independent once started, is it?
ChrisArchitect 6y ago
related from today: Facebook Joins Rust Foundation https://news.ycombinator.com/item?id=26982890 https://news.ycombinator.com/item?id=26982890
dragosmocrii 6y ago
I'm curious what people think about Rust as a long-term investment from an employment/job perspective. Is it going to pay the bills for the next 10 years? I've been using PHP for the past 10 years, and I've never run out of work. I can't say the same about Elixir, which I very much like, but the job market proved to be scarce. Just wondering what Rust's future looks like. Thanks for your opinions A note(since I notice my comment is getting downvoted): I've actually been spending time regularly for the past few weeks reading multiple tutorials, and getting familiar with Rust's concepts, and I really like the language and I can see that a lot of work has been put into developing it. But my concern is that there are other languages as well that have a solid background (OCaml, Haskell, to name a few), but that are still niche languages and suffer from the same scarce job market opportunities. Which proves that adoption does not always depend on how good a language is.
- est31 6y ago
  From a long term perspective I'm not worried but short to mid term it might cause some issues because currently there aren't that many Rust jobs yet. It's kind of a niche still, jobs wise.
  - dragosmocrii 6y ago
    Thank you, this is reassuring!
- habitue 6y ago
  Rust has been picked up at Amazon, Google, Facebook and Microsoft. I think that gravitational pull is going to keep Rust a going concern for a long time. That being said, it's an investment in the future mostly. There aren't anywhere near as many Rust jobs as PHP, Java, or Python jobs.
  - joatmon-snoo 6y ago
    Rust at Google is in a bit of an awkward state. There's a bunch of teams/projects that have used it, but we haven't yet staffed a team to manage an internal Rust toolchain/ecosystem. The most recent one was Kotlin, in large part because our Android ecosystem was increasingly having to play catch up, so we'll see if/when a Rust team gets staffed.
Graffur 6y ago
Without getting a job in Rust (due to lack of experience) what is the best way to get experience with it?
- the_gipsy 6y ago
  I did some experiments with bevy.
- da39a3ee 6y ago
  Write little command line tools for yourself in it (it’s the same answer for most languages).
  - bigiain 6y ago
    The embedded RustConf talk said a big thing internally at FB was rewriting stuff like existing/well-used Python scripts into Rust...
- ahelwer 6y ago
  Find an open source project you care about that uses it then try to fix some simple issues. That's how I learned!
- azdle 6y ago
  Write something that sounds fun. It doesn't even have to be useful to anyone, just interesting. And you have to be able to talk about it. The last person we hired for our team, I actively courted because he'd written a javascript parser (note: just a parser, it parsed basic JS to an AST and did nothing with it) and talked about it at a local rust meetup I'd been hosting (until COVID). If you don't have local (or maybe now vitual?) meetups to go to, write a blog post about it and post it to HN and put a single sentence "I'm looking for a job that lets me write Rust professionally" note at the bottom, you never know who's going to see it.
- oconnor663 6y ago
  The official book is good, and I recommend even experienced programmers read it. Ownership, borrowing, and lifetimes are really central to the language, and really handled differently from other familiar languages. The jump from "implicit and occasionally violated" notions of ownership to an "explicit and 100% enforced" notion is a big one.
frob 6y ago
I personally know this timeline to be incorrect by at least a year. I was part of a startup that got acquired by FB in early 2015. We moved our codebase into the FB monorepo pretty quickly. One of our microservices was written in Rust. It was only a few hundred lines, but it was in the repo and actively deployed on FB infra by April or so of 2015.
- oconnor663 6y ago
  Does that mean it was pre-1.0 Rust!?
  - alfiedotwtf 6y ago
    Must be, since the 1.0 release was a month later.
  - frob 6y ago
    Yup!
- jsgf 6y ago
  Wit?
deleted 6y ago
[deleted]
higerordermap 6y ago
Are there enough rust jobs that don't involve shady stuff like crypto currency?

234 points by tomduncalf 6y ago

Rust releases only last about 5 months before they're so out of date you can't compile something written $today. I suppose this is a perfect fit for Facebook though since they control their entire stack and rebuilding the world is a-ok. It's not so okay if you're trying to write something you expect other people to be able to compile and run.

dijit 6y ago
Stop using +nightly. Stable rust hasn't broken in my experience.
- superkuh 6y ago
  I don't. I use rust from debian repos. In Debian 11 (bullseye), a distro which has not even been released yet, it has Rust 1.48 from 2020-11-19. This already is out of date and was unable to compile the two 1.50 targeting applications I wanted to try out. And don't go saying I should use rust-up. That's a symptom of the very problem I'm describing. What other compiler is only usable if you install from some website instead of your repos? I can't think of any.
  - csomar 6y ago
    This might be a case of a dependency that doesn't respect SemVer? Did you post this incidence? Edit: Just re-read your comment. Maybe ping the guys in Debian to update their repos?
  - foota 6y ago
    Typescript and node?
  - jacobolus 6y ago
    So your complaint is that Rust library authors are too excited to use new stable features as soon as they are available, and your preference would be for them to wait e.g. a year before adopting new language features, so that their code keeps working with old compiler versions? Hard to see this as a problem with the language per se. What is the language supposed to do, ship working features but ask people politely not to use them? Not ship new features even if they solve acute problems? As a library consumer, if you want you can just stick to >6 month old versions of all the libraries you depend on, and they should work fine with your 6 month old compiler version.
    - rhn_mk1 6y ago
      It's not a problem with the language directly, but with its culture. People being excited to use new feature is a nice thing for them, but the trade off is that the consumers of their work may suffer.
      - mijamo 6y ago
        It is actually a problem with the language as well because it is still missing a lot of important things, so releases actually change your productivity and you use the shiny new features because they solve real pains. And this is far from over because there's still a lot of pain in rust development and a lot in the work to fix it. The same could have been said about JS/typescript where so many things were annoying that people rushed to use the new features. This is getting a bit calmer now because the new annual features are less life changing. Eventually maybe in 5 years Rust will have it's major pains solved and things slow down a bit. Maybe then the release schedule will actually change as well? Who knows
        nindalf 6y ago
        What are the features you expect Rust to gain between now and 5 years from now? As for major language features I remember async await from a year ago, const generics recently and that’s it. If you can remember more features that fundamentally changed how we write code, please let us know. I don’t think many features are expected in the near future apart from maybe generic associated types. But not any time soon either. I think you might be seeing releases every six weeks and assume that each of these bring massive changes. They don’t. Each is a small iterative improvement. Take a look at the Rust release notes if you like.
  - the_mitsuhiko 6y ago
    I maintain a project which has _a bunch_ of dependencies and tests im CI that it can compile on 1.41. That’s a lot of dependencies: https://crates.io/crates/insta/1.7.1/dependencies https://crates.io/crates/insta/1.7.1/dependencies
  - deleted 6y ago
    [deleted]
  - da_big_ghey 6y ago
    i am not rust user, but many language are use its own pacage managing. making pacage first through language then through distro are two layer of review it must pass, so are always slow. i am not hearing persons complain on ruby, python, javascript, go, r, perl, ... use own pacage manage. rust are not a different here. in future maybe it stabalize and we are then having fewer update for to manage.
  - howinteresting 6y ago
    Plenty of C++ code can't use modern C++ features because of Linux distributions holding everyone back. I think this is a bad thing and don't want these concerns to seep into Rust as well (outside of "fundamental" libraries.) Safety-critical systems may need these guarantees, but I object to them externalizing the costs they need to bear on the whole community. Almost everyone should be on up-to-date compilers, assuming the compilers promise that they won't break old code. The more we move towards that world the better.
  - ogoffart 6y ago
    Yeah, this is a problem that the distribution packaged rust compiler is quickly out of date compared to what most of the ecosystem expect. However there is hope for a better future: https://github.com/rust-lang/rust/issues/65262 https://github.com/rust-lang/rust/issues/65262 will allow crates to specify a minimum supported rust version (MSRV), this way, we can imagine cargo resolving algorithm taking the installed rust version into account when picking the version of a crate to download so it would pick the last version of the crate that still compile on your system. Another thing is the Sealed Rust / Ferrocene initiative [https://ferrous-systems.com/ferrocene/ https://ferrous-systems.com/ferrocene/]. The idea is to have a version of rust supported for a long time, and it is likely that many core crates from the ecosystem will decide to keep compatibility with that LTS version.
    - ogoffart 6y ago
      Relying to myself to mention another thing: https://github.com/rust-lang/rust/issues/64796 https://github.com/rust-lang/rust/issues/64796 is adding support for a #[cfg(version(x.y))] tag that will allow crates to more easily provide additional feature when using newer compiler, while still being compatible with older rust versions.
  - hctaw 6y ago
    It's becoming less sane to use any systems package management to handle tool chains and libraries with each passing day. The recommended way to manage your rust installation is rustup. It makes it trivial to set up and manage tool chains, globally or otherwise. > what other compiler is only usable if you install from some website instead of your repos? What compilers' recommended installation is some 3rd party package manager that lags behind the latest stable release by months? Rustup is a useful tool, it's dumb to ignore it.
    - disgruntledphd2 6y ago
      > It's becoming less sane to use any systems package management to handle tool chains and libraries with each passing day. And this is a terrible development that we should all try to resist, as it leads to a combinatoral explosion of dependencies and problems, as soon as you introduce another language. So then we end up using docker to encapsulate things because they are hard to manage on one box. It just seems crazy, but I don't really have much of a solution, tbh. Perhaps we could just install the build tool (in this case rustup) for supported languages and stop trying.
      - hctaw 6y ago
        I don't think it's terrible. Modern package management just works on a different assumption - the dependencies and their artifacts are required at build time, and for libraries they cannot assume the version required by the software exists outside the build environment or in deployment. If all of software respected those assumptions then we wouldn't need containerization nearly to the degree we have it today.
        disgruntledphd2 6y ago
        It's all fine until you start needing multiple language package managers, each with their own C/C++ dependencies, and then it gets a lot trickier. I mean, I know how to handle it, but it's pretty depressing that I need to do it, when in the past one could rely on relatively recent versions of everything existing with a system package manager. I always need C/C++/Java dependencies in DS, so maybe I just feel the pain points more.
  - jen20 6y ago
    I see this complaint a lot. The answer is not for people to not use modern features of tools with frankly very reasonable cadence, but instead for distributions to adapt to a world where things are not distributed on CDs any more.
  - akiselev 6y ago
    The problem is that you chose a Linux distro with an explicit stability guarantee and a slower release cadence than Rust. If you had chosen a rolling distro like Arch, you wouldn't have to use Rustup.
  - sophacles 6y ago
    > And don't go saying I should use rust-up. That's a symptom of the very problem I'm describing. What other compiler is only usable if you install from some website instead of your repos? I can't think of any. Lets see... i had this problem with python all the time, the system python version was notoriously old and out of date on macos, redhat, debian, etc. This is how pip and pyenv and a dozen other tools were born. Similar things with node. Or when the distro gcc has a bug that your code hits. Go has this problem too - e.g. the pain around moving from nothing -> dep -> modules was real (if not widely publicized). The language provided version/package manager solves a very real problem. That problem is a mismatch in what a system package should be vs what a development package should be. In some sense containers, nix/guix stye package management, and language specific dependency managers are different approaches to solving the problem: what my computer runs for daily use should be relatively stable and generally I won't need the latest and greatest package features in software I use - upstream developers have generaly dealt with various library deficiencies bugs in their dependencies. In software I develop though, I regularly hit api bugs and sure would like to just use version+1 instead of spending time developing around it. Particularly when the output of my development is a binary that is running in a container on some server.
- deleted 6y ago
  [deleted]
pizza234 6y ago
I've just taken a snapshot of a non-trivial project of mine, from exactly 5 months ago: builds fine. Last snapshot with significant changes: 4 months ago, builds fine as well.
- steveklabnik 6y ago
  I think your comment is good, but also, your comment and the parent comment highlight a situation that makes this discussion hard: you're both talking about two different things. You're talking about using a current compiler to build old code, aka, backwards compatibility. We put a lot of time and effort into this, because it's important, and we're not perfect, but we're pretty darn good at it, it seems. The parent is talking about using an older compiler to build newer code, aka, forwards compatibility. Basically no programming languages I'm aware of provides this today, but they release on a much slower schedule, which means that in practice, it is likely to happen less often. Because Rust ships so often, and because it's so easy to upgrade Rust, the community tends to adopt newer features faster than in other language ecosystems, meaning that forward compatibility becomes more of an issue if you do not want to update the compiler.
  - swsieber 6y ago
    To build on this, there are parts of the ecosystem that explicitly outline their Minimum Supported Rust Version. Sometimes it's short (e.g. last two stable releases), and sometimes it's longer (6+ most recent stable releases). What's not well expressed is that is that certain releases prompt a bunch of people to upgrade the newest libraries to require the latest stable release. And these releases are not easily visible or predictable from outside the community. This is driven by Rust releases that stabilize significant features; I'm talking about stuff like async, min const generics, impl trait, proc macro support. So support for older releases tends to wax and wane depending on how recently a big feature was stabilized. There is one other contributing factor - cargo tries to pick the most recent version of library (that's SemVer compliant), not the earliest one, and MSRV changes aren't at this point considered a breaking SemVer change (as far as I know)
  - returningfory2 6y ago
csomar 6y ago
That's really weird. So far Rust has been the most stable thing I have worked with. Working with Cargo was a pleasant experience knowing that I will compile any program and the compilation will go smoothly (vs. Python where I have multiple times figure out what went wrong).
otabdeveloper4 6y ago
Don't blaspheme against the FOTM gods. Today is the year of the Rust. Wait until next year when $language is the next shining beacon of not-having-to-deal-with-legacy and Rust itself goes to the dustheap where Cobol and Fortran and Python 3.6 now live.
- dave_sid 6y ago
  Rust was doomed to fail from the start.
  - yjftsjthsd-h 6y ago
    Why?
reificator 6y ago
I don't understand your concern. You're upset that new features are not backported to older compiler versions? If you have some reason to not update your compiler, then don't use those new features, and use dependency versions that also don't use those features. Go back a few releases if you need to. If you do need those features though... Then just upgrade your compiler? I'm not aware of any compilers/interpreters that work the way you want here. Maybe Python 2 for that painful decade of overlap...
mamcx 6y ago
I have done more than dozen of languages and consider Rust the best experience for both "get new shinny things" and "keep old quiet". But the Rust experience IS cargo. No (other) package managers. Rust is cargo centric. With it, you are free to pin to versions and keep things working for very long. BUT also if you are coming cold to any library is to be EXPECTED to be "new". This is a good thing: The community at large move forward in tandem as if it were a coordinated army! But that don't mean I can't work with older code, is that if you see a crate RIGTH NOW you see te forward momentum at large. If you wanna use something older you can pin to a back version. However, this also point to a fair problem: Is not easy to correlate to which version of Rust each crate(version) relate to.
- deleted 6y ago
  [deleted]
carlosdp 6y ago
That's just blatantly false. Rust takes extreme pains to be backwards compatible. When they wanted to make breaking changes to support some new language features, they literally spun up a separate compiler front-end behind a cargo.toml flag to make sure they didn't break any existing code. Compiler changes are tested against a bunch of libraries in the crates.io repository to ensure nothing breaks. It's just exceedingly rare that a new Rust version would break older code.
- ithkuil 6y ago
  I think GP meant forward compatibility. New code will use new features and won't compile on old compilers (like other languages)
  - Ar-Curunir 6y ago
    If you updated old compiler with new features, aren't they new compilers?
    - ithkuil 6y ago
      the most charitable reading of GP is not that nobody can ever implement new features in a language but that the 5 month release cycle is causing new features to come in too fast.
serial_dev 6y ago
Backward compatibility doesn't mean that you write code with the latest features, then go back to a version that's a year old than expect it to work. No language or software does that. The promise is that if you have code you didn't touch for a year, you can update Rust, and it will still compile. You got it backwards.

atom_arranger 6y ago

Not mentioned here but FB is rewriting the Relay compiler in Rust as well. Will be interesting to see how well it works. https://github.com/facebook/relay/issues/3180 https://github.com/facebook/relay/issues/3180 Personally I've had trouble with the Relay compilers watch mode not picking up file changes but that might be a Watchman issue not a Relay compiler issue.

atom_arranger 6y ago
Should have mentioned that I only mentioned watch mode issues because that’s the only issue I’ve had with the JS compiler. It’s been fast enough, although the app I’m working on is relatively small.

throwastrike 6y ago

Did they release any Rust-related libraries for their crypto project?

TechBro8615 6y ago

> As one significant example of that growth, Rust is the leading language in the development of the Diem (formerly Libra) blockchain, which is overseen by the independent Diem Association. Facebook, through its digital wallet Novi, is a member of the Diem Association. I'm always amused by the contortionist double-speak of Facebook communications. They put so much effort into distancing themselves from Libra when they launched it, but now they have a chance to take some credit for the work behind it, all of a sudden it's a kinda-sorta Facebook project. Totally off-topic but I can never resist a jab at Facebook. Anyway – great news for Rust. Despite my distaste of FB, I can't deny the value of their open source contributions.

xrikcus 6y ago
It's not really a contradiction to take credit for the effort behind something, but also make an effort to allow that thing to be independent once started, is it?

ChrisArchitect 6y ago

related from today: Facebook Joins Rust Foundation https://news.ycombinator.com/item?id=26982890 https://news.ycombinator.com/item?id=26982890

dragosmocrii 6y ago

I'm curious what people think about Rust as a long-term investment from an employment/job perspective. Is it going to pay the bills for the next 10 years? I've been using PHP for the past 10 years, and I've never run out of work. I can't say the same about Elixir, which I very much like, but the job market proved to be scarce. Just wondering what Rust's future looks like. Thanks for your opinions A note(since I notice my comment is getting downvoted): I've actually been spending time regularly for the past few weeks reading multiple tutorials, and getting familiar with Rust's concepts, and I really like the language and I can see that a lot of work has been put into developing it. But my concern is that there are other languages as well that have a solid background (OCaml, Haskell, to name a few), but that are still niche languages and suffer from the same scarce job market opportunities. Which proves that adoption does not always depend on how good a language is.

est31 6y ago
From a long term perspective I'm not worried but short to mid term it might cause some issues because currently there aren't that many Rust jobs yet. It's kind of a niche still, jobs wise.
- dragosmocrii 6y ago
  Thank you, this is reassuring!
habitue 6y ago
Rust has been picked up at Amazon, Google, Facebook and Microsoft. I think that gravitational pull is going to keep Rust a going concern for a long time. That being said, it's an investment in the future mostly. There aren't anywhere near as many Rust jobs as PHP, Java, or Python jobs.
- joatmon-snoo 6y ago
  Rust at Google is in a bit of an awkward state. There's a bunch of teams/projects that have used it, but we haven't yet staffed a team to manage an internal Rust toolchain/ecosystem. The most recent one was Kotlin, in large part because our Android ecosystem was increasingly having to play catch up, so we'll see if/when a Rust team gets staffed.

Graffur 6y ago

Without getting a job in Rust (due to lack of experience) what is the best way to get experience with it?

the_gipsy 6y ago
I did some experiments with bevy.
da39a3ee 6y ago
Write little command line tools for yourself in it (it’s the same answer for most languages).
- bigiain 6y ago
  The embedded RustConf talk said a big thing internally at FB was rewriting stuff like existing/well-used Python scripts into Rust...
ahelwer 6y ago
Find an open source project you care about that uses it then try to fix some simple issues. That's how I learned!
azdle 6y ago
Write something that sounds fun. It doesn't even have to be useful to anyone, just interesting. And you have to be able to talk about it. The last person we hired for our team, I actively courted because he'd written a javascript parser (note: just a parser, it parsed basic JS to an AST and did nothing with it) and talked about it at a local rust meetup I'd been hosting (until COVID). If you don't have local (or maybe now vitual?) meetups to go to, write a blog post about it and post it to HN and put a single sentence "I'm looking for a job that lets me write Rust professionally" note at the bottom, you never know who's going to see it.
oconnor663 6y ago
The official book is good, and I recommend even experienced programmers read it. Ownership, borrowing, and lifetimes are really central to the language, and really handled differently from other familiar languages. The jump from "implicit and occasionally violated" notions of ownership to an "explicit and 100% enforced" notion is a big one.

frob 6y ago

I personally know this timeline to be incorrect by at least a year. I was part of a startup that got acquired by FB in early 2015. We moved our codebase into the FB monorepo pretty quickly. One of our microservices was written in Rust. It was only a few hundred lines, but it was in the repo and actively deployed on FB infra by April or so of 2015.

oconnor663 6y ago
Does that mean it was pre-1.0 Rust!?
- alfiedotwtf 6y ago
  Must be, since the 1.0 release was a month later.
- frob 6y ago
  Yup!
jsgf 6y ago
Wit?

deleted 6y ago

[deleted]

higerordermap 6y ago

Are there enough rust jobs that don't involve shady stuff like crypto currency?