New blog post on Rust.

blog/posts/2021-04-18-first-impression-of-rust.cfg

@@ -0,0 +1,5 @@
+filename = 2021-04-18-first-impression-of-rust.html
+title = First Impression of Rust
+description = After some time using Rust, and initially being very skeptical, I give my first impressions of the Rust programming language.
+created = 2021-04-18
+updated = 2021-04-18

blog/posts/2021-04-18-first-impression-of-rust.html

@@ -0,0 +1,100 @@
+<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>