Interning works by ensuring that there’s only one canonical copy of each distinct string in memory.

CGP makes use of Rust's trait system to define generic component interfaces that decouple code that consumes an interface from code that implements an interface. This is done by having provider traits that are used for implementing a component interface, in addition to consumer traits which are used for consuming a component interface.

libSQL is a portability in WASM of SQLite.

The Turso project experiment a rewrite of SQLite in Rust with some technical implementation in mind:

Limbo is a research project to build a SQLite compatible in-process database in Rust with native async support. The libSQL project, on the other hand, is an open source, open contribution fork of SQLite, with focus on production features such as replication, backups, encryption, and so on. There is no hard dependency between the two projects. Of course, if Limbo becomes widely successful, we might consider merging with libSQL, but that is something that will be decided in the future.

Either all fields are public or all fields are private.

Pain in C++

• tools and compiler/platform differences
• ergonomics and (thread) safety
• community

Why Rust?

• fun & cool: better for a hobby project. It is a need.
• Great tooling
• Options are easier to use than C++'s pointers
• use system over #include
• simpler dependency management
• killer feature is Send and Sync, statically enforcing rules around threading.

Ship of Theseus strategy for the rewrite: component by component. The fish app should work exactly the same.

So if you are trying to draw any conclusions from this, consider the context: A group of people working on a thing in their free time, diverting some effort to work on something else, and deciding that after the work is finished it actually isn’t.

Gripes with Rust

• portability between OS: it allows to miss systems and ignoring version differences
• string translation and localization: format! are checked at compile-time
• building to other targets: "it is often better to use if cfg!(...) instead of #[cfg(...)] because code behind the latter is eliminated very early, so it may be entirely wrong and only shows up when building on the affected system.

They also report mistakes they made.

There are good with quick-wins of the port to Rust. There is also some sad ones: CMake is not removed yet. Cargo is missing some features to install third dependencies (.fish scripts, 130 pages of documentation, the web-config tool and the man page generator).
Cygwin is not a supported platform.

Different thoughts about how we handle faillible and infaillible functions

Similarly as in functional programming where functions and closures are „just values“, here results are „just values“. This opens up some new possibilities.

So how to handle infallible functions that returns an expected error (Can not divide by 0) and infaillible functions (that execute 1 + 2): there is no way to distinguish them with Result only... Or maybe Result<Result<T, InfallibleError> FallibleError>

Conclusion:

Honestly, I don’t know if there’s any. I just hope to illustrate some reasons why I personally don’t like the Ok-wrapping in as analytical way as possible. I hope we can at least learn to agree to disagree on this point and respect that each one has their reasons for the preferences.

A curated list of articles or blog posts

The part "Why not use Rust?" is interesting

The post is full of links related to the ecosystem

How fast can we recognize a word from a small pre-determined set?

Every program has dependency, even C builds.

The real thing with toools like go, cargo and npm is they move that library management out of the distro’s domain and into the programmer’s.

Un retour d'expérience sur la réécriture d'un projet de Java en Rust. Les mesures montrent de meilleures performances partout, et une difficulté supplémentaire par rapport à l'écriture du code en Java.

About the hyper backend of curl in Rust

Build a CLI for it (or a web UI)