- instig007It's perfect for most Python developers actually, not just for myself, contrary to your "in practice" claim.
- > pyrsistent is super slow, though
Since when is Python about speed?
> Just ran a quick benchmark
Where's the code? Have you observed the bottleneck call?
> Except at 10k+ items, batchup dates on 100K+ items or inserting 100 keys.
> This is rarely the case in practice
Where's the stats on the actual practice?
> You'd better have an incredible ROI to justify that.
The ROI being: fearless API design where 1) multiple instances of high level components are truly independent and could easily parallelize, 2) calling sites know that they keep the original data intact and that callees behave within the immutability constraints, 3) default func inputs and global scope objects are immutable without having to implement another PEP, 4) collections are hashable in general.
- The free Idea in December 2025: no JS code completion.
- > most software engineers are not writing banking software
Many software engineers write software for people who won't like the idea that their request/case can be ignored/failed/lost, when expressed openly on the front page of your business offering. Are bookings important enough? Are gifts for significant events important? Maybe you're okay with losing my code commits every once in a while, I don't know. And I'm not sure why you think it's okay to spread this bad management idea of "not valuable or critical enough" among engineers who should know better and who should keep sources of bad ideas at bay when it comes to software quality in general.
- > software engineers have egos that will not let them accept that they are not designing critical stuff
> Don't write bad code, but also sometimes just getting something out the door is much better than perfect quality (bird in the hand and all that).
Your bank account can be represented as a CR app, it's two letters short of CRUD, but it doesn't make it simple or simpler in any sense of the words.
Now the question: how much are you tolerant to bugs in your bank account? How often can they happen before you complain?
- > and a decade of tinkering has just fatigued everyone and destroyed any momentum the language once had.
it's hard to buy it, considering that many of those "fatigued" moved on Kotlin, led by their managers' bs talking points.
- > but the reason Unison is a new language is exactly to avoid the limitations of such frameworks
by introducing another set of limitations that Unison docs don't state upfront, because it will affect their progression as the business.
> namely that they _can't_ send arbitrary code and data around like Unison can.
> You should totally write up a tutorial demoing the development of the same application using each. Folks would love that.
You should add "out of the box", and that "like Unison can" isn't the only way to implement a distributed runtime. This leads to another logical question: why should I "totally write up" the Unison way of things? At this point I'm not even sure that 99.999% of workloads need distributed runtimes of any kind, let alone the Unison one.
- > And I bet those green threads still need an IO type of some sort to encode anything non-pure, plus usually do-syntax.
There's no need for the do-syntax at all. The (IO a) is no different to other generic types that can be fmap-ed, pointfree-composed with other expressions, and joined/folded when required. The only difference is the fact that they represent actions that affect the real world, so that ordering of things suddenly becomes important.
- If you ever need this kind of stuff, you'll be better off building your own distributed interface by using plain regular GHC Haskell and https://haskell-distributed.github.io/
- > std::variant and std::optional are not nearly as ergonomic or safe to use as rust equivalents.
> but I also use rust daily and you cannot really make a straight faced argument that c++ is catching up.
I mostly use std::ranges, lambdas, and concepts, and I see them catching up, as an evolutionary process rather than a fixed implementation in the current standard. Nowadays I can do familiar folds and parallel traversals that I couldn't do in the past without assuming third-party libraries. My optionals are empty vectors: it suits my algorithms and interfaces a lot, and I never liked `Maybe a` anyways (`Either errorOrDefault a` is so much better). I also use Haskell a lot, and I'm used to the idea that outside of my functional garden the industry's support for unions is hardly different to the support of 2-tuples of (<label>, <T>), so I don't mind the current state of std::variant either.
- > The range of problems where C++ is unequivocally the superior solution is getting smaller.
The range of issues where the superior solutions offer language features superior to the features of modern C++ is getting smaller too.
- > Once you get to that point, you might as well create and learn a different language.
Nope, it's still incredibly valuable to be able to c++14 and c++26 two different translation units and then later link them together (all without leaving the familiar toolchains and ecosystems). That's how big legacy projects can evolve towards better safety incrementally.
- Sweden isn't famous for good tech salaries and stock grants though, even among the best/high profile engineers.
- > orders.c.id
you don't need .c. in recent releases, you can just use the same model attributes as in orm.
- how exactly do you compile to sql?
- It's not heavy. The abstrations allow for consistent query compositions from reusable expressions. Demonstrate how you do conditional query building for everyone to witness the way.
- > Building a framework on a non-async foundation (flask) in 2025 is bizarre.
Assuming that non-blocking sockets require a special language syntax that breaks seamless compositionality of functions is a lack of fundamental knowledge. No wonder you refer to the industry adoption (crowd opinion) in your next sentence, instead of applying the first-principles analysis. In 2025, the expectation is that you should've at least tried learning how Project Loom is implemented, before venturing bold opinions on the async keyword in Python: https://openjdk.org/projects/loom/
> The only way to scale a flask API is to use gevent, which is just problems waiting to happen.
This is FUD.
- skill issue
- > but I wanted something more lightweight
it's called "sqlalchemy core"
- > if you can write compilers anything that involves composing functions is weak beer
> screwing around with functions and macros doesn't hold a candle to what you learn from the Dragon Book.
---
So, what is it that you learn from that book that's a revelation for you compared to the weak beer of composable effect systems?