niels_bom's comments

On: Hoodmaps: Publicly Annotated City Maps

[niels_bom]

In Amsterdam close to Sloterplas (lake in the West) “aggressive Moroccans”.

On: Classifying all of the pdfs on the internet

[niels_bom]

Typo: “meats the eye”

On: What I Learned Working for Mark Zuckerberg

[niels_bom]

How do y’all filter out survivorship bias in articles like this? I can imagine 50 other people with the exact same experiences but then having worked for companies that ended up fizzling.

On: UI elements with a hand-drawn, sketchy look

[niels_bom]

tldraw.com is also excellent

On: Show HN: Godspeed is a fast, 100% keyboard oriente...

[niels_bom]

If I have todo items that are 10 years old it’s a sign I don’t really care about them.

For (PKM) notes it’s a whole different story.

On: How web bloat impacts users with slow devices

[niels_bom]

It might also be people not willing to admit that they don’t know how to optimize website performance. And if you have a somewhat complex web app it can be complicated, especially if your stack doesn’t help you (looking at you React).

On: Building Meta's GenAI infrastructure

[niels_bom]

Capitalism is so weird sometimes.

On: Show HN: 3 years and 1M users later, I just open-s...

[niels_bom]

I think there are valuable positions to take in between “let’s manipulate the DOM by hand” and “React Server Components, NextJS and the kitchen sink”.

I personally think there’s great value in the pattern of reactivity where parts of your DOM update based on bits of data. Developing, designing and testing components like this becomes way simpler.

On: Is there a linter for Python "dependency definitio...

[niels_bom]

I’m familiar with lock/freeze files but that’s not what I’m after.

On: PostgreSQL is enough

[niels_bom]

Would you say it's slower than file IO too?

[Too → niels_bom]

It’s not slow by itself. It’s a single point of bottleneck that will inevitably become slow as you cram everything into it.

[dagss → Too]

...but by trying to avoid the bottleneck and moving things to backend, you make things 10x worse resource wise for the DB. So it is not a easy tradeoff.

Take any computation you can do in SQL like "select sum(..) ...". Should you do that in the database, or move each item over the network and sum them in the backend?

Summing in the database uses a lot less resources FOR THE DB than the additional load the DB would get from "offloading" this to backend.

More complex operations would typically also use 10x-100x less resources if you operate on sets and amortize the B-tree lookups over 1000 items.

The answer is "it depends" and "understand what you are doing"; nothing about it is "inevitable".

Trying to avoid computing in the DB is a nice way of thinking you maxed out the DB ...on 10% of what it should be capable of.

[Too → dagss]

Yes. Aggregations and search are often best done as close to the data as possible, in the DB.

Rendering html, caching, parsing api responses, sending emails, background jobs: Nope.

Basically, use the database for what it’s good at, no more.

[legohead → niels_bom]

Well, it is file IO, plus processing on top. But it's not that simple, since if your data is small enough it can all be loaded into memory, allowing you to sidestep any file IO. But you still have the processing part...

[alternatex → niels_bom]

Kind of irrelevant since a DB provides some guarantees that a simple file does not by default.

[samtheprogram → alternatex]

GP was responding to a comment comparing it to network IO in terms of bottlenecks in your application stack ...?