Yes, AI or no AI, tell me about something actually interesting that you're working on.
Currently it feels a bit like everyone is talking about what new editor they're using. I don't care about that type of developer tooling very much. AI isn't coming up with some exciting new database, type system, etc etc.
"Look at how I'm able to web dev x% faster" because of LLMs is boring.
> Pascal did not have sum types because Wirth thought they were less flexible than untagged unions
I'm not sure whether my dream language would have tagged or untagged unions (Scala 3 has both it seems). I'd be interested if anyone has any further points of comparison beyond:
Tagged unions, eg. in Rust: enum Tagged {A(i64), B(String), C(f64)}
Untagged unions, eg. in typed Python: Tagged = int | str | float
Tagged unions are better as you can represent duplicated types and types with no data, eg: enum Tagged {A, B(f64), C(f64)}
Untagged unions are better as you can willy nilly create new subsets and intersections of types. I find often in AST-ish work I want to express eg: def f(x: A | B | C) -> A | B
In my linked example, on getting the item from the queue, you immediately set the status to something that you're not polling for - does Postgres still have to skip past these tuples (even in an index) until they're vacuumed up?
I'd be interested as to how dumb-ol' polling would compare here (the FOR UPDATE SKIP LOCKED method https://leontrolski.github.io/postgres-as-queue.html). One day I will set up some benchmarks as this is the kind of thing people argue about a lot without much evidence either way.
I plan on using it for semi throw away UIs for things where I don't want the user to have to spin up a Web server. Right now there's no canvas support, but there is that kind of thing in the Tk/Tcl docs (linked in the project). I probably need to add a way to reference a specific Widget so you can access the raw name and run taw Tcl against it.
For those of you from a Python background - this is basically "Pydantic for Typescript". See also trpc - cross client/server typing using zod under the hood - https://trpc.io/
If like me, you've ignored poetry and friends and stuck with pip-tools (congrats!), uv (used by rye internally) is a drop in replacement.
IMHO pip-tools was always the far nicer design than poetry, pipenv etc as it was orthogonal to both pip and virtualenv (both of which have been baked into Python for many years now). I would argue Rye is the iterative, standards compliant approach winning out.
Beyond the speedups from Rust, it's nice to have some opinionated takes on where to put virtualenvs (.venv) and how to install different Python versions. It sounds small, but since wheels fixed numpy installs, sane defaults for these and a baked in pip-tools is basically all that was missing. Talking of which, what has been the point of anaconda since binary wheels became a thing?
I'm always excited by the idea of rendering jsx from Python in the same process. Mostly as a bridge between eg. an existing Django app and full SPA React land. You'd swap out the scrappy Django string templating with jsx, then once a page passes some frontend interaction complexity threshold shift it over entirely (with shared components between both). Could this project help achieve this or are imports/build processes etc too much of an impediment?
Thanks for the comprehensive reply, does the following argument stand up at all? (Going on the assumption that LISTEN is one more concept and one less concept is a good thing).
If I have say 50 workers polling the db, either it’s quiet and there's no tasks to do - in which case I don't particularly care about the polling load. Or, it's busy and when they query for work, there's always a task ready to process - in this case the LISTEN is constantly pinging, which is equivalent to constantly polling and finding work.
Regardless, is there a resource (blog or otherwise) you'd reccomend for integrating LISTEN with the backend?