abendstolz

> I think the notion that you could control something (legitimately) smarter than you is a pretty risky proposition.

But then think about the CEOs and their employees again.

We just need to invent something like money for an "AI" and then we can lead in on a stick ;-)

But yours is human IQ, theirs is Artificial IQ.

It's like human to dog years ;-)

Don't rust shared libraries have the problem of no stable rust ABI? So you either use the C ABI or you use some crate to create a stable rust ABI, because otherwise a shared lib compiled with rust compiler 1.x.y on system a isn't guaranteed to work with the binary compiled on the same system with another compiler... or on another system with the same compiler version.

Right?

Sounds interesting but at the same time a bit complex.

I assume you wouldn't ship the whole plugin runtime for each plugin that wants to host another plugin?!

You're right. Hot reloading isn't done by default.

I manually compile a plugin and in my system I can "refresh" a plugin and even say "activate version 1.1 of the plugin" or "activate version 1.2" of the plugin etc.

But that's something I had to build myself and is not built into wasmtime itself.

                match Plugin::instantiate_async(&mut store, &component, &linker).await {
                    Ok(plugin) => {
                        match plugin
                            .plugin_guest_oncallback()
                            .call_ontimedcallback(&mut store, &callback_name)
                            .await
                        {
                            Ok(()) => debug!("Successfully called oncallback for {plugin_path:?}"),
                            Err(e) => warn!("Failed to call oncallback for {plugin_path:?}: {e}"),
                        }
                    }
                    Err(e) => {
                        error!("Failed to call oncallback for {plugin_path:?}!: {e}");
                    }
                }

See the "call_ontimedcallback"? It's not a string. The compiler ensures it exists on the Plugin type generated from the .wit file.

If of course I put a wasm file in the plugin folder that doesn't adhere to that definition, that wasm file isn't considered a plugin.

Very cool!

But I prefer the wasmtime webassembly component model approach these days.

Built a plugin system with that, which has one major upside in my book:

No stringly function invocation.

Instead of run_function("my-function-with-typo") I have a instantiated_plugin.my_function call, where I can be sure that if the plugin has been instantiated, it does have that function.

For binaries, I agree. For libs, I prefer semver

There is cargo install, yes :)

https://doc.rust-lang.org/cargo/commands/cargo-install.html

Thanks for correcting my error.

I've never checked core before, so I did when checking up for this discussion.

I somehow missed Result. Silly me didn't search on that page, but ofc I found it on std

https://doc.rust-lang.org/std/result/index.html

Also thanks for clarifying that values of Result can be stack-only!

Thanks for the thorough explanation!

Mhm, thanks.

It never occurred to me (being in non-embedded land) that returning an enum as the error or a &'static str instead of a heap structure like String, could also fail.

Seeing that Result isn't part of core, but of std, this makes sense.

Just to tickle my nerve though: theoretically speaking, with your example, it would work, right?

I couldn't allocate 100GB (because OOM or not even enough RAM to begin with) but it could be that the system can allocate the needed memory for error message just fine.

Very interesting.

Oh, wow, I was under the impression that the error message would be stack only, no heap involved, but as Result is part of the std library and not of core, this totally makes sense.

So for `Rust for Linux` they also need to implement a `Result-like` type that is stack only based to solve this issue, right?

If so, cool, thanks, you just made my day by tickling my learning nerves! :)

Can you elaborate as to why "his isn't how you'd do things in userspace, but, this isn't userspace so fine" holds?

Naive me - not a kernel dev at all - would argue that returning Result<Memory, AllocationError> is always better, even for userspace because it would allow me to additionally log something or gracefully deal with this.

Even if I don't want to deal with it, I could just `.unwrap()` or `.expect('my error message')` it.

Note: I am not trying to be snarky here, I genuinely don't know and would like to.

If answering this is too complex, maybe you can point me in the right direction so I can ask the right questions to find answers myself? Thanks in any case!

Just in case you don't know about it: https://redox-os.org/ could be interesting to you :)

Yes, it was/is for only the duration of the summer (school) break.

Has some very weird constraints regarding borders when combining with the eurorail/interrail though.

You may be interested in https://github.com/joaoh82/rust_sqlite

Ah, the good ol' KISS - complexity kills.

But not Down Under scnr