so yeah idk, i just don't really see the value around using extensible effects for this kind of thing.
there's some justification in that they're instrumenting some of the effects w/ like `trace` or w/e but it's just like... why use this construction?
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.
2
1
Also how variants are namespaced behind the type name… little stuff like that makes navigation and reading code so much easier, imo.