rtpg

for function calls, look at django.db.models.functions, you can find a bunch of stuff in there or create custom ones super easily (like "two lines of codes" easily)

I mean you have a thing that works in theory so it's a bit of navel gazing, though.

It can take a while to wrap your head around what fields get used in aggregates and the like, but when working with big models with like 65 fields and juggling a bunch of stuff, not having to futz with serialization/deserialization and "just" expressing your problem in the dumb way is nice.

I want to say this all comes back to bite you in the end but honestly it's more just having wide tables that comes to bite you. A service layer wouldn't really save you. Meanwhile you save yourself a bunch of tedium in the mean time

Is this not the same for the data centers? Have data centers solved parking provisioning in a way office parks haven't?

> Second, no, these jobs are not generally filled by neighbors of the office complexes, or even people from the muni where the office complex is situated.

I mean again... are the data center jobs like ... guaranteed to be people in the local area? Isn't the nature of the job provisioning going to be the same with both buildings, roughly? What is special about the data center jobs to not have parking/traffic/etc?

I saw the pics of the data center you're talking about, with nice trees. I get what you're saying, it looks nice!

But it's not like if I made a nice park buffer around my office park that you would be like "oh they're the same" now right?

Is your argument "if you have a data center and an office park of the same size, the data center will generate less traffic and be less of an eyesore"? Then that means less jobs right? Why is the "cost to municipality per job" lower with the data center? Or maybe your argument is simply based on value to the specific municipality, and that the jobs are not worth much to your eyes in any case/in fact are negative, and so it's about (glibly) damage reduction?

(in other words: if you're going to a council meeting to fight a data center being built, you probably should be going to the council meeting to fight the office building being built...?)

(Serious question, I want to understand the dynamics here better)

Like maybe the municipality doesn't care because a lot of jobs are filled by people coming in from an hour away, but surely the inverse of "I am sad because <some job source in my area> closed" is "I am happy because <some job source in my area> opened", right?

I get what you're saying about the buildings themselves. I just think that, in the abstract and all else being equal (it isn't of course!) "big box for 50 jobs" and "big box for 200 jobs", one seems nicer. Maybe I'm overestimating the job differential. And this is all a bit of a false dichotomy anyways

I do not believe this to be true! I have the impression you keep up with zoning discourse etc in your area based on your posting history... you surely have heard of people complaining about things like traffic concerns and general "ugliness" complaints around building out office parks, right?

Data centers might be making the nat'l news at the moment, but it feels hard to consider any subcategory of project development that doesn't have a bunch of whiners associated to it.

I ended up finding a good number of HN comments like "we were doing this and regretting it".

So here's my ask: anybody here use PG for queues at a system with reasonable throughput, without regretting it? Like where there might be some contention

I just read your post on hacker news about people using The Sentence, and couldn't agree more!

I think trying to make a "playful" personality turns off some people and is more work than just getting to the point. Opening with "here's the thing I want/what I'm reaching out for". then reasons. Then close out with a thank you.

Added bonus: short emails tend to get replies more often in my experience.

> For python - https://github.com/aspect-build/rules_py parses a UV lockfile and does not use either UV or pip at build time.

rules_python does for example call into piptools to do installation

https://github.com/bazel-contrib/rules_python/blob/main/pyth...

To be honest this stuff feels like it's gotten soooo much better in the years since I've used Bazel. (one can easily argue that it's been thanks to language ecosystems getting their things better) compared to when I've last had to use Bazel back in 2021-2022 (I had initially set up Bazel in ... 2018 for an existing Python project). So this might be a bit like relitigating Python 3.0. The lessons are learned perhaps!

If I want to be very cynical... I think there is a universe where uv could have existed 5 years earlier if Google had decided "we're going to extract our Bazel learnings to get Python packaging to be better".

You might say "well they have blaze they don't need this" and that's kind of the point. In the world of setup.py you still need some language-specific infrastructure. Google and friends could have pushed things along in interesting ways, IMO!

But given their general sort of "we just vendor everything in" attitude they don't need to do that. So language ecosystems don't get the right kind of pushes and it takes us a decade for someone in the Python community to write "lockfiles that work + a package installer that works". Feels like a missed opportunity, mainly.

the blog post announcing this

> If you need another graphic like that in another place, doing it manually is simply not worth the time. Another problem is experimentation. When you are trying to find the final look, you need to test a lot of small ideas: density, direction, color, spacing, gradients, randomness, shape. The faster you can change these things, the better the final result will be. > > Doing all of this manually would be a massive waste of time, so building your own procedural art tool for this kind of effect is a perfect solution. The Polar Signals example also works well for the UX argument. A custom tool does not just improve your speed. It gives you an interface that is simply better for this exact task.

feels like the design industry has forgotten about things like Processing. Unfortunate!

Bazel uses npm/cargo/pip in most people's usage of these tools! People still use these packages managers, with random patches and tweaks (because the overall ecosystem assumes you're using them). But Bazel often includes random fixups in their own tools.

For example [0] is some patches Bazel does to node to get it to play nicely witH Bazel. In an (IMO) better world Bazel people figure out what they need, and figure out what they can get upstreamed into node to get things working.

Instead we have patches that (if you jump through the history) have been around for 6+ years

[0]: https://github.com/aspect-build/rules_js/tree/main/js/privat...

It does look like for some projects it's almost entirely "just declare the dep tree" (https://github.com/allyourcodebase/boringssl), + the tiniest patch.

But what's going on in grpc for example? Like this build file https://github.com/allyourcodebase/grpc/blob/master/build.zi...... why is this build file in this repo? Is the grpc makefile no bueno?

Efforts to pull out information from existing build systems (if possible, ofc) means that you don't have to spend your time _rewriting build scripts_.

I don't know if it's really possible. Maybe this is step .. 4 of 34 to getting there. Just wondering if there's an alternative here that doesn't involve rewriting build scripts

Maybe a part of the pitch here is to just upstream these build scripts so that ones makefile becomes "just" `zig build`? In that case I'd actually like to see (for example) a fork of oyacc using what is figured out in https://github.com/allyourcodebase/yacc to "just" use the build script even in the higher level project.

The gist of it is something like:

- Bazel community hits a problem with something like how npm behaves around paths

- Bazel's solution is to create a patching system around paths to resolve them

- rinse and repeat for every piece of tooling us "normies" are using

The end result is that instead of Bazel's efforts showing up in the base tooling, they build up a bunch of their own tooling and patches, and the underlying tools don't get really much if any benefit. Moving to Bazel still is a PITA, and there's a lack of improving onramps

In an alternate universe when people in Bazel land hit issues they would show up with patches and recommendations _to the underlying tools_ to get things merged in so that the workflows can be better supported across the board.

I don't think anyone working on Bazel is against upstreaming, but I think they discount the value of it because, hey, _they_ can get patches and hacks working for their flow

I had the impression `zig` already has stuff like `zig cc`. Would... would `zig make` be an impossible proposition? Maybe that makes no sense.

I still think there are lines (I have to begrudgingly accept that downtime for PG upgrades is still basically worth it because the effort to not downtime there is so high but the frequency is so low), and it's a spectrum. But I've found that this particular flavor of tech debt tends to hurt quite a lot even with fairly low activity systems

I do think that people really underestimate how quickly a system starts being "please, no downtime" (or its weaker cousin, "please, don't make your ops people do rollouts at 1AM").

Like obviously it's not the end of the world but the default assumption of "the system is up" makes a loooooot of things downstream of that easier.

Having to do operational bug triage on systems that routinely have blips in availability is unfun.

When I've used interactive proof systems like Roq, I'd often kinda code myself into a hole by cutting along the wrong axes and not specifying my problem in a way that's easy to prove. After all, this is just like in math: you really want to cut at a problem the right way to get to the easy proof.

I think people are discounting how important that decision making is. It's not just about whether an LLM can churn through specific proof strategies on a problem, but also about how to pose the problem etc.

I'm not saying LLMs can't help, but I think it's less that "proof engineering is not needed" and more that "when these tools are used in the right way, proof engineering is easier". Because at the end of the day these tools work well when they have the right kind of foundations in the first place

> AWS made LNSym: a semantics and simulator for AArch64. That's cool. Perhaps we could use it to show equivalence between an optimised assembly implementation of some functions, and their Lean counterparts, and then use the assembly code at run-time? Then we could let LLMs rip at optimisation and they couldn't introduce any functional bugs. Verified assembly is well-trodden in crypto implementations, but perhaps now it could be cheap?

Trying to one-shot compcert might be hard! Thinking about it and planning it out might make it easier though...

The cookie banner isn't about the usage of cookies, it's about _the underlying tracking_. You're allowed to "just" use cookies for normal shit! You can make a website where you use cookies to store login state for a user, without a single banner.

The thing is that every company in the world feels the need to add 1000 tracking cookies to anonymous users to track them through conversion funnels (on top of the ad stuff). That's what you have to inform people about

You can use cookies normally without a banner! You can't track without consent! Every cookie banner is actually a "we want to track you" banner. Calling it a cookie banner is playing into the confusion about what those banners actually are meant to communicate

In practice I think it's very easy to make your htmx application JS-requiring.

But also just type "android mp3 player" into Amazon dot com. You'll find plenty of stuff under $100[0]

[0] https://www.amazon.com/4-02-Player-Bluetooth-WiFi-Speakers/d...

Having them around is like 100000x better than having just random engineers be doing product design. And "oh just listen to your power users"... come on folks, surely we know about designing our software into a corner right?

I'm saying all this but am very sympathetic to the pain brought by bad product people (or just like ... mid product people. It's a hard space)

I do generally agree that the theoretical model being _this_ misaligned with the reality in front of us feels a bit hard to use

Though I have a walkman (that kinda sucks cuz it's android.... it's (USB-C AND annoying Android OS) XOR (Proprietary charging cable) from Sony nowadays

> Why can't somebody take simple smartphone hardware and make a modern media player that is not a phone?

Sony Walkmans are this, along with a bunch of the random mp3 players you would find on amazon. I don't know why some other people replying to you are acting like this doesn't exist.

I don't understand the truth to this point, and there's a clear difficulty in establishing structure, a thing that you don't need to actually do with raster image gen, right?

Like if you say "please give me 9 circles" you expect circles in the image and not just a bunch of pixel that are vaguely circle-like, right?

here lies the fundamental misunderstanding by many people in this thread.

Is the objective of Codeberg to host as many projects as possible on its own server? I do not believe so!

The question then becomes "what is Codeberg's objectives?"

It's not to become the world's largest code forge instance! It's to build a set of FOSS tools for FOSS software development. Look at [0], for example, which lists alternatives.

But perhaps most importantly, the FOSS tooling can be self hosted, right? There's still a notion of freedom there.

[0] https://docs.codeberg.org/getting-started/what-is-codeberg/#...

I think this deserves a real response.

First, an analogy. I drive along a cliff with no guardrail. How do I not drive off the cliff? By knowing how to drive. Sometimes people mess up and drive off the cliff

In practice people are operating Postgres as a machine, more than an abstract spec. Minor releases exist, but the changes are made by people operating the machine and who have a fear of making the machine break.

There are also performance characteristics that are part of an informal spec. While you can definitely write regression tests on performance, theres loads of value in stability of internals because people who have problems look into the machine and discuss it.

The internals might change, but there’s a lot of friction. So… you can have a lot of informal knowledge about.

If everyone working on a software stack is bathing in this informal knowledge, then the decision making is based on that. Things like what is meant to be in a minor or major release is understood. And people make those judgement calls.

After all, even if you have regression tests if you’re making changes you’ll need to write new tests! How do you know your new tests are right? That the new behavior is right?

PG is the entire machine. Fortunately we have version numbers, migration strategies, etc. But “here’s a new binary that passes the test suite and… maybe changes everything not covered by tests maybe doesn’t”. Why bother suffering when there are totally reasonable gradual rewrite strategies?

And of course… every bug in the world… got through despite a test suite! What software out there doesn’t have bugs?

And if the behavioral difference in the rewrite does affect people… I guess that’s something right? “Oh this isn’t a bug because it wasn’t covered in regression tests” is not that tenable.