TWiR quote of the week

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.



  • The compiler is your friend.
  • It’s a very good friend. It’s a very honest friend.
  • It might be Dutch.

Just as Bruce Lee practiced Jeet Kune Do, the style of all styles, Rust is not bound to any one paradigm. Instead of trying to put it into an existing box, it's best to just feel it out. Rust isn't Haskell and it's not C. It has aspects in common with each and it has traits unique to itself.

@ajnye in Idiomatic Rust favors Functional or Imperative Style?


Threads are for working in parallel, async is for waiting in parallel.

By ssokolow on reddit

(I saw it in tweet by @bitshiftmask)


While I'm flattered to see that here, honesty demands that I make it clear that I was paraphrasing an article on the difference between parallelism and concurrency that I read a few years ago, though I can't remember who or where or how much I'm paraphrasing it.

(The original might have been something like "parallelism is for working busily, concurrency is for waiting busily".)


The first thing I learned about profiling programs in Rust is that you have to do it with compiler optimizations turned on.

Taken from here

It turn out rust programs even in debug mode are faster than python and ruby scripts :smile:


By boats,

As I said once, pure functional programming is an ingenious trick to show you can code without mutation, but Rust is an even cleverer trick to show you can just have mutation.

From here:

That made my day when I read it.

For years I have thought that the "functional programming" thing was completely bonkers. Either that or I'm too stupid to appreciate the idea.

So I was very happy to have someone as smart and knowledgeable as boats succinctly tell me there that the former is true.


I like that quote, though I disagree with your conclusion. Functional programming is not "completely bonkers", as you say. In certain settings it can work very well.

That said, Rust gets us perhaps 90% of the benefits of pure functional programming with 10% of the cost in terms of incidential complexity.


Of course I'm being somewhat extreme and provocative with my "completely bonkers". However I think it's that 90% incidental complexity you refer to that validates it as a fair description of pure functional programming. And causes my wondering as to why anyone would ever want to do that.

Do you have an example of a case where Functional programming works very well? Something that fits on a page and is understandable by mortals?

No doubt I'm totally missing a point but as far as I can tell it is impossible to compute anything of interest with pure functional programming and immutable data.

My naive mind thinks of it like this:

I can count my sheep in the field by carving successive notches on a stick. Each notch is there forever. If I want to count a new sheep I need to carve a new notch. Anyone with only a partial view of the stick may only see the old notches, unchanged. Or they can see the notches on my old discarded sticks. That is immutable data.

Soon, my farm is so big, I have so many sheep, I run out of room on my stick for new notches, I run out of sticks to use. So I invent a number system that compresses huge counts into little space. I can't use my number system on a stick as I can't remove notches. So I invent the abacus. I now have mutable data.

Some time later the tax man comes by. He asks to see my tally sticks from last year. Oops, now I have a problem! I need records, databases, immutable data structures, extra book keeping work. Incidental complexity.

What am I missing in my shepherds tale?


Heard from a colleague, quoting a mailing list discussion:

After a few weeks of writing Rust and feeling like I was near tears of frustration, I returned to Python. But when I did start writing in Python again, I felt like a newly fit and healthy guy relapsing into old habits in an ugly way (e.g. eating a whole pizza each night and chasing it with a six pack and a bottle of liquor while watching star trek voyager on binge mode). The relapse felt both good and horrible at the same time.


If you show up and act like you're in, you're in.

  • Lokathor, explaining how to join the Gamedev Working Group

"In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data."

I dunno, I always thought of functional programming as a deranged COW disorder... :wink: