themusicinnoise-site/blog/posts/0130-first-impression-of-rust.html

<p>I'd like to make it clear first that I by no means have extensive
experience with the Rust programming language, nor will I be diving into
the more technical aspects of Rust as a language. This is simply my
first impressions as someone who is largely a fan of C/C++.</p>

<p>Now, this being said, I have lately been porting one of my favorite
projects, Indivisible<sup><a href="#r1" >[1]</a></sup> to the Rust
programming language. I started this journey when a good friend of mine
sent me a link to a video about Rust which had challenged a few things I
had thought erroneously about the language in practical terms. My main
critiques of Rust prior to seeing this video were that it uses garbage
collection, that it is incompatible with C/C++ and therefore would never
kick off, and that it doesn't allow you to use pointers (because of
garbage collection). What I had found was that all these are completely
wrong, especially this last one since the Rust compiler won't stop
bothering me about memory references. The fact of the matter is that
Rust's memory management is basically like using smart pointers in C++,
but with a compiler that makes sure you're using them appropriately (and
is really annoying about it). And as for compatibility with C/C++, it
was made to be compatible.</p>

<p>For me, this last point about compatibility is especially important
if I'm going to learn a systems language since the last thing any
serious code project (like the Linux kernel) is going to do is to
rewrite their entire code base in a new language. It simply doesn't make
sense. And although there are (apparently) many Rust fanatics who will
propose such insanities, the real power of Rust is not in being a tool
to rewrite existing code, but to be used on top of existing C/C++ code.
As such, I see it as at least plausible that Rust may be used as a
serious language for systems programming for future code bases and
modules to existing code bases, making it a valuable investment of my
time.</p>

<p>Getting into some of the details, I can very much appreciate the Rust
compiler. I've said in another post that I'm very much a fan of running
compilers with strict options to have a safer code base. Well, for Rust
this is basically the default mode of the compiler. Granted, sometimes
it's annoying, but being someone who always adds a bunch of flags to his
compiler options to make it as strict as possible, it's something I'm
used to. It's also worth noting that the Rust compiler is extremely
helpful when it gives an error or warning, often proposing solutions,
providing a command to get documentation found locally on your system -
which is always a plus for me, since I dislike having to open my browser
for things like this. I must also admit that I enjoy the build system
from what I've seen so far. I've always been critical of
language-specific package managers (e.g. pip), but I have no problem in
making an exception for cargo. It's probably not very UNIX of me, but
the fact that cargo is a build system and a package manager at the same
time makes my life a whole lot easier. Managing dependencies in
languages like C and C++ has generally always been a pain. And unlike
pip, which tries to install on your system, or some home folder or
something, cargo does everything on a project-by-project basis, which I
very much appreciate.</p>

<p>Now, getting into the syntax of the language itself, I must say that
there are things I like, things I dislike, and some which I've grown to
like. I must say that I miss the typical <code>var++</code>, but it's
something I'm willing to get over. I also found for-loops to be somewhat
confusing originally, since sometimes I have to do weird things with
for-loops which are quite easy with the standard format we're all used
to: <code>for(&lt;initial definition&gt;; &lt;end condition&gt;;
&lt;variable change&gt;)</code>, but it's something I can look past, as
I simply have to get used to the new format.</p>

<p>I am also very happy with the <code>mut</code> keyword. That is, in
Rust every variable is constant by default. In order for a variable to
be <em>mutable</em> you must add the <code>mut</code> keyword. Typically
compilers will make use of constant variables in order to compile more
optimized assembly code, but unfortunately many folks don't use these
keywords (e.g. <code>const</code> in C/C++), so they hardly end up being
used. I've always tried making a point to restrict my variables as much
as possible when programming in C/C++, but with Rust this is once again
the default. This makes it more likely that programmers will make use of
stricter variable definitions, and therefore help the compiler to
optimize the code.</p>

<p>Perhaps the one thing I dislike about Rust is the prevalence of type
inference. I'm generally not a fan of ambiguity, and I think that type
inference is just one of those things I'm never going to actually
appreciate. I always feel as though the compiler/interpreter is going to
get it wrong, especially when we're talking about a language which
differentiates between differently sized data types like 64-bit and
32-bit integers. That being said, the fact that the norm in Rust when
defining variable types is to use keywords like <code>u64</code> and
<code>i64</code> is something I do actually appreciate rather than the
C/C++ way of adding the <code>unsigned</code> keyword to the data type.
By including all the information in one, it gets rid of ambiguity. I
have no doubt as to the size, or whether or not it is signed. And since
all this is defined in a single keyword, when one wishes to define the
variable type one will inevitably have to consider both these aspects
instead of intuitively using <code>int</code>.</p>

<p>Obviously, this is very superficial and not very technical, but I
also don't have much experience with Rust as of yet. However, from what
I have seen it is quite a cool language, and I'm interested in seeing
where it goes from here.</p>

<ol class="refs" >
	<li id="r1" ><a href="https://gitlab.com/naortega/indivisible" target="_blank" >Indivisible GitLab Page</a></li>
</ol>