On 2/6/23 11:40, Imobach Gonzalez Sosa wrote:
Hi all,
As a Hack Week project, Josef and I started to work on a Rust-based
command line interface[1] for D-Installer. My primary purpose was to
determine whether it is a good language for building this tool.
Moreover, I wanted to put my (limited) knowledge of the language into
practice.
TL;DR; the experience was really positive. Although it is far from
finished, we managed to build a minimal CLI that allows setting/getting
configuration values (using YAML and JSON as output formats). You can
find more details in the Running section[2] of the README.
Now, I will comment on some aspects that I found interesting. I hope
you enjoy the reading :-)
# The main obstacle
Funny enough, the main "problem" we found was unrelated to Rust. It
was, instead, the gap between our new CLI design (+ the auto-
installation specification) and the D-Bus API. To fill the gap, we
decided to keep an in-memory representation of D-Installer's settings
(see the Settings and related structs[3]) and implement a separate
mechanism to read/write those settings (see the Store struct[4]).
# Procedural macros
We found out that to set or get those configuration values, we needed
to determine the name of the method/function to call at runtime. That's
trivial with Ruby, but not with Rust without writing one line per each
possible function. So we implemented a proc-macro[5] that generates the
code for us. Beware that these macros are different to C/C++ ones and,
among other things, they are written in Rust and give you access to the
AST.
# Abstraction level
Rust cannot offer the same abstraction level as Ruby, period. But it
has an expressive type system and powerful tools for meta-programming
if needed. So when writing this CLI, I felt quite comfortable with the
level of abstraction.
# Error messages are helpful
Most of the time, compiler error messages make sense. Apart from an
explanation, it usually gives you some hints to solve the issues.
However, if the error implies lifetimes, generics and so on, it can be
hard to understand what is happening behind the scenes.
# Extensive documentation
Apart from "the book"[6], the standard library documentation is
rather complete. However, it can be intimidating if you do not know the
basis.
# Closing thoughts
As said before, the experience was really positive and I enjoyed a lot
working on this project. There were a few things that we wanted to try,
like calling Rust code from Ruby or using the async support, but we ran
out of time.
My main question now is: should we use this as the base for our D-
Installer CLI or should we go back to our Ruby-based implementation?
Regards,
Imo
[1] https://hackweek.opensuse.org/22/projects/rewrite-the-d-installer
[2] https://github.com/imobachgs/dinstaller-rs#running
[3]
https://github.com/imobachgs/dinstaller-rs/blob/update-readme/dinstaller-lib/src/settings.rs#L9
[4]
https://github.com/imobachgs/dinstaller-rs/blob/update-readme/dinstaller-lib/src/settings.rs#L49
[5]
https://github.com/imobachgs/dinstaller-rs/blob/update-readme/dinstaller-derive/src/lib.rs
[6] https://doc.rust-lang.org/book/
[7] https://www.rust-lang.org/tools
Thanks for the summary! Very interesting, indeed. About deciding whether
to continue with Rust or not, I would put several aspects on the balance:
* Do we gain any use cases? Probably yes. For example, if the CLI is
able to run commands remotely, then we don't need ruby deps in the system.
* Is Rust a good option for other future migrations? Right now
D-Installer uses a lot YaST logic, but we could start implementing new
features in a separate Rust based backend.
* In case of continuing with the Rust based CLI, more people in the team
should start learning Rust. I think this is a positive thing, just
commenting to make clear we don't want silos anymore.
* Is there any other options to consider? Maybe we could do the exercise
of implementing something similar with other modern language, for
example Go, just to compare.
* Having a team that speaks Ruby, is Rust the best migration? If not,
are there good reasons to pay the effort?
And for sure there are more things to consider. BTW, I am all for
learning Rust. I am only expressing that officially migrating to another
language is a difficult decision ;).
Thanks a lot Imo and Josef. Great work!
Regards,
Iván
--
José Iván López González
YaST Team at SUSE LINUX GmbH
IRC: jilopez
