You brought up valid points. To that, I don't have much to counter against because Rust truly suffers from relatively slower compile times and inferior tooling compared to the C++ equivalent (as of writing).
However, these pain points do not outright dismiss Rust's value in the ecosystem. From a developer experience standpoint, Rust empowers me to achieve low-level capabilities using familiar high-level syntax. Meanwhile, Cargo itself automates project management (from dependencies to testing).
All of these features (and the others I've mentioned in my article) combined truly make Rust a language worth considering, even despite its yet-to-mature ecosystem. Or at the very least, all languages should look to Rust as a prime example of a language that puts developer experience at the forefront of its values.
My experience with C++ had none of these "quality-of-life" features. One can argue that C++ is for the "hardcore programmers", but speaking once again from a developer experience standpoint, these languages do not feel empowering. In fact, they are quite intimidating, to be honest. Perhaps that reflects more on me than the language; my point is: if a language goes out of its way to accomodate for developer experience regardless of expertise, then I am all for it, even if the ecosystem will take some time to mature.
Now, regarding your argument on C#, I don't have much to say, but I'm glad C# empowers you in that way! At the end of the day, what really matters is how a language empowers us to create and innovate in the technological space.
For me, I find this in Rust. For you, this is in C#. For others, it may be in C++. For some, it may be in Python and JavaScript. Regardless of language, developer experience and empowerment should always be the basis of our judgements.
With that said, thank you for your insights on the pain points. I must admit that I have failed to add more of them in the article. I feared that they may further lengthen an already lengthy article, hence the rather skewed commentary. But that's what the discussion threads are for, right? Thank you for adding value to the article.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You brought up valid points. To that, I don't have much to counter against because Rust truly suffers from relatively slower compile times and inferior tooling compared to the C++ equivalent (as of writing).
However, these pain points do not outright dismiss Rust's value in the ecosystem. From a developer experience standpoint, Rust empowers me to achieve low-level capabilities using familiar high-level syntax. Meanwhile, Cargo itself automates project management (from dependencies to testing).
All of these features (and the others I've mentioned in my article) combined truly make Rust a language worth considering, even despite its yet-to-mature ecosystem. Or at the very least, all languages should look to Rust as a prime example of a language that puts developer experience at the forefront of its values.
My experience with C++ had none of these "quality-of-life" features. One can argue that C++ is for the "hardcore programmers", but speaking once again from a developer experience standpoint, these languages do not feel empowering. In fact, they are quite intimidating, to be honest. Perhaps that reflects more on me than the language; my point is: if a language goes out of its way to accomodate for developer experience regardless of expertise, then I am all for it, even if the ecosystem will take some time to mature.
Now, regarding your argument on C#, I don't have much to say, but I'm glad C# empowers you in that way! At the end of the day, what really matters is how a language empowers us to create and innovate in the technological space.
For me, I find this in Rust. For you, this is in C#. For others, it may be in C++. For some, it may be in Python and JavaScript. Regardless of language, developer experience and empowerment should always be the basis of our judgements.
With that said, thank you for your insights on the pain points. I must admit that I have failed to add more of them in the article. I feared that they may further lengthen an already lengthy article, hence the rather skewed commentary. But that's what the discussion threads are for, right? Thank you for adding value to the article.