cpburns2009

People began disliking big tech well before this latest bout of AI.

Literally all the PSF had to do was follow federal antidiscrimination guidelines. I guess that's too much of a burden for some organizations.

If there's common real world paths that need to be supported, you can tailor optimizations to target those uses cases.

What would have been really nice is if the $1M/y in funding the PSF rejected due to ideological purity could have been reallocated to PyPy.

This is exactly how I write my Python. I'm currently debating between going in deep and transitioning to either TypeScript or Rust. Go's object system and error handling is too weak. Java is too verbose, but I have a soft spot for it.

The problem with PyPy, which I'm a huge fan of BTW, is it's on life-support. The only reason the past couple major versions were released was due to a few small companies or individuals directly implementing the updates themselves. That's my understanding at least. It's disheartening because I've been primarily using PyPy for 5 years, advocated for it, and was looking into contributing more to it before finding out about its state.

I have no doubt Julia's far better with this. I just wanted to point out Python does have a similar precedence for ahead-of-time compilation, albeit with byte-code only. If the Python steering council ever gets its act together, maybe Python could have real AOT and JIT.

I've never bought this argument. Underneath all of the magic inheritance in Python is just the MRO (method resolution order). That's not characteristically any different from JavaScript's prototype chain. There's no reason a Python JIT couldn't optimize everything JavaScript does, and if you do specifically access `self.__dict__`, that can be a cold, unoptimizable path.

That's basically how Python already compiles source to byte-code.

Quite simply the audio mixing for TV and movies is utter shit. You shouldn't need a 7.3 sound system to potentially hear the actors legibly. The stereo speakers built into my TV should be adequately supported, and it is frankly the default set up for most people including myself.

I read it. There's no convincing reason for most applications.

What's bad about using them as opaque public ids? The only information that's leaked is approximate time of creation which is moot for most applications.

ULID is what I use. I convert it to UUID before storing in PostgreSQL. Technically it's an invalid serialization but it works. The system predates UUIDv7. I also like ULID's shorter representation.

PostgreSQL's UUID type is convenient. But yes it's pretty much just a 16 byte type.

Only decompression with Google's brotli library is affected. So if you use "Brotli" or "brotlicffi" in your Python app to decompress brotli, you're vulnerable. Compressing responses with brotli from Apache is safe.