Originally written on 2023.11.30
I should mention now that I’ve always stuck with procedural programming for simplicity, and the fact that most “object-oriented” concepts (and languages) are just utterly incomprehensible to me. That is why I’ve always preferred Lua, Go and recently even C. On the other hand, interfaces in Go actually make sense and even seemed to be the most natural fit for one project I created, marking the first time I’d ever written anything that was “object oriented” by any definition. After 18+ years of on/off coding, it was nice to learn another way to get stuff done. With that said, what’s up with Rust and why am I even looking at it?
Other (more experienced) programmers have mentioned the learning curve as being unusually steep, often taking months for them to be productive. There’s also a lot of hate for Rust on Reddit, but I can’t read any of it because Reddit is being… well we’re just not gonna go there, okay? Overall, this doesn’t sound like a language I want to work with, but since it’s apparently becoming one of the most popular languages in spite of its numerous supposed issues, maybe it’s time to revisit this alien world and see if anything has changed. After all, I’m trying to shed the old prejudices and have an open mind.
I did try Rust once before, but that was several years ago and I hated it… The syntax was more confusing and difficult for me to comprehend than any other language I’d tried up to that point, and that even includes Java, C++, Ruby and… Perl. Writing trivial programs in Rust was difficult since I didn’t know what was wrong when they failed to build, partly because the compiler errors pointed at all the wrong things. Missing a double quote at the end of some string? Haha, we’ll just point at the next string and claim that it’s unterminated, even though it’s not. The same thing would happen if one of the many strange tokens were missing, such as a ‘!’ or a ‘:’.
Overall that experience was about as pleasant as rubbing hot thumb-tacks with sea salt and Sulfuric Acid. After several years and just a bit more coding experience, round two should be smoother, right?
First I ran ‘pkg_info -Q’ to see if Rust is even available on OpenBSD; it is, but the download took a while because my ISP is a jerk and likes to throttle the bandwidth to 56k dial-up speeds. This often results in large downloads getting corrupted when they suddenly stop without apparent cause, but I was lucky this time and ended up with the ‘rustc’, ‘cargo’ and ‘rustdoc’ commands. Apparently ‘rustfmt’ is a separate package, which is just as well since Rust prefers indentations of four spaces, just like Python and GNU… I’ll stick with tabs[1], thank you very much.
-and “slam!” goes the door to an open mind-
So now I’ve got things in place, let’s do the classic “hello world” exercise, because, ya know… why not?. I run ‘cargo new hello’ and enter the new directory to find Cargo.toml and a ‘src’ directory. Upon entering ‘src’ to edit the presumably empty main.rs that was created, I found that it’s already been filled in!
fn main() {
println!("Hello, world!");
}
“Well damn, this language is great! It seems to just know what I’m about to write and does all the work for me. Guess I don’t actually have to write any code, like, ever…”
Jokes aside, it seems the ‘cargo new’ command is pretty handy since it sets up the otherwise boring and mundane stuff and even creates a git repository within the directory, so one can get right to work. There is ‘cargo build’ to compile the package, with a default (unoptimized) “debug” profile for development and even a “release” profile that turns on optimizations. That sounds convenient. There is ‘cargo run’ to test a program without building an executable, and even ‘cargo check’ to see if it will still compile without having to actually build anything (even better). So far I like what I see…
Except that each time I run ‘cargo new’, the main.rs file is still filled with the above “Hello, world” example code… Surely there must be some way to turn that off so I don’t have to keep deleting it when I start new projects?
Reading the official (online) book is nice for the fact that it’s actually quite detailed. On the other hand, I’m reminded of the reasons I hated Rust before: it too is extremely detailed. For example, chapter 2 has us writing a short guessing game that introduces… a lot of foreign stuff that I’ve never seen before, plus some clear influences taken from other languages. It doesn’t help that the book uses all sorts of fun new lingo (and some that’s just confusing). In essence, I feel like I’m learning how to code for the first time again, because Rust is to programming languages what Plan 9 is to operating systems; it turns everything you know on its head and spins it around until you don’t know what the f#!k you’re looking at anymore… But it’s not all bad.
When I say the book is detailed, I mean it. There are numerous examples of error messages for just this one project, with explanations for why they might occur. That’s not something I’m used to seeing in books about programming languages, but it’s definitely something more books should include. That level of detail seems to cover much more than just errors, at least from what I’ve seen so far. Even the language used to explain things is surprisingly clear, though much of the lingo and core concepts of Rust are still not that quick to sink in, at least not after the first pass. Moving on to chapter 3 helps to clarify some things, but it still unloads a lot of information at once and is likely going to need another few passes.
As I slowly make it through the first few chapters, one thing becomes clear: Rust is so different that it seems you have to unlearn programming in order to make the most of it. Perhaps that’s why people find it so difficult, because they’re accustomed to certain ways of doing most “normal” tasks, but the similarities to Rust are only superficial. And it’s not even just the syntax but also concepts like “shadowing” and all the weird little macros and methods that can be attached to things. Coming from a long background of procedural programming, things like this just look insane:
let guess: u32 = guess.trim().parse().expect("Bloody hell! What is this?");
Chapter three reveals another thing I don’t particularly care for; snake case. Why must a function be named some_function instead of someFunction? What is so wrong with camel case? First of all it’s easier to type, and second it’s not that hard to read when done right. Oh, and the compiler does spit out warnings about this, but will otherwise run the program (thankfully). It’s superficial, I know, but still important to me. Tabs are faster to delete than spaces, and snake case is just weird and annoying to write.
2023.12.03
The initial shock of information overload has mostly worn off, and I’ve been reading the first five chapters multiple times while writing a temperature conversion tool to see if I’m “getting it”. It’s rather clean and not at all unpleasant to look at, while the only problem is a total lack of proper error handling (which I do intend to fix). Writing the same tool in C was a failure because it suffered from a couple of major bugs, one of which had no apparent cause. Sadly this happens more often than I care to admit, even with simple tools…
The first round is certainly a lot to take in, but the book is well-written and helps to clarify a lot of things which puzzled me. Most of the compiler errors I’ve encountered have been trivial to understand, unlike the errors provided by Lua. Another thing I like is that the book is CLEAR and SIMPLE when explaining statements and expressions. Every other language I’ve used made this more confusing than it needs to be, filling multiple paragraphs on that subject with little clarity. The Book sums it up in just one simple paragraph!
As for references… well, maybe prior experience helped me understand this, but somehow I doubt that’s what happened. Pointers are another thing that other languages fail to explain in a clear and concise fashion, but with Rust it made sense the first time, despite the different name. I was even able to predict why several examples would fail to build, without having to read past the bad code. This is very encouraging…
[1] “I’ll just stick with tabs, thank you very much”… Oh, what a mistake THAT was! Awkward line breaks will be your new best friend unless you are willing to sacrifice the comfort of an 80-column terminal window.