Why Rust? Introduction
A few hours ago Steve Klabnik published an article about how to market rust. Specifically, Steve brings up the current problem of trying to sell rust as a ‘safe’ language - this is a sentiment that I have felt strongly about for months.
The fact of the matter is that most people don’t care about security. It’s a burden, treated as an inevitability just as any other kind of bug. While I disagree with this it’s very hard to convince people otherwise, and even if you do, I think it takes a lot to internalize what safety really provides.
Rust is also often targeted as a “better C/C++”, but who is that going to win over? I would bet that most developers are at least content in the languages they use day to day. Paul Graham famously discusses the Blub Paradox in which programmers are incapable of seeing the benefits of something different, and I think it matches up accurately with reality. Rust being marketed as ‘better than x’ is just not going to be effective. If the arguments are “Like C++ but safer” no one is going to explore the language.
Something talked about at RustConf and for the last 5-6 months or so is that rust isn’t just about safety but about productivity. I think that’s the goal of marketing rust in 2017, and I’d like to contribute to that. I’ve written a bit about Rust and the safety it provides but I’m going to try to switch gears and talk more about what problems I can solve easily with rust - real problems that I have run into in my short career.
I honestly do believe that Rust will make many aspects of the development lifecycle cleaner and more efficient, but I’m unsure I’ll be able to express all of the reasons why this is the case. And so I encourage others to write about what makes rust a productive tool for them.
blog comments powered by Disqus