Native libraries are hard in Rust; the compiler offers no guarantees about the memory representation of structs; or these structs needs to be FFI-Friendly with unsafe extern "C". There is no sandboxing, so a malicious code could promise the machine; or corrupt the memory silently.
Finally, dynamic library plugins are distributed as compiled code.It's easier to hide backdoors in compiled code. It's also harder to share the code than simple scripts.

There are two main ways to embed JavaScript in a Rust program. The first one is with bindings for the lightweight QuickJS engine, such as rquickjs. Take a look at AWS' LLRT (Low Latency Runtime) for an advanced integration of QuickJS in Rust.

Ho, and did I mention that QuickJS is lightweight? Around 210 KiB of code vs around 40 MiB of code for V8, all while being fast enough for most situations.

My vision of programming is to limit ourselves to two programming languages. A very powerful, secure and fast compiled language for the lower levels of the computing stack, Rust, and a less powerful and slower scripting language for high-level scripting and user interfaces, JavaScript.

Another alternative is WASM. The provided code is already compiled; and the author judges the ecosystem too immature.

The last method is the less powerful: expression engine. It allows to specify a language with some rules, even if it is not turing complete and the result always evaluate to an expression.

So to rank them:

• scripting language
• expression engine
• WASM
• at the end native libraries

I agree: if we want to build complex products, we have to hide implementation details. It means for example at some level, the type or structure should abstract an empty value for me: 0, null, undefined, false, NULL, etc...

I have the same idea for a node js backend serving a fancy UI :)

It would be better to split the UI and the server while developing to benefit from hot reloading.

Example: https://git.sr.ht/~pyrossh/rust-embed/tree/master/item/examples/axum-spa/main.rs

How We Structure It – No Guesswork Needed:

• One frontend framework (Astro) for performance and design flexibility
• One headless CMS (DatoCMS) structured for multi-brand, multi-region content
• One hosting platform (Vercel) that scales automatically
• One monorepo for all brands and sites
• One dev team managing the whole thing

However, there’s already something that I’ve singled out to use with my own and my teams’ work—to aim for 80% utilization.

Simple rules to handle load

A model

(via https://nicolas-delsaux.hd.free.fr/Shaarli/shaare/1L8NcQ)

Hydro is a high-level distributed programming framework for Rust. Hydro can help you quickly write scalable distributed services that are correct by construction. Much like Rust helps with memory safety, Hydro helps with distributed safety.

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.

Either all fields are public or all fields are private.

A dependency in software can be summarized to a checksum, a location, a name and a version.

The checksum checks the integrity, the location defines how to retrieve the dependency, the name identify the dependency and the version its substitutability (major with breaking changes, minor if it has new features or bug fixes).

A summary of comments about maintaining projects over decades

About documentation:

This does not tell you however WHY things are like this. What is the idea behind how the system works? Is there a philosophy? Is there a specific reason why we do these non-obvious things? Why is the solution split up the way it is?

code definitely needs comments. Especially why a function is like that. Other feedback was to work on commit messages

In js, asserts can be used with console.assert(<condition as expression>, error message)

It is great for prototyping or use defensive programming inside a function.

Assertions often come in pairs.
Whenever you assert something, think about which distant part of the code base relies on the assertion you just wrote, and add an equivalent assertion there.
This is worth doing even in the trivial case, where the two parties are a function and its caller.
But be on lookout for more interesting cases, where the two halves of an assertion pair are separated by different implementations, or a process and time boundary.

Great advices

It is much easier to add features to reliable software, than it is to add reliability to featureful software.

Besides, it’s very easy to accidentally think you need features that you don’t actually need.

Write serialized test scenarios

How to cache? It depends of the context: push vs pull and owned vs user.

Push means that the asset is pushed to a central server and then distributed.
Pull means the asset is referenced and the central server has to “pull” the content.
Owned means it’s owned by the central server.
User means it’s user-submitted content.

Push + owned

Make everything push + owned content if possible. "It turns out, however, that you can make a shit ton of other stuff push + owned if you try a little harder. "

How does the client check if they're expired?
Use “stale while re-validate”. Ur welc’

In summary:

• store asset
• use stale-while-re-validate access patterns
• should work offline

Push + User & Pull + Owned

Handle these with hash URLs. Hash the URL and treat it immutably.
Push + User: Forum comment -> hash URL
Pull + Owned: "in-content" assets. That’s where it’s user generated content, but not owned by the server.

Summary:

• Load asset
• Use infinite TTL + hashed URLs
• Should not re-fetch across page/app reloads

Pull + User

That’s where it’s user generated content, but not owned by the server. Posting gifs into the chat is a prime example; linking a blog post and generating a media upload for that is another.

Guess what: this pattern fits for highly dynamic user-generated content, which means it’s the content users link to each other in-platform.

Stable URL, short TTL. YES, SHORT TTL. [...] Debounce + throttle? Sure. Micro-TTL? Yes. Cache? Never.

Shift is_active to something more generic: a status field, so we can expand it down the line for other parts of the state space.

Honestly, 80% of the time in these meetings I just tell people to either use an enum instead of a boolean or to make it more clear which data is events and which is state. I'm always right, it's always useful, and there's never that much fuss about it.

How to build the local-first software with the most interoperable data system: files.
How to avoid conflict while syncing them on cloud providers? Tonsky relates some strategy.

About OOP.
Notice a faisable comparison with the current AI