I guess it would make sense to put this question into context.
I came across Rust while looking at TechEmpower benchmarks, a year or so ago - I believe. Back then it was crushing the charts, being far beyond almost anything else. It picked my attention, and I decided to inquire a bit further about what it was and how it worked. How the hell did it get there, with such a leap beyond everything else?
I've begun to study the book and the answer soon became quite apparent. Rust managed to combine the highest level FP concepts with C-level performance, "zero-cost abstractions", all the while enforcing the type safety and making sure that the guy or gal that was writing his or her software wasn't writing anything that could blow up in his/her face without any prior notice.
This wasn't simply "cool". This made sense, on a deeper level. It meant that people could start focusing on doing the hard work beforehand to avoid the debugging nightmares later. This meant that the programs written could have C/C++ - like performance, all the while having the necessary level of abstractions above to hide all the unnecessary (for most folks) complexity underneath. Fast, performant, efficient, safe, productive, reliable - with, arguably, just one caveat: compilation speed. And a steep learning curve - but pretty much anything is hard at the beginning, so it's not much of an argument against a language.
I kept coming back to it again and again - and I still do. I love the fact that I'm able to squeeze my CPU to the limit without wasting unnecessary resources, something which interpreted languages force you to do - and yet I'm able to enjoy the creation of my masterpiece without the anxiety that comes with languages like C++, due to their very nature. And yet, I continue to forget about it just as often.
I have to use other languages, not only because there's no real alternative to some languages - like HTML/CSS/JS on client side, but because despite the Rust's ability to abstract things away, no one seems to care. Saving up precious CPU cycles, which boil down to additional cost for companies, running their back-end processes, seems to be of a big deal only to a select few employees once a while, who might choose to replace some of their Go codebase with Rust. Django-, Laravel- like frameworks? A dedicated part of the community, who could be working on all the tools, used on a daily basis in production environments? - non-existent. Everyone does their own thing. Other guys might come in and use Rust as part of their own project, but no one inside the language community itself seems to give a crap. Which feels just a little bit off.
I've taken a look at the Governance Board - unsurprisingly, the least of teams include all kind of wonderful people, which are doing a beautiful job, but there's one team that is missing - and the fact that is missing can be sensed a mile away, not just by the insiders, but by most of the people who take Rust into any kind of serious consideration whenever they're facing a decision regarding the right tools to use for their next project. Libraries Team.
A group of people, who would work in close proximity to both the current community of Rust, as well as all the possible adopters that would come flushing in if only they knew in advance which kind of tools they could rely on when starting their next project in Rust. A team, that would oversee and prioritize the development of various libraries, depending on what we currently lack - to make sure the whole community thrives and prospers, both in terms of the tools available for any given important task, as well as for establishing Rust as a new standard among programming languages - on the job market and beyond. It has all the potential to replace not only C and C++, but Node / Deno, PHP and RoR. This is not going to happen, however, until a team of dedicated professionals makes this a priority.
"Awesome Rust" is not going to do it. A whole web site dedicated to as to "Why You Shouldn't Use Rust in Production" is not going to help. There are, obviously, different fields, each with its own challenges - Game Developers are not going to be interested in the same things that Back-End Developers care about, and those are not going to be concerned much about the development of AI-related tools and libraries. But unless we come together and make a conscious effort not only to develop the best tool possible, as a standalone language, but to use this tool to create other tools, in the forms of packages, libraries and frameworks, which could then be used by ever greater and greater amounts of people, we might simply get stuck, for a long period of time, in the niche of embedded, too-low-level-to-be-used-in-anything-practical programming, with a whole array of attempts to make viable tools, with none of them ever becoming anything other than hobby projects.
Yes, I'm biased towards web development myself. I strongly believe there is a good reason why Actix Web made it to the top of the charts in that benchmark, and although its author did a terrific job, the language itself contributed a ton to it. Forcing people into contributing to projects they don't care about is obviously a dumb idea - but I rarely read about any concrete, focused plans or even priorities from the community as a whole. Every Ruster (pardon me, I like the term better than "Rustacean") enjoys the language, but rarely seems to notice the struggles of people nearby, nevermind anyone else, who could be thrilled to adopt an efficient, productive, safe tool for almost any job, should there be any viable alternative for what they're using right now.
Establishing the upmost priorities for different categories of libraries - WebDev, GameDev, AI, CLI, GUI - and regularly reminding people about them, in "This Week in Rust", promoting the most promising libraries, actively asking for contributions, and actively contributing to the existent projects, instead of trying to rewrite each and every time a "yet another thing" - could help tremendously.
Forming a "Libraries team", dedicated to all of the above, could be a great start.
Thoughts, opinions, comments?
P.S. The "Future Team" could be a bit more appropriate of a name - there's already a "Library team", with a slightly more sparse and diverse range of responsibilities, than would be necessary to create a somewhat more directed and unified structure within the community.
