DEV Community

Discussion on: πŸ¦€ Rust Reviewed: Is the hype justified? πŸ¦€

Collapse
 
atomicstan profile image
Stan Prokop

Let me play a devil's advocate and list things which I think are worth to mention when it comes to pain points in rust and are sadly not mentioned in your post:

  • questionable benefits of borrow check for data driven programming
  • it's easier and cheaper to hire seasoned C#/Java/Python/Node.js developer than a seasoned rust developer (not enough of them and complexity of rust)
  • inferior tooling (just compare the best Rust IDE with JetBrains Rider for C#)
  • long compile times due heavy use of meta programming
  • it's possible to implement borrow check (at least to some degree) in other languages, see: pspdfkit.com/blog/2020/the-cpp-lif...

For example I can't really rationally justify using rust for my hobby data driven gamedev experiments, because the return on investment is simply too low. I use C# because it allows me to go low level enough (even to SIMD) while having garbage collector and bunch of TODOs with hacky code simply because I don't have enough time.

Btw you can end up with spaghetti code even in Rust, there is nothing which would stop you in writing long and messy block of code with terrible cohesion between modules.

Collapse
 
l0uisc profile image
Louis Cloete

Rust is gaining a lot of traction in security-critical low-level software like browser engines, etc. IMO that's where it shine. You can't write a CSS parser, HTML parser, JS interpreter, etc. in C#. You can do it is C++, in fact most are written in C++ today. However, security bugs are starting to become even more of a problem as the world gets more connected. Which is where Rust come in. You can access all the low-level stuff you can from C++ and get the same predictability and performance, but you get language-level protection against memory errors causing security vulnerabilities.

Collapse
 
somedood profile image
Basti Ortiz

Well, technically, you can still write a parser and an interpreter in C#. It's just that the language may not be the most ideal option.

And, also, Rust isn't exactly bulletproof from all security vulnerabilities. The onus is still on us, the developers, to make sure that nasty bugs (like buffer overflow vulnerabilities) are avoided. But sure enough, Rust does help in avoiding many memory issues and pitfalls.

Thread Thread
 
l0uisc profile image
Louis Cloete

You can write it in C#, sure, but not with the performance and memory footprint required. Browsers are already notorious for their appetite for RAM. That's why it is traditionally done in C++. And it is orders of magnitude easier to avoid memory bugs causing security vulnerabilities in Rust compared to C++.

Collapse
 
singalen profile image
Victor Sergienko
  • Re: borrow checker and data-driven programming. I don't mean to invalidate the point itself, but the medium is not suitable for a discussion, because of readability. Maybe their point is valid, maybe it's like "Purely functional languages are bad for data-driven programs because they are stateless". I will not go sink my time into watching a random video to find it out. Retelling the basic idea or finding a similar paper would have worked much better.
  • Re: hiring. Completely valid. Well, it's inevitable for a young language. Though, there's been a strong positive trend this year. Plus there's a "Scala effect": if you hire a Scala programmer, you hire a great programmer, because they managed to learn this advanced thing for the love of the art.
  • Re: IDE. I have a different opinion. I've used IDEA/Java for a decade, and their support for Rust is getting closer to Java support. I'm working with it right now, it's quite good and it's developing fast.
  • Re: compile times. Well, they haven't killed C++ so far, and C++ is way worse. Rust, on other hand, is getting better in this department all the time.
  • Re: borrow check in C++. Yes you can, but a) it's yet another set of APIs and conventions on top of already huge stack of standards, APIs and conventions, and b) it costs us to implement, to educate the team, change coding standards, and to maintain. In Rust, borrow checked comes for way lower price. Sure, it's not free in Rust as well: a large part of Rust learning curve is caused by borrow checker.
Collapse
 
somedood profile image
Basti Ortiz

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.