TWiR quote of the week

Are we trying to steal the JVM’s “compile once run everywhere” concept?

No, we just borrow it mutably.

/u/llogiq re: Stabilization of wasm-wasi target announcement on Reddit


This post by @rubberduck203 should be the Mantra of Rust and Open Source:


Rust is 5 languages stacked on top of each other, except that instead of ending up like 5 children under a trenchcoat, they end up like the power rangers.


You can write safe C++, but you can not accidentally write unsafe rust.


So he went from 1000$ a month to 0 a month, by rewriting a script with Rust.

‘Rhymes’ on summarises the economical value of writing performant code, in An example of why performance matters (with Python and Rust).

“He” is André Arko, lead dev of Ruby’s Bundlr, who got a 230x speedup in rewriting his bundlr log-parser in rust.
I’d recommend mr. Arko’s piece to anyone: it really captures that incredulous feeling of empowerment people get from Rust :blush:


Yes, of course we don’t call Python an “unsafe language” - but if we don’t call Python an unsafe language, it’s unfair to conclude that Rust is unsafe, since Rust actually does a better (imo) job of segregating and controlling unsafety.

/u/NoraCodes in


“[that unsafe function] might actually be safe for all I know. Feel free to investigate further!” – Lokathor, on writing a Rust wrapper for SDL


You shoot yourself in the foot. Nothing happens to the foot because it wasn’t declared mutable #rustlang

Elena Nadolinski on Twitter.

Originally suggested by @SenojEkul.


Roses are red,
Rust-lang is fine,
cannot borrow `i` as mutable more than once at a time


@drXor from internals engaging in UB poetry.


Perhaps a better way to explain this is: you cannot ever get a function pointer to an intrinsic.

The compiler will just throw a block of ice in your face.

nagisa on Zulip


Rust isn’t training wheels, it’s a containment vessel and some minimal failsafes.

/u/yawpitch - on reddit


Rust clearly popularized the ownership model, with similar implementations being considered in D, Swift and other languages. This is great news for both performance and memory safety in general.

Also let's not forget that Rust is not the endgame. Someone may at one point find or invent a language that will offer an even better position in the safety-performance-ergonomics space. We should be careful not to get too attached to Rust, lest we stand in progress' way.

-- llogiq


-- @H2CO3: Println! - use named arguments from scope?


H2CO3 on whether Rust is an OOP language:

Rust is…

…a language whose main goal and promise is to bring compile-time-proven memory safety and thread safety together with runtime performance, ideally without compromising either;
…which is achieved via a unique combination of half-century-old and novel good ideas from the history of programming language design; drawing heavily on
…interface-/protocol-/typeclass-/trait-/whatever-you-call-it- based programming complementing real, parametric polymorphism aka "generics" aka "type-level functions";
…making the strong static typing easier to digest for the programmer via extensive and smart type inference;
…mixing in the basics of algebraic type systems found in traditional statically-typed so-called functional languages, such as Haskell and its family;
…as well as the superb pattern matching abilities of said languages;
…allowing as syntactic sugar for function calls what many consider "THE object-oriented syntax";
…although the latter was never the essence of object-oriented programming – according to some, myself included, it is instead encapsulation, which Rust also provides via the simple concept of visibility modifiers;
…while it also cleverly manages mutable state, allowing for the so-called procedural-imperative paradigm to be embedded into the language without undermining its safety.

@H2CO3 in Is Rust OOP? If not, what is it oriented to??


@kornel about blocking Tokio threads:

If you want to block threads, get your own threads.


@dholroyd in How are you using rustfmt and clippy?.


@tmandry on futures/async/await:

Seeing code written like this that compiled down to one state machine, with full code and data inlining, and no extra allocations, was captivating. You may as well have dropped out of the sky on a flying motorcycle and told me that magic exists, and I was a wizard.


C++ being memory safe is like saying riding a motorcycle is crash safe.

It totally is, if you happen to have the knowledge and experience to realize this is only true if you remember to put on body-armor, a helmet, a full set of leathers including gloves and reinforced boots, and then remember to operate the motorcycle correctly afterwards. In C/C++ though, that armor is completely 100% optional.


Maybe a bit long, can probably be cut down.

The project began and completed in less than a month. Around 2-3 weeks of time. Something that wouldn't have been possible in C, and certainly not at this level of quality. The vast majority of time was spent implementing features, rather than fixing bugs. Issues in the UI could be fixed in a couple minutes, so QA had quick turnaround (although compile times caused us to have to wait).

There was a smaller C attempt prior to this that integrated directly into GNOME Settings, but a month later it was far from complete, riddled with bugs requiring runtime sanitizers to find, and nearly-unmaintainable. System libraries are often unergonomic to use, and prone to misuse. Many things had to be implemented from scratch. Code handling DBus was atrocious. Many basic data structures completely absent.

We then decided to scrap it for a more ambitious firmware manager project written in Rust, and by the third day of development, it was already significantly better than the C implementation. I was surprised at how easy it was to write GTK widgets in Rust, and then give a C application a pointer to its container widget.

It uses slotmap for storing firmware devices as entities, and then storing data associated with that entity in secondary map component storages. Examples of components would be the GTK widgets related to the entity, data shared between fwupd and system76 firmware, as well as fwupd-specific and system76-specific data. The UI frontend holds exclusive access to the slotmap and its secondary maps.

There's a background thread that carries out all of the tasks on behalf of the UI in the main thread. Widgets send events through channels to the background thread, along with the entity key referring to the device being handled. The background thread then sends responses through a glib channel, with that entity key associated with the response. The UI can then map the entity key to the proper widgets and update the UI accordingly.