Fair point. So the deployment automation for rustc is really just provisioning a well controlled, reproducible internal build host, which can be kept in sync for OS/distro updates on the "fleet of servers". Once you have binaries built you can distribute them as you suggest.
Yes, there is also a game called Rust. I usually search for
rust lang <problem>.
If you have a fleet of build/CI servers. Our company has about 50.
I automate configuration of servers even when I manage a single instance. That's because sooner or later I'll have to move it to new hardware or OS version, and manual migration of a "snowflake" server is time consuming and risks forgetting something.
This problem also seems to extend to docs.rs - whenever I search Google for a type from a library, the top result is almost always from an old version. For example, searching for
sdl2::video::Window gives me the docs for
sdl2 v0.30.0, which is over two years old at this point.
That said, the recent change to make the 'Go to Latest Version' button keep you on the same page rather than redirecting you to the root of the crate has made this less of an annoyance. Whoever made that PR is my actual hero
Whoever made that PR is my actual hero
That was me! The redirect was annoying me too, I use Cranelift for my compiler and somehow Firefox decided that cranelift-codegen v0.36.0 is really the version it wants to keep in suggestions (Cranelift is on 0.51.0 right now).
There's actually a crazy story behind the PR - The main way to contribute to docs.rs for a long time was with Vagrant, which spun up a whole VM that you provisioned over SSH. I tried using it and it ... didn't work. Long story short, I actually ended up writing a whole new Docker deploy system just so I could build the site locally . Actually merging the PR came about a month later.
I've been meaning to write a blog post about this, I might get around to that today.
Unprecedented (but greatly appreciated) levels of yak shaving Thank you for all the hard work!
It may be helpful to consider some concrete use cases. It's probably worth focusing on companies, since ultimately to be widely adopted people need to be paid to use it. What are the things that encourage or hinder using rust for:
- A newly-formed startup?
- A small company of 50-200 people looking to build/rebuild/refactor a component?
- A large-ish company of 1000+ looking to build/replace a system?
My initial thoughts:
Newly formed startups don't have legacy code, so they can make a new language choice easily. One obstacle is that most new startups are web or mobile first. Stability is not as important as quick iteration. Another obstacle is that most new hires aren't going to know rust, and rust has a higher learning curve than, say, Python. This is a problem given the need to hire and ramp-up people quickly. The best two sells I see here are:
a. "Work for us because we use rust and we love rust."
b. Once a given component/microservice is more stable, and reliability is more valued, rebuild it in Rust instead of Node/Python/Ruby.
I've seen several small-to-mid-sized companies want to replace a legacy (eg PHP) stack with something "newer", like Python or Node. To make a business case for this, you have to argue that rebuilding will improve some company-critical metric, like reliability. Maintenance-burden or security arguments primarily seem to work in engineer-led companies; product/sales-driven companies are very hard to convince to pay down even low-hanging-yet-egregious tech debt.
Large companies may have the runway to invest in a few engineers building a POC Rust system, but from large companies I often hear variants of "we already have lots of in-house C++ experience: we'll build a system faster and more reliably with C++ than Rust." Closely related is "C++ isn't perfect, but it's good enough, and we won't make many memory errors anyway." Regardless of the truth of these statements, they are the first barrier. The impression of fanboys who want to rebuild everything in Rust because it's Rust increases the resistance.
One area (in case 3) that I was almost successful was in converting performance-critical components from Python to Rust. I wanted to make a solid and performant piece in Rust that could be called easily in Python. However, I could not find any canonical way to make those bindings, just several unmaintained and poorly documented crates, so I gave up and used C/Cython instead.
You're welcome! I love open source because I get to help others and myself at the same time
As promised, here's the blog post: https://jyn514.github.io/2019/11/26/building-docs.rs.html
39 posts were split to a new topic: Suggestion for making Rust's trait system as powerful as OOP
crates-io crates don't support Rust 1.25 anymore.
I just checked the Repology page for Rust versions, and it seems nobody ships so archaic version anymore. Even the Debian-based distributions more or less updated (concerning Rust only, while failing other languages, e.g. OCaml). So I don't think this argument holds today.
Distros move slower than Rust, and users of distros upgrade them slowly, too. VPS providers that I use still offer Debian 9 and Ubuntu 18.4 as the latest. That's with Rust 1.24.1, unless you hunt for backports.
Debian 10 is only a few months old at this time, so it's not too terrible yet, but consider that: it has 1.36 without
await, and Debian 11 is going to be released in mid 2021. So
await code that's being released now will be usable in Debian in about 2 years from now.
Yes, Debian and all distributions based on it is a huge problem for any software developer. To be honest, I don't know why would anyone use these at all. I know the pain through the range of different programming languages and tools I care about. The
rustup is the only way for Debian and Co. I think the best strategy in this case is to force these distributions to remove the rust packages if they can't keep up. I remember some software project added this in its license.
To be fair to Debian team, maintaining package repositories to ensure a stable OS that can run in multitude of environments and support extremely large set of use-cases is non-trivial effort. Not that their coffers are overloaded with cash either.
A solution here could be for Rust to publish, at the very least, an official PPA and Yum repository which could cover a significant portion of server deployments. Postgres, for example, offers one which allows very convenient way to install a custom version of Postgres (and it's plugins like Postgis) in either local or server environments.
But, then again, neither are Rust's coffers overflowing with money!
Since Rust project uses GitHub Actions now, maybe it is possible to create Debian/Ubuntu packaging action, it will also help any other project to reuse the same action.
I have been a die hard Debian user for nearly two decades now, in all kind of scenarios.
Why? Because it has proven to be a stable and robust platform. That is "stable" and "robust" in terms of always working the same and surviving upgrades over time without issue. But at the same time being prompt with security fixes.
That of course dictates that Debian does not, cannot be, constantly churning out new releases of newer software that is under rapid development. Examples are node.js, Rust, Cockroachdb, NATS. There are many others now a days.
Luckily it is often trivially easy to install those items from their tarballs or whatever and use systems like npm and Cargo. The Debian packages of the same, if there are any, go unused.
I recently started to wish Debian would not have it's own packages for such things. It causes a lot of confusion. It should just supply those packages required to support the OS itself. It's especially crazy with things like node.js where there are hundreds of node packages in Debian that should all be coming from NPM instead. Apparently this happens so as to support Node-Red.
I think another significant factor is a lack of (or immaturity thereof) a significant ecosystem for various use-cases.
For example, my company makes a device that uses the TI MSP432E4 microprocessor. The firmware is written in C and makes extensive use of existing C libraries for preemptive multithreading and an IP stack. While there is a peripherals crate for the MSP432E4, there's no HAL crate and there's no production-quality threading and IP stack crates. We cannot justify the time and expense of writing those crates, so Rust is out of the question even though it would otherwise be a perfect fit.
Rust already has image of respected language, IMHO the only reason which stops adoption is lack of people on market which is a risk for companies. It will change with the time, since it has rather open ecosystem and state of documentation in Rust is great compared to other languages, maybe more learning materials and socializing would help to accelerate adoption.
For most people rust is not the first language, and that probably explains why it inherited so many great ideas from other languages - not just inherited but thoughtfully redesigned e.g. docs, tests, workspaces, types, pattern matching, multi-thread-capable futures, async/await etc. On the other side it is quite surprising for such a strong foundational language stay flexible that it adopts to challenges fast, including syntax changes when needed (hello JS and Python), and sometimes base concepts (rip green threads), hopefully it does not change when it enters mainstream.
I also like to admit one more very powerful distinction of other languages - powerful macros, static documentation generator and hosting, build system for public crates, embedded package management provide crate producers with tools to design ergonomic APIs - in the end language will be adopted if it has easy to use libraries, hence providing crate producers with more powerful features (like GATs, const generics) will pay back with wider adoption for sure.
Rust will grow, it is the only language that can compete with C++, but it takes time for programming language to reach wide usage.
The only other language competing with C++ is Dlang but due to extensive use of GC in std libraries it will take time for them to catch up.
Only in standard library with the idea to allow for libraries requiring their own memory management.
The other question is to which extent Dlang's standard library can be rewritten without breaking backward compatibility.
Further, ARS/RC is not that interesting for Dlang as they already have that in their GC coupled with cycle detection, they are more interested in unique ptr/ownership mgmt.
Dlang itself would never be really shipped without a GC, they do like too much, including me.
Rust is a different story.