Answering the call for #Rust2020
Another year already and I’m still knocking myself out using Rust. It is also the year where I can use Rust in a professional environment with people interested in the technology. Let’s review my last year post and try to come up with what I think Rust should focused on for the next year.
I’ve revisited my last year post to see if any of my wishes has been fulfilled during this year.
No being unrespectful to the people working on
RLS, I still feel this component to be
disappointing and not giving a great UX. I even abandoned it and use
even if it is far from being production ready, it gives me a spark of joy when using it,
RLS only frustrated me with the lack of responsiveness.
⇒ So, no, IDE support is not done yet.
Nothing has really changed on this topic for a production ready, idiomatic, full Rust
solution… yet. Some major work is being done with
Druid and we can only hope that this initiative
will bloom soon into the Rust way of doing GUIs. To be fair, I haven’t tried it so I
don’t have any opinion on it, but from the feedbacks I can see, it seems pretty great, and
it’s leaded by Ralph Levien (I think, as the repo is under
xi-editor org), so it will be
⇒ So, not yet.
Big improvements have been conducted this year, spread on
rustc itself but also on
cargo. But we have to admit that it is still slow at the moment.
⇒ Progress, but not there yet.
rustup 1.20 introduced the
profile system and it solves the problem for me!
⇒ It’s a yay!
This aspect is also getting better, with new blogs and more WG.
⇒ It’s a yay!
No More Rush
Nothing to notice on a mistake because of rushing things like the web site last year. If I
recall properly, the
async/await has even been postponed to 1.39 when the initial plan
was targeting 1.38.
⇒ It’s a yay!
Without surprise, many stuff from last year will still be there.
This bit is critical for Rust adoption by the masses. IntelliJ Rust plug-in is doing some
great progress and I have big hopes for
rust-analyzer (I’m trying to contribute more on
it as well). But the task it’s hard, and I’m pretty sure that this item will still be in my
list by next year. Still, the effort must continue. :)
The progress must continue on this field to the point where sceptical people will have one less argument in their pocket to use. :D One aspect could be serving pre-compiled binaries from the crates registries. But raw compilation speed should not be under considered (and I know it’s not).
Rust is already great for CLI tools, and I’d like to see this level of power in the desktop application area as well. Druid seems promising, but according to Ralph himself, it will take years… so go go Druid!
That’s new for this year! I’m using embedded Rust at work now and I’m really grateful to
the people of the community for helping me grasping some concepts. The ergonomic could be
svd2rust already empowered me to play with registers, thing that I’ve never
done before, and that I’d probably screw up in C.
One thing to improve is maybe some way to complete the
svd file with parts that the
manufacturer didn’t put in. I had to patch the generated code to add some interruption
handlers needed for the proprietary radio part of the chip. I also had to path the
file to access to the
ROMTABLE and might do it again to access to
A way to it in a declarative way as an input to
svd2rust would be great.
Working on embedded, sometime the binary is not the same from a build to another, with the same source code. Not great in an embedded world where moving a function can have catastrophic consequences. So this must be addressed, and the sooner the better.
Part of this new job, a colleague (hard C/asm coder) is always surprised by the size of
the produce binary. And it’s true that Rust binaries are big. Not really important on
desktop, it became critical in embedded world. I don’t know what can be done about it when
a "Hello, world!" in C compiles to 101,376 bytes with VS 2017 (
149,504 bytes for the Rust version (
--release, 1.38), but hey, this is a wish list! :p
Like last year, I still think that the theme for a new edition (if any), should be
confidence. We still have a very moving ecosystem. I gave the example of error
handling last year. And it’s still relevant this year with yet another error management
anyhow), which is super great, but make the ecosystem shaking again. I don’t
even need to mention
async/await that will change the landscape of web framework, and
will probably push me to rewrite my little backend project.
Tooling on the IDE, needs to reach some level of usability. Maybe it’s time to ditch
to focus on
rust-analyzer which already provides a better user experience even if it’s
not 1.0 yet.
And even if this past year have seen more sponsoring from big names (Amazon and Microsoft), there’s still the need to push Rust into more big vendors. Like chip manufacturers who still have a full C stack only. Having them to provide Rust API would give a big boost of confidence in the language.