7 ms·

> I'd choose Scala and get a large and active community, as many Java libraries as there are stars in the sky, and the most sophisticated runtime environment ma

> I'd choose Scala and get a large and active community, as many Java libraries as there are stars in the sky, and the most sophisticated runtime environment mankind has ever dreamed of (for better or worse). Hahahaha oh wow. You never ever used Scala, aren't you? I did, I moved from OCaml to Scala. Oh, good luck joining Scala community then, we don't have aforementioned problems, don't we? Because Akka vs Zio vs Cats vs Scalaz is not a thing. Because ensime vs metals debacle never happened. Because we don't rewrite the complete ecosystem each couple of years. > most sophisticated runtime environment mankind has ever dreamed of Which you need to tune quite a lot to fit Scala into it (hopefully, it's very tuneable). Oh, and this "most sophisticated runtime" doesn't support TCO btw. Oh, and any AnyRef value (so anything but basic types) can be null, thanks, runtime. I love Scala, but all these "I wouldn't choose OCaml, I would choose F#/Clojure/Scala/other obscure language" usually mean "I've tried ocaml but didn't try other obscure language, so maybe it's better" I love OCaml is well, and most of your points could be reduced to simply "it's lacking manpower" (Scala is lacking it too). Because all of the "why is stdlib vs. Core vs. Batteries and Async vs. Lwt still an issue" we have in C, C++ and many other popular languages too, but it's not a big issue. People complain on meson/cmake/autotools/boost/glib/qt but not leave for some reason. Maybe people don't use OCaml that much rather because there are simply too few jobs and too few programmers and it's a simple chicken and egg problem. And all these technical rationalization is not the reason because it's applicable to quite a lot of languages (safe for lack of libraries)

pdimitar 6y ago
Yep, I completely get the "the grass is NOT greener on the other side" sentiment. I've been a victim of it many times and I am much more careful these days. > I love OCaml is well, and most of your points could be reduced to simply "it's lacking manpower" (Scala is lacking it too). 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. Otherwise you get sucked on a joyful ride at the end of which you find lack of employability. :( I personally much prefer OCaml's syntax but since Rust has much more mindshare and is mostly serving the same niche (with GC being the apples-to-oranges comparison here), I preferred to work with Rust. I still would like to work with OCaml but the odds are stacked against the financial incentives of doing so. > Because all of the "why is stdlib vs. Core vs. Batteries and Async vs. Lwt still an issue" we have in C, C++ and many other popular languages too, but it's not a big issue. People complain on meson/cmake/autotools/boost/glib/qt but not leave for some reason. Sure, many other languages suffer from that but it's still a very good ideal to strive for -- namely have very few (ideally one) ways of doing things. I personally look for such languages / frameworks and sadly they are very few and far between (Elixir and Clojure come to mind as refreshing exceptions and even they don't follow it everywhere). --- In the end, we all do this for money. If I could work without charging for it then I'd likely know more languages and even work more overall, but it's not the reality we are living in currently.
- ernst_klim 6y ago
  > 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.

pdimitar 6y ago

Yep, I completely get the "the grass is NOT greener on the other side" sentiment. I've been a victim of it many times and I am much more careful these days. > I love OCaml is well, and most of your points could be reduced to simply "it's lacking manpower" (Scala is lacking it too). 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. Otherwise you get sucked on a joyful ride at the end of which you find lack of employability. :( I personally much prefer OCaml's syntax but since Rust has much more mindshare and is mostly serving the same niche (with GC being the apples-to-oranges comparison here), I preferred to work with Rust. I still would like to work with OCaml but the odds are stacked against the financial incentives of doing so. > Because all of the "why is stdlib vs. Core vs. Batteries and Async vs. Lwt still an issue" we have in C, C++ and many other popular languages too, but it's not a big issue. People complain on meson/cmake/autotools/boost/glib/qt but not leave for some reason. Sure, many other languages suffer from that but it's still a very good ideal to strive for -- namely have very few (ideally one) ways of doing things. I personally look for such languages / frameworks and sadly they are very few and far between (Elixir and Clojure come to mind as refreshing exceptions and even they don't follow it everywhere). --- In the end, we all do this for money. If I could work without charging for it then I'd likely know more languages and even work more overall, but it's not the reality we are living in currently.

ernst_klim 6y ago
> 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.