[re: the null thing]

@Chip_Unicorn No worries! And to be sure, you can absolutely work around that limitation by making users call `haskey` or something first, or by doing what C# does and also returning a bool that indicates whether the value is valid or not. But the dict API example is the […]

[re: the null thing]

@atax1a Oh, yeah. Anything that learned from how OCaml handles nullability (in particular, that nullability is a consequence of good ADT design and not something to be special cased) is going to come out a lot better for it.

[re: the null thing]

@Chip_Unicorn The example I always give is an API for fetching values from a dictionary. So if you have a data type like `[K, V]dict`, using that syntax, then you might have a function like `[K, V] get(d: [K, V]dict, k: K) -> V?` and that returns `null`, `nil`, `None` or […]

@bob I kind of agree, weirdly? I think there's efforts to make C a lot better than it is, but I don't see any such efforts on the C++ side. I can absolutely see a world that isn't even too far away where C is a pretty usable language as long as you never let C++ anywhere near it.

But I don't […]

@mark I think one of my wakeup calls was realizing that, at least per C99, it is not possible to write a program without undefined behavior, given that `int main() { }` fails if the maximum stack size is set to zero, which in turn is completely allowed by the specs.

[the null thing]

Nullability should not be idempotent. That is, T? and T?? should be distinct types, otherwise you wind up with problems the moment you try and design an API that is generic over types that can include both T and T? for any concrete type T.

All of those problems can be worked […]

@whitequark It's kind of funny how after taking an incredibly toxic response to real problems, everyone leaves and shit gets even more toxic.

Like, backporting memory safety onto C and C++ were never going to be easy, but writing whitepaper after whitepaper about how memory safety was useless? […]

Hate Rust? Fine, there's valid criticisms. I'm not a fan of Zig or Swift either (seriously, how many new languages are going to continue to fuck up null), but they're not *bad* in the same ways that C and C++ are.

Just please, I'm begging software engineers to come to terms with that C and C++ […]

You can get amazing shit done in bad languages, that's not surprising. For a long time, the *only* options available for most applications have all been bad, so the prevalence of C and C++ is neither surprising nor an argument against them being bad.

But they are bad. And it's an absolute shame […]

@glyph Oh, yeah. I just got bit by this optimization as I thought I was working on a completely user-local install, but something somewhere inadvertently implied using system Python to call venv. But only on one machine...

But yeah, distro hacks are always frustrating.

@glyph Ah, no sorry. I should have said stdlib instead of site-packages. Debian and derivatives patch the stdlib in ways that break venv, I think? Making a new venv with a fresh Python fixed it, in any case.

@SnoopJ That is precisely the substantial pain I'm going through today, yeah. I don't even mind esp-idf other than my baseline loathing for cmake, but I did not want to run the installer at all.

Hah! Success! The above cursed bug was ultimately triggered by inadvertently depending on system-wide site-packages. The solution, then:

```
uvx --with pip --managed-python platformio run
```

That lets me use esp-idf without having to install either platformio or idf.py!

@SnoopJ Oh, yeah, and absolutely. The esp-idf *installer*, though, left crap all over my system last time I used it. I'm quite eager to use esp-idf without running their installer.

@glyph I didn't expect system-wide site packages to take precedence over packages installed into the venv. Turns out something was implying `--no-managed-python`, manually setting `--managed-python` forces venv to make a new symlinked environment without depending on anything in /lib.

Packages aren't leaking on my other machine…

```
$ uv run --with pip python
>>> import sys
>>> sys.path
['', '/home/cgranade/.local/share/uv/python/cpython-3.11.10-linux-x86_64-gnu/lib/python311.zip', '/home/cgranade/.local/share/uv/python/cpython-3.11.10-linux-x86_64-gnu/lib/python3.11' […]

how, just how

```
$ ~/.local/share/uv/tools/platformio/bin/python
Python 3.12.3 (main, Aug 14 2025, 17:47:21) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/lib/python312.zip', '/usr/lib/python3.12' […]

ffs

```
$ uv run --with pip python
Python 3.12.3 on linux
>>> import venv
>>> venv
<module 'venv' from '/usr/lib/python3.12/venv/__init__.py'>
>>> import json
>>> json
<module 'json' from '/usr/lib/python3.12/json/__init__.py'>
>>> import sys
>>> sys.executable
'/home/cgranade/ […]