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.
+ +