pimbrouwers

very cool little project! just wanted to mention your footer like is missing the user and repo from the link.

Great post. Also, I absolutely love your website.

I normally do a much deeper dive into the existing ecosystem before I write a library like this. In this case, I tried a few of the popular packages, but in the end decided my own pursuit of the exact types I wanted was more interesting. So, I just went for it.

100%! I would be thrilled! Thank you very much.

I can second this experience. I arrived roughly 10 years ago, right in time to see netcore1.0 emerge. Been onboard even since. You should absolutely check it out. The compilation story (native aot) is what I'm currently most excited about it.

Not a python developer, just casually curious about the discourse. But I wanted to say that I completely agree with the point on letting dynamic languages be dynamic. Otherwise, you reduce the benefit of a dynamic language to the point where I feel like the value proposition comes too close to disappearing. Really at that point, you're just trading performance for compile time or lack there of.

Recency bias playing a factor here. But System.Data.SQLite. When you scan around the offerings of the other top-shelf languages, it becomes quickly evident how good/reliable that DLL is. Not to mention that it's maintained by he SQLite team. SQLite has been having a moment in the sun, and this is the perfect package to use it in production.

Hi Isaac ;) Of course you can train people. But in my experience they take a lot longer to learn than you suggest.

Our shop converted 6 years ago, from C# to exclusively F#. I also author and maintain some packages (falco, donald, validus and others). The language is tough to learn if you're coming from a C-style language. But worth the effort and experience. It's extremely concise a true delight to build programs in that are fast, robust and durable.

There are a few drawbacks, depending on your perspective:

- compilation is slower than c# and hot reload isn't supported (it's in progress)

- there are very few opportunities to use it professionally

- hiring devs can be challenging

I came to say exactly this. I was sucked right into this. I am looking forward to reading more thoroughly and understanding it better.

It most definitely does not. Yes, you will lose foreign keys across silos. But this will usually be one association, like a user id for example.

You are also thinking of this defensively, "x value cannot exist here if it doesn't exist in y store". Just think how you'd access this, and you'll realize at worst this creates a void of data which your app likely handles anyway.

If there are numerous associations required across these silos. You don't have the right silos yet.

Be brave. Just try it.

Removing the network latency is a massive gain, especially for small/medium apps, which is most sites. And if you find yourself asking this, the answer is yes, it will work.

SQLite will force you to rethink your architecture a bit, don't forget it doesn't HAVE to be _one_ file. This alone helps you scale further.

There are some chafing points: 1. Schema migrations 2. Configuration, PRAGMA's applied at design time or during each connection