Rust 2020: Growth

My hypothesis is: Rust is already good enough, and ready to grow beyond status of a new/experimental language.

If you only look at Rust through its issue tracker, there are obviously sooo many things that are still missing, need to be fixed or improved. There are a few major features I'd still like to see added.
But if you look back at what has been shipped: it's a pretty good language! It already has way more features than C. It many areas it's already much more polished and mature than other languages.

So if Rust-the-language is ready to be used, let's have a closer look what is stopping people from actually using it, and fix the blockers.

I don't know exactly what is putting brakes on Rust's growth. Part of the work would be figuring this out and verifying assumptions (which Rust team has been doing already to some degree).

  • Is it documentation? For example, Rust has messed up SEO. Google is confused by older versions of std docs, early book versions, and stub-redirect pages left behind some book versions. This may create an offputting experience for new users if half of documentation they Google is incomplete or doesn't work. This is going to get worse with async/await now that all existing futures v0.1 docs/tutorials/crates were obsoleted.

  • Is it distribution and packaging? e.g. in my case curl | sh is a blocker, since it works very poorly with tools that automte server deployments. Regardless of whether it's actually secure in Rust's case, the curl | sh pattern has an awful reputation of being an amateurish hack, so it's hard to recommend in "enterprise" environments.

  • Is it lack of MSRV support in Cargo? If someone installs Rust through a Linux distro, they're likely to run into a ton of compilation errors they don't understand, because most of crates-io crates don't support Rust 1.25 any more. This may enforce users' belief that 3rd party crates are fragile, and since Rust relies on them so much, Rust as a whole may look fragile.

  • There may be lots of other reasons, which may even be non-technical, e.g. chicken-egg problem of lack of Rust jobs, because few companies are hiring, because there are few professional developers to hire. Maybe this could be helped with training programs, or focusing on use of Rust alongside other languages, etc.

People who use Rust already tend to really like it, and Rust itself attracts a lot of attention/hype, so I suspect it has a lot of potential to grow its userbase.

42 Likes

I certainly hope so. I bet the company on it!

A year ago a couple of us formed a company and we are building everything from scratch in Rust. From the sensor handling in remote embedded devices to server side processes to
web server. I have yet to bite the bullet and switch to Rust in the browser mind.

Despite the fact that I only started looking at Rust about 5 months ago and it's a case of learning by doing.

So far we have exactly one client and one project, so it had better work out!

With the availability of many useful crates it has been pretty easy to get going with CockroachDB, NATS.io, the Rocket web server and others.

I keep wondering when the day will come when we hit a wall and I realize I've made a big mistake. So far the out look has become more reassuring every day though.

What makes you think there are breaks on Rust's growth? I get hints it is being adopted all over the place.

5 Likes

I've listed things that were "brakes" for me. For example, I could not use Rust at Cloudflare until our team created custom Rust packages, because curl | sh was "LOL, no", and we use Debian stable, which has a useless Rust version. It wasn't a big deal for Cloudflare, but for some companies that I've worked for before with less flexible sysadmins it would have been the end of the story.

When I was still learning Rust and I needed to look stuff up regularly, I was really annoyed about Google searches being polluted by deprecated book versions. For some people that's not an issue, because they may prefer a paper book, but for my style of learning this was a total disaster (and it still is).

I suspect that even small hurdles in the beginning may be a big problem. If someone wants to try Rust, but they run into many small annoying problems, they may decide to try something else instead, because they're not invested in the language, and they don't have skills yet to diagnose and fix even small problems. At some point in the beginning I was really close to giving up on Rust.

Rust does an excellent job with error messages helping beginners. But IMHO the aforementioned stuff around Rust has gaps.

14 Likes

In my opinion the main language blocker is const generics and to a lesser extent making CTFE more powerful. I think it's the only unimplemented feature which will significantly change how we write some crates. Optional/named arguments probably will have a certain impact as well, but for me it's more of a quality of life feature than necessity. And I think GAT is a somewhat niche feature, which will have a limited surface impact.

Other than that, I think the main blocker for wider Rust adoption is the ecosystem. Minor language changes will not have a significant impact here. Of course we are doing great considering that only 5 years have passed since 1.0, but we are still miles behind other languages. For example, robotics and computer vision areas are still very under-developed and you have to use C++ for high-performance industrial applications. And for web services we are still very far away from Go. And you know the current GUI status...

One way to "solve" this problem is to simply wait, as years go situation will improve steadily. But we may think about ways to accelerate this process. It would be nice if we had good ways to support development of foundational crates and incentives for companies to invest in such work, but personally I don't have any good practical ideas right now.

5 Likes

Yeah, which is why I'm starting with an assumption that Rust is good enough already, and it's not blocked by missing yet-another language-level feature. Even though personally I can't wait for const generics, I don't think it's the thing that's stopping Rust from "hokey-stick" growth.

  • C doesn't have CTFE, GATs or even usable generics. It doesn't even have a hashmap in stdlib. And it's still doing well. New C projects are being created. It's not just legacy.

  • Some people are already scared of trying Rust, thinking it has too many features, and keeps adding too much too fast, and it's heading towards being the next C++ (in a negative way).

16 Likes

The secret to C's success as a programming language, was the success of Unix as a platform. I am not sure what future "killer platform" could similarly propel Rust to the status of unavoidable system API standard which people must use whether they like it or not. Maybe Fuschia?

6 Likes

I do get you point there but a couple of thoughts:

  1. Debian stable is our platform of choice but for new things that are under rapid development using the current Debian package has never made sense. Was, probably still is, true for Node.js, Go, Clang and a bunch of others.

  2. Despite that node.js took off like a rocket. I conclude this issue of having to fetch and install anything recent on Debian is not a problem.

  3. I have also found myself reading docs for old versions of Rust and crates. I hope there is a way to deoptimize search to bury them a bit deeper in search engines.

Having been living and working in programming for decades it constantly amazes me that everyday things turn up that I have never heard of, which are apparently important to get anything done. How did we ever manage without it?!

In this case I had to google "CTFE".

Well really, you want some data computed and inserted into your program. How is that not done with, you know, a program that does that and sticks the result in your source which you then compile?

Hardly a show stopper. C++ has done with out constexpr for a log time. In fact I would argue that if CTFE adds complication to the language and/or compiler we should reject it.

I still have no idea what "GAT" is.

5 Likes

That may have been so in the early days when Unix was spreading around. Pre 1980.

It has not been true since then. C got adopted for use in MS-DOS and Windows. It got adopted for a billion embedded systems, with an OS or without.

C got everywhere. And mostly there was no Unix there.

I and millions of others, used C for almost 20 years before I got to use a Unix like system, in the form of Linux.

I look at it like this: C is a systems programming language created to implement Unix in a portable way. That made it a very good choice to implement a billion other systems. Even if Unix is nowhere to be seen,

2 Likes

I don't believe that is case. Both C/C++ have multiple industries supporting the language which is difficult to compete. You have open source communities like Linux and closed source like Microsoft and Oracle. You have multiple compilers.

For Rust or any other newer language it will be difficult to get that level of support after Java vs Microsoft case. If Microsoft jumps in, probably, they will create their own language rather than using Rust.

Rust can still flourish, because I doubt companies like Apple or Microsoft (e.g. Swift and VC++) can properly support other platforms. But Rust can fill this gap by making it easy to write once and compile on all other popular platforms. This makes development more efficient and cost effective. The only exception is by Google with Golang which is easy to compile for most of the popular platforms but it is more comparable to Java and C# than C/C++Rust.

That is not so clear to me.

MS joined the Javascript standards body and was part of it's evolution. Still are as far as I can tell

MS joined the C++ standards body and is still a major force in it's evolution.

That Java case was very different what with having no community and no standard. Only a demand from Sun to conform.

I suspect modern day MS is even less likely to want to create a different language. They want to attract developers to their cloud offerings. What better way than supporting a most loved language?!

On the other hand I do worry when the big ships move in. The influence of the likes of Intel and MS could very well bury Rust in complexity as they twist arms to get this and that feature they like.

Rust has to remember the down fall of CORBA and the ongoing train wreck that is C++. Brought on by feature creep.

1 Like

The status quo is already good enough. Rust has to be better or find a unfilled hole.

Simplicity has to be a strong focus.

I think university education is a big influence in driving more to some languages.

Some older documentation is good to keep.

5 Likes

The only reason C++ is a train wreck is because syntax is ugly compared to modern languages and Bjarne Stroustrup can't fully support strict safety ergonomics because there has to be support for legacy C++ code.

In Rust borrow checker is part of the language but in C++ memory management support are classes in standard library.

If C++ adds easy to use and proper support for memory safety then it may not move current users who wants a language that enforces better safety to other languages.

The "status quo" if that is a good way to describe the current situation, is amazingly brilliant. From the language itself, to the cargo and crates eco system to the documentation. My hat is off to all involved.

The unfilled hole is huge. A vast ocean of software based on undefined behavior that is totally unpredictable.

Yes, please keep it simple.

What they teach in our schools has a big effect for sure. However Javascript and node,js have done very well and I don't recall any university using it in that CS courses!

Arguably Python was a hit before universities started to use it. As was Java before.

1 Like

Indeed.

The syntax ugliness is large dictated by a dogged insistence of building on and remaining compatible with C. The impossibility of memory safety for the same reasons.

Train wreck, ship wreck, C++, all the same. The course and speed are set, with the best of intentions, a long time ago, there is nothing that can be done but watch the outcome in horror.

1 Like

This is great and I really hope we as a community focus on this for 2020. More adoption would also mean more momentum in terms of contributions / libraries and would, in my opinion, drive the resolution of other aspect of Rust adoption even faster.

I think one aspect that is a blocker for a lot of people is lack of higher level crates for certain thing. For example, in Node if you want to authenticate users, the Passport module is pretty much the de facto standard. As far as I'm aware, we don't have anything like that in Rust. There are, of course, good lower level crates for working with OAuth2 but I don't think they are equivalent to Passport. Passport itself has a learning curve for people.

We have great web frameworks like Rocket, but in order for a lot of people to adopt Rust faster, I think we need other aspects of web tools that are easy and high level, just like Rocket. A Passport-like framework for authentication, as well as other high level frameworks for any other normal uses for web.

I also think more web-related stuff will drive adoption, for a couple reasons: web is everywhere, and web is broken. Look at the web related issues Rocket solves compared to Express. Those are real world problems that devs don't have to worry about anymore. That is a big selling point.

If we can create libraries and frameworks that are web related but solve a lot of high level issues like that, we will have a large number of potential users who can see real world problems they don't want to deal with solved for them. That's huge.

4 Likes

Another aspect of mainstream adoption I think Rust is severely lacking in is YouTube videos. There are a couple Rust tutorial videos that go over some basic stuff, but anything more advanced and you are stuck with just reading documentation or hoping there is a good blog post out there.

Most other languages have some YouTube channel with a sexy intro and a dev who makes learning it fun. Rust has a ton of extremely low level videos that only very advanced devs understand.

Tons of programmers learn from YouTube videos, to the point it has become a meme.

I would like to see a channel that makes it interesting and high level, and has a playlist for everything from "what is a Cell" to "let's learn Rocket" to "let's learn gRPC with Tonic".

People need videos to watch devs actually using these things. Both from a std API perspective as well as a library/framework perspective to see how these things work, what they actually are used for, how they fit in with Rust tooling, etc.

6 Likes

There is also competition developing from other languages.

Kotlin native is underdevelopment, but I think that is GC based.

.Net Next will have AOT compiler which will compile .Net core languages to native binaries, but I believe that is also based on GC memory model.

And there is Dlang, they want to move to RC/ARC memory management model but keeping GC if somebody wants to use it. Their standard library has GC based code so they need a lot of work before they can switch to RC/ARC model.

Node.js has packages for lots of systems/distros in addition to a bunch of installers. I can use latest Node on Debian stable just by adding an apt source. This is all much easier to find and much more comprehensive than what Rust officially offers.

2 Likes

True enough. The situation for node installation seems to have greatly improved since I started to use node. Node became massively popular before that.

Oddly enough that nodesource installation page comes down to a "curl" command https://github.com/nodesource/distributions/blob/master/README.md#installation-instructions which you said was a show stopper above.