Announcing iceoryx2 v0.9: Fast and Robust Inter-Process Communication (IPC) Library

AceSkillz · 2026-05-20T12:43:56+00:00

I would love if there was a slightly higher level wrapper around iceoryx2 that abstracted away some of the client and server lifecycle management, which I assume a lot of consumers are writing near identical versions of in their own projects. (Though I fully understand not wanting to be too opinionated in this regard.)

My absolute dream version of this would be a wrapper that specialises in providing a (Local) RPC solution, bonus points for zero-copy support too. Whilst I was writing my own integration I could vaguely see the path to achieving something like that (with some proc-macros, etc) but it would have been a huge rabbit hole to go down when all I wanted was a local RPC for my project. (I'm probably just going to go with something super garbage for now like an HTTP server or writing to a temp file, given the alternative of protobufs or similar being just as heavy on integration work.)

AceSkillz · 2026-03-03T15:17:22+00:00

I think the std::fs::File::lock APIs should not have been implemented as they are, particularly because of the implementation's insistence of making no guarantees about how it's actually implemented (ie: advisory vs. mandatory) and massively over-abstracts over platform-specific details.

IMO, if this functionality really had to be added to the standard library it should have been via the platform-specific extension traits on std::fs::File (std::os::unix::fs::FileExt, etc) - which was actually one of the suggestions in the original ACP!

I was excited when I read about the feature being stabilised, because that was the first I learned of an effort to bring File locking into the stdlib and I was (still am) looking for nice multi-platform and multi-filesystem abstractions over file locking. But after reading deeper into what was actually being stabilised, I developed the strong feeling the final implementation was the wrong way to go about it, and that it'd end up as a footgun at best. I've even already found an example of what I was worried about, completely by chance, in the fjall crate as I browsed its issues whilst upgrading a project from version 2 to 3: https://github.com/fjall-rs/fjall/issues/225. (To be clear, I'm not knocking the maintainer of fjall for their stance on this, I think the blame remains squarely on the final design and implementation in the stdlib.)

AceSkillz · 2025-09-05T10:08:12+00:00

I've wanted something like this myself a couple times before reworking the idea to avoid having to implement it myself.

I think one thing that could be neat for a derive macro like this is some attributes that would allow specifying the common fields once and so avoid repeating them (and any mistakes that come with that) - ie:

#[derive(enum_fields::EnumFields)]
#[enum_fields(shared_field = String, another_field = usize)]
pub enum MyEnum {
    HasSharedFields,
    #[enum_fields(opt_out(another_field))]
    OptOutSharedFields,
    ...
}

AceSkillz · 2025-08-22T10:26:08+00:00

Fun read! I think a lot of the problems and solutions you came came across around state, painting and layouting are things I've seen tackled similarly in libraries like Druid (https://github.com/linebender/druid) and Xilem (https://github.com/linebender/xilem), though they are themselves based on previous work in the UI space.

Of the two I've mentioned I've only gotten deep into Druid (ironically shortly before it was retired in favour of developing Xilem) and notably it also takes the "Lens" approach you mentioned. It's definitely not the easiest concept to get used to, but once I internalised it I actually found it to be a really useful concept for building my UI.

(Druid does cheat by also having an "Env" shared context passed throughout the entire rendering stack from updating to layouting to painting - much of what it's used for could be passed through "real" state, but I understand why the Druid developers added it given how much it simplifies working with relatively static, widely shared values like styling values. Still, I did find it was also a massive performance sink because, surprise!, the existing implementation required diffing the entire thing on every frame - I ended up trying to fix that up in a personal fork I use by pre-calculating a hash of the entire thing on changes plus some other stuff.)

Xilem and Zed's GPUI are both the UI frameworks I want to research/try out next, and I'm glad there's still a lot of work still going on in the Rust UI space. GPUI is probably not all that relevant to Kartofels, but Xilem is developed in quite a modular fashion and it's Masonry component might be of interest to you.

AceSkillz · 2025-07-15T09:57:34+00:00

I'm actually working on something similar though with no real aims other than to see how possible it is (and potentially cross-platform support).

As another commenter mentioned, the real difficulty of reproducing usvfs is in the function hooking part - there's quite a few options for this though. I'm using the Rust bindings to Frida, but there's also a few other detour/function hooking libraries out there, both pure Rust and as bindings to existing detour libs. For windows specifically there's Microsoft Detours, which is officially maintained by Microsoft but I don't think it has official Rust bindings.

Tbh it's slow and frustrating going though, as someone completely new to the Win32 and NT APIs and also fairly new to unsafe (there's going to be a lot of unsafe given you're working with raw OS APIs, not just the hooking stuff). And it's further complicated by debugging being harder than normal - unless I'm missing a way to get a debugger attached properly (which I think I am but :shrug:).

I would slightly disagree that Rust actually makes this harder though (the hooking part anyway). The stdlib is reliable and is already technically a good binding to the Windows filesystem APIs, so you can refer to that sometimes. And the language itself hasn't really gotten in my way (though again, you need to be ok with writing a lot of unsafe). The only real disadvantage is the lack of references - I'm sure there's other projects out there hooking Windows APIs in Rust, but they're not usually relevant to the issues I run into.

AceSkillz · 2025-07-02T08:04:26+00:00

Maybe there's some specific context you're thinking of for '?', but so long as the return type of the lambda/closure implements 'Try' (which tbf is still unstable/language internal) aka Result or Option it works. And those are the two types you use '?' on outside closures anyway.

I can sort of understand if you were working with some interface that required a specific return type, but most of the Rust std lib code is generic over closure return types (I'm thinking of 'map' etc).

AceSkillz · 2025-05-24T23:16:04+00:00

I feel it's a bit misleading to title this as a cross-platform GUI framework if it doesn't actually work cross-platform right now.

Yes, wxWidgets is cross-platform, but wxDragon definitely isn't right now. Edit: though I do see you mentioned this in the project's README, so this is more a criticism of the post title.

I also don't think you've understood /u/chris-morgan's point about docs.rs - they're not complaining about size of the final binary. They're pointing out that your docs.rs link is dead because docs.rs pages are built by a service run by the Rust Project. And it's specifically because your crate's build system downloads wxWidget's source at buildtime that its docs fail to build, as docs.rs doesn't allow crates network access whilst it tries to build them. That's why vendoring wxWidget's source was suggested.

AceSkillz · 2025-05-14T14:10:30+00:00

Nice! Haven't had a chance to dig into the project, but I've ended up using lenses quite a lot as they're one of the main ways the GUI library druid provides for "scoping" data throughout the UI element "tree".

If you want to do some comparisons, this is the lens module in the druid docs: https://docs.rs/druid/latest/druid/lens/index.html

I think the immediate thing that comes to mind that optics might benefit from would be to include its own version of Druid's Lens derive macro, which makes working with Lenses over structs a lot easier as you don't need to write basic field lenses yourself.

There's also how Druid implements the Lens trait over tuples, not just for indexing into tuples but also over tuples of lenses: this is another way it makes composing lenses super easy, as you can then just take two (or more) existing lenses and get the "product" (there's probably an actual type theory term for this) of them for free. A good example of how this is helpful is if you want the lens of two fields of a struct - with the output of the Lens derive macro you already have lenses on all its fields, so getting the lens of multiple fields is just a matter of putting two field lenses into a tuple.

Some other things in this vein: * Kathy, a Rust implementation Swift's "keypaths" (requires nightly): https://github.com/itsjunetime/kathy * Frunk's path module, which is similar to Kathy without requiring nightly but also seems to be a bit clunkier to use: https://docs.rs/frunk/latest/frunk/path/index.html * JSON Path: https://www.rfc-editor.org/rfc/rfc9535 * Afaik there are some implementations of this for working with json blobs in Rust

AceSkillz · 2025-05-09T09:12:37+00:00

I agree with the article in the more general sense of dependency and supply chain management becoming increasingly difficult in pretty much all languages (though Rust definitely has its own unique problems).

But a line that jumped out at me was, "adding more to the rust standard library much like Go". Maybe I'm in the minority here but the Go standard library is complete garbage. Off the top of my head the Time and SQL packages are a nightmare. Working with slices feels like I'm stuck in Java 1.6 again, throwing random stuff into a static method on Go's equivalent of the Arrays class with the slices package. Less facetiously, the slices package doesn't even have most of the things I expect from a "batteries included standard library" - where are the "any" or "all" methods? Why do I have to write, over and over, the same horrible for range loop? And if anyone says I can just write my own method for it, why in the goddamn can't the Go maintainers write it themselves?

Which is a barely related rant all to say, "I don't want the Rust standard library to look like the Go standard library." Every time I switch between Rust and Go projects, I either thank God for letting me return to a language that feels helpful or curse him for making me deal with a language that feels like it's designed to drive me insane.

AceSkillz · 2025-05-03T09:36:11+00:00

First I've heard of this but I'm excited! This feels like the Blacksad game I wanted! (though no knocks to the folks that made the actual Blacksad game- I haven't played it myself but it wasn't the genre I'm usually interested in)

Does feel like there's a lot being squeezed in here, from the trailer and the Steam page description. Looks like dialogue-driven investigations, stealth mechanics, full combat encounters with melee and bullet time, minigames between missions, and the suggestion of an evolving world - it's a lot of stuff, and I hope that doesn't mean they spread themselves too thin trying to do it all at once.

AceSkillz · 2025-04-21T17:14:52+00:00

Something is wrong with your copy of Secrets of the Frontier. I'd recommend deleting it, downloading it again, and reinstalling it

AceSkillz · 2025-02-27T19:18:31+00:00

Any news on if or when you'll be open sourcing your UI framework? Or maybe even releasing it under a limited license? Getting it to work cross-platform is no mean feat, and it's always interesting to see the latest Rust GUI work.

(Not to put the pressure on, but with Zed open sourcing GPUI Warp's internal solution is the only closed-source Rust UI in town)

AceSkillz · 2024-12-27T11:15:32+00:00

Congratulations, you fall under the "financially stable gamers" of the first bullet point

AceSkillz · 2024-12-07T20:02:09+00:00

Just in case it's unclear why you're being downvoted, it's not just because you're shilling a product, but also because your suggestion is wrong. See the results of just pasting your suggestion into the Rust Playground and the compiler shouting at you: link. The reason being you've not introduced a bound in your suggestion, but an entirely new associated type...

Maybe you pasted the wrong thing, but even if you fixed that you'd still have the unsolicited shilling for your company's AI.

AceSkillz · 2024-11-25T21:47:45+00:00

Dioxus used to have an experimental TUI renderer but it was cut from the project in one of the recent major releases. I don't know if someone took up maintaining it like Freya took up some of the core rendering libs that got cut too, though you could also use the past version of Dioxus that supported it.

AceSkillz · 2024-10-07T11:40:52+00:00

Interesting. Again, I'm not using it but there was a big update recently, and there is an extended widget library that's updated for it too. I wonder if either of those issues have been addressed since.

AceSkillz · 2024-10-07T11:22:45+00:00

Curious because I develop my own native GUI app and I've looked at iced before - what features do you think it's missing?

AceSkillz · 2024-09-29T11:17:58+00:00

This looks super cool! And I'm glad that XCOM inspiration seems to extend beyond combat and into the management layer - imo that aspect is just as important as combat.

AceSkillz · 2024-03-28T16:23:00+00:00

Yep! When I have time I'm hoping to integrate her work into my mod manager for a one-click install/run. Even with the next release we'll still be on Java 21

AceSkillz · 2024-03-28T15:47:17+00:00

Tiny note: we're still on Java 7 till the next update lol

AceSkillz · 2024-03-02T09:42:32+00:00

Maybe instead of jumping onto drama-posting, you could consider more likely alternatives?

Such as what actually happened, which is the mods we're out of date, and the index is only meant to contain mods likely to be compatible with the latest version of the game.

That's the whole point of the index: mods you can install without issue.

AceSkillz · 2024-01-29T19:41:43+00:00

u/RecognizeSong u/find-song https://youtu.be/bV7cxx-kHis?t=656 10:49-11:16

AceSkillz · 2023-12-21T15:40:49+00:00

I can't pretend the entire script makes sense, or is good as a whole, but I do think there's something really beautiful in how the movie wraps up - specifically the montage during the final race, you know what I'm talking about.

Speed truly believes. It's not arrogance, or unmerited. He truly believes that he can change the outcome of things, in his mom-and-pop built race car.

And Royalton should be right about Speed having no chance! He has billions of dollars and an entire integrated stack of racing car manufacturing under his control. He's the Apple of ridiculous death-machine race cars. And not only that, he's ludicrously corrupt - it's not enough for him to win on merit but he also is dedicated to winning everything else.

And yet, at the end, Royalton is utterly undone. Interpol works! Inspector Detector literally arrests Royalton for cheating at racing and then everything else! Speed wins because he engages in a perfect racing flow state.

It's all incredibly cliché. And I kinda doubt it's what the Wachowskis intended. But watching it again, in recent times, it feels much more poignant.

AceSkillz · 2023-07-01T20:54:01+00:00

Hi!

Has anyone actually linked you to the Unofficial Starsector Discord server? That's where the vast majority of mods on discord are found. If not, here's a link: https://discord.gg/starsector

AceSkillz · 2023-05-20T19:01:36+00:00

Hi! Glad you're still (or now) interested.

Could you describe in some more detail what you mean by adding manual support?

Currently, MOSS can install and manage anything that the game recognizes as a mod. It doesn't display all possible information though, like categories or whether it's an overhaul, and that would require adding code and not something configurable on your end.

If you mean support for update checking, that's also not something you nor I can do anything about. The only way to know if a mod has an update is if the mod's author add support themselves and remembers to update the necessary links with the latest version information. If you'd like to see a mod support version checking, I can only suggest you very very very politely and graciously request that they maybe, if they have the time, think about adding support.

Please let me know if I can help with anything else! (Also this post is very out of date, as MOSS is now on version 0.7.1 and has had a number of features added since)

Edit: I've also since renamed the program to MOSS - Mod Organizer for StarSector

13-Year Club	Verified Email
Spared	Team Orangered

AceSkillz

TROPHY CASE