13 ms·

An OCaml manifesto – Problems and what's needed for widespread adoption

96 points by e_d_g_a_r 11y ago

systems 11y ago
kinda sorta, the reason why people still thing of ocaml is because janestreet use them, and janestreet makes a lot of money .. and we all want to make money, so somewhere vaguely some people can/may link ocaml with money i love ocaml, i love ml languages, and i think ocaml is a very good ml but, i think its kinda too late for it, i think people who want to program with types today most likely will go to rust, scala or f# ocaml is very niche
- pcwalton 11y ago
  Which is a shame really, because OCaml is a very nice language. Everyone who is interested in "worse is better" design should really study it (and I mean "worse is better" in the most genuinely approving sense). I don't think I've ever seen a language other than SML and OCaml that sits in such a "sweet spot" on the simplicity-vs-power tradeoff for general-purpose programming (not counting the module system of SML and the object system of OCaml). I honestly think that OCaml's type system is simpler than a lot of other type systems that people think of when they think of "simple type systems". (Including its support for generics—OCaml is proof that generics can be an extremely simple feature that add basically no complexity to a type system, contrary to popular belief.) I think the biggest issue with OCaml for mainstream adoption is the syntax, honestly.
  - hxegon 11y ago
    Been sampling a bunch of languages in the past 3+ months and I have to say, [| |] is really, really off-putting.
    - pauldirac137 11y ago
      All the minor syntax issues in Ocaml are just that, minor. After a week of coding in Ocaml you won't even notice them. The operator underloading is the most annoying, but with modular implicits on the way that will probably go away.
      - tomp 11y ago
        I disagree. I used OCaml extensively 10 years ago, and syntax is, in one word, terrible. I don't care about the minor issues, but about the major ones; the ambiguities concerning ;, if and match; essentially, as soon as you're using imperative features (which often result in using ;), you have to be very careful to make sure your code means what you think it means.
  - swah 11y ago
    I suppose many folks will assume later languages (Rust) have learned from older ones and will just use the more widespread one without a second thought...
  - virtualwhys 11y ago
    > I think the biggest issue with OCaml for mainstream adoption is the syntax, honestly. Indeed, a barrier in itself, after working through RWO I was impressed with the language, clearly very powerful, but some aspects of the language are syntactically unpleasant. Yes, yes, semantics, not syntax, but new comers will come in all forms, including those who will just say no based on the general "look" of the language. IMO, if OCaml had the same power but looked more like SML it would have much greater adoption. Anyway, modular implicits and multi-core will certainly help OCaml to grain traction, syntax notwithstanding.
    - daxfohl 11y ago
      In layman programmer terms, what are modular implicits? Are they like (please no) Scala's implicits? (Or is there some way Scala's implicits are less scary than years past?)
      - whateveracct 11y ago
        Scala implicits are really one of the "killer apps" of its type system. No language I know of really has anything quite like it. Scala "implicits" mean two different things: 1) implicit conversions. e.g. If there is an implicit def f(x: Int): String = x.toString in scope, then any time you try to use an Int where a String is expected, Int::toString will be called automatically. Using implicit conversions like this is generally frowned upon and also where the "please no" probably comes from. implicit conversions are used frequently but almost entirely for extension methods (there's even sugar for it now: "implicit class") 2) implicit parameters. These are parameters in a functions type signature keyed by type. You can emulate Haskell typeclasses (sans canonicity) with these. For instance def monoidSum[A](as: List[A])(implicit m: Monoid[A]): A = as.foldLeft(m.zero)(m.append) is equivalent to the Haskell monoidSum :: (Monoid a) => [a] -> a monoidSum as = foldl' mappend mempty Scala implicit parameters can be defined inductively and depend on other implicit parameters. You can do this to perform some really cool type-level computation. The shapeless library is full of stuff like this. Once you understand implicit parameters, it really is somewhat nice to write functions that operate on arbitrarily-sized HLists and Coproducts. Modular implicits are similar to (and inspired by?) Scala implicit parameters.
  - wtetzner 11y ago
    Actually, for me the biggest obstacle is the lack of a good build/dependency tool along the lines of cargo. The closest I've been able to get is Oasis+OPAM, but it's just not the same.
  - nickpsecurity 11y ago
    "Everyone who is interested in "worse is better" design should really study it (and I mean "worse is better" in the most genuinely approving sense). I don't think I've ever seen a language other than SML and OCaml that sits in such a "sweet spot" on the simplicity-vs-power tradeoff for general-purpose programming" Didn't think of it that way. Well-put and I totally agree. So odd that one hits that sweet spot in design yet gets almost no uptake. Whatever problems like OP posted need to get solved because interesting and useful things are sure to come from mainstream attention to it. Useful even outside Ocaml given its influences on other languages. Another thing is the compiler. It's reportedly easy to understand and robust compared to most. I recall reading Esterel's report on DO-178B certifying their code generator written in Ocaml. They had to do source-to-object-code equivalence. They said that, very unusually, the Ocaml toolchain was well-structured to the point they only need minor tweaks to get the job done. So, great language design plus great implementation equals great opportunity for robust, app development. The concurrency situation is ridiculous, though. Even C-like languages and Haskell have safe concurrency techniques. They need to get on that shit cuz nobody uses single-core boxes anymore unless they're a small shop licensing Oracle. ;)
- ZenoArrow 11y ago
  I don't see why someone would evaluate F# but not OCaml, they're very similar languages. The breadth of libraries available for F# may be greater, but OCaml has some strengths that F# currently doesn't, such as native compilation. I'm teaching myself F# at the moment but I'd not rule out using OCaml in the future.
  - alkonaut 11y ago
    F# will likely have a native compiler soon (and you could argue it does in case you compile it for mobile using Xamarin). The key difference for me is "is there a polished development environment where I can get from zero to debugging within minutes".
  - mercurial 11y ago
    To be fair, for most people who may use something for work, "lack of available libraries" can easily be a death knell.
    - ZenoArrow 11y ago
      Sure, but it depends on what you need to do. From my perspective Mirage is OCaml's 'killer app' (I'm sure others would disagree). Where I could see it excelling is as an open-source home server platform. I'm not sure what the current progress is but I know some of the Mirage developers were working on this particular use case, I'll see if I can find the link. Could something like Mirage exist for F#? It could, though the Mirage team have a considerable head start. EDIT: The project I was referring to before is Nymote: http://nymote.org/ http://nymote.org/
  - pauldirac137 11y ago
    F# is nice but it doesn't have the Ocaml module/functor system, which is a huge loss in expressiveness. It does have seamless .NET interoperability, which is a big win in some cases. YMMV. Both are good languages.
- cm3 11y ago
  Why Rust though? It doesn't provide much in terms of an expressive type system when compared to Haskell, SML, OCaml, Idris. I like Rust for many reasons and it's a huge boon for more correct software produced by more people (aka those who don't use an Ada profile :D) but Rust's type system isn't something to weight heavier than OCaml's. There is at least one SML implementation with region types from what I understand. Need to look it up, but it was the implementation from that Dane whose name was something like Elsberg or something and which also had tracing and stuff. For SML I use the MoscowML REPL and MLton for executables. But I don't do much SML, unfortunately. In some ways it's nicer than OCaml.
  - pcwalton 11y ago
    What features does SML or OCaml's type system have that Rust's doesn't? Haskell has higher-kinded type parameters and Idris has dependent types. But SML and OCaml don't even have typeclasses at all, much less higher kinds. Furthermore, what makes Rust's type system interesting isn't just its use of regions (which the ML Kit used); it's regions combined with inherited mutability plus the borrow check to maintain soundness.
    - cm3 11y ago
      OCaml's module system is a nice tool for many cases that is only slowly getting into Haskell via Backpack but not there yet. So that's one. GHC 8.0 almost has dependent types and the expectation is feature completeness in 8.2, thought what's in 8.0 is already useful. I like and use Rust and the design decisions that led to a very capable region system that allows one to write data race free and memory correct code is excellent. Haskell doesn't have such a thing because it doesn't try avoid GC. I didn't do a point by point comparison of Rust expressiveness vs Haskell recently, but I don't remember it being close. Rafael might need to write a Rust for for Haskellers as an update of his "for OCamlers" post a while back.
      - knz42 11y ago
        The post is called "Rust for functional programmers" and contains side-by-side comparisons with both OCaml and Haskell. http://science.raphael.poss.name/rust-for-functional-programmers.html http://science.raphael.poss.name/rust-for-functional-program... you might be confusing it with the other post "Haskell for OCaml programmers"? It is a bit outdated but as far as I can see not inaccurate yet. I only plan to update it when HKTs make it to Rust.
- draven 11y ago
  > i think people who want to program with types today most likely will go to rust, scala or f# I'm a Scala dev. I'm playing with Rust for lower level stuff, don't know much about F#, but FWIW I would rather code in Ocaml than Scala.
  - daxfohl 11y ago
    Serious questions: Why, and why don't you?
    - hisham_hm 11y ago
      Probably because they're paid to write Scala.
    - draven 11y ago
      As suspected by hisham_hm, I'm paid to code in Scala. At my previous job I tried to introduce some functional languages without much success. The stack was C++/Java and a lot of Python. I learned Scala because it runs on the JVM and I thought that may help. Later I moved to another city and when looking at job offers I saw a few Scala offers (and no Ocaml in sight) so I settled on Scala. IMHO Scala gained traction because it runs on the JVM. It's easier to train Java devs because you can start by writing Java-in-Scala and incorporate specific features as you go. The web ecosystem is nice (at work we're using Play.) There's also a few killer apps, like Spark. I'm currently trying to become as proficient in Ocaml as I am with Scala, but I'm already working with Scala 8+ hours a day so it's not that easy.
- dwc 11y ago
  I don't agree with your Jane Street / money reasoning. I had never heard of Jane Street until I started looking at OCaml. That Jane Street makes money and is "all in" on OCaml does support the idea that one can use OCaml for serious projects. But does anyone really think (even subconsciously) that using OCaml will make them rich, just because?
- pauldirac137 11y ago
  I completely disagree. I'm a typoholic to the core. For the last five years I've mostly been programming in Haskell, but lately I've come back to Ocaml and I have to say it's improved massively and continues to do so. I'm happy if people use any decent typed language (including Rust, Scala, F# etc.) but Ocaml has some unique strengths. The module/functor system is the best in the business, and is incredible for defining parameterized data structures. It's even better than anything Haskell has in that regard, as the Haskell community freely admits (they are working on their own version of it). Polymorphic variants are also amazing, and are found in no other language. The object system is really good, although it's seemingly little used because with modules and functors, you rarely need it. And there are lots of exciting things coming down the pipeline, including true multicore support with user-definable schedulers, modular implicits to get the effect of Haskell type classes (but better), a new inliner, and much more. Ocaml is ripe for a massive comeback. I've started using it in my university courses, and students are amazed at how often code "just works" if it type checks (this is also true of the other languages I mentioned). And Ocaml is much easier to learn than Haskell (though I still love Haskell). So give it a try! Once you get past the odd syntax, it's pure pleasure.
  - daxfohl 11y ago
    Okay I (having done a little Haskell and enough F# to know a higher abstraction was needed) thought that modules were already OCaml's counter to Haskell typeclasses, and they were already better. Some weird set-theory-looking T-shirt (obviously) proved it. So what are modular implicits, and how are they better than modules and typeclasses, why are modules not actually enough anymore as an answer for typeclasses, and are they (please no) related to Scala implicits?
    - mercurial 11y ago
      You don't get "magic" to_string and equals with just modules, for instance.
      - daxfohl 11y ago
        explain? And how do modular implicits fix?
pklausler 11y ago
Sincere question: as a Haskell programmer, why should I also learn/use O'Caml?
- bru 11y ago
  Some differences are outlined in this insightful post: http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r... Overall I'd say that OCaml is more pragmatic.
  - pklausler 11y ago
    Thanks for the link, will read soon.
- adamwk 11y ago
  One advantage ML has over Haskell is that it's not opinionated on how one manages effects. How effects are managed in ML is a design decision by a library author, whether that be monadic or eff-style or sprinkling a printf here and there.
  - pklausler 11y ago
    I know Standard ML, and yes, it has eager evaluation and modifiable references. I've learned to appreciate lazy evaluation and purity, so those have little value to me. I miss parameterized modules, as Haskell's modules are strictly for namespaces. But I'm pretty clueless on the delta from SML to modern OCaml, so maybe I've missed out on valuable developments.
  - lomnakkus 11y ago
    Interestingly, that's also a disadvantage since you cannot control effects (in the user-supplied code) if you're e.g. writing a library API with callbacks. On the advantage side you have what you mentioned, namely "benign" effects -- but I've found that the "sprinkle a few debug printfs" use case is adequately handled with Debug.Trace... unless you're trying to debug a terminal application! :) Logging is another popular example of a "benign" effect, but I personally don't think is: I mean, your logging library could be doing all kinds of weird things like shipping logs over TCP to a remote syslog daemon... and I don't want that to be hidden under the rug (using unsafePerformIO or similar) only to blow up later when the network happens to be down. Anyway, having programmed in O'Caml for 3-4 years, I was won over to Haskell by the compiler-supported (side) effect tracking. I think it's also important to note the distinction between side effects and plain (desired) effects. Not enough people do this in these sorts of discussions.
mercurial 11y ago
I'm wary of the term "ORM" and in particular the idea that you'd get your SQL defined at compile, which is exactly what something like PGOcaml does, and which is a bad idea if it's the only game in town. As someone who gets to write SQL fairly regularly, I'm a lot more interested in composability than anything else (I'll even trade type safety for composability if I have to pick one). I'd rather have a system to generate composable queries (hopefully in a typesafe manner) and able to use modern SQL syntax (eg, window functions), without the stuff you typically find in an ORM (identity map, magic setters, etc)
- sgrove 11y ago
  This has always been a big challenge for me with SQL - programmatically composing queries, filters, etc. has been 1. very difficult across the board and 2. very function-oriented rather than data-oriented. I still hold out hope for a datalog-to-sql layer, someday.
- snuxoll 11y ago
  This is something that really bugs me about OCaml in general. There's really no good option to do database access that doesn't involve writing raw, non-composable SQL queries. I don't need a full blown ORM, but something that makes writing type-safe (and injection-resistant) SQL queries like JOOQ would be absolutely amazing. For now I'm just sticking with Python and SQLAlchemy, as much as I love OCaml and F#.
  - insulanian 11y ago
    F# doesn't fit into the rest of your comment. There are type providers and Entity Framework, both of which are very good options for DB access.
    - snuxoll 11y ago
      IFF you are using Microsoft SQL Server, sure. Any other RDBMS is a crapshoot, I've been using FsSql which works but I have to devolve into manually manipulating SQL Query strings to do anything sufficiently advanced. Technically there is SQLProvider, but it's ugly as sin (I also don't care for type providers in general, I don't need automatic code generation, I have no problem specifying my schema and not needing access to a database server just to compile my code).
jfaucett 11y ago
I'm not a big OCaml user, have used it on occasion for a few small projects and I liked it, but from what I remember, I think a few things are missing from this list if OCaml wants to obtain widespread adoption. 1. Really good unicode support 2. A dead simple high quality package manager i.e. bundler, mix, cargo. I'd also add built-in concurrency primitives i.e. (Channels in Go, Processes in Erlang), though this probably isn't a must have currently, but will surely only become more important as time progresses into the multicore future.
- e_d_g_a_r 11y ago
  1. There are libraries for that. 2. opam.
  - jerf 11y ago
    It can be worthwhile to bless a set of libraries. Even if it seems like it can be done unofficially, it helps to have it done "officially", at least, from the point of view of a newcomer to the language. Haskell's getting some mileage out of that sort of thing, lately, starting with the "Haskell Platform" and lately moving into Stack, a blessed set of packages that are maintained in certain snapshot sets and guaranteed to compile together.
    - e_d_g_a_r 11y ago
      I have created a starterkit package to get someone's new opam switch prepped quickly. https://github.com/fxfactorial/ocaml-starterkit https://github.com/fxfactorial/ocaml-starterkit See it for cool gifs/images.
  - ZenoArrow 11y ago
    Shouldn't #1 be out of the box these days? You'd hope it'd be included in the standard library. Do any of the standard library sets available for OCaml (e.g. Core, Batteries, etc...) have Unicode support?
  - nextos 11y ago
    For concurrency, Ocaml's spinoff Jocaml (based on joincalculus) works exceptionally well. It got a lot of attention on Tim Bray's widefinder benchmark: https://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Results https://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Result...
muraiki 11y ago
A few weeks ago I started learning OCaml via Real World OCaml. However, I became concerned when I discovered that there are multiple competing "standard libraries" and that there are also two different competing async frameworks. It looks like work is being done to ensure that the async frameworks are interoperable, but the existence of various standard libraries is worrisome to me. In particular, while the one used in RWO (Core) seems very nice, it looks like its use of named parameters is via some kind of syntax extension (edit: not the case; see LeonidasXIV's reply). This seems to be a pretty large difference in approach, and while I can appreciate the reasons behind using named parameters in Core, it makes me worried about writing code that might have to interact across different stdlibs. As such, I've decided to hold off on learning OCaml for now until resolutions to these community issues can be made more clear. But perhaps I just prefer the Python approach, and that may not be the same objective as those in OCaml. Edit: Actually, the nail in the coffin was probably when I found a web framework that I wanted to use, but then the author explained why he was removing support for both of the async frameworks and going with only one of them (the one that RWO doesn't use). And then the other main web framework I found also used non-RWO async... :(
- joshmarlow 11y ago
  I started learning OCaml about a year ago (started with "OCaml from the very beginning" and moved onto "Real World OCaml"). The different extended standard libraries (Batteries and Core) gave me pause too. I'm by no means an active part of the community, but I feel like everything is moving toward Core (and I prefer it to Batteries anyway).
- pauldirac137 11y ago
  Named parameters in Ocaml are not a syntax extension. http://caml.inria.fr/pub/docs/manual-ocaml/lablexamples.html#sec42 http://caml.inria.fr/pub/docs/manual-ocaml/lablexamples.html...
- richard_todd 11y ago
  The multiple standard libraries thing also really cooled my enthusiasm last time I investigated the language. They really need to resolve that, or at least explain on their website why a newbie should not be concerned.
vrotaru 11y ago
I like OCaml, just.. Has it ever been anything which can be called a successful manifesto? I, certainly, do not remember one for JS or Node.
swah 11y ago
If only OCaml was handled like Go is...
- placeybordeaux 11y ago
  Developed and shepherded by one of the most powerful companies in the world?
  - swah 11y ago
    Still more open and closer to the community than OCaml... Or do you see Xavier Leroy talking to people like @bradfitz?
toolslive 11y ago
I've been using OCaml for system's programming for 6+ years, and it's better than most other things we've tried. I guess any (mostly) functional language with a static type system based on Hindley-Milner would give the same advantage. This advantage is basically: the compiler acts like a neo nazi and slaps you mercilessly on the head whenever you do something stupid. So in the end, you can often get to the "if it compiles, it works" promised land. The situation improved drastically over the last years with opam which allows easy installation of most packages. What's still missing, however is - decent multi core - resource management for things other than memory. For example, bigarrays don't cause enough gc pressure, and can therefore leak space. Thus people tend to manage that manually (acquire, release) which is even worse than what a C++ dev can use (unique_ptr) - decent profiling (yes I can leverage strace and callgrind, but they don't understand lwt) - decent runtime inspection. (what are all theses values in my heap?)
- paxcoder 11y ago
  That comparison makes no sense.
  - deleted 11y ago
    [deleted]
  - dang 11y ago
    Maybe not, but a comment like this helps no one. If you know enough to make such a claim then you know enough to show what the problems are, and that would make a much better comment. We'd all learn something.
    - paxcoder 11y ago
      It might be considered poor form not to spell the problem out, however I honestly think it is crystal clear But what's interesting is that I was being upvoted until I've rephrased the comment. It used to be "That's an unfortunate comparison you've made". In the same time it sounded more moderate and more personal. I've edited it because moderation came at the cost of authenticity/honesty, and I thought addressing the comment risked automatic rejection of the underlying message on the OC's part. I did think that the actual sentiment could sound worse to others, but it would be hypocritical of me not to have gone with it. The underlying message is precisely "don't conform on account of genuineness". Hope this cleared something up after all
jsli 11y ago
The article mentioned OCaml meetup in Bay Area. Where can I find one?
- LeonidasXIV 11y ago
  Here you go[0] organized by e_d_g_a_r. As far as I've heard the show up rate is pretty good. [0]: http://www.meetup.com/sv-ocaml/ http://www.meetup.com/sv-ocaml/
  - jsli 11y ago
    Great! Thanks.
openplatypus 11y ago
Great write-up. If I could nitpick a bit I would say... I am on the fence with ORMs. Yes, they make 80% of cases possible, remaining 19% difficult and last 1% sometime impossible. Having Slick (Scala) and JOOQ (Java) makes code much more transparent, explicit and easy to maintain. Debugging nasty stateful session bugs (oh JPA) can be nightmare.

96 points by e_d_g_a_r 11y ago

kinda sorta, the reason why people still thing of ocaml is because janestreet use them, and janestreet makes a lot of money .. and we all want to make money, so somewhere vaguely some people can/may link ocaml with money i love ocaml, i love ml languages, and i think ocaml is a very good ml but, i think its kinda too late for it, i think people who want to program with types today most likely will go to rust, scala or f# ocaml is very niche

pcwalton 11y ago
Which is a shame really, because OCaml is a very nice language. Everyone who is interested in "worse is better" design should really study it (and I mean "worse is better" in the most genuinely approving sense). I don't think I've ever seen a language other than SML and OCaml that sits in such a "sweet spot" on the simplicity-vs-power tradeoff for general-purpose programming (not counting the module system of SML and the object system of OCaml). I honestly think that OCaml's type system is simpler than a lot of other type systems that people think of when they think of "simple type systems". (Including its support for generics—OCaml is proof that generics can be an extremely simple feature that add basically no complexity to a type system, contrary to popular belief.) I think the biggest issue with OCaml for mainstream adoption is the syntax, honestly.
- hxegon 11y ago
  Been sampling a bunch of languages in the past 3+ months and I have to say, [| |] is really, really off-putting.
  - pauldirac137 11y ago
    All the minor syntax issues in Ocaml are just that, minor. After a week of coding in Ocaml you won't even notice them. The operator underloading is the most annoying, but with modular implicits on the way that will probably go away.
    - tomp 11y ago
      I disagree. I used OCaml extensively 10 years ago, and syntax is, in one word, terrible. I don't care about the minor issues, but about the major ones; the ambiguities concerning ;, if and match; essentially, as soon as you're using imperative features (which often result in using ;), you have to be very careful to make sure your code means what you think it means.
- swah 11y ago
  I suppose many folks will assume later languages (Rust) have learned from older ones and will just use the more widespread one without a second thought...
- virtualwhys 11y ago
  > I think the biggest issue with OCaml for mainstream adoption is the syntax, honestly. Indeed, a barrier in itself, after working through RWO I was impressed with the language, clearly very powerful, but some aspects of the language are syntactically unpleasant. Yes, yes, semantics, not syntax, but new comers will come in all forms, including those who will just say no based on the general "look" of the language. IMO, if OCaml had the same power but looked more like SML it would have much greater adoption. Anyway, modular implicits and multi-core will certainly help OCaml to grain traction, syntax notwithstanding.
  - daxfohl 11y ago
    In layman programmer terms, what are modular implicits? Are they like (please no) Scala's implicits? (Or is there some way Scala's implicits are less scary than years past?)
    - whateveracct 11y ago
      Scala implicits are really one of the "killer apps" of its type system. No language I know of really has anything quite like it. Scala "implicits" mean two different things: 1) implicit conversions. e.g. If there is an implicit def f(x: Int): String = x.toString in scope, then any time you try to use an Int where a String is expected, Int::toString will be called automatically. Using implicit conversions like this is generally frowned upon and also where the "please no" probably comes from. implicit conversions are used frequently but almost entirely for extension methods (there's even sugar for it now: "implicit class") 2) implicit parameters. These are parameters in a functions type signature keyed by type. You can emulate Haskell typeclasses (sans canonicity) with these. For instance def monoidSum[A](as: List[A])(implicit m: Monoid[A]): A = as.foldLeft(m.zero)(m.append) is equivalent to the Haskell monoidSum :: (Monoid a) => [a] -> a monoidSum as = foldl' mappend mempty Scala implicit parameters can be defined inductively and depend on other implicit parameters. You can do this to perform some really cool type-level computation. The shapeless library is full of stuff like this. Once you understand implicit parameters, it really is somewhat nice to write functions that operate on arbitrarily-sized HLists and Coproducts. Modular implicits are similar to (and inspired by?) Scala implicit parameters.
- wtetzner 11y ago
  Actually, for me the biggest obstacle is the lack of a good build/dependency tool along the lines of cargo. The closest I've been able to get is Oasis+OPAM, but it's just not the same.
- nickpsecurity 11y ago
  "Everyone who is interested in "worse is better" design should really study it (and I mean "worse is better" in the most genuinely approving sense). I don't think I've ever seen a language other than SML and OCaml that sits in such a "sweet spot" on the simplicity-vs-power tradeoff for general-purpose programming" Didn't think of it that way. Well-put and I totally agree. So odd that one hits that sweet spot in design yet gets almost no uptake. Whatever problems like OP posted need to get solved because interesting and useful things are sure to come from mainstream attention to it. Useful even outside Ocaml given its influences on other languages. Another thing is the compiler. It's reportedly easy to understand and robust compared to most. I recall reading Esterel's report on DO-178B certifying their code generator written in Ocaml. They had to do source-to-object-code equivalence. They said that, very unusually, the Ocaml toolchain was well-structured to the point they only need minor tweaks to get the job done. So, great language design plus great implementation equals great opportunity for robust, app development. The concurrency situation is ridiculous, though. Even C-like languages and Haskell have safe concurrency techniques. They need to get on that shit cuz nobody uses single-core boxes anymore unless they're a small shop licensing Oracle. ;)
ZenoArrow 11y ago
I don't see why someone would evaluate F# but not OCaml, they're very similar languages. The breadth of libraries available for F# may be greater, but OCaml has some strengths that F# currently doesn't, such as native compilation. I'm teaching myself F# at the moment but I'd not rule out using OCaml in the future.
- alkonaut 11y ago
  F# will likely have a native compiler soon (and you could argue it does in case you compile it for mobile using Xamarin). The key difference for me is "is there a polished development environment where I can get from zero to debugging within minutes".
- mercurial 11y ago
  To be fair, for most people who may use something for work, "lack of available libraries" can easily be a death knell.
  - ZenoArrow 11y ago
    Sure, but it depends on what you need to do. From my perspective Mirage is OCaml's 'killer app' (I'm sure others would disagree). Where I could see it excelling is as an open-source home server platform. I'm not sure what the current progress is but I know some of the Mirage developers were working on this particular use case, I'll see if I can find the link. Could something like Mirage exist for F#? It could, though the Mirage team have a considerable head start. EDIT: The project I was referring to before is Nymote: http://nymote.org/ http://nymote.org/
- pauldirac137 11y ago
  F# is nice but it doesn't have the Ocaml module/functor system, which is a huge loss in expressiveness. It does have seamless .NET interoperability, which is a big win in some cases. YMMV. Both are good languages.
cm3 11y ago
Why Rust though? It doesn't provide much in terms of an expressive type system when compared to Haskell, SML, OCaml, Idris. I like Rust for many reasons and it's a huge boon for more correct software produced by more people (aka those who don't use an Ada profile :D) but Rust's type system isn't something to weight heavier than OCaml's. There is at least one SML implementation with region types from what I understand. Need to look it up, but it was the implementation from that Dane whose name was something like Elsberg or something and which also had tracing and stuff. For SML I use the MoscowML REPL and MLton for executables. But I don't do much SML, unfortunately. In some ways it's nicer than OCaml.
- pcwalton 11y ago
  What features does SML or OCaml's type system have that Rust's doesn't? Haskell has higher-kinded type parameters and Idris has dependent types. But SML and OCaml don't even have typeclasses at all, much less higher kinds. Furthermore, what makes Rust's type system interesting isn't just its use of regions (which the ML Kit used); it's regions combined with inherited mutability plus the borrow check to maintain soundness.
  - cm3 11y ago
    OCaml's module system is a nice tool for many cases that is only slowly getting into Haskell via Backpack but not there yet. So that's one. GHC 8.0 almost has dependent types and the expectation is feature completeness in 8.2, thought what's in 8.0 is already useful. I like and use Rust and the design decisions that led to a very capable region system that allows one to write data race free and memory correct code is excellent. Haskell doesn't have such a thing because it doesn't try avoid GC. I didn't do a point by point comparison of Rust expressiveness vs Haskell recently, but I don't remember it being close. Rafael might need to write a Rust for for Haskellers as an update of his "for OCamlers" post a while back.
    - knz42 11y ago
      The post is called "Rust for functional programmers" and contains side-by-side comparisons with both OCaml and Haskell. http://science.raphael.poss.name/rust-for-functional-programmers.html http://science.raphael.poss.name/rust-for-functional-program... you might be confusing it with the other post "Haskell for OCaml programmers"? It is a bit outdated but as far as I can see not inaccurate yet. I only plan to update it when HKTs make it to Rust.
draven 11y ago
> i think people who want to program with types today most likely will go to rust, scala or f# I'm a Scala dev. I'm playing with Rust for lower level stuff, don't know much about F#, but FWIW I would rather code in Ocaml than Scala.
- daxfohl 11y ago
  Serious questions: Why, and why don't you?
  - hisham_hm 11y ago
    Probably because they're paid to write Scala.
  - draven 11y ago
    As suspected by hisham_hm, I'm paid to code in Scala. At my previous job I tried to introduce some functional languages without much success. The stack was C++/Java and a lot of Python. I learned Scala because it runs on the JVM and I thought that may help. Later I moved to another city and when looking at job offers I saw a few Scala offers (and no Ocaml in sight) so I settled on Scala. IMHO Scala gained traction because it runs on the JVM. It's easier to train Java devs because you can start by writing Java-in-Scala and incorporate specific features as you go. The web ecosystem is nice (at work we're using Play.) There's also a few killer apps, like Spark. I'm currently trying to become as proficient in Ocaml as I am with Scala, but I'm already working with Scala 8+ hours a day so it's not that easy.
dwc 11y ago
I don't agree with your Jane Street / money reasoning. I had never heard of Jane Street until I started looking at OCaml. That Jane Street makes money and is "all in" on OCaml does support the idea that one can use OCaml for serious projects. But does anyone really think (even subconsciously) that using OCaml will make them rich, just because?
pauldirac137 11y ago
I completely disagree. I'm a typoholic to the core. For the last five years I've mostly been programming in Haskell, but lately I've come back to Ocaml and I have to say it's improved massively and continues to do so. I'm happy if people use any decent typed language (including Rust, Scala, F# etc.) but Ocaml has some unique strengths. The module/functor system is the best in the business, and is incredible for defining parameterized data structures. It's even better than anything Haskell has in that regard, as the Haskell community freely admits (they are working on their own version of it). Polymorphic variants are also amazing, and are found in no other language. The object system is really good, although it's seemingly little used because with modules and functors, you rarely need it. And there are lots of exciting things coming down the pipeline, including true multicore support with user-definable schedulers, modular implicits to get the effect of Haskell type classes (but better), a new inliner, and much more. Ocaml is ripe for a massive comeback. I've started using it in my university courses, and students are amazed at how often code "just works" if it type checks (this is also true of the other languages I mentioned). And Ocaml is much easier to learn than Haskell (though I still love Haskell). So give it a try! Once you get past the odd syntax, it's pure pleasure.
- daxfohl 11y ago
  Okay I (having done a little Haskell and enough F# to know a higher abstraction was needed) thought that modules were already OCaml's counter to Haskell typeclasses, and they were already better. Some weird set-theory-looking T-shirt (obviously) proved it. So what are modular implicits, and how are they better than modules and typeclasses, why are modules not actually enough anymore as an answer for typeclasses, and are they (please no) related to Scala implicits?
  - mercurial 11y ago
    You don't get "magic" to_string and equals with just modules, for instance.
    - daxfohl 11y ago
      explain? And how do modular implicits fix?

pklausler 11y ago

Sincere question: as a Haskell programmer, why should I also learn/use O'Caml?

bru 11y ago
Some differences are outlined in this insightful post: http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r... Overall I'd say that OCaml is more pragmatic.
- pklausler 11y ago
  Thanks for the link, will read soon.
adamwk 11y ago
One advantage ML has over Haskell is that it's not opinionated on how one manages effects. How effects are managed in ML is a design decision by a library author, whether that be monadic or eff-style or sprinkling a printf here and there.
- pklausler 11y ago
  I know Standard ML, and yes, it has eager evaluation and modifiable references. I've learned to appreciate lazy evaluation and purity, so those have little value to me. I miss parameterized modules, as Haskell's modules are strictly for namespaces. But I'm pretty clueless on the delta from SML to modern OCaml, so maybe I've missed out on valuable developments.
- lomnakkus 11y ago
  Interestingly, that's also a disadvantage since you cannot control effects (in the user-supplied code) if you're e.g. writing a library API with callbacks. On the advantage side you have what you mentioned, namely "benign" effects -- but I've found that the "sprinkle a few debug printfs" use case is adequately handled with Debug.Trace... unless you're trying to debug a terminal application! :) Logging is another popular example of a "benign" effect, but I personally don't think is: I mean, your logging library could be doing all kinds of weird things like shipping logs over TCP to a remote syslog daemon... and I don't want that to be hidden under the rug (using unsafePerformIO or similar) only to blow up later when the network happens to be down. Anyway, having programmed in O'Caml for 3-4 years, I was won over to Haskell by the compiler-supported (side) effect tracking. I think it's also important to note the distinction between side effects and plain (desired) effects. Not enough people do this in these sorts of discussions.

mercurial 11y ago

I'm wary of the term "ORM" and in particular the idea that you'd get your SQL defined at compile, which is exactly what something like PGOcaml does, and which is a bad idea if it's the only game in town. As someone who gets to write SQL fairly regularly, I'm a lot more interested in composability than anything else (I'll even trade type safety for composability if I have to pick one). I'd rather have a system to generate composable queries (hopefully in a typesafe manner) and able to use modern SQL syntax (eg, window functions), without the stuff you typically find in an ORM (identity map, magic setters, etc)

sgrove 11y ago
This has always been a big challenge for me with SQL - programmatically composing queries, filters, etc. has been 1. very difficult across the board and 2. very function-oriented rather than data-oriented. I still hold out hope for a datalog-to-sql layer, someday.
snuxoll 11y ago
This is something that really bugs me about OCaml in general. There's really no good option to do database access that doesn't involve writing raw, non-composable SQL queries. I don't need a full blown ORM, but something that makes writing type-safe (and injection-resistant) SQL queries like JOOQ would be absolutely amazing. For now I'm just sticking with Python and SQLAlchemy, as much as I love OCaml and F#.
- insulanian 11y ago
  F# doesn't fit into the rest of your comment. There are type providers and Entity Framework, both of which are very good options for DB access.
  - snuxoll 11y ago
    IFF you are using Microsoft SQL Server, sure. Any other RDBMS is a crapshoot, I've been using FsSql which works but I have to devolve into manually manipulating SQL Query strings to do anything sufficiently advanced. Technically there is SQLProvider, but it's ugly as sin (I also don't care for type providers in general, I don't need automatic code generation, I have no problem specifying my schema and not needing access to a database server just to compile my code).

jfaucett 11y ago

I'm not a big OCaml user, have used it on occasion for a few small projects and I liked it, but from what I remember, I think a few things are missing from this list if OCaml wants to obtain widespread adoption. 1. Really good unicode support 2. A dead simple high quality package manager i.e. bundler, mix, cargo. I'd also add built-in concurrency primitives i.e. (Channels in Go, Processes in Erlang), though this probably isn't a must have currently, but will surely only become more important as time progresses into the multicore future.

e_d_g_a_r 11y ago
1. There are libraries for that. 2. opam.
- jerf 11y ago
  It can be worthwhile to bless a set of libraries. Even if it seems like it can be done unofficially, it helps to have it done "officially", at least, from the point of view of a newcomer to the language. Haskell's getting some mileage out of that sort of thing, lately, starting with the "Haskell Platform" and lately moving into Stack, a blessed set of packages that are maintained in certain snapshot sets and guaranteed to compile together.
  - e_d_g_a_r 11y ago
    I have created a starterkit package to get someone's new opam switch prepped quickly. https://github.com/fxfactorial/ocaml-starterkit https://github.com/fxfactorial/ocaml-starterkit See it for cool gifs/images.
- ZenoArrow 11y ago
  Shouldn't #1 be out of the box these days? You'd hope it'd be included in the standard library. Do any of the standard library sets available for OCaml (e.g. Core, Batteries, etc...) have Unicode support?
- nextos 11y ago
  For concurrency, Ocaml's spinoff Jocaml (based on joincalculus) works exceptionally well. It got a lot of attention on Tim Bray's widefinder benchmark: https://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Results https://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Result...

muraiki 11y ago

A few weeks ago I started learning OCaml via Real World OCaml. However, I became concerned when I discovered that there are multiple competing "standard libraries" and that there are also two different competing async frameworks. It looks like work is being done to ensure that the async frameworks are interoperable, but the existence of various standard libraries is worrisome to me. In particular, while the one used in RWO (Core) seems very nice, it looks like its use of named parameters is via some kind of syntax extension (edit: not the case; see LeonidasXIV's reply). This seems to be a pretty large difference in approach, and while I can appreciate the reasons behind using named parameters in Core, it makes me worried about writing code that might have to interact across different stdlibs. As such, I've decided to hold off on learning OCaml for now until resolutions to these community issues can be made more clear. But perhaps I just prefer the Python approach, and that may not be the same objective as those in OCaml. Edit: Actually, the nail in the coffin was probably when I found a web framework that I wanted to use, but then the author explained why he was removing support for both of the async frameworks and going with only one of them (the one that RWO doesn't use). And then the other main web framework I found also used non-RWO async... :(

joshmarlow 11y ago
I started learning OCaml about a year ago (started with "OCaml from the very beginning" and moved onto "Real World OCaml"). The different extended standard libraries (Batteries and Core) gave me pause too. I'm by no means an active part of the community, but I feel like everything is moving toward Core (and I prefer it to Batteries anyway).
pauldirac137 11y ago
Named parameters in Ocaml are not a syntax extension. http://caml.inria.fr/pub/docs/manual-ocaml/lablexamples.html#sec42 http://caml.inria.fr/pub/docs/manual-ocaml/lablexamples.html...
richard_todd 11y ago
The multiple standard libraries thing also really cooled my enthusiasm last time I investigated the language. They really need to resolve that, or at least explain on their website why a newbie should not be concerned.

vrotaru 11y ago

I like OCaml, just.. Has it ever been anything which can be called a successful manifesto? I, certainly, do not remember one for JS or Node.

swah 11y ago

If only OCaml was handled like Go is...

placeybordeaux 11y ago
Developed and shepherded by one of the most powerful companies in the world?
- swah 11y ago
  Still more open and closer to the community than OCaml... Or do you see Xavier Leroy talking to people like @bradfitz?

toolslive 11y ago

I've been using OCaml for system's programming for 6+ years, and it's better than most other things we've tried. I guess any (mostly) functional language with a static type system based on Hindley-Milner would give the same advantage. This advantage is basically: the compiler acts like a neo nazi and slaps you mercilessly on the head whenever you do something stupid. So in the end, you can often get to the "if it compiles, it works" promised land. The situation improved drastically over the last years with opam which allows easy installation of most packages. What's still missing, however is - decent multi core - resource management for things other than memory. For example, bigarrays don't cause enough gc pressure, and can therefore leak space. Thus people tend to manage that manually (acquire, release) which is even worse than what a C++ dev can use (unique_ptr) - decent profiling (yes I can leverage strace and callgrind, but they don't understand lwt) - decent runtime inspection. (what are all theses values in my heap?)

paxcoder 11y ago
That comparison makes no sense.
- deleted 11y ago
  [deleted]
- dang 11y ago
  Maybe not, but a comment like this helps no one. If you know enough to make such a claim then you know enough to show what the problems are, and that would make a much better comment. We'd all learn something.
  - paxcoder 11y ago
    It might be considered poor form not to spell the problem out, however I honestly think it is crystal clear But what's interesting is that I was being upvoted until I've rephrased the comment. It used to be "That's an unfortunate comparison you've made". In the same time it sounded more moderate and more personal. I've edited it because moderation came at the cost of authenticity/honesty, and I thought addressing the comment risked automatic rejection of the underlying message on the OC's part. I did think that the actual sentiment could sound worse to others, but it would be hypocritical of me not to have gone with it. The underlying message is precisely "don't conform on account of genuineness". Hope this cleared something up after all

jsli 11y ago

The article mentioned OCaml meetup in Bay Area. Where can I find one?

LeonidasXIV 11y ago
Here you go[0] organized by e_d_g_a_r. As far as I've heard the show up rate is pretty good. [0]: http://www.meetup.com/sv-ocaml/ http://www.meetup.com/sv-ocaml/
- jsli 11y ago
  Great! Thanks.

openplatypus 11y ago

Great write-up. If I could nitpick a bit I would say... I am on the fence with ORMs. Yes, they make 80% of cases possible, remaining 19% difficult and last 1% sometime impossible. Having Slick (Scala) and JOOQ (Java) makes code much more transparent, explicit and easy to maintain. Debugging nasty stateful session bugs (oh JPA) can be nightmare.