According to Stack Overflow survey, it's apparent most coders prefer themselves to be a developer rather than an engineer or programmer.
This might feel like a case of misnomers, but the difference is psychologically key to a person's identity. As a developer, one self-actualizes as a builder who composes modularities into functional applications. Developers do not necessarily write or know every inner working of the modules. The impression of an engineer is someone who knows damn well what she is doing in finer detail. For instance, an engineer would know how a radix tree is implemented or when a linked list is better than an array. A developer just needs to know a library that is well-implemented. For the most part, programmer is the least popular term suggesting an entity who knows Assembly, binary, and compilers.
Up until a few years back, I'd still have a momentary pause when I had to refer to myself as an engineer or programmer. My Slack title sums my feelings up -- I "whacked things to make it work". If there was a label that best suited me, it would have been hacker (but then again the popular culture ruined it all by associating the term with criminal intents). For a hacker, breaking and patching code is learning. Hackers move back and forth between the realm of developers and engineers, re-inventing without much thinking and duct-taping code together when it's critical. Being a hacker means prioritizing speed and objectives over correctness and efficiency.
I used to love Python and scripting languages because they are perfect tools for my hacking. They promote discoveries through feedback. When pushes come to shoves, copying and pasting Python code from another source is more likely to work with little modifications.
But as I've grown more mature as a person (I'm a father now) and as a software engineer, I've become tired of the thrill that comes with hacking. It's like I woke up one day and felt that I did not want to go back to partying until six anymore. My mind and body need more balanced bits of actions and rests. Optimization and prioritization became a priority in life and in code.
Years ago, I transcended to Go, a simple programming language with types and a classic C vibe I liked. It has since become the language I'm most productive in and led me to author my first real open source project. There is no denying that typed languages force you to get more involved in the code you write to different degrees. With Go, that involvement is casual enough that I still felt Python-comfortable (many people would attest to that). One great bonus with types is more instructing error messages.
Today, I'm here because I want to talk about Rust. If you are here, it's likely that you know it's also the most loved programming language on Stack Overflow years in a row. People love Rust for different reasons because there is very little to hate it. One thing that's clear to me is because Rust strives at teaching people to be better in programming, and most coders want to be better.
This is evident in every aspect of Rust, but most obviously in its introductory documentation called the Book. It is a masterpiece on programming language material that can hardly be matched, and yet it's free and available to all. The subtext of the Book is, "You won't need any other books to start being productive in Rust". And that's an understatement. In the Book, you will even learn the concept of stack and heap--an advanced computer science topic--is explained in a very clear and suitable manner. You just learn a lot about computer science by learning Rust.
The core feature of Rust is ownership, and it is also the best one that can teach you a whole lot. Ownership is nothing more than a compiler-enforced deallocation of pointers based on lexical scoping. When you write code in Rust, you need to keep track of your variables and their scopes, but in a different way than you do in C/C++. The compiler is so strict it won't let you brush by whistling and hoping it will turn out okay. It forces you to own your sh**. It would be near impossible for anyone to have written a Rust code and not able to walk through it for another person.
Make no mistake, you will have a hard time picking up the language. Many have attempted several times in the course of their programming career before being comfortable enough to stick with it. So far, this is my third attempt, and I'm not sure if it will still be counting. But with each return, I find myself more and more educated and writing more advanced code in it. This time around, I'm finding its use in Webassembly (the cover image was showing my first pass at going through Rust-WASM Game of Life tutorial). Hopefully I can make it an excuse to work on a real-world project with Rust.
Top comments (1)
Interesting article, I've been hearing about Rust for a while but have never gotten around to trying to learn it yet.
I completely relate with wanting better safety in the programming languages I use. For me, it wasn't so much that I lost the "thrill" of hacking, but more that I started feeling more and more uncomfortable with the lack of types existent in scripting languages like Python and JS. As a web developer, I've completely converted to TypeScript and haven't looked back. It's a steeper learning curve than regular JS, but the safety it provides is more than worth it.