• 1 Post
  • 12 Comments
Joined 1 year ago
cake
Cake day: August 10th, 2023

help-circle



  • Sure, but my point was that such a C ABI is a pain. There are some crates that help:

    • Rust-C++: cxx and autocxx
    • Rust-Rust: stabby or abi_stable

    But without those and just plain bindgen it is a pain to transfer any types that can’t easily just be repr(C), and there are quite a few such types. Enums with data for example. Or anything using the built in collections (HashMap, etc) or any other complex type you don’t have direct control over yourself.

    So my point still stands. FFI with just bindgen/cbindgen is a pain, and lack of stable ABI means you need to use FFI between rust and rust (when loading dynamically).

    In fact FFI is a pain in most languages (apart from C itself where it is business as usual… oh wait that is the same as pain, never mind) since you are limited to the lowest common denominator for types except in a few specific cases.


  • Yes, rust is that much of a pain in this case, since you can only safely pass plain C compatible types across the plugin boundary.

    One reason is that rust doesn’t have stable layouts of structs and enums, the compiler is free to optimise the to avoid padding by reordering, decide which parts to use as niches for Options etc. And yes, that changes every now and then as the devs come up with new optimisations. I think it changes most recently last summer.


  • So there is a couple of options for plugins in Rust (and I haven’t tried any of them, yet):

    • Wasm, supposedly https://extism.org/ makes this less painful.
    • libloading + C ABI
    • One of the two stable ABI crates (stabby or abi_stable) + libloading
    • If you want to build them into your code base but not have to update a central list there is linkme and inventory.
    • An embedded scripting language might also be a (very different) option. Something like mlua, rhai or rune.

    I don’t know if any of these suit your needs, but at least you now have some things to investigate further.





  • The drama sucks, agreed. But crates.io is lightyears behind in design, search and features.

    For example: Lib.rs has the first thing I want to know (when was the last release, is this still developed?) right at the top. For crates.io that is hidden near the bottom, especially on mobile.

    Also: Lib.rs has search that actually works and finds relevant things, I cannot say that for crates.io.

    I would love for crates.io to take (some) inspiration from lib.rs.

    Finally: I share the lib.rs author’s opinion on cryptocurrency, though I don’t agree with his extreme measures. (If it was me I would put a note in neutral tone that crypto is problematic for the environment on the relevant categories and crates, with some links to more into, then leave it at that.) So using lib.rs despite the drama doesn’t bother me that much.




  • Be sure to treat state and configuration separately. It doesn’t matter on Windows as far as I know (they go in the same location), but on Linux those are supposed to go in different places.

    Many programs get this wrong, and it is quite annoying as I track my config files in git. I don’t want a diff just because the list of recently opened files changed! Or even worse: the program stores the last window size and position in the config file… (looking at you KDE!)

    Here are some libraries I found to help with this in a cross platform way:

    I haven’t tried either, haven’t written such a program yet.

    As for how to store data, there are indeed many options, depending on your needs:

    • Plain text based formats (toml, yaml, JSON, ini, …) can be good for configs and basic state. As a bonus it let’s the user easily manage the file in version control if they are so inclined.
    • Databases (SQLite mostly)
    • Custom formats (binary files in a directory structure is often used for browser caches for example) .

    Without knowing more it is hard to give specific advise.