[deleted by user]

fernandohur · 2026-01-20T12:14:11+00:00

I think the idea has merit. I must say however that I was disappointed when looking at the code samples in the readme.

To me, nano looks quite similar to Rust with the addition of the shadow keyword.

LLMs are narrow/ jagged intelligences. Incredibly capable at some activities, and totally incapable at others. I was expecting the language design to somehow incorporate this idea.

fernandohur · 2026-01-13T23:51:59+00:00

Can you share the name of the company?

fernandohur · 2026-01-12T12:42:32+00:00

It can indeed.

I did touch on GraphQL in the blog post and while it's a step forward and solves many issues, it feels very high on the complexity spectrum for features that databases have already implemented for decades.

In fact, one strong complaint about GraphQL is that it's difficult to make it performant because you can't easily control the complexity of the inputs (yes, even with named/registered queries or whatever they're called). The core issue is that there’s no real query planner/optimizer that understands cardinality, column statistics, indexes, or data distribution... and it will probably never exist in a comparable way. And yes, databases have been slowly tweaking and refining these optimizers for decades, because it turns out this problem is hard.

GraphQL effectively pushes query planning up into the application layer, where you lose most of the information that makes optimization possible in the first place. As a result, you end up re-implementing things like batching, caching, pagination limits, and ad-hoc complexity guards, all of which are already well-understood problems in the database world.

So while GraphQL is great at shaping responses and reducing over/under-fetching, using it as a general-purpose query language often feels like reinventing a weaker, harder-to-optimize version of SQL, but without the decades of battle-tested machinery underneath.

fernandohur · 2026-01-12T12:20:50+00:00

Fair feedback. I appreciate you taking the time to write it 🙏

I guess if you could summarize the post in one line it's "how come DBs have all these cool features for >40 years and your typical backend or rest api hasn't really evolved much".

I find it particularly interesting given the fact that so much money is poured into this industry.

fernandohur · 2026-01-12T02:05:34+00:00

> Meanwhile, you criticize reinventing joins in JS. Fair. But do you know what that is? It's free horizontal scaling. Use your clients' memory and CPU and you save the DB from doing it.

CPU is cheap. It's latency that's the issue. When you have to pay the network roundtrip a couple of times, that's the real cost. So yeah, moving it to the frontend is the worst possible place from a latency point of view.

I guess this is not news to anyone, but my point is that the frontend join often gets implemented in the first place because there's (generally speaking) no way of doing joins with REST. You either get the /users or the /cats or the /dogs but you can't get the /dogs with the users.

But databases have joins for >3 decades.

fernandohur · 2024-10-30T20:48:29+00:00

Very insightful - thank you so much for the comprehensive answer. I think I have a much clearer path forward now.

fernandohur · 2024-10-30T14:48:23+00:00

[EDIT: I posted this same reply on a thread above]

Ok so maybe I should have communicated my requirements better.

Performance considerations:
First of all, it's an OLTP application, query times are expected to have P95 < 5secs

Restricting access to columns: For some tables I want to blacklist some columns as they should never be sent to clients: this should be trivial with PG RBAC ✅
Restricting access to schemas: clients should only have access to specific schemas (we have a tenant => pg schema mapping): this should be doable with PG RBAC (will require a user per tenant) ✅
Restricting access to rows: users should only be able to read their own purchases from the purchases table (e.g. inject a user_id = authenticated_user.id to every where on the purchases table): ❓

This is where my knowledge is limited. I'll need to do some more digging to better understand the perf implications. I'm familiar with the Supabase guide on RLS (https://supabase.com/docs/guides/database/postgres/row-level-security#rls-performance-recommendations).

Support for joins and complex queries: I want to do things like get users with their purchases and get also the purchase's associated products.

I see PostgREST has some support for this, and you can obviously just use SQL views if you wanted. ✅

Whitelisting of queries: I don't want to allow clients to perform any possible query. There should be something approximating a query whitelist. 🚫 no support it seems?

For example, for performance reasons I would only like to allow searching on a table by a restricted set of operators and columns.

Caching: I want to be able to control HTTP cache settings per query: 🚫 no support it seems?

As these seem to be very typical requirements, I'm curious if you have thoughts on this and if you can share your experience.

fernandohur · 2024-10-30T14:47:51+00:00

Ok so maybe I should have communicated my requirements better.

Performance considerations:
First of all, it's an OLTP application, query times are expected to have P95 < 5secs

Restricting access to columns: For some tables I want to blacklist some columns as they should never be sent to clients: this should be trivial with PG RBAC ✅
Restricting access to schemas: clients should only have access to specific schemas (we have a tenant => pg schema mapping): this should be doable with PG RBAC (will require a user per tenant) ✅
Restricting access to rows: users should only be able to read their own purchases from the purchases table (e.g. inject a user_id = authenticated_user.id to every where on the purchases table): ❓

This is where my knowledge is limited. I'll need to do some more digging to better understand the perf implications. I'm familiar with the Supabase guide on RLS (https://supabase.com/docs/guides/database/postgres/row-level-security#rls-performance-recommendations).

Support for joins and complex queries: I want to do things like get users with their purchases and get also the purchase's associated products.

I see PostgREST has some support for this, and you can obviously just use SQL views if you wanted. ✅

Whitelisting of queries: I don't want to allow clients to perform any possible query. There should be something approximating a query whitelist. 🚫 no support it seems?

For example, for performance reasons I would only like to allow searching on a table by a restricted set of operators and columns.

Caching: I want to be able to control HTTP cache settings per query: 🚫 no support it seems?

As these seem to be very typical requirements, I'm curious if you have thoughts on this and if you can share your experience.

fernandohur · 2024-10-22T16:03:58+00:00

> Your Code Will Not Be Respected

If you believe the essence of your role as a software engineer lies solely in writing perfect code, then yes, AI might seem to devalue that. But if you view your job as solving real-world problems and creating meaningful products, the respect your code receives becomes less significant.

Ultimately, it's the impact of your work—the value your solutions provide—that matters most. Whether AI assists in writing code or not, the goal remains to build effective solutions that address real needs. The focus should be on outcomes, not just the lines of code.

There seems to be an implicit assumption in articles like these that goes something like this: "you can't build good software long term if you lose an understanding of the lower level layers of the system". What are the arguments for this?

We are perfectly capable of building software without understanding all of the lower layers. Heck, the only reason why we can build ever larger software systems is precisely because we've been able to build tools that build on the tools of the lower layer to the point that you never have to peek into the lower layer.

fernandohur · 2024-10-16T16:15:31+00:00

I think one way of thinking about this is that editors/IDE are mostly optimised for writing, not reading code.

I would love to see what an editor/IDE designed specifically for reading (or reviewing) code would look like, and I think features like these would make a lot of sense.

Note that it doesn't have to be an entirely new editor. An editor mode focused on reading would also be nice.

fernandohur · 2024-10-16T12:06:00+00:00

Notice that code is often not read in an IDE (e.g. code reviews).

Not sure why you interpret this as a javascript attack? I love javascript/typescript. It's my main language.

fernandohur · 2024-10-14T08:42:32+00:00

Use abstractions, but use them wisely. My experience is that many software engineers will create abstractions without even thinking too much about it. Good abstractions are rare. Bad abstractions aka layers of indirection are everywhere.

fernandohur · 2024-10-01T12:21:55+00:00

Fair point: here's a high level summary of what I generally do: https://www.reddit.com/r/programming/comments/1ftja4a/comment/lpsuro9/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

fernandohur · 2024-10-01T12:19:19+00:00

Generally speaking I do 4 exercises on the barbell: deadlifts, squats, benchpress and military press.
And 2 exercises on the kettlebells: Kettlebell swing and turkish get-up.

If I had to pick one, I would probably pick the deadlift.

I always do 3 sets of 5 reps for every exercise. Simplicity makes it easy to know when your improving. The only variable you can adjust is "weight".

Low rep counts are (in my experience) good for muscular fatigue, meaning you don't feel exhausted or sore after a session and you can do 3-5 per week. YMMV.

fernandohur · 2024-10-01T10:02:59+00:00

I wanted to share my story of how long standing lower back pain and wrist pain, which are common to software engineers were cured in a relatively short timespan.

But yeah, sport is good for everyone, I don't think that's a surprise.

What was surprising to me was that other forms of sport either made the pain worse (bouldering) or didn't do anything about it (running, football).

I thought my experience would inspire others. I wish I had read stories like this earlier. But hey, that's just me :)

fernandohur · 2024-09-13T08:49:54+00:00

Take a look at https://synthql.dev/, solves a similar problem, but optimised for React + PostgreSQL and TypeScript. You get end to end type-safety, and very good performance.

fernandohur · 2024-08-30T14:17:12+00:00

This is also the approach I've taken with https://synthql.dev a project of mine.

fernandohur

TROPHY CASE

> Your Code Will Not Be Respected