Like if I add library X to my Cabal file, and then later add library Y, there's always a chance that my library will fail to build with a confusing constraint error due to an incompatibility in some common ancestor dependency Z having an incompatible version.
Conversation
All true, but I do think the Rust package ecosystem will hit its own strain points (e.g. tokio vs async-std today) as it grows and the pace of development gets less uniform. But we've been talking about external things almost exclusively here, and I agree, these are essential!
1
2
Oh yeah, absolutely agree with that!
1
Really hoping that Multicore OCaml's effects and handlers will provide a nice example for future languages to follow - once it lands that is! Seems like a nice way of handling the problem of ecosystems fracturing along sync/async boundaries.
1
1
I'm not well in tune with the OCaml ecosystem, but my understanding is that competing stdlibs have already (unintentionally) caused some amount of fracturing.
1
1
Oh yeah, more talking about the yet-to-land Multicore OCaml project. Which will make it easy to make functions that are polymorphic over whether or not they can be run synchronously or asynchronously.
1
2
I need to read up on that! Rust is providing a wealth of learning for everyone on that front.
1
1
For example:
map : ('a ~> 'b) ->> list 'a ~> list 'b
which is sugar for:
map : ('a -[e]-> 'b) ->> list 'a -[e]-> list 'b
where `~>` is an effectful function, and `->>` is a pure function. This avoids stuff like Haskell's `mapM` and `mapA` etc.
1
4
Because OCaml uses effects as part of asynchronous scheduling, this means `map` can be used synchronously or asynchronously.
1
4
Oh, wow, that does look fantastic!
1
1
Replying to
Yeah it's neat! I think that trying to do this nicely in a language like Rust would be much trickier due to issues with memory management and so called 'zero cost abstractions' etc. but it would be cool to see effects and handlers to brought to the world of systems programming.