this post was submitted on 28 Jul 2023
33 points (97.1% liked)

Rust

5980 readers
101 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] RunAwayFrog@sh.itjust.works 1 points 1 year ago

the quality of the typesystem would only matter if the typesystem caught real problems that I face in my day to day work. For a Web app for instance, it makes no sense to use Rust vs a GC’d language because the kinds of bugs that you face in Web apps aren’t really the kinds of issues that a borrow checker will help you with.

It's quite reductionist (and weird) to describe Rust's type system in terms of it's borrow-checker only, ditto for describing the other simply as "GC'd languages".

The borrow-checker together with move semantics and RAII are a small, if dominating -especially for beginners-, part of Rust's type system. There are many other very relevant aspects, type classes (traits), sum types (enums), hell, not being OOP alone is a big win for many.

Talking about Rust only in terms of its type system would also be reductionist. The macro system alone is a big differentiator (I would know, because I've been working on a proc-macro crate for sometime which will support (de-)serializing a format with both more flexibility and reliability than what serde can offer).

Even talking about Rust only in terms of the language is reductionist! The ecosystem and tooling... okay, I will stop reaching further here.

Talking about the other as "GC'd languages" is also reductionist and weird, since it puts, for example, Go (lol) and Haskell on the same bracket. And that's two strongly and statically typed languages. I could have picked two languages that are even more different than each other. "GC" as a differentiator for languages is actually even more reductionist than "borrow checker" for Rust.

The whole point of Rust being difficult is that it saves you time down the line

Neither Rust is actively trying to be difficult, nor is it really difficult beyond some early friction while learning the language, and even that friction is overblown often by many.

We do actually have some data on this (I wouldn't dare calling it "research"). There is this part which actually relates to one of the arguments made in your YouTube link:

And, it’s not just correct—it’s also easy to review. More than half of respondents say that Rust code is incredibly easy to review. As an engineering manager, that result is in many ways at least as interesting to me as the code authoring results, since code reviewing is at least as large a part of the role of a professional software engineer as authoring.