Comment by phplovesong

16 hours ago

Why is stuff written in rust always promoted as "written in rust" like its some magic thing?

I'm old enough to have seen the "written in lisp", "written in ruby", "written in javascript" eras, among others. It's natural.

It carries some weight, very roughly in the direction of formal verification. Since (assuming there isn't any unsafe), a specific class of bugs are guaranteed to not happen.

However, this repo seems like it uses quite a bit of unsafe, by their own admission.

  • I mean if i care about safety that much i would just write the damn thing in ATS. Rust has too many escape hatches to be safe anyway.

    • You never have only one requirement to satisfy. For example, if you'd welcome a certain amount of contributors, your language should be something people know or people like to learn. And of course it may just be the mood of the initiator, which I find completely fine.

      Personally I find rust projects very inviting. Figuring out the amount of unsafe code is easy with grep/rg (to a certain degree), the project structure is pretty standardized, etc. All of this makes even a complex project relatively easy to start with. At the same time, the language is pretty usual (C-like and readable). I understand people like it, and writing "written in rust" is a good call for those people, I guess.

      "Written in JS" would communicate something else than "written in D" or "written in C++". It communicates a lot of things implicitly.

It’s a very Blub. Rust seems ok as a language, but some young uns moving from say JS/TS think it’s amazing because they haven’t used anything else.

One simple reason: for those of us invested in the Rust ecosystem it helps us spot new projects we could consider using.

In the case of libraries, this distinction is important; we've set up our computing infrastructure in a way replete with barriers which and drive repeated efforts in isolation. Therefore, if a library is written in Rust, it suggests that I can use it in my Rust program clear of a conspicuous barrier type.

For an application, service, etc like this... it is not relevant.

I think the idea is like: it took extra work 'cause Rust makes you be so explicit about allocations and types, but it's also probably faster/more reliable because that work was done.

Of course at the end of the day it's just marketing and doesn't necessarily mean anything. In my experience the average piece of Rust software does seem to be of higher quality though..

  • Even forgetting the memory safety and async safety guarantees, the language design produces lower defect code by a wide margin. Google and other orgs have written papers about this.

    There are no exceptions. There are no nulls. You're encouraged to return explicit errors. No weird error flags or booleans or unexpected ways of handling abnormal behaviors. It's all standardized. Then the language syntax makes it easy to handle and super ergonomic and pleasurable. It's nice to handle errors in Rust. Fully first class.

    Result<T,E>, Option<T>, match, if let, if let Ok, if let Some, while let, `?`, map, map_err, ok_or, ok_or_else, etc. etc. It's all super ergonomic. The language makes this one of its chief concerns, and writing idiomatic Rust encourages you to handle errors smartly.

    Because errors were so well thought out, you write fewer bugs.

    Finally, the way the language makes you manage scope, it's almost impossible to write complicated nesting or difficult to follow logic. Hard to describe this one unless you have experience writing Rust, but it's a big contributor to high quality code.

    Rust code is highly readable and easy to reason about (once you learn the syntax). There are no surprises with Rust. It's written simply and straightforwardly and does what it says on the tin.

    • Thats not special to rust in any way or form. Most of mentioned features are stolen from ML, and in some cases badly. Eg rust has unwrap thats basically a ticking time bomb waiting to blow up. Rust has many other ways to blow up the program. Its not only about memory safety (80% of rust apps in the wild dont benefit from "memory safety" in any way or form).

      3 replies →

Because many people, including myself, have been consistently experiencing better quality from Rust-written software.

Maybe it's the type of language that attracts people who are interested in getting the details right.

Or maybe the qualities of the language mean if a project manages to reachthe production stage, it will be better than an alternative that would reach the production stage because the minimal level of quality and checks required are better.

Or maybe it's because it comes with very little friction to install and use the software, because Rust software usually comes with a bunch of binaries from all popular platforms, and often, installers.

Or maybe the ecosystem is just very good.

Or maybe it's all together, and something more.

Doesn't matter.

The fact is, I did have a better experience with software written in rust that in Python, JS or even Go or Java.

And I appreciate knowing the software is not written in C or C++, and potentially contains problems regarding security, segfaults, and encoding that are going to bite me down the road, as it's been common in the last 30 years.

So "written in rust" is a thing I want to know, as it will make me more likely to try said software.

The people that complain about projects saying they were written in rust are far more annoying than the projects themselves at this point.

When it's a library it's fairly important what it's written (or at least written for)

Usually people think Rust = fast, so "Written in Rust" might imply it runs fast.