TBH, a bit of up front research would have found all of those issues in the beginning.
As somebody who’s pretty dedicated to working with an obscure language (Common Lisp), my advice is that if you’re not able (or not willing) to help write the missing libraries and tools that you need then you’re almost certainly better off using a language that already has them.
Although Common Lisp is not mainstream, but I wouldn’t say it’s obscure. There’s plenty of libraries, the developer experience is very good (ASDF, Quicklisp, etc). And there’s quite a lot of deep production use of CL.
We have considered OCaml but went for F# instead. I could not be happier. Great libraries, good tooling, in 2020 F# is a first class citizen in the cloud thanks to C# and .NET Core. You can develop on Linux, Windows, MacOS and without modification it works. Compilation times are great. Unless you want to deal with the low level nature and the C++ influence in Rust F# is a much more logical step to move from OCaml. There is dotnet fsi for REPL too. I really like OCaml, it was my first ML language but it is not great for cloud computing or anything where you do not want to write a ton of code that has nothing to do with your business problem, because there aren’t many libraries. F# has access to C# libraries and it is relatively easy to write a thin wrapper that convert nulls to Nones, so you are null safe or C# style functions to ML style functions so you can use |> or <| etc. Out frontend is in Elm and we follow
elm-format style in F# (manually though) so our codebases look very similar.
What’s your problem domain? I will use F# at a new job, and I would love to hear which libraries & frameworks you love, and which resources are good for learning.
For context, I already know Elm very well, and Haskell at an intermediate level. I also plan to work through “domain modelling made functional”.
That would be awesome! I’m especially interested in what stands out, or strong opinions you have derived from your experience. I’m sure I can find the very basic stuff with a bit of research :)
You can develop on
Linux, Windows, MacOS and without modification it works.
AFAIK, F# programs need the .NET runtime being installed.
How do you enforce this on the client side?
Or is it possible to bundle the runtime with your program?
Publishing your app as self-contained produces an application that includes the .NET Core runtime and libraries, and your application and its dependencies. Users of the application can run it on a machine that doesn’t have the .NET Core runtime installed.
fairly lousy in my experience. i try it every year or two, because it really does sound like a great language for it, and invariably end up giving up after a few days due to running into issues with linux as my development environment. that said, my last attempt was in 2018 so things might be better now; i would personally like to see a working, reasonably-sized gui app somewhere on github that i could use as a reference before trying again.
It’s okayish. Worst case you can use C# for UI which has better tooling. Check out Avalonia which supports Windows, MacOS, and Linux, with Android and iOS coming soon.
I see that this post is a merge of two submissions. Could you we make the second submission’s title (Dark’s new backend will be F#) the default title, as that’s a bit more informative when glancing the frontpage?
Language tutorials are extremely poor in OCaml compared to other languages; they’re mostly lecture notes from academic courses.
Given the language’s origins, there are a lot of resources written in French (As a quick example, https://ocaml.org/learn/books.html list 16 books in French, compared to 12 books in English). I haven’t read enough of them to come to a conclusion, but it’s possible that some of the good resources are in French.
I wish the OP good luck with finding their next language.
The one argument that rings true is the overall quality of the documentation. Not the core language, mind (that one is usually quite excellent), but for most libraries in the ecosystem. It’s not that it’s bad in the sense of lacking or half-backed, but I feel like library authors expect a very high level of fluency in the language and the concepts from their users. Lwt is indeed a good example of a critical piece of software in the OCaml ecosystem that could deserve a bit of documentation TLC.
For the other points, YMMV:
I have never needed multicore OCaml and Lwt has always been more than enough for my use cases.
I have always found OCaml tooling to be first class (the compiler itself has gotten a lot better with error reporting over the years, merlin and ocaml-lsp are top shelf).
IDE integration has always been premium within vim. The OP issues could be because of ReasonML.
The only tool you really need is opam. The dune build tool is certainly an improvement over the dark days of oasis and ocamlbuild but it is not required to get started. I have never heard of esy and never ever used it.
“Real World OCaml” is excellent for any beginner wanting to get into the language.
If support for some API or service is missing I usually end up writing the necessary libraries. I always found that fairly straightforward especially given the very high quality of some core libraries like opium, cohttp, or conduit, to mention only a few. But I understand how that could be seen as an impediment when the focus is to deliver a PoC or a MVP.
The only tool you really need is opam. The dune build tool is certainly an improvement over the dark days of oasis and ocamlbuild but it is not required to get started. I have never heard of esy and never ever used it.
This may be true, but when I was learning OCaml there was no way for me to find it out. There was no high-level description of how the tools fit together; all the docs that mentioned ocaml, dune, and ocamlbuild just assumed you were already familiar with what they were for. As someone new to the language, it just made my head spin trying to figure out how the pieces fit together.
Rust sounds like a good match (but i doubt that’s your choice because I think you tried it already). But see the recent post here about rust being as productive as kotlin.
My money is on F#. He gets everything he likes from OCaml as well as proper multicore support. Plus he has the entire .NET ecosystem to fall back on when it comes to libraries, documentation etc.
Rust has a much bigger ecosystem especially in terms of “cloud” and web stuff. You won’t have the “there’s no google cloud client library and the postgres client is incomplete” problem in Rust.
Rust is approaching 50,000 crates (that’s 1/5th of nuget, and more than CPAN). It’s not as big as mainstream package repositories, but it’s definitely past being a niche language.
Rust doesn’t really have a good official google cloud sdk. I think the safest choice is Go if your aim is interfacing with google products.
That being said, I wish someone made the equivalent of bucklescript/reasonml that compiles to go so you can just use ocaml with go’s extensive set of libraries.
That’s one of the reasons I don’t like Go—its ecosystem is a walled garden.
OCaml libraries are usable from other languages, you can write a shared library in it. Whether to link everything statically is a choice. With Go you don’t have that choice, if you write a library, no one but other Go users can ever benefit from it.
I am quite fascinated by both their technology and their story. I sent the author an interview request. Sure hope he has time to chat some. I imagine those guys are getting a ton of attention right now!
I used OCaml for a personal project and what’s described here on tooling and general user-friendliness is sadly correct. And I didn’t need that many libraries, wasn’t writing a web service, or connecting to a third-party… it was a static-site generator! I really, really tried to make something positive come from my frustrations and wrote up some things I wish I’d known before, but you can tell the post is a bit seething with how hard it was to find what I needed.
I think a doc like What I Wish I Knew When Learning Haskell or even How I Start would do a lot of good. There’s so much there that I love and I’d love to use it for more projects but it’s such a spiny experience I can’t recommend it to those who value their time.
Clojure is dynamically typed, you can’t reuse the Java type system (and even if you could, it’s not a great type system). We experimented with Core.Typed, a library for static typing in Clojure, here’s how that went:
TBH, a bit of up front research would have found all of those issues in the beginning.
As somebody who’s pretty dedicated to working with an obscure language (Common Lisp), my advice is that if you’re not able (or not willing) to help write the missing libraries and tools that you need then you’re almost certainly better off using a language that already has them.
Although Common Lisp is not mainstream, but I wouldn’t say it’s obscure. There’s plenty of libraries, the developer experience is very good (ASDF, Quicklisp, etc). And there’s quite a lot of deep production use of CL.
If you look at some of the other posts related to async and performance, they do seem to re-learn things.
We have considered OCaml but went for F# instead. I could not be happier. Great libraries, good tooling, in 2020 F# is a first class citizen in the cloud thanks to C# and .NET Core. You can develop on Linux, Windows, MacOS and without modification it works. Compilation times are great. Unless you want to deal with the low level nature and the C++ influence in Rust F# is a much more logical step to move from OCaml. There is dotnet fsi for REPL too. I really like OCaml, it was my first ML language but it is not great for cloud computing or anything where you do not want to write a ton of code that has nothing to do with your business problem, because there aren’t many libraries. F# has access to C# libraries and it is relatively easy to write a thin wrapper that convert nulls to Nones, so you are null safe or C# style functions to ML style functions so you can use |> or <| etc. Out frontend is in Elm and we follow elm-format style in F# (manually though) so our codebases look very similar.
What’s your problem domain? I will use F# at a new job, and I would love to hear which libraries & frameworks you love, and which resources are good for learning.
For context, I already know Elm very well, and Haskell at an intermediate level. I also plan to work through “domain modelling made functional”.
SAAS, energy, finance.
I could collect some of the libraries for you.
That would be awesome! I’m especially interested in what stands out, or strong opinions you have derived from your experience. I’m sure I can find the very basic stuff with a bit of research :)
Mind sharing company’s name? Curious about places using functional programming languages.
Sure, it’s called valora digital. It’s in the retail space, based in Switzerland. We’ll basically build self-serve stores and a bunch of ecommerce.
My sole issue with F# is that dotnet has no support for the ppc64le architecture yet.
There is some progress on this front: [1] [2] [3]
AFAIK, F# programs need the .NET runtime being installed. How do you enforce this on the client side? Or is it possible to bundle the runtime with your program?
https://docs.microsoft.com/en-us/dotnet/core/deploying/
Thanks. Do you know much MBs this adds to an “hello world” application?
A lot, in my experience. A simple program that uses nothing but the standard library will output a binary of about 90mb.
Do you know if there are any efforts in the pipeline to modularize .NET, like JDK 9 did?
And? How is this related to my comment about development?
How good is F# for writing cross-platform GUI apps?
fairly lousy in my experience. i try it every year or two, because it really does sound like a great language for it, and invariably end up giving up after a few days due to running into issues with linux as my development environment. that said, my last attempt was in 2018 so things might be better now; i would personally like to see a working, reasonably-sized gui app somewhere on github that i could use as a reference before trying again.
Good question, I have no idea.
It’s okayish. Worst case you can use C# for UI which has better tooling. Check out Avalonia which supports Windows, MacOS, and Linux, with Android and iOS coming soon.
I see that this post is a merge of two submissions. Could you we make the second submission’s title (Dark’s new backend will be F#) the default title, as that’s a bit more informative when glancing the frontpage?
Given the language’s origins, there are a lot of resources written in French (As a quick example, https://ocaml.org/learn/books.html list 16 books in French, compared to 12 books in English). I haven’t read enough of them to come to a conclusion, but it’s possible that some of the good resources are in French.
I wish the OP good luck with finding their next language.
The one argument that rings true is the overall quality of the documentation. Not the core language, mind (that one is usually quite excellent), but for most libraries in the ecosystem. It’s not that it’s bad in the sense of lacking or half-backed, but I feel like library authors expect a very high level of fluency in the language and the concepts from their users.
Lwtis indeed a good example of a critical piece of software in the OCaml ecosystem that could deserve a bit of documentation TLC.For the other points, YMMV:
Lwthas always been more than enough for my use cases.merlinandocaml-lspare top shelf).vim. The OP issues could be because ofReasonML.opam. Thedunebuild tool is certainly an improvement over the dark days ofoasisandocamlbuildbut it is not required to get started. I have never heard ofesyand never ever used it.If support for some API or service is missing I usually end up writing the necessary libraries. I always found that fairly straightforward especially given the very high quality of some core libraries like
opium,cohttp, orconduit, to mention only a few. But I understand how that could be seen as an impediment when the focus is to deliver a PoC or a MVP.This may be true, but when I was learning OCaml there was no way for me to find it out. There was no high-level description of how the tools fit together; all the docs that mentioned ocaml, dune, and ocamlbuild just assumed you were already familiar with what they were for. As someone new to the language, it just made my head spin trying to figure out how the pieces fit together.
Followup: https://blog.darklang.com/new-backend-fsharp/
Rust sounds like a good match (but i doubt that’s your choice because I think you tried it already). But see the recent post here about rust being as productive as kotlin.
My money is on F#. He gets everything he likes from OCaml as well as proper multicore support. Plus he has the entire .NET ecosystem to fall back on when it comes to libraries, documentation etc.
Looks like you were right:
https://blog.darklang.com/new-backend-fsharp
You nailed it!
It sounds like Rust would be an awful choice, because most of his complaints are true for Rust as well, especially where the ecosystem is concerned.
Rust has a much bigger ecosystem especially in terms of “cloud” and web stuff. You won’t have the “there’s no google cloud client library and the postgres client is incomplete” problem in Rust.
Rust is approaching 50,000 crates (that’s 1/5th of nuget, and more than CPAN). It’s not as big as mainstream package repositories, but it’s definitely past being a niche language.
It doesn’t matter how many crates exist if none of them provide what you need
That’s a meaningless tautology. It’s true when applied to any language.
Rust doesn’t really have a good official google cloud sdk. I think the safest choice is Go if your aim is interfacing with google products.
That being said, I wish someone made the equivalent of bucklescript/reasonml that compiles to go so you can just use ocaml with go’s extensive set of libraries.
That’s one of the reasons I don’t like Go—its ecosystem is a walled garden.
OCaml libraries are usable from other languages, you can write a shared library in it. Whether to link everything statically is a choice. With Go you don’t have that choice, if you write a library, no one but other Go users can ever benefit from it.
I am quite fascinated by both their technology and their story. I sent the author an interview request. Sure hope he has time to chat some. I imagine those guys are getting a ton of attention right now!
I used OCaml for a personal project and what’s described here on tooling and general user-friendliness is sadly correct. And I didn’t need that many libraries, wasn’t writing a web service, or connecting to a third-party… it was a static-site generator! I really, really tried to make something positive come from my frustrations and wrote up some things I wish I’d known before, but you can tell the post is a bit seething with how hard it was to find what I needed.
I think a doc like What I Wish I Knew When Learning Haskell or even How I Start would do a lot of good. There’s so much there that I love and I’d love to use it for more projects but it’s such a spiny experience I can’t recommend it to those who value their time.
I can’t help but notice this:
in light of the Tea language project, which someone is actually helping with me now!
https://github.com/oilshell/oil/tree/master/tea
The README.md links to previous lobste.rs threads on the subject.
Also related: https://lobste.rs/s/vmkv3r/first_thoughts_on_rust_vs_ocaml#c_v5ch1q (previous OCaml vs. Rust thread)
I’d like to see why they chose OCaml then F# over Clojure, considering his previous experience with Clojure.
Static typing
Thanks for replying!
Does that really make a large difference? Clojure sits on top of the JVM with that type system, would it have been a problem to build on top of that?
Clojure is dynamically typed, you can’t reuse the Java type system (and even if you could, it’s not a great type system). We experimented with Core.Typed, a library for static typing in Clojure, here’s how that went:
https://circleci.com/blog/why-we're-supporting-typed-clojure/ https://circleci.com/blog/why-were-no-longer-using-core-typed/
So final question on the topic, was static typing really so important for Dark?
yeah, absolutely. We’ve made so many huge changes and the compiler guides us the whole way. We were deathly afraid of making changes in Clojure.