I’m looking for a typed FP language for practical use. I tried Haskell, and while I absorbed so many knowledge while learning it (and thankful for that!), several things that always had me blocked, to name a few, are tooling, looking for proper (maintained) packages for various tasks, and long compilation times.
Currently trying to get my hands dirty (or clean? ) with OCaml. It seems promising if we want to get native performance (challenging C/C++), with fast compilation. However, it being quite an old language and (I believe) not getting the hype and reputation as Haskell, it’s kinda hard to look for both resource and community. I know FB uses OCaml (with their own dialect, Reason), and it’s great, but its use is not quite as talked about as their JS contributions.
So, I’m asking:
How would you suggest learning OCaml for people who aim to get knowledge to get things done? (I’m currently going through Real World OCaml).
Is there any community forum or mailing lists that is friendly for beginners? Forums like Elixir Forum has helped me get updated with stuff happening in the Elixir world. The OCaml mailing lists seemed to have more advanced topics than basic ones, so I guess I’m looking for places where I can “ask away with it”, if there is any.
OGads the compilation times rival C++! The Haskell tooling is pretty good though I’ve always thought, and as for packages that just depends.
Yep, OCaml is significantly faster in compiling than… well almost any compiled and optimized language. Some things you might find odd in its language is design is not ‘holdovers’ but specifically for speed reasons, the language was designed to be quite pure and amazingly fast to parse.
Ocaml is also about the same age as Haskell, which is about the same age as Erlang, early 90’s / late 80’s, and it has a lot more ‘real-world’ use than Haskell, but Haskell is more ‘loud’ because it is used more as a research language. Now to define these more clearly, OCaml’s real-world usage is like Erlang, it is quite functionally pure but it will also sacrifice that in the name of ‘getting stuff done’, compared to Haskell, which is purely functional, in about every aspect, which is nice but can make it hard to get some work done, however because it is so pure it is taught more as a functional language to push the idioms through to your mind. For doing work though I’d recommend OCaml over Haskell any day, for both this reason as well as significantly faster compilation.
The ocaml website itself has a great tutorial section. Real World OCaml is a bit dated but it works well too, however it assumes you have certain packages (like ‘Core’) installed that you will not by default (though they are nice, you cannot use them everywhere). Other than that go through one of those sets-of-problems websites and solve them.
Not really a forum like this, most OCaml’s I’ve seen are on the mailing list or on discord more lately (plus IRC as always). The reason most topics are more than ‘basic’ is because OCaml is actually a very simple language, it is easy to get up with the basics very quickly as well as about every basic question is answered somewhere already, Google.
Also wtf it submitted my post early ‘as’ I was typing, keeping editing it…
coughcough Um yes. ^.^
I’ve actually been learning F* lately too. It is not ‘quite’ as powerful as OCaml in overall abilities, however it has two things going for it, first is that it does not compile to its own thing, rather it compiles to both OCaml and F#, can take your pick, and it has dependent typing (Oh if OCaml had dependent typing it would be such an awesome language), so that might be fun for you to learn too.
Yeah but sadly its lack of a first class module system hobbles it pretty hard, you can kind of work around it with the class system but that incurs an (at times significant) overhead in both coding and performance. It is pretty good if you absolutely have to work with the .NET ecosystem though, otherwise it is just OCaml with some features stripped and slower so you may as well just use OCaml then.
Oh, and OCaml has awesome tooling too! Merlin is behind almost all of it. ^.^
I’ve done a little F# on my Declarative Programming course in Uni a few years ago. I admit that I am a bit biased against Microsoft products (but then again, Microsoft Research and Simon Peyton Jones have significant contributions on Haskell and GHC, so I’m being a bit picky).
Will look at it if I somehow need to tackle the .NET world, thanks!
Is that (using Jane Street’s Core) a bad thing? Would you expand what you mean by “you cannot use them everywhere”? I was under the impression that Core is recommended to have for developing in OCaml, basically because it gives the language a proper standard library.
You mean the #ocaml channel on Reason’s discord? Or does OCaml has a dedicated discord server? I guess Reason’s discord server has quite a bit of activity so I can start there
Thanks for the suggestion, but I think I’ll take this one at a time. Basically I’m looking to have a fast, natively-compiled language up my sleeve since I’ve only worked with Java, PHP, Javascript, Python, and Elixir (which are either interpreted or have their own VM, not necessarily bad, but not suited for some tasks). OCaml seems to fit the bill nicely while being functional, so that’s a plus
Core is indeed quite good, however if you use any of its PPX’s then it becomes more difficult to use in other areas, like bucklescript (different ecosystems), but yes it is quite good.
Nah pretty much that, more activity lately. Most is still mailing list or IRC.
While I adore OCaml for its advantages, this is not one of them. There are less useful basic libraries for OCaml and I don’t see how if this was a problem in Haskell it’s something that’s answered in OCaml. My experience has been the complete opposite. Haskell has a much broader and deeper ecosystem with much better documentation.
For all the flak that Haskell gets for being impractical, OCaml gets very little for not even being able to handle big ints without making your code a complete mess. It seems like a nitpick but it’s a symptom of a sometimes impractical focus on speed, as well as an inherently inflexible polymorphism model that’ll become better SOON™ (where “soon” is defined as “some time in a future where we still have a need for programming languages”). You also need either Batteries or Core (but absolutely not both(???)) to make it usable. Multicore stuff is also coming SOON™.
Also, I would take any claim that OCaml is used more in real-world contexts than Haskell with about a sack of salt. It’s easy to claim but it’s clearly not reflected in the actual progress of the community. Jane Street are really the only ones who care all that much whereas Facebook has about the same interest in it as they do in Haskell (peripherally, and they really only are looking to create languages/frameworks/tools with it). Proposals to fix the two biggest issues with the language haven’t actually come through over several years and they’re basically “Duke Nukem Forever” features at this point.
I was under the impression OCaml was one of the better languages for polymorphism, at least at the module level. Can you elaborate on how polymorphism is currently limited and how people are planning on improving it?
In the Haskell world Backpack is trying to improve module-level polymorphism and composition. One of the mentioned use cases is overriding the default random number generator implementation used by a library you’ve included in your project without forking.
I like both Haskell and OCaml. It’s very possible to do real productive work in both. Since it hasn’t been mentioned yet, I really like the MirageOS project. The idea is to compile your application into a unikernel which can run on Xen. A single Xen node can handle many concurrent unikernels and they boot very quickly. Jitsu takes advantage of this by dynamically creating new unikernels in response to DNS requests.
What do you mean? OCaml’s Module system puts even Haskell’s HKT’s to shame in terms of power (and speed), in addition OCaml also has a full OO class system (that almost no one uses because Modules are better anyway, but it is there and easy to use).
MirageOS is fascinating yes, there are a few things like that for a few languages. ^.^
Type classes are infinitely more practically useful than what OCaml has to offer, which is why using bigints, for example, is a pain. You only have to look as far as the standard operators to see that there should’ve been a much more flexible system (+., etc.).
It’s not convenient enough and it leads to really crappy solutions. Perhaps more annoying is the time it takes them to actually solve it. No one really cares that their proposed solution seems to be best in breed if it takes too long to actually arrive.
Type Classes are like OCaml’s modules via Witnesses, easy to replicate, the standard Core does not use it though (EDIT: Because the OCaml community is mostly agreed on explicit operators make sure that you are working on the right type, use a Witness if you want to be generic). There is a PR in process to add implicit Witnesses to OCaml, you could then easily have a generic + that works on all numeric types without needing to pass a Witness yourself. However passing a Witness is not a hard thing and only adds a few characters for a given usage as it is. In the mean time type classes slow down compilation substantially compared to how Modules work, in addition the HKT’s that are often necessary for type classes slow down compilation to C++ level of slow. OCaml’s method is more powerful, can do more things, compiles in a fraction of a second, compiles to code that is optimized better than Haskell’s, all in exchange for a few extra characters when you want to use that feature (and those few extra characters will not even exist once that PR is finalized and accepted). ^.^
I hope this thread isn’t seen as a bashing of either Haskell or OCaml, I certainly don’t want it to I was providing my anecdotal experience in my first post as a background for me starting this thread. Another thing that also trips me over a few times is determining which type of String to use (String? ByteString? ByteString.Lazy? Text? And also what are Char8 and Word8?) and what their differences are. Sometimes different library uses different types, then you end up having to convert one to another. In my case it caused huge cognitive load.
Then again, I was wondering if these problems exist in OCaml, or if using OCaml would solve them for me.
It wasn’t my intention to seem offended on in the name of Haskell or whatever. Sorry if it seemed like that. Both languages have pretty gaping usability holes, in my opinion. Haskell has about a gazillion string types, as you mention, and no real guide to how they work. My main gripe with OCaml really is that it seems to be the language where pull requests for modern day-to-day features (that it should already have, and have been in the works for several years) go to die. It goes completely against any claim that the language is somehow used more than any other.
Once upon a time I was choosing between Haskell and OCaml and went with OCaml initially. It’s sold as being “more pragmatic” than Haskell, but once I’d become annoyed enough I tried doing what I wanted in Haskell and even though the initial bump was considerably rougher, it was a much more convenient experience.
I would still choose Bucklescript over GHCJS (or any other Haskell-to-JS language/compiler) simply because it seems to map better (and also because I’m hoping for the port of Elm that @OvermindDL1 has created). I also still think that OCaml is great in certain respects. It’s certainly much better than actually doing JS and it’s so much more thought out than Elm, which makes the previously mentioned port actually more promising than Elm itself.
OCaml has one string type, however in older OCaml it is mutable (yeeck!), however there has been a big push to make it immutable, that work is now ‘done’ and a switch is available on the compiler to enforce it in the type system now, many systems build with it on now and it will be default in a future compiler version.
However, OCaml has no built-in unicode support, have to use external libraries for that (which are good).
I’m really curious what you mean here. I’ve been following the OCaml compiler repo since it was moved to Github a couple years ago. Every feature request seems well discussed, example implementations made, PR’s built and everything gets well tested. OCaml is quite large as a language, far more so than Haskell, so you have to consider how everything interacts with every other feature, but if it is a truly useful feature that has no compatibility issues and someone makes a full PR that tests successful on all supported platforms then it gets accepted at either a minor or full revision depending on the extent of it. The most recent OCaml just implemented a replacement optimizer (flambda) that both does even better optimizing than the old one, while being easier to add new features as well. A few pending features had been waiting on it to be finished, and just in the past month a lot of PR’s have been updated and merged. This is not a tiny language like LUA or so that you can just add a new opcode and have a new feature, this is a fully compiled language that compiles to bare metal, you have to test.
Basically already done, just want to rewrite a few parts for clarity and release it as its own stand-alone library. ^.^ I really want an OCaml->EVM backend, I’d love to be able to use the, say, same html template code on both the front-end and back-end while using the EVM. ^.^
I wouldn’t rule out F# because it came from Microsoft. Microsoft Research, is almost like another company. F# is managed in a completely different fashion than the other 2 dotnet languages. It truly is an open source project compared to being “developed in the open”.
The best way to tell is the fact that the tooling on macOS is completely different than windows. Even on windows it feels like it was added to Visual Studio as an after thought. It’s pretty easy to argue that the tooling on open source projects like Ionide is better or on par with tooling that was added to Visual Studio. And there is one advantage that F# has over ocaml, it already has multicore capabilities if you need it.
Well when F# get’s .NET Native support (we’re not there yet but Microsoft said it will support it in the future) then F# becomes an AOT native compiled language too, just like OCAML. Today you kind of can get AOT binaries via NGen.
@OvermindDL1 A question: I’ve been dabbling with OCaml these past weeks and I’m stuck on setting up a satisfying and productive dev environment in my editor. I mainly use Atom, but I have no problems should I need to use either Sublime, Vim, or Emacs (with Spacemacs).
I’ve tried the ocaml-merlin package on Atom and got it working, but it not specifying default keybindings for anything except for jumping into declarations kinda sucks. Facebook’s nuclide provides too much.
Can you share your dev environment for developing in OCaml?
Currently it is spacemacs with the ocaml layer. I used Atom in the past and don’t recall issues with it (though I near always change up my keybindings anyway so I would have bound things).
Was a bit disappointed to see this. I was under the impression that OCaml multicore was actually close. From the look of the reply here it seems like it is still nowhere close to be done
I get the impression they are still in “research land” and haven’t even started any serious implementation yet. Is Ocaml Multicore still another 10 years away?
) with OCaml. It seems promising if we want to get native performance (challenging C/C++), with fast compilation. However, it being quite an old language and (I believe) not getting the hype and reputation as Haskell, it’s kinda hard to look for both resource and community. I know FB uses OCaml (with their own dialect, Reason), and it’s great, but its use is not quite as talked about as their JS contributions.
)
(now with dot net core also on Mac, Linux)
(but then again, Microsoft Research and Simon Peyton Jones have significant contributions on Haskell and GHC, so I’m being a bit picky).
