So it’s not presenting a smaller api footprint than beam?
Conversation
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
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
Ahh gotcha. Maybe I am more use to seeing academic code… just often find it can get pretty hard to track down where symbols come from when I'm reading stuff on Github :(
Yeah I have seen some codebases where they open a bunch of modules at the top. In practice it’s considered bad style, unmaintainable.
1
+1 to the above! What's the point of all the awesome local open syntax if you never use it?
1
1
Show replies