1,600 karma · joined August 1, 2019
However, Rust makes use of it for fast safety checks. Because rust strings must be valid utf8, if you want to take a substring at some range, eg "Hello, World!"[7..12] then it's very simple to just check bytes 7 and 12 and see if they are the start of a codepoint, no other scanning or parsing is required.
The passkey integration goes the other way, which is much more reliable.
It's of course impossible to have any nuance or middle ground here where you use LLMs to assist while you still focus on the engineering design decisions and the quality.
For work, given we pay API pricing anyway, I've been happy experimenting with K3-medium as my default, and now I'm planning on trying GLM 5.3 as well. Sol-medium is my fallback for my work purposes but I occasionally use Opus 4.8 as an additional reviewer.
I like the open weight models because much of my time at work is spent on security hardening (specifically, hardening my own service), and Sol/Opus keep snitching on me and blocking my prompts.
Some people feel the need to attach an image to almost everything the post - even in chat rooms (including slack at work). These images serve no purpose, but the poster feels it is useful - though it was often reaction gifs in the past I'm seeing a lot more AI content than I ever saw reaction gifs, maybe because of novelty or maybe because it's ultra personalised.
Sometimes images help to visualise something or to get a point across, but I see so many people who think it's necessary to reply to a discord message with a cat with human limbs doing a dance, or a photo of "themselves" climbing a mountain with the Rust logo to show them mastering Rust... Ok?
Image models are useful and I'm thankful for much better visual reasoning but it really really frustrates me the constant need to burn money for all of this slop.
You can choose where your PDS runs and the ecosystem still works. If one relay shuts down (Google Reader) or takes their API private (X, Reddit) it shouldn't matter, the PDS are separate and another relay can take over.
Worst case you can go directly to the PDS, but that wouldn't work at scale
It's not ideal during a drought though to be using water like that, it would be nice if we had a grey water tank system so we didn't have to waste drinking water. It doesn't seem possible to install a grey water tank like that in our apartment though. Given our apartment already has district heating, there's not a super strong reason why it couldn't have district cooling as well, but the regulations are not in our favour here.
We installed it all without planning permission, although it still might require permission from the freeholder depending on the rules regarding Service Media alterations (as it requires new plumbing for our mains water).
Everyone likes stories in some form. Everything has a story and it's natural for the brain to invent new stories. Some stories are addictive - brain worms - you just need to explore the story you developed. Writing is the cheapest medium to explore it.
I'm certain if I wrote a book no one would want to read it - but maybe it's still a good story.
I always enjoyed writing code and I am very good at writing very performant and elegant code, but it would sometimes come at the detriment of focusing on the code and not the design.
I don't understand how it forces you to engage with Rust. It happens to be written in Rust but that shouldn't be a major consideration for a user
Sharding/peering pgbouncer works, but it's not perfect.
More significantly for us is that Neon has millions of databases in each region, and thousands get created/destroyed every hour. Managing the pgbouncer config and shared connection pools will be extremely tricky to balance. We have a bunch of logic for this in the proxy I maintain, but not in pgbouncer.
The main intent is to incorporate a pooler directly into our existing proxy service to avoid needing double proxy services. We just need to find the right pooler implementation (and one that works in async Rust)
PgBouncer is entirely optional and it's not always the right choice. If you have a classical app (non serverless) and you can maintain a connection pool from your app, then I recommend avoiding pgbouncer.
The benefits of pgbouncer mostly come from irregular client connections (too many, too much churn). If you don't have that problem, go direct to postgres.
I'm exploring replacing pgbouncer with an alternative (maybe home grown) at the moment. Mostly for multi-tenancy and HA reasons. Pgbouncer has been good for us, but it's limited in how we can deploy it in a multi-tenant environment.
It mentions that a cpu request is a guarantee, but how is that enforced? If I have 32 pods running on a 32 core machine, each with 1cpu requested, what stops one of those pods using an unfair share? I assume we just rely on the Linux scheduler. If I have 16 pods with 1cpu and 1 pod with 16cpu, does the Linux scheduler make sure to give the 16cpu pod more time? Or are we back to using cgroups.