moggers123

I go "oops I probably should have realised that existed before I decided to purchase the rights to and re-release a 999999 year old game which already has a GPL clone/spiritual successor/something".

I then go "well why re-release this ancient game running in an emulator, when this exists?" and ask the core team of OpenTTD if they want to monetize their steam/GOG releases now that I can licence out the TTD IP to them and remove any remaining legal ambiguity (and recoup my """investment""" via revenue sharing).

And if they don't I take it as a learning experience (to do my homework before I buy IPs) and release my TTD-in-an-emulator on steam and GOG knowing full well that its probably not going to generate many sales. Maybe I add "hey just so you know there's this really cool modern source port you can get for free..." to the description and hope that I can generate some sales off of good boy points.

What's the grug brain method of "live updating list with a search bar". I tried htmx sse but it turned out to be not that great. I was hoping I could model it as a single request/response cycle like a traditional page post, with the astericks that the single response is actually a stream of responses. Clicking search or whatever again "just" axes the old request and sends another one with the updated parameters. Perhaps the form being dirty would actually be what axes the stream.

>Back when I was writing xdg-desktop-portal-hyprland

Bahaha. I could have guessed. My only interaction with D-Bus as a layman is xdg-desktop-protocol. Is there just something about that particular use case that makes it so... Obnoxious? I presume all kinds of applications on my computer are right now busily d-bussing away without my notice, but getting xdg-desktop-protocol working with wlroots involved pentagrams and tomes bound in human skin.

I just don't really know where the ecosystem is going with async these days. I see a lot of changes in the language, many of which seem more complex than are typical for the justification, some of which have broader utility but generally wouldn't be done if it weren't for them being necessary for async... A hydra of complexity and honestly, where does it end? When will async be "solved"? What will the language look like when it is? Is it really all justified? Did we know that the road would be this long when we started it? For me, you could resolve this complexity by just letting me flip a switch and have things operate in a really basic blocking mode with no state machine or runtime and I'll sling this stuff on a thread if I have to, the way I used to. My use cases never needed this. I can get by just fine solving the circumstances I would need something like this with a purpose build mechanism, not a language native feature trying to solve all the different flavors of asynchronous problems I have + a million I don't.

of course... Its obviously not as simple as "just give me a way to turn it off", but more importantly, I just don't see this concern being addressed by the Powers That Be. Am I just not looking hard enough? Did I miss the rust blog post titled "hey - so you didn't want to use async but the libraries that you did want to use ship with async so you're up shit creek.. Here's what our plan for that is"?

I'm sorry. I generally lurk because I don't consider myself up to the caliber of others on this website, but nonetheless the few posts I make do end up being about async because it does make me feel quite hopeless at times. Hopefully someone can look passed my ignorance/incompetence/selfishness/immaturity and tell me its all going to be okay.

I doubt you'll ever see this.. Oh well..

I probably should have been explicit in that I'm not arguing in favor of CRDTs, just that the adverse doesn't need to be "send it and accept the collateral".

Draw The Rest Of The Owl energy here, but at least its a nice northern star.

>Example: two people starting to work on the same task in an offline-enabled task tracker. Wouldn't this just mean both people are working on it?

I agree that this means humans intervening.. It sounds like there was a comms breakdown. But rather than doing a first-in-best-dressed, it sounds like accurately recording that both users are in fact working on the same thing is the best option since it surfaces that intervention is required (or maybe its intentional, tools insisting that only one person can work on an item at once annoys me). Sounds much better than quietly blowing away one of the user's changes.

In principle, local-first to me means each instance (and the actions each user carries out on their instance) is sacrosanct. Server's job is to collate it, not decide what the Truth is (by first-in-best-dressed or otherwise).

SQLx is great, but I really wish they had a non-async interface. I had to switch a project from sqlx to rusqlite seemingly just due to the overhead of the async machinery. Saw a 20x latency reduction that I narrowed down to "probably async" (sort of hard to tell, I find it very difficult to do perf analysis of async code). I try to avoid discussing async so as to not come off as a frothing-at-the-mouth-chest-thumping-luddite but honestly, if sqlx had a non-async interface I'd be very happy to accept the "you don't need to use it" argument. its the only place where I don't feel like I really have a choice.