The Build-up
I met Debasis Basu (LinkedIn) at a social event, a few weeks ago.
Debasis is a childhood friend. We studied at the same residential high-school and spent six of our formative years together: a brilliant student (much better than I have been 😁) and an excellent sportsperson (again, much ahead of me 😞), Debasis has had an outstanding career for over 35 years, after graduating from IIT, Kharagpur, India. A keen observer of the goings-on, in the technology industry, Debasis has this habit of putting me off-guard, by asking relevant, pointed and interesting questions. I fumble but then, I become aware of gaps between what I know and what I think I know.
This time, too, Debasis threw a seemingly simple question at me: why are you learning Rust? What is it that you can do using Rust, that you cannot do using say, 'C'?
I put up a brave face, thought on my feet and mumbled something. It quickly became obvious to me, that my effort did not leave any much effect on him. He looked plainly unimpressed.
Later, I played the conversation in my mind. If I could not tell Debasis - who has (more than) the requisite background and was genuinely all ears - reasonably convincingly why I was learning Rust, what chance did I have to tell someone else, having much less attention to and much less time for, what I had to say? More importantly, did I ever tell myself why would I like to learn Rust?
So, I decided to put together my thoughts into a more coherent form, but I will begin with a quote I have remained very, very fond of:
A language that doesn't affect the way you think about programming, is not worth knowing.
-- Alan Perlis
Learning a new language makes me think differently from what I am used to
Rust is a systems programming language. I have developed non-trivial software using 'C' in the first decade and a half of my career. That was my first - and so far, last - fortuitous association with what is called systems programming. A compact language, having 32 keywords, 'C' propounded a philosophy of doing a lot by saying a little. Being a low_level language, it provided powerful constructs that allowed me - the programmer - to go very near to the world where the machine ruled. The fall-out was a huge responsibility on me to be 'right' along the entire flow from very near to the user application to very near to the machine. The price to pay for being inattentive could be disatrous. The power was intoxicating for a programmer and the responsibility was unnerving. The long nights spent in following a wayward pointer are still etched in my mind.
Rust brings in a different philosophy. The Rust compiler has strict rules and it employs them ruthlessly. Armed with these rules, it tries to foresee where my code can go wrong when it runs, even when I haven't been careful. This changes the game altogether. The compiler can see what I - the programmer - have possibly failed to see and then, by throwing compile-time errors, the compiler refuses to let me move ahead. Thus, to satisfy the compiler, I am forced to consider implications of my code while writing it:
- is a variable associated with right data type througout its usage?
- is a pointer dangling dangerously?
- is a piece of memory being used incautiously by two threads? and such.
The important point is that the compiler doesn't let me proceed with such vulnerabilities. Consequently, in order to run my program, I have to think the way the compiler is thinking. This forced co-thinking with a very smart and powerful compiler has its benefits: I am made to think more precisely than I am used to. It helps sharpen my programming thinking.
I feel welcome. Yes, that matters.
From the very first time I stepped in the world of Rust, I felt that folks in the community were all extending a helping hand. Documentations were crisp and clear. Tutorials were meant to coach me and not just to take me to quick end of an example. Exercises were usefully graded, with appropriate hints to assist. Videos (on youtube) varied from simple features to complex concepts, without being patronizing.
Now, one may raise the eyebrow and wonder how do all these make Rust special? Are proponents and practitioners of other, newer languages any different?
Well, I will be honest. I cannot knowledgeably comment on how is the state of affairs with long list of other languages. I know and professionally work (have worked) with a few of them. I have dabbled with a couple of others. Thus, the background with which I say this, is quite limited.
It is not that I decided to jump into Rust without any consideration. I had been watching Rust from the fence for some time. I have spent time watching video clips, listening to podcasts and of course, reading blogs as well as discussion-threads in 'Stackoverflow' and 'reddit'. Like I mentioned earlier, Rust indeed has many quirks, some of which are quite inscrutable at the beginning. At times, this is definitely frustrating.
Countless enthusiastic newbies like me threw (and are throwing) in questions, ranging from eye-opener-types to eye-rolling-in-socket-types. However, I didn't find responses which were dismissive in nature and in tone. One may argue that the sample-set is too small, but I did sense the care and the wardship of the Rust experts who proffered their responses. It was as if they knew that the language brought in approaches which, a large swath of mainstream programmers hadn't heard about, let alone being comfortable. These programmers needed calming hands on their shoulders while they joined the community.
Praising by practitioners, backing by biggies
Even though large corporations of the world of software are not particularly loved for their large-heartedness 😉, it is undeniable that their endorsement of a technology matters. A programming language's uptake gets a shot in the arm, when they announce their support, contribute to the effort and in the process, keep generations of programmers enthused. Java, Javascript (nodeJS to be a little more accurate), Swift etc. good examples.
Rust has made some of the biggies interested and that is a good news. Amazon,, Microsoft and Cloudflare have endorsed it and have put up production versions of some of their offerings.
Several publicly available datasets indicate that Rust has a significant following and the trend doesn't seem to wane.
TIOBE Index confirms the upward trend, but Rust decidedly has a long distance to cover.
Redmonk suggests in its June'2022 report that "it seems increasingly clear that the hypothesis of a temporary equilibrium of programming language usage is supported by the evidence". If this indeed is the case, Rust has a steep upwards climb ahead, from its current position of 19 out of 20.
According to statisticstimes.com, Rust is showing slow yet steady progress upwards in popularity in countries like US, Germany, France, UK and in India!
So, there's something going on with Rust. Will it sustain (or accelerate) its current rate of adoption? Time will tell.
So, where do I find myself?
Well, I am not a soothsayer. I cannot and certainly don't want to, predict the fate of Rust. I feel that Rust very unlikely to dethrone Python or Javascript based on number of deployed applications. It is also unlikely to challenge Java (and other JVM based languages) for enterprise-focused, large, server-side application, meaningfully. It will possibly remain a niche language, used for specific purposes and by a smaller segment of the tech-industry. Having said that, I also feel that these specific, niche areas will only increase in number. Hopefully, the time and effort that I am investing in learning and mastering Rust, will not go in vain.
So, this is all that I have to say to Debasis 🤗.
I have steadfastly kept away from the technical features of Rust, their power and their usage-patterns and the cautionary steps which the experts remind the new entrants. Debasis was not interested about those in any case and this blog is primarily meant to give a compact and honest answer to the question he posed, during a sumptuous dinner in Kolkata, India.
Top comments (12)
Tell Debasis this additional thing too: Rust has no undefined behaviour. I'm sure you ran into this with c. It does not happen in Rust
I am trying to learn rust and making basic videos on it. Learning a language was never this tough for me ( not having experience in systems programming might be a reason ), but it is giving that in depth knowledge in every aspect when I m trying to learn new things. And I want to continue that for systems programming.
Thank you for your article. It made me pause to reflect on why I learned Rust.
In addition to your own reasons, I chose to learn Rust after working at some companies who didn't understand that a single point of failure in their systems was unacceptable and other companies that did.
Rust's added strictness makes it much less likely that a bug in my code might escape detection with my tests.
It also ensures that every path has code to handle it or that I have had to intentionally no-op my way past it. Having the compiler force me to contemplate every possible path forces me to consider all failure points..even the ones that will "never happen"..and create the back up code for every closet case.
In short, it points out most single points of failure in my code that I didn't already notice when planning my projects and forces me to include code to recover from or avoid those pitfalls.
That...and Rust is just fun. ;)
When I click on the documentation link you mentioned:
dev.to/nsengupta/%5BThe%20Rust%20P...
it sends me to an non-existing page.
What am I doing wrong, please? Thank you.
I 'Thank' you, twice!
I have edited the blog. Please check once more, and let me know if the problem persists. I will be more careful, the next time.
:-)
You're very welcome! The link works properly now.
I had a similar discussion with a friend who loves C++ and tried to learn Rust, but abandoned it very soon.
He laughed in my face comparing simple things, like a for loop in C++ and one in Rust, pointing out the elegance of the C++ syntax.
in C++
for (int i = 100; i >= 1; i -= 5) { ... }in Rust
for i in (1..=100).rev().step_by(5) { ... }in C++ : I thank you
in Rust : you to me do the thanking, but in reverse
What would you answer to this comparison, as I was at a loss of words?
I don’t see anything inelegant in rust for loop: it even intuitively clearer as having semantic parts like range from 1 to 100, rev, step_by…
His reluctant behaviour is just a matter of habit and unwillingness to step out of his comfort zone.
The loop also can be rewritten with while:
let mut i = 100;
while i >= 1 {
i = i - 5;
}
Let me nitpick at the beginning:
That's a 'C' loop, and not a C++ loop, in the strict sense and with my tongue firmly in the cheek. :-)
The loop in Rust can be written in a way that Eugen (dev.to/tsolan) has shown already.
However, in case of Rust code shown by you, the idea is of having an Iterator as a datatype and treat it as that. It is not a
for loopin that sense. Declaratively speaking, we areAnd, we are not specifying a terminating condition. This is an Iterator and we are declaring what should happen during each iteration. the Iterator understands that when it has gone beyond the lowermost end of the Range, nothing needs to be done! The iteration stops.
Rust playground is here: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021
C playground is here: cplayground.com/?p=pika-seahorse-t...
Honestly, I have done quite some Java (using both OO and FP constructs) and Scala programming and I understand and appreciate the declarative nature of many operations which these propound. Readabiity of a code - a somewhat underrated yet extremely important aspect - increases with right level of declarative-ness. SQL is a great example of declarative programming.
NB: Just to make it clear, I have remained a big fan of C and I only have awe and respect for late Dennis Ritchie and Brian Kernighian. Whatever little I have been able to do in my career so far, I attribute that to the chance exposure to, adoption of and a l-o-n-g association with 'C' programming, from the very early days in my career. 'C' has helped me to sense, what is happening at the critical spot where my code meets the machine.
But, now, I am beyond that 'my language is better than your language' warfare. It is plain silly! :-P
I can't take SVD file and generate peripheral access crate in C in portable way. I have to take vendor locking library and use it in my embedded code, that porting in future is going to be nightmare.
But in the end it's not about what I can or cannot do, but how quick, how reliable and how many security holes I'm going to leave in my solution.
Great post!
The price to pay for being inattentive could be disatrous.
Loved the accidental here
😃 I thought of using ruinous but then, decided against it.
Thanks for your comment.