Actually, it'll probably be easier to do it on paper, and this is exactly why I chose Rust. I shudder to think what this would be like if I was also dealing with segfaults emerging from incorrect in-process memory management alongside the panics, errors and leaks emerging from incorrect interprocess resource dependency tracking.

God damn it, I need to write a fucking log aggregator script to figure out where the refcount math is going wrong. I didn't choose Rust for this.

@12bitfloat A very very very important Drop callback is not being called

I gave up on this particular refactoring angle because I noticed a much faster way to solve the immediate problem I was having, but I do actually want to return to it and figure out how much of a performance impact it has, because it would be really neat to speed up compilation and also to be able to separate out the client's and server's distinct implementations of certain shared concerns while retaining the shared interface.

Ideally, a debug build should be massively parallel, almost file-by-file, with no type's structure depending on the fields of any other, and a release build should be fully static, with virtual calls exclusive to heterogenous containers (of which at runtime there are like 3 in the whole system). I know C++ could do this, but Rust doesn't provide as much type information to LLVM so it benefits significantly less from these high level optimizations specifically.

@jestdotty MPSC queues are a big help.

The other side of this coin is that my barrier for something that's too complex to be serviced by a shell script is quite low. If you need xargs, you're probably past it. If you (semantically) need a conditional inside xargs, you're _definitely_ past it. If you need to edit it often, if more than one person needs to edit it, if it stores anything more than plain-value tables (either nested structure or references across tables), if it might be used by people who can't read it, or otherwise requires error handling besides basic argument validation.

The only use case on which Rust and shell scripts overlap is build automation. I love my xtask binary because it's exactly as portable as the project itself; every target is a dev target. But the same applies for any other language; your language has to have supremely shitty abstraction capabilities for it to be a bad idea to use it for build automation.

@antigermanist My testicles are the ideal size for riding the village bicycle that is your mum

Also, check your size. I'm no expert but I have three guesses, either your seat is pitched wrong causing you to slide off, or the frame is too big causing you to stretch too far forward to reach the handlebar. It took me visiting the bike shop at closing time for the repair man to see me get on the bike and point out that the piece securing the handlebar to the steering column is too long and I would be a lot more comfortable if I replaced it with a shorter or possibly an inverted one, which is far cheaper than a new smaller frame.

You're literally busting your balls to prove your masculinity when you can just ride a "women's" bike. I ride a men's because I think the straight simple truss structure is pretty. Is that a masculine reason? Do I give a fuck?

@12bitfloat well, for one, you aren't obligated to directly await the Send future, you can put it inside a higher structure like a join or a select. High performance async code does this a lot, they do as much stuff synchronously as they possibly can and parallelize the rest aggressively. This leads to really weird incentives where you don't actually want to use async closures because you would miss the opportunity to execute synchronous code before returning the future that ultimately gets nested into a weird user-side scheduling primitive tree.

Nonetheless, both language design and convention dictates that you follow thee terminology of the physical stack and only mention details like this after the simpler concepts have been established.

Your enemy can also shoot 3 bullets a minute. Your primary concern is to find a good vantage point without becoming an obviously better target than everyone else, because you can only realistically survive so many times 3 bullets a minute. Realistically, you will die of dysentery, a mugging, or STDs within 5 years of service.

@SoldierOfCode I was talking about the connection between the RP and the app server. With HTTP/2, you could use H2C on the backend and have full support for all the cool features like server push without paying the performance cost of encryption. With HTTP/3, you either encrypt that backend connection, or use H2C on the backend and miss out on all the even cooler new features, because there isn't an unencrypted but otherwise equivalent protocol like H2C for HTTP/2 that open-source web frameworks and reverse proxies can implement.

@whimsical I looked up what a shetland pony is, they look like pretty solid generalists (also pretty sane proportions for a pony). What's wrong with them?

@whimsical It will require changes for the new version, but hopefully not fundamental ones. The biggest change is that the new systems are async and async Rust is like a whole separate language.

Especially since most of it is written as libraries so about 80% of the functions are public.

The argument for that clause by the way was that GMO crops may escape into the wild to unforeseeable effect. I wonder if that was ever a legitimate concern or just part of their PR campaign to justify the transparently extortionate license.

Actually, the Veritasium video improved my view on Monsanto somewhat, because I somehow thought their crops were infertile / physically unable to be replanted, whereas apparently it's just illegal to replant them and they will sue you into poverty if you do so, and they only use GMO to outcompete natural crops.

I'm so glad this stuff is finally breaking into the mainstream, I was worried I'd be lumped forever with the conspiracy nuts in casual conversation for believing this and Teflon.

@BordedDev yeah, and I'm wondering why that would seem like a good idea when it's redundant for some contexts. Reverse proxies benefit from feature parity between the downstream and upstream protocol, which is why H2C is used.

I mean, HTTP2 "requires" TLS, but it's a separate layer so H2C is a strong standard with a very obvious definition. QUIC doesn't really work without TLS, so I'm not sure how an unencrypted version would even work, or whether anyone will support it.

This is so cool, I almost forgot about Strudel

@Lensflare I guess there's node-gyp but it's so terrible to work with from the C angle that I'm convinced the intended extension mechanism is just to write all the libraries directly in JS on top of Node's networking and disk IO.

@Lensflare JS isn't really glue though, before WASM it was impossible to call out to other languages from it, and even with WASM the targets must be designed with the limitations of WASM in mind. I call Python glue because it's usually used to call out to C libraries that weren't written with Python in mind at all.

@Lensflare It's glue, It should have the simplest options for everything. The only argument I can see in favour of concurrency is that C# has blocking and green threads rather than async, and if you don't care at all about efficiency, this saves you from function coloring.

For dev stuff: Kevin Fang, LaurieWired, Developer Voices, CppCon, Sebastian Lague, and a few that upload even less frequently than these.

@12bitfloat I'm not sure why the narrative is that it's a dev version, but I'm like 95% sure that the current feature set is permanent and will only ever be deprecated, not removed, as is usually the case with stable web APIs. The solution for bindings seems to be mostly to write very specific JS glue distributed alongside compilers like Emscripten that the browser can trace compile. Cooperative GC is an unbelievably hard problem, and switching between WASM and arbitrary (uncompiled or dynamically typed) JS is pretty slow, so I don't expect we'll get many features to encourage using them together.

@BordedDev That's odd, I could've sworn that Rust's wasm support uses a virtual stack to allow "blocking" the "invoking thread" which all looks like regular async work from the JS side. I mean, Rust at least actually has a type of async support that makes no assumptions about the executor so you can use that. But still, it surprises me that the general solution isn't to lift all work into promises while we're already on a compilation boundary where anything goes.

@BordedDev what has cors got to do with the parallelization of client-side programs?

@whimsical I look forward the most to the end of Javascript's hegemony and opening the floor to languages with better static analysis and opportunistic parallelization potential, although that may be a bit ambitious. Otherwise, I hope it can become a democratic distribution method for indie games. Since payment providers like Stripe aren't too difficult, the biggest argument in favour of Steam for many devs is actually player convenience.