[HN Gopher] A brief history of Rust at Facebook
___________________________________________________________________
A brief history of Rust at Facebook
Author : tomduncalf
Score : 131 points
Date : 2021-04-29 16:01 UTC (6 hours ago)
(HTM) web link (engineering.fb.com)
(TXT) w3m dump (engineering.fb.com)
| ChrisArchitect wrote:
| related from today: Facebook Joins Rust Foundation
|
| https://news.ycombinator.com/item?id=26982890
| dragosmocrii wrote:
| 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.
| fioawjpoifajio wrote:
| I've never thought of myself as a C++ dev (or a PHP dev, or
| Rust dev, or Haskell dev).
|
| I write computer programs. I don't "invest" in a language and
| only take jobs that use that language.
|
| Learning more languages is almost always good. Not because
| you're learning more languages, but because you're learning
| more modes of thinking which will apply to any future language
| you learn.
| est31 wrote:
| I agree but many job postings contain stuff like "3+ years of
| professional experience in language x".
| abzug wrote:
| Yes but with time you gain experience in one or more
| languages and you can choose a job with the ones you like
| (or tolerate more). You don't need to pick or specialize
| one to apply for this kind of postings.
| howinteresting wrote:
| I agree in the abstract, but Rust is a step-function
| improvement to most other mainstream languages. It is hard to
| go back to writing, say, C++ once you have a few years of
| Rust experience.
| est31 wrote:
| 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 wrote:
| Thank you, this is reassuring!
| habitue wrote:
| 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.
| nicoburns wrote:
| As a long term investment, I think it'll be great. I expect
| it'll be another 5-10 years before it's as employable as C++,
| but it'll last at least another 20 beyond that.
| superkuh wrote:
| 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.
| otabdeveloper4 wrote:
| 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 wrote:
| Rust was doomed to fail from the start.
| yjftsjthsd-h wrote:
| Why?
| reificator wrote:
| 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 wrote:
| 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]
| dijit wrote:
| Stop using +nightly.
|
| Stable rust hasn't broken in my experience.
| [deleted]
| superkuh wrote:
| 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.
| howinteresting wrote:
| 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 wrote:
| 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 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/]. 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 wrote:
| Relying to myself to mention another thing:
| 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.
| jacobolus wrote:
| 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.
| [deleted]
| est31 wrote:
| It's a bunch of problems. Firstly, you can't even say,
| reasonably, that you only want >6 month old versions of
| libraries, at least not with cargo. Yes, you can express
| such a wish for your direct dependencies, by using =
| versions in Cargo.toml, but the _transitive_
| dependencies, aka the dependencies of your dependencies
| and so on, those you can 't control. Putting Cargo.lock
| into git solves some of your problems, but this doesn't
| help you when you are adding a library. Then, for any
| novel transitive dependency, Cargo just takes the highest
| version that works.
|
| The second problem is that even if 90% of your
| dependencies support older compilers, it doesn't matter,
| because the 10% that insist on newer compilers will still
| break. It can be a single dependency, and you usually
| have hundreds, with vastly different policies.
|
| There are solutions to this problem, like MSRV aware
| cargo. They just need someone to implement them (as well
| as someone to compute MSRV numbers).
| jacobolus wrote:
| What proportion of programmers/projects are (a) so risk
| averse/untrusting that they are unwilling to update their
| compiler to the latest version, but (b) want to depend on
| the latest version of hundreds of miscellaneous
| libraries?
| est31 wrote:
| Again, that's how the default development workflow with
| rust, which uses cargo, works. Including the cargo that's
| packaged by debian.
| tene wrote:
| I think you'll find that using an old Rust from Debian is
| not the default development workflow for most Rust users:
| https://blog.rust-lang.org/images/2020-12-rust-
| survey-2020/r...
| rhn_mk1 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| tene wrote:
| Non-Lexical Lifetimes were a pretty big quality-of-life
| improvement. The question mark operator was also quite
| nice.
| steveklabnik wrote:
| NLL landed in 1.31, in 2018, and ? landed in 1.13, in
| 2016. two and a half and five years ago :)
| superkuh wrote:
| Correct. It's the extremely rapid pace of development in
| the language combined with enthusiast devs using the
| latest and greatest that make it unsuitable for general
| use. Part of this stems from Rust almost _requiring_
| installing with rust-up instead of from repos. This
| encourages the bad behavior.
|
| Eventually the Rust dev community will grow enough to
| have non-language-specific-enthusiasts devs as a majority
| and it will slow down and begin to target actually stable
| releases. But as of now you have about 5 months
| functionality per "stable" release.
| xxpor wrote:
| Every modern language works like this. rbenv, pyenv, nvm,
| gvm all exist for a reason. People don't want to wait for
| package managers. I go out of my way to avoid
| dependencies on them, because all they do is break
| things. Hard drive space is cheap, things should be self
| contained.
| darkwater wrote:
| I understand your point and kind of agree but you should
| also keep in mind that Rust is a relatively young
| language. I would treat these as growing pains.
| nindalf wrote:
| Just to summarise your position
|
| - you will only use an old compiler because that's your
| preferred source of installing tools
|
| - you will only use the latest and greatest packages that
| require the newer compilers.
|
| And this is somehow the languages fault. The language
| needs to fix the problem of library authors using
| language features? Seems to me like it'd be easier for
| you to relax one of your two requirements. They're
| fundamentally incompatible.
| est31 wrote:
| In the C++ world there is no such problem. You can
| usually compile most projects using compilers found in
| stable distros. Maybe not all projects with LTS distros,
| but at least the ones which are released once or twice
| per year. In debian, the rust compiler is updated more
| often than other programs and it's still not enough.
| josephg wrote:
| I see rust as following the evergreen model - along with
| nodejs, chrome, Firefox and others. In this software
| model the authors make strong stability and backwards
| compatibility guarantees.
|
| For example, as I understand it the rust compiler team
| literally compiles every public crate with each version
| of the rust compiler to make sure they haven't broken
| anything. The platform generally expects users to mostly
| keep up to date - as a web developer I can now use new
| features in chrome and FF within a month or so of the
| feature being released. Gone are the days of leaving
| behind large swathes of users because they're still using
| FF 4.0 or IE 6. Nodejs has its own support table. I don't
| care what version of nodejs Debian LTS has; when version
| 8 of nodejs stopped being officially supported and
| maintained, I immediately dropped support for it in my
| npm packages.
|
| The "minimum supported rust version" flag in cargo will
| help with this going forward. But more generally I think
| this model of software development makes sense and we'll
| see it more and more going forward. There was a kernel
| bug a few months ago caused by a bug in an old version of
| gcc. The gcc bug was fixed years ago but the patch was
| never backported to ancient gcc versions. Some distros
| were compiling Linux using ancient gcc versions, and then
| got upset when they ran into problems. The answer here is
| for gcc to say the same thing nodejs does - "these
| versions are supported and get bug fixes. These versions
| do not. Use old versions at your peril - they have known
| bugs." Explicit support periods is better than vague,
| ambiguous expectations that software will work forever.
| Microsoft has the same policy with windows patches.
|
| I think the era where it makes sense for apt to carry
| that burden by serving us ancient software packages is
| slowly coming to an end. As software packages take
| responsibility for evergreen stability, it also makes
| sense for users to get evergreen software. It would be
| nice if we could do that without needing app specific
| version managers like rustup and nvm.
| est31 wrote:
| rustc is _already_ exempt from Debian 's policies to not
| update most software after a stable release. It's still
| not enough because Debian lags behind 2-3 releases. It
| has a high standard for supporting various niche targets
| and there are regressions every now and then, and often
| there is simply no volunteer time to package all the
| libraries.
| rapsey wrote:
| Strange how a language according to you is unsuitable for
| general use. Yet it is used by Google, Facebook, Apple,
| Amazon, Dropbox, Microsoft, Mozilla, Huawei, etc.
|
| You live by some principles. Most people don't care about
| the principles you seem to care very much about. Most
| just have problems that need solving and Rust is the best
| tool for solving them. If the tool works differently to
| how they are used to working, they adapt and get on with
| their lives.
| DougBTX wrote:
| Debian has a policy for a packaging Rust crates:
|
| https://wiki.debian.org/Teams/RustPackaging/Policy
|
| If you restrict yourself to packages in the repo, won't
| that resolve the issue? The idea of a distro is that all
| the packages in the distribution should play nicely
| together, but if you go outside that then version
| compatibility won't be handled for you.
| pornel wrote:
| Debian's repackaging is not useful for Rust developers.
| It's a tiny tiny fraction of Rust packages (Rust has over
| 60,000 now), and it's not integrated with Rust tooling.
| It's not useful for anything other than the few binaries
| written in Rust that Debian ships.
|
| Debian's policies are simply incompatible with the
| Chrome-like "evergreen" release model that Rust uses. I
| feel sorry for anyone who tries to use Debian's Rust. It
| _is_ an awful experience.
| hctaw wrote:
| 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 wrote:
| > 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.
| [deleted]
| hctaw wrote:
| 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.
| akiselev wrote:
| 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 wrote:
| > 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.
| the_mitsuhiko wrote:
| 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
| [deleted]
| jen20 wrote:
| 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.
| csomar wrote:
| 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 wrote:
| Typescript and node?
| da_big_ghey wrote:
| 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.
| serial_dev wrote:
| 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.
| carlosdp wrote:
| 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 wrote:
| I think GP meant forward compatibility. New code will use new
| features and won't compile on old compilers (like other
| languages)
| Ar-Curunir wrote:
| If you updated old compiler with new features, aren't they
| new compilers?
| ithkuil wrote:
| 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.
| pizza234 wrote:
| 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 wrote:
| 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 wrote:
| 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)
| ISV_Damocles wrote:
| I am still pretty new to Rust (about a year of usage), but
| I think there are ways to have this "forward compatibility"
| problem be a less significant impact in real world usage,
| though.
|
| Node.js went through similar rapid development of the
| runtime as Rust is with the compiler. Node's package.json
| includes an "engine" field to indicate which runtimes are
| supported from which version, so NPM could immediately tell
| you if you were trying to use a library for a newer Node
| version than you have installed, and could automatically
| downgrade to an older version that still supported your
| Node version, if one existed.
|
| That eliminates much of the pain of using libraries by
| others that are sticking to the latest release of the
| language.
|
| But it also encouraged library authors to try to push that
| supported version number _down_ as far as they could,
| because that would juice adoption of their library in the
| wild, further making forward compatibility less of an
| issue. (This isn 't exactly apples to apples since most of
| the advances in Javascript the past decade have been
| syntactic sugar, not new powerful features, and there is a
| hard split on async/await versus callbacks as that was more
| of a feature than just sugar.)
|
| In Rust, if libraries could broadcast their minimum Rust
| version in their crates, and treated changing that as a
| breaking change (major version bump), and were open to
| backporting features onto prior majors (for the bigger,
| important libraries), there can be a rolling drop-off of
| older versions of Rust instead of hard, unpredictable
| dropoffs.
| steveklabnik wrote:
| I appreciate this post. I have one or two points to make
| about what you've said here (none of which is wrong)
|
| > because that would juice adoption of their library in
| the wild
|
| That requires a lot of people to be using older versions,
| that is, it assumes there's an audience of people who are
| interested in using older Rusts. But we don't have that
| in Rust, even if it was that way with Node. Look at this
| chart from our survey last year: https://blog.rust-
| lang.org/images/2020-12-rust-survey-2020/r...
|
| There isn't a huge audience to get adoption from if you
| support a wider array of versions; the vast majority of
| users seem to be using the latest stable.
|
| > and treated changing that as a breaking change (major
| version bump),
|
| This is controversial, because in some sense you're not
| wrong, but this also creates a _lot_ of churn, and churn
| that doesn 't really have to happen. In a model where
| most folks target the latest stable, you're creating tons
| of work for most of your users, at the expense of making
| things slightly better for a very small number of users.
| ISV_Damocles wrote:
| > That requires a lot of people to be using older
| versions, that is, it assumes there's an audience of
| people who are interested in using older Rusts. But we
| don't have that in Rust, even if it was that way with
| Node. Look at this chart from our survey last year:
| https://blog.rust-lang.org/images/2020-12-rust-
| survey-2020/r...
|
| So I would cite the classic statistics example of adding
| armor to the parts of returning aircraft that weren't
| shot up: https://worldwarwings.com/the-statistics-that-
| kept-countless...
|
| That survey (that I wasn't aware of despite using Rust)
| likely self-selects the most enthusiastic users of Rust.
| There could certainly be a large number of other users,
| or potential users, that would answer things differently.
|
| > This is controversial, because in some sense you're not
| wrong, but this also creates a lot of churn, and churn
| that doesn't really have to happen. In a model where most
| folks target the latest stable, you're creating tons of
| work for most of your users, at the expense of making
| things slightly better for a very small number of users.
|
| I don't agree that it's that much extra work? As a user
| running `cargo update` should be enough and the versions
| increase. If cargo refused to update to a version beyond
| the currently installed `rustc` version, then this should
| be completely safe on their end.
|
| Then the library authors can either do what they
| currently do and not backport features/patches for
| earlier Rust implementations, or they can if they want to
| support those users (so no extra work is _required_ ),
| but now it's very clear to them (based on download stats
| on crates.io) how much demand for prior rust compilers
| there is, and they can decide if they want to provide a
| stronger backwards compatibility for their library, and
| the users can tell based on the semver releases for the
| library if that library supports older versions of
| `rustc` or no.
|
| This is still personally one of my more minor complaints
| about the Rust ecosystem. It's still far better done than
| most other major languages, and the current state of
| Cargo/crates.io was a major factor in our picking Rust
| over C++ for the project we're using it for. So this is a
| critique because I do actually care about this and see
| how it could help both adoption (less worry about "what's
| the right version of Rust to use?" for newbies) and long-
| term maintenance (if you can't come to a project a few
| months later and install any security fixes because there
| are library changes that require you to upgrade your
| compiler and there's a cascading set of dependencies-of-
| dependencies that make that riskier to do, so
| application-level developers may not want to jump on such
| a "treadmill").
| steveklabnik wrote:
| I am not saying that there is no possible sample bias
| from the survey, but it is the best data that we have.
| I'm not aware of it being an issue for our users in
| general. Some folks do say things about this from time to
| time, but it seems like largely hobbyists and open source
| folks with strong opinions, rather than large corporate
| users or even most open source users.
|
| > As a user running `cargo update` should be enough and
| the versions increase.
|
| They would not increase, because that would be a major
| version change. To do that, you'd have to go into your
| Cargo.toml and change the version number there. This
| would also be true of all of your dependencies. Major
| versions, while Rust can have two of many of them in tree
| (but notably, not ones that wrap C libraries, for
| example...) can still work, but like, then you have two
| copies until the long tail of your dependencies updates,
| and maybe by the time that happens, it's bumped again in
| your code.
|
| > So this is a critique because I do actually care about
| this
|
| I totally believe this! It's also possible that I am not
| right, just my take on what you're saying, that's all :)
| swsieber wrote:
| There's an RFC to add the minimum rust version supported.
| It was merged! The tracking issue is here:
| https://github.com/rust-lang/rust/issues/65262
| returningfory2 wrote:
| Yes! As a non-Rust example, the Go 1.15 compiler can't
| compile some Go 1.16 projects because they use the new
| embed library.
|
| The idea in the root comment that it's somehow outrageous
| that a compiler for version N of a language can't compile
| versions N+M is ... strange.
|
| PS I love your book :)
| faitswulff wrote:
| I know only the slightest fundamentals of compilers in
| general and Rust's compiler in particular, but would it be
| technically possible to ship library dependencies as
| compiled MIR code to older compilers to maintain forward
| compatibility?
| steveklabnik wrote:
| MIR is not stable, so no. In some world where it was, and
| stability meant "unchanging" not "adds new features",
| then yes, in theory, it might be possible. Note that this
| even doesn't actually solve the parent's problem; they
| want to use the old compiler to compile the new code, not
| compile the new code with a new compiler and use that
| binary as a dependency for their code that's built with
| the old compiler.
| faitswulff wrote:
| Ah, I see. I don't know where I got the idea that they
| were trying to use newer dependencies instead of just
| compiling newer code themselves. Thanks.
| steveklabnik wrote:
| I mean, maybe they are, I guess that if you add "we
| somehow allow for binary packages to be distributed via
| crates.io" that would remove them needing to compile
| those dependencies themselves, right now, you do both of
| those things locally, so I was kind of assuming that was
| still the case.
| csomar wrote:
| 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).
| TechBro8615 wrote:
| > 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 wrote:
| 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?
| throwastrike wrote:
| Did they release any Rust-related libraries for their crypto
| project?
| atom_arranger wrote:
| 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
|
| 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.
___________________________________________________________________
(page generated 2021-04-29 23:01 UTC)