I won't pretend its perfect, but it can be a fun team-building exercise and provide common language for discussing differences.

We are working on a stealth startup which will use AI to analyze e.g. Slack messages and build out results of personality tests using methods like MBTI, so that e.g. when reaching out to someone in your workplace, you can get view a personalized overview of how to interact with that person, their behavior, how they might prefer you communicate with them, etc. Email in my bio for anyone interested, we're looking for early adopters.

..an image decoding library.

..an audio input/output library.

..a multi-channel audio mixer.

..ttf and rtf font rendering.

..networking.

..runtime shader cross-compilation

..its own entire graphics abstraction layer / API.

..its own shader language, shader compiler, and shader bytecode format.

I don't know at which point something becomes 'high level', but SDL is only 'minimal' if you use a subset of its functionality.

[0] https://github.com/gpuweb/gpuweb/issues/4266

But even more, the level at which WebGPU exists (not too high level, not too low level) necessitates that if a native API graphics abstraction sticks with the WebGPU's API design and only 'extends' it, you actually end up with three totally different ways to use the API:

* The one with your native 'extensions' -> your app will only run natively and never in the browser unless you implement two different WebGPU rendering backends. Also won't run on Chromebook-type devices that only have GLES-era hardware.

* The WebGPU browser API -> your app will run in the browser, but not on GLES-era hardware. Perish in the verbosity of not having bindless support.

* The new 'compatability' mode in WebGPU -> your app runs everywhere, but perish in the verbosity of not having bindless, suffer without reversed-z buffers because the underlying API doesn't support it.

And if you want your app to run in all three as best as possible, you need to write three different webgpu backends for your app, effectively, as if they are different APIs and shading languages.

I've seen ~100 line HTTP handler methods that are implemented using generics and then a bunch of type-specific parameters inevitably get added when the codepaths start to diverge and now you've got a giant spaghetti ball of generics to untangle, for what was originally just trying to deduplicate a few hundred lines of code.

When I navigate to various websites that support Passkeys these days - Lowes, Home Depot, and handfuls of others - on iPhone (firefox) I am prompted with 'Do you want to use Face ID to sign in?'

If I do the same on macOS (firefox or safari, I'm sure Chrome does it too.), I am similarly prompted 'Do you want to sign in using a passkey?' and it gives me steps to use my mac's fingerprint reader or delegate to the iPhone Face ID to sign in on my Mac.

Combine that with Apple offering to use a private/hidden email address for signing up to the service in the first place and forward mail to your real email, plus the auto-generated secure passwords stored in the new Apple password manager.. and it's a pretty magical and secure experience as a user.

https://github.com/ziglang/zig/issues/20274

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I'm not sure why Web Locks is useful TBH. I guess if you don't understand atomics it's a friendlier API?

Early first-person shooter games had this figured out (small servers with 20-30 regular players, the server admin could choose to ban you), RTS games have this figured out, many MMOs have this figured out (interact with non-friends sometimes, but they have to 'join your party', etc.)

Playing with random strangers on the internet who may want to grief/destroy your game, be incredibly toxic, or cheat against you in general.. that's the cost of playing with random people in a completely public forum.

People are learning to prompt LLMs in ways that produce better results for their LLM of choice, so switching to another one they find their approach no longer works as well.

Or.. LLMs have different personalities in terms of output; some being more or less direct/polite than others, or sounding more or less confident; and that is causing people to perceive a difference that in terms of factual answers may not be different.

Or just personal preference masquerading as intelligence - a classic among software engineers.

e.g. instead of tokens ['i', 'am', 'beautiful'] having tokens ['I am', 'beautiful'] on the premise that 'I am' is a common set of bytes for a semantic token that identifies a 'property of self'?

Or taking that further and having much larger tokens based on statistical analysis of common phrases of ~5 words or such?

    static int pretty_float_equal (float a, float b) { return fabsf(a - b) < FLT_EPSILON; }
    static int pretty_double_equal (double a, double b) { return fabs(a - b) < DBL_EPSILON; }
    static int pretty_long_double_equal (long double a, long double b) { return fabsl(a - b) < LDBL_EPSILON; }

[0] https://github.com/KhronosGroup/MoltenVK/issues/1524

BBB is just a review website. Like Yelp.

Filing a complaint with BBB is like saying 'I left a bad Yelp review' ... useful, maybe.. if the company cares..