Success rate in that era was very low. There are thousands of movies from that time that no one cares about today.

Do you know of anything like AoC but that feels less contrived? I often spend the most time understanding the problem requirements because they are so arbitrary - like the worst kind of boardgame! Maybe I should go pick up some OSS tickets...

Take a look at Everybody Codes. It occurs in November instead of December, so this year is wrapping up. Like AoC, it is story based but maybe you'll find the problem extraction more to your liking.

https://everybody.codes/events

Being contrived, with puns or other weirdness is kinda on par for this kind of problems. Almost every programming competition I've ever been to have those kind of jokes.

Just a random example: https://open.kattis.com/problems/magicallights

But the Kattis website is great. The program runs on their server without you getting to know the input (you just get right/wrong back), so a bit different. But also then gives you memory and time constraints which you for the more difficult problems must find your way out of.

Terse languages with great collection functions in the standard libraries and tail call optimization. Haskell, OCaml, F# ...

- Write side is a Postgres INSERT

- Read side is a SELECT on a Postgres view

I think you might struggle to "scale the read and write sides independently".

It's a real stretch to be describing a postgres view as CQRS

Sqlite can scale CQRS to 100000 events per second on a relatively small VPS. That's 10x what the author achieves with postgres.

You can scale them independently in that you can control the rate at which your views are read and the batch size of your updates.

The whole big win wirh CQRS is it allows for very efficient batching.

But only one server can access each SQLite at a time?

I've heard worse, e.g.

You use POST for your Cs and GET for your Qs. Tada!

Huh?

That's EXACTLY what CQRS.

I think you might struggle to understand CQRS.

> Go is one of the best languages to go for Event Sourcing toda

Can you explain this? Go has a very limited type system.

How does event sourcing handle aggregates that may be larger than memory?

Smaller aggregates.

You really don't want your streams/aggs to come close to being that large.

This assumes the boundary between Python and the native code is clean and rarely crossed.

I've never understood this. Python cannot be optimized like C, C++ or Rust. It cannot do advanced functional things like OCaml, Haskell or Scala. It cannot run in browsers like TypeScript. It cannot do games programming like C# and it can't do crazy macro stuff like Clojure. I don't think it's even second best at those things.

I'm reading this as, "It cannot do things the best", and that's correct. It can't.

But it can do them well enough, and enough people know it that they can drag a solution across the line in most domains.

Sure, Python has types as part of the syntax, but Python doesn't have types like Java, C#, etc. have types. They are not pervasive and the semantics are not locked down.

This surprises me.

If you want the .NET ecosystem and GC conveniences, there is already F#. If you want no GC and RAII-style control, then you would already pick Rust.