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've been playing around with some of the "standard/common monads in C# for a while now, in OSS (https://github.com/pimbrouwers/Danom) and at work. It's awesome. I can't imagine working without them anymore.

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

I’m excited to share a project I’ve been working on for the past 8 months called Danom. After spending 6 years writing F#, I found myself in a situation where C# was mandated. I thought to myself, "I wonder if Option and Result functionality would translate effectively into C#?".

Obviously, implementing them was possible, but what would consumption be like? It turns out, it's amazing. There were already some open-source options available, but none of them had an API that I loved. They often allowed direct access to the internal value, which I felt defeated the purpose.

So, I decided to create Danom with a few key goals in mind:

- Opinionated Monads: Focus on Option and Result rather than a more generic Choice type.

- Exhaustive Matching: An API that enforces exhaustive matching to ensure all cases are handled.

- Fluent API: Designed for chaining operations seamlessly.

- Integration: Works well with ASP.NET Core and Fluent Validation.

The pattern has exceeded my expectations, making functional programming patterns in C# not only possible but enjoyable. If you’re interested in bringing some of the functional programming paradigms from F# into your C# projects, I’d love for you to check it out.

You can find the project here: https://github.com/pimbrouwers/danom.

Looking forward to your feedback and contributions!

Legend has it, if you play Danom backwards it will reveal the meaning of life.

This was very interesting and a clever way to demonstrate the state of AI video gen.

I really like this. My only pause would be strict CSPs that don't allow inline scripts. I suppose in those cases you're able to use the selector overload.

Damn this is cool!

You had me until JVM

Very neat John! Bookmarked.

My best advice, try it! I have used it many times for server apps with great success, namely "forms-over-data" systems, some even with a large user base but low concurrency.

Some tips to make this work:

- use the latest version

- use write-ahead logging

- use synchronous execution model

- favor insert (and delete) over update

- favor many small, simple queries over larger, all-serving queries

- open and close connections quickly

- employ app level validation

- define a typed schema

Falco is a toolkit for building functional-first, fast and fault-tolerant web applications using F#.

Built upon the high-performance primitives of ASP.NET Core. Optimized for building HTTP applications quickly. Seamlessly integrates with existing .NET Core middleware and frameworks.

So glad to hear that!

Toronto without question. There are some company's in Waterloo as well, Google has a presence there for example, because of the University of Waterloo. But it is not as bustling as it was when RIM was still a big thing.