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++.
Now, this being said, I have lately been porting one of my favorite projects, Indivisible[1] 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.
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.
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.
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 var++, 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: for(<initial definition>; <end condition>;
<variable change>), but it's something I can look past, as
I simply have to get used to the new format.
I am also very happy with the mut keyword. That is, in
Rust every variable is constant by default. In order for a variable to
be mutable you must add the mut 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. const 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.
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 u64 and
i64 is something I do actually appreciate rather than the
C/C++ way of adding the unsigned 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 int.
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.