the `DbStoreEffect` is indirection layered on top of `beam`
it only really has one reasonable interpretation, but even _if_ the argument is that you could use the `beam`-specific types for a test implementation (or something) they don't do this at all!
Conversation
So it’s not presenting a smaller api footprint than beam?
1
1
ah, it looks like they hired enthusiastic haskell programmers and just let them do what they wanted. Classic mistake. That API looks horribly complicated.
1
5
Agreed. I also think Haskell has some serious ergonomic problems for software at significant scale, and most of it isn't serious semantic problems in language design but syntactic stuff like overhead when using monads vs pure code, namespacing, records etc.
2
3
Maybe the lack of a module system on top of simple functions
1
2
Rust's module system is not much more complex than Haskells, but it allows nested modules and defines a special module for each type, containing its constructors and utility functions. That is enough to solve the problems in that area I think. No need for ML modules even.
1
3
I love in Rust how the convention is to import stuff in a fine-grained way, as opposed dumping the entire contents of a module into the current scope… I struggle with this so much in languages like OCaml and Haskell.
Also how variants are namespaced behind the type name… little stuff like that makes navigation and reading code so much easier, imo.
1
1
In OCaml the convention is to namespace nearly everything behind its module name and open everything else in as small a scope as possible…
2
One of the few conventions in OCaml I like..
2