Isn't there something good about being embodied and understanding a medium of expression rather than attempting to translate ideas directly into results as quickly as possible?

Comments URL: https://news.ycombinator.com/item?id=44247124

Points: 105

# Comments: 14

Comments URL: https://news.ycombinator.com/item?id=39383386

Points: 655

# Comments: 153

Comments URL: https://news.ycombinator.com/item?id=36212499

Points: 4

# Comments: 1

Maybe the sentence makes that confusing - we're using other stuff on Render, which are basically "web servers" in the Heroku-ish sense, and we're also using their managed database, which is just a database. And it's nice that Render, like some other managed hosting providers, lets you boot up and connect those services.

I guess it's more than a database in some sense because it networks to our web servers and can be booted up in a preview environment, but it is mostly just a database. There are cheaper options that would be more work to wire up in such a convenient way, but the pricing difference between a database on AWS and one on Render is not the highest priority right now.

Kysely is a little more established than Drizzle, which I think is one of the major reason why it has broader adoption. My bet is that Drizzle is moving really fast, gaining adoption, and might catch up at some point. It's also - in terms of performance - super fast, and nicely layers on top of fast database clients.

Some of the differences that I liked about Drizzle were the extra database drivers being core and developed as part of the main project. It supports prepared statements, which is awesome. The Drizzle API also covers an impressive percentage of what you can do in raw SQL, and when there's something missing, like a special column type, it's been pretty straightforward to add.

I prefer the way that it lets us write parts of queries, and compose them - like you import expressions like "and" and "eq" and you can write and(eq(users.id, 'x'), eq(users.name, 'Tom')) and you can actually stringify that to the SQL it generates. Or you can do a custom bit of SQL and use the names of table columns in that, like `COUNT(${users.name})`. I can't say scientifically that this is superior, and it's almost a little weird, but I've really found it a nice way to compose and debug queries.

That said, Kysely is also a great project and it'd be possible to build great products with it, too. I just found the momentum, API, and philosophy of Drizzle to be pretty compelling.

Happy to adjust this conclusion - I've spent some hours trying to figure out how to pay for anything with FileCoin and come up empty-handed. Does anyone want to do a walkthrough of buying the coins, installing the software, storing data in exchange for FileCoin, and retrieving it?

In the meantime, you have to wonder: is this a sort of "you get what you pay for" scenario, and you pay nothing, so you get… no reliability?

The problem is when folks - and I’m not saying just like this thread, but this is a phenomenon in some governance - when folks say that self-driving cars mean that we should reduce public transit or rail investment now, because those problems will be solved, right around the corner, as soon as the cars work.

If/when self-driving cars happen, sure, that’ll be great! People who are skeptical about the technology aren’t going to stop Tesla or Waymo from forging ahead. But car-centric planning does, currently, reduce public transit investment, and self-driving car hype does reduce the political will to build rail.

“Modern” car dependent suburbs are beyond saving. We should save the towns we can and resist this suburb-style development in and around cities.