min-sized-rust VS dioxus

Who knows what they did, but there are things which can be done: https://github.com/johnthagen/min-sized-rust

> By default, Rust optimizes for execution speed, compilation speed, and ease of debugging rather than binary size, since for the vast majority of applications this is ideal. But for situations where a developer wants to optimize for binary size instead, Rust provides mechanisms to accomplish this.

https://github.com/johnthagen/min-sized-rust?tab=readme-ov-f...

You can get Rust binaries pretty small: https://github.com/johnthagen/min-sized-rust

But in practice it's more like there's an overhead for "hello world" but it's a fixed overhead. So it's really only a problem where you have lots of binaries, e.g. for coreutils. The solution there is a multi-call binary like Busybox that switches on argv[0].

C programs often seem small because you don't see the size of their dependencies directly, but they obviously still take up disk space. In some cases they can be shared but actually the amount of disk space this saves is not very big except for things like libc (which Rust dynamically links) and maybe big libraries like Qt, GTK, X11.

This is a good guide on building small Rust binaries: https://github.com/johnthagen/min-sized-rust

This talks about going to extreme lengths on making the smallest Rust binary possible, 400 bytes when it was written, https://darkcoding.net/software/a-very-small-rust-binary-ind...

The thing is, you lose a lot of nice features when you do this, like panic unwinding, debug symbols, stdlib… for kernel and some embedded development it’s definitely important, but for most use cases, does it matter?

Oh it was 137, haha. I will link you to this older comment of mine: https://news.ycombinator.com/item?id=29408906

See also https://github.com/johnthagen/min-sized-rust

Are you sure? If so then this is awesome news, but I'm a bit confused; the commit in that min-sized-rust repo adding `build-std` to the README was merged in August 2021: https://github.com/johnthagen/min-sized-rust/pull/30

Are you saying that at that point the feature still hadn't "landed in Rust nightly" until recently? If so then what's the difference between a feature just being available in Rust nightly, vs having "landed"?

Rust binaries are by default nowhere close to 500MB. If they are not small enough for you, you can try https://github.com/johnthagen/min-sized-rust. By avoiding the formatting machinery and using `panic_immediate_abort` you can get about the size of C binaries.

A useful reference: https://github.com/johnthagen/min-sized-rust

The framework is actively developed at dioxuslabs.com with 22,000+ GitHub stars and a growing ecosystem. The component model is stable enough for production use.

What's "rust scripting"? I don't see any mention of it in the docs nor dioxus native roadmap and AFAIK https://github.com/DioxusLabs/dioxus/tree/main/packages/inte... is used as the interpreter although I can't for the life of me figure out where the JS engine is actually instantiated.

Rewrite Muscurdi - Password Manager in Rust with iced, dioxus and/or tauri ❌ Did not any of those, but I have explored tauri and I am some ideas on some other sideprojects with it. I did a little todo-app in tauri and svelte with a little persistence layer and it is lovely.

> I don't see what advantage this gives

I believe it may "just" be faster link times. Which may seem minor, but link times can often dominate incremental compile times because it's a slow and (at least historically) serial step which is O(total code size) even if the actual compilation is incremental.

See mold's linking benchmarks: https://github.com/rui314/mold. It can be the difference between multiple 10s of seconds with traditional linkers vs <2s with newers ones.

There are few strategies for dealing with these days:

1. Is just to use a faster multi-threaded linker. On Linux, lld, mold, and wild on Linux are all much faster than the traditional ld/gold (and the latter two another step above lld). On macOS, then new built-in ld64 is pretty good. Not sure what the state is on Windows. Possibly lld is best?

2. Is dynamic linking as above. This seems to be faster even though the dynamic links need to resolved at runtime. I presume because at least the links wholly within the dynlib don't need to be resolved.

3. Is tools like Subsecond (https://github.com/DioxusLabs/dioxus/tree/main/packages/subs...) which effectively implement incremental linking by diffing the symbols in object files.

We do have a couple of PoC examples of integrating with the Bevy game engine. Both of these use Dioxus Native, which wraps Blitz with Dioxus (which is a React-like framework but in Rust rather than JavaScript - https://github.com/DioxusLabs/dioxus), but you could do DOM tree creation and event handling manually if you wanted to.

- This first one includes Bevy inside a window setup by Dioxus Native (using a `` element similar to how you might on the web). Here the event loop is controled by Dioxus Native and the Bevy game is rendered to a texture which is then included in Blitz's scene. https://github.com/DioxusLabs/dioxus/tree/main/examples/10-i...

- This second one does it the other way around and embeds a Dioxus Native document inside a window setup by Bevy. Here the event loop is controlled by Bevy and the Blitz document is rendered to a texture with which Bevy can then do whatever it likes (generally you might just render it on top of the games, but someone tried mapping it into 3d space https://github.com/rectalogic/bevy_blitz) https://github.com/DioxusLabs/dioxus/tree/main/examples/10-i...

The latter is probably what I would recommended for game UI.

Both approaches probably need more work (and Blitz could do with more complete event handling support) before I would consider them "production ready".

Also this might be especially useful in UIs built with Dioxus or Tauri, where changes are expected to trigger immediate reactions across the system.