101 lines
6.0 KiB
HTML
101 lines
6.0 KiB
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(<initial definition>; <end condition>;
|
||
|
<variable change>)</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>
|