4 ms·

> For the better or the worse, this is literally the #1 priority one has to have before trying to technically evaluate a language / framework these days. Well,

> For the better or the worse, this is literally the #1 priority one has to have before trying to technically evaluate a language / framework these days. Well, people use OCaml, I've introduced and used it in a couple of workplaces. OCaml shines in domains like system programming, and it's worth trying to introduce it for your team and see how it will end (for small projects if OCaml fits the domain). I did that couple of times and people were glad not only because it's a delightful language to work with, but also because you can learn some stuff while working with it. > Sure, many other languages suffer from that but it's still a very good ideal to strive for I think that it's an unachievable ideal. There are two approach: batteries included and community driven. Former leads to bloated slow half-baked or even straight incorrect implementations of every algorithm or parser or server people need in the standard library (python way). Latter leads to fragmentation. Neither is perfect, and I haven't seen a language without such troubles.

wtetzner 6y ago
> I think that it's an unachievable ideal. There are two approach: batteries included and community driven. You know, there might be a somewhat nice middle ground: after several community driven libraries have materialized, maybe include some interfaces in the standard library, that allow users to choose which community library the want without having to hardcode too much to that library. It's not perfect and wouldn't work for every situation, but might be a way to soften the downsides of the community-driven approach.
- ernst_klim 6y ago
  Well many OCaml libraries do abstract from Lwt/Async using Functors allowing you to choose library you want to go with. But it's still not perfect since sometimes third party libraries still need to write concrete implementation of something diving into lower level, hence breaking the abstraction. This "interface" approach wouldn't work in all cases.
- pdimitar 6y ago
  > after several community driven libraries have materialized, maybe include some interfaces in the standard library, that allow users to choose which community library the want without having to hardcode too much to that library. That's what Elixir did with calendars and timezones. Worked great.

wtetzner 6y ago

> I think that it's an unachievable ideal. There are two approach: batteries included and community driven. You know, there might be a somewhat nice middle ground: after several community driven libraries have materialized, maybe include some interfaces in the standard library, that allow users to choose which community library the want without having to hardcode too much to that library. It's not perfect and wouldn't work for every situation, but might be a way to soften the downsides of the community-driven approach.

ernst_klim 6y ago
Well many OCaml libraries do abstract from Lwt/Async using Functors allowing you to choose library you want to go with. But it's still not perfect since sometimes third party libraries still need to write concrete implementation of something diving into lower level, hence breaking the abstraction. This "interface" approach wouldn't work in all cases.
pdimitar 6y ago
> after several community driven libraries have materialized, maybe include some interfaces in the standard library, that allow users to choose which community library the want without having to hardcode too much to that library. That's what Elixir did with calendars and timezones. Worked great.