It was my mistake, I said that we definitely know they don't vs. there is no evidence showing that there is. There aren't much studies to back this up. The whole point of the talk is that software engineering as a discipline is really poorly studied and we tend to make assertions like this without actually validating them.

If I was betting money on this(I.e. deciding where to focus my investment), 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. The whole point of Rust being difficult is that it saves you time down the line, if it's difficult and it doesn't then that tradeoff doesn't make sense.

Hilel teaches formal verification for a living, he very much sees the value of automatically proving properties about your program, as do I, but the reality is that the typesystem doesn't necessarily help as much as we think it does.

[–] [email protected] 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.