Slonik does _not_ make it possible (let alone trivial) to write composable queries. You're just doing string concatenation and string concatenation will bite you when things get complex enough.
There is also a big difference between an ORM and a query builder. Knex (and kysely, which is the only thing I'd use these days) allows you to write SQL that's just as complex as anything you'd write raw, complete with escape hatches if you need them. The criticisms of ORMs tend to be spot on, they are nice until they run into a wall, but that same thing simply does not apply to a robust query builder.
> Slonik does _not_ make it possible (let alone trivial) to write composable queries. You're just doing string concatenation and string concatenation will bite you when things get complex enough
In practice, I find this to be potayto/potahto. At the end you need the thing to output SQL that is going to run, and I've had a lot more problems trying to get Knex to output the SQL that I know works vs dealing with any string composition issues in Slonik.
More importantly, at the end of the day, when it comes to DB operations, all of the information you get from the DB is going to be output/logged in SQL. There is no way getting around the fact that you need to know SQL well to manage a DB. Knex just becomes another layer that you need to translate to and from ("the leakiest of abstractions" as I like to say). I'd rather focus my effort on becoming an expert in SQL than yet another popular-library-of-the-month.
1. You certainly need to know SQL
2. Composition is very different than concatenation and the differences become apparent as a project increases in complexity
3. I'd recommend checking out the current SOTA, especially with kysely (or Ecto if you ever get into Elixir projects)
I've used kysely extensively on a project built using sst.dev. I can't paste proprietary code, but I remember my head spinning over a particularly gnarly query (e.g. a bunch of window functions, aggregations, etc.) It was a million times more difficult to grok reading this in kysely's syntax than SQL.
I'm using kysely with a database that has quite a few complex functions, etc. Lots of queries that require CTEs and so on. It's fantastic. Type safety with the codegen is amazing and catches a tremendous amount of simple bugs and typos which are super easy to make in raw SQL strings.
People talking about writing raw SQL have never maintained a large project. Once you start string concatting queries and trying to remember which table aliases are which you're halfway to writing a custom, buggy query builder without type safety. It's a trap for young players.
As someone with 25 years of experience using lots of ORMs and query builders in both Java and JavaScript/Typescript, I believe the exact opposite to be true. There are libraries now that let you write composable, safe SQL with type guarantees (I am a big fan of Slonik, but there are other libraries).
Every single time I've seen an ORM or query builder used for application software, eventually I see it becoming a big headache for operations. It usually makes debugging and and performance investigations more difficult, and I so often see developers "fighting with the tool" when they're just trying to get it to output the SQL they want it to.
In my experience, people who are fans of ORMs and query builders never have had to deal with significant scale and the operational difficulties that come with it (and I'm not talking about "Google scale", either, I'm just talking about a reasonably well known consumer site with moderately heavy traffic at times).
I've been at it for a bit over 25 years as well and have worked on everything from telco billing projects to complex consumer applications. Query builders and ORMs are not the same thing, and it's odd that you conflate them.
The project that I happen to be on now has a mid sized db (~70 ish) tables with quite a few custom functions and complex queries. I have been untangling a mess of slonik queries and there's an objective difference in the quality of the code and the maintainability between that and the kysely code that's replacing it.
The people I see drift toward things like slonik tend to be journeyman level developers and they often end up over their skis. Smart folks a lot of the time, but inexperienced.
Had a flashback to twenty odd years ago in Sydney when there weren't enough Rubyists to get a reservation at the pub for a meetup so we had to team up with the Smalltalk guys. Ahhh, different times.
It gave me a flashback to 2007, when I was a hobbyist programmer and signed up for a Ruby meetup on a whim, and a recruiter called me 5 minutes later and ended up getting me my first programming job. Crazy to think how much that changed my life.
Interestingly, Sydney does not seem to have an event listed on this site when I checked. Adelaide and Auckland lead the charge, with an occasional Melbourne meetup.
As an aside, I dislike the strong association between Rails and Ruby. Ruby can be a fun scripting language. In my experience I'm generally about as productive writing Ruby as I am with writing Python, but Ruby seems to get bucketed into a very Rails centric world of "not the worst choice you could make if you wanted to make a web service" (at least when it comes to meetups).
Maybe it's just that the web service guys are more likely to need a support group! :)
> Interestingly, Sydney does not seem to have an event listed on this site when I checked.
To be fair, Boulder Ruby is pretty active, and we aren't on that list. Just moved to Luma from meetup but have had meetings 10 months a year since 2016.
I keep telling people to think of Rails as a “ruby-like” language. Rails monkey-patches so much and has so much magic that it’s substantially a different thing.
I started the Portland Ruby meetup back in '02. IIRC we had 4 people including myself in that first meeting at a pub. And it went that way for several years where we'd never have more than about 6 people (and often less). Then after Rails hit it took off. I Haven't been to one in at least a decade.
Software specification documents will, as they say, rise in status. The kind of specification outlined in this article misses the mark–why would we use anything but actual natural language? That said, there will be real returns to structuring specifications so that they are actionable and easy to navigate to achieve context, both kinds.
> why would we use anything but actual natural language?
Because natural language is not a good tool to describe computational processes.
Which one would you rather write:
(a) p(x) = x^2 + 5x + 4
(b) Let us consider the object in the ring of univariate polynomials with complex coefficients defined by the square of the variable, plus five times the variable plus four.
Every scientific discipline moves away from natural language as soon as possible. Low-code, no-code and the likes have been a dismal failure precisely for this reason. Why would I move back to natural language if I can effectively express my problem in a formal language that I can manipulate at-will?
I am not convinced by the utility in this case. I'm well aware of low code and no code problems, but I am less convinced that the same principles apply to LLM code generation.
By all means use some formal language to describe LLM capabilities and so forth, but the most fantastic thing about using LLMs is that you can convey the why along with the what and get better results and the "why" does not lend itself to expression in formalized notation.
Mathematics is not the only formal languages. Every profession soon invents its own jargon because natural language are too ambiguous. For some that’s enough. But science require more formalism.
Boole’s Laws of Thought or Church’s The Calculi of Lambda-Conversion are mostly describing how to be so precise that the description of the problem equates its solution. But formal languages have their own issues.
I have issues with that as well, started taking magnesium (both normal, elemental magnesium and magnesium l-threonate) and it's made a world of difference for me.
Tangental but as someone who used to have sleep issues but has no intention of ditching coffee, taking Magnesium L-Threonate has utterly transformed the quality of my sleep. Used to wake up a ton in the night, take forever to get to sleep, etc. and now I sleep extremely well and if I'm up in the night it doesn't take me long to get back to sleep.
The sales pitch the manufacturers give is that L-Threonate is better at getting through the blood/brain barrier so it is more effective for stuff like sleep. I do notice a difference between that and when I just take Magnesium Chloride but I haven't tried citrate so I don't know.
People are saying One Medical isn't great but it's by far the best experience I've had with health care. Good comms, easy to get visits, walk-ins for bloodwork etc etc. It's just super convenient. I'm in NYC and maybe it's different elsewhere but it's totally worth the subscription for me.
reply