9 ms·

OCaml 4.03: Everything else

177 points by yminsky 11y ago

melling 11y ago
I recently started to learn OCaml. This blog post convinced me that it was worth learning: http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain/ http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain... I'm putting my notes on github, in case anyone wants a head start. https://github.com/melling/ComputerLanguages/blob/master/ocaml.org https://github.com/melling/ComputerLanguages/blob/master/oca...
e_d_g_a_r 11y ago
For anyone looking for an OCaml quick start: http://hyegar.com/2015/10/20/so-youre-learning-ocaml/index.html http://hyegar.com/2015/10/20/so-youre-learning-ocaml/index.h...
3327 11y ago
Basically JaneStreet realized its a tough time maintaining the repo if they are the only ones using it.
- cies 11y ago
  Sure. Facebook? Bloomberg? Citrix? https://ocaml.org/learn/companies.html https://ocaml.org/learn/companies.html
catnaroek 11y ago
Still no support for threads running in parallel? I guess things didn't go well: https://news.ycombinator.com/item?id=9582980 https://news.ycombinator.com/item?id=9582980
- Scramblejams 11y ago
  There's still hope! There are a number of much anticipated features that haven't made it into this release. In particular, the multicore GC, which at one point had been expected to land in 4.03, has been pushed back, likely to 4.04.
  - zerosign 11y ago
    and when exactly 4.04 will pop up ? ~~ Well, I know, it's hard. ..
    - technomancy 11y ago
      I'm guessing after 4.03 and before 4.05?
- eggy 11y ago
  I really wanted to use OCaml, but it is adding features way later than I can continue to wait. I've started learning Ponylang as my CSP language over Elixir ever since I checked it out several months ago. Maybe OCaml will fit the bill one day. Jane Street's inertia seems to keep it going outside of the academic world, but that's a single linchpin in the commercial world outside of its academic pen.
  - amirmc 11y ago
    Many commercial companies (and startups) use OCaml, eg Facebook, Bloomberg, etc https://ocaml.org/learn/companies.html https://ocaml.org/learn/companies.html
    - eggy 11y ago
      I am aware companies, big companies, use OCaml. My point, perhaps not made clear, is that Jane Street is building useful libs, and contributing back to OCaml with 'batteries included' type libraries. Facebook creating a VM and programming language compatible with PHP may be useful to some, but is not addressing the more fundamental needs or issues like bringing multicore to OCaml.
      - amirmc 11y ago
        I think that does a disservice to the much greater number of people who are not at Jane Street but contributing useful code and libraries. You also seem to imply that Jane Street is the one 'bringing multicore to OCaml' but that's not the case. Jane Street certainly contributes a huge amount to the ecosystem, both in terms of code and other support, but they're not the only people pouring effort into it.
BWStearns 11y ago
If I were already sold on using Haskell or OCaml for a new project, what would be the big seller for OCaml being the choice? I haven't dug into SML or OCaml and I'm not expert with Haskell yet but from looking at them they don't look substantially distant from Haskell.
- semisight 11y ago
  Can't speak for OCaml yet; I've wanted to learn for a while but decided to go with Haskell first. On the Haskell side of things--it's biggest seller (functional purity) is also the biggest downside. To give you an idea, papers have been written about the best way to implement common data structures purely functionally. From what I've seen, OCaml has less "abstraction overhead" because it can dip into imperative code. While Haskell is really fun, it definitely has moments where you want to beat your head against your desk.
  - catnaroek 11y ago
    The real downside isn't purity - purity is a good thing! What Haskell suffers from is a lack of flexibility w.r.t. the evaluation strategy of pure functions. More precisely: (0) Haskell starts with a bad default - laziness. (1) Haskell uses special annotations to introduce strictness. The presence of these annotations isn't tracked by the type system, which reduces the usefulness of the type system as a tool for understanding your program. (2) More sophisticated evaluation strategies (e.g., memoizing functions, which can be seen as a generalization of laziness) are difficult to achieve in Haskell, even though it's completely straightforward in ML.
- seagreen 11y ago
  I've only written Haskell, but I'll try to give a fair shakedown from my perspective: + OCaml is eagerly evaluated while Haskell is lazily evaluated. This makes it easier to reason about things like memory use in OCaml. + IO is reflected in the type signature of Haskell functions. You may find this annoying because it stinks to have to change a lot of type signatures just because, e.g., you want one of your utility functions to make a log entry when called. On the other hand, IO is often a huge deal either semantically or from a performance perspective. For big projects having IO reflected in the type system can be a huge help. + The ecosystems are different. Haskell's is bigger, though I've heard the quality of OCaml libraries tends to be very high.
zerosign 11y ago
how about SMT support for ocaml(multicore) ? Could it catch up to the current implementation (HEAD) or it's still in the process of moving its implementation ?
xvilka 11y ago
And here is the pending effort for better experience of OCaml on Windows: https://github.com/ocaml/opam/issues/2191 https://github.com/ocaml/opam/issues/2191
- kxyvr 11y ago
  For me, this has been the central issue for not moving many of my projects to OCaml. OPAM sort of works on Windows, but most of the packages I tried to pull broke and fixing them was difficult. Making OPAM work seamlessly on Windows would be a big win in my opinion.
  - dhekir 11y ago
    I had some success using this MinGW-based OPAM repository: https://github.com/fdopen/opam-repository-mingw https://github.com/fdopen/opam-repository-mingw The packages that I needed and that didn't compile in the standard repository were working thanks to patches applied in his repository. Also, the maintainer was very prompt and helpful when dealing with my pull request. There are other forks of that repository, but when googling for "opam windows" they do not appear on the first page, which is unfortunate since they seem to me the best currently available option.
    - kxyvr 11y ago
      Thanks for the reference as I've not tried that. Unfortunately, that project just failed to install for me, but I put in a bug report for the maintainer. Ideally, there'd be an official Windows port and installer that doesn't depend on Cygwin. Certainly that takes time and effort to develop and maintain, so it's nice to see projects like this in the interim.
- kevingadd 11y ago
  Getting OCaml working at all on Windows was a hell nightmare early last year when we were setting it up for WebAssembly and that definitely soured people's opinions of it. We stuck with it because it had some dedicated fans in the working group (happily using it on linux, mostly) and it turned out to be worth the trouble, but otherwise we would have turned to some other language (F#, probably). So I'm really glad to see those problems are being taken seriously!
doomrobo 11y ago
Could anyone explain ephemerons further, maybe with examples? It seems really interesting.
- jlouis 11y ago
  The wikipedia page explains them pretty well I think, so going there is a better explanation than anything else. For a programmer, they allow you to be more precise about the point in time where an object should be regarded as a weak object. That is, an object which can be collected when under GC pressure. A weak references edges itself toward this goal, but often require some manual intervention and/or knowledge of the GC world to manage by the programmer. An ephemeron removes this additional knowledge from the programmers mind. It allows one programmer to make an interface which is truly not leaking in GC abstraction. So other programmers don't have to know about it at all.
GreaterFool 11y ago
I really hope modular implicits will make it to the language one day. While OCaml libraries are no stranger to monads they usually only include `bind` and `return`. Since I'm coming from Haskell I'm used to a vast Applicative and Monad vocabulary and making do with just `bind` and `return` is rather painful. So having a generic library of Monad combinators that one could use with any Monad would be great. Also, being able to just write `show x` is so nice! Edit: while I often see "modular implicits are being worked on" it is not very clear whether there is a concrete plan to add them to the language. Is there any place in the official OCaml repository / issue tracking system / wiki etc where one could check the status?
- lpw25 11y ago
  > Is there any place in the official OCaml repository / issue tracking system / wiki etc where one could check the status? You can see some things on: https://github.com/ocamllabs/ocaml-modular-implicits but you shouldn't take a lack of activity on there as a sign nothing is happening. For instance, Frederic is actively hacking on the prototype at the moment but hasn't pushed anything to that repo.
  - GreaterFool 11y ago
    That's really great.
- virtualwhys 11y ago
  > I really hope modular implicits will make it to the language one day "I'm expecting there will be more news about those in the next six months". I'd be very surprised not to see modular implicits in 4.04 now that the foundation has been put in place with Flambda[1]: "Even if you're perfectly happy with OCaml's performance as is, Flambda is still an exciting change. That's because various upcoming language improvements like modular implicits (a feature that brings some of the same benefits as Haskell's typeclasses) will only really perform acceptably well with a good inliner in place". [1] https://blogs.janestreet.com/flambda/ https://blogs.janestreet.com/flambda/
- massysett 11y ago
agentgt 11y ago
I wonder if this change will have any impact on multicore OCaml (given the reduction of allocation)? I don't know the internals of OCaml that well but multicore support has been my BS reason for not embracing OCaml albeit Mirage is looking better and better every day.

177 points by yminsky 11y ago

I recently started to learn OCaml. This blog post convinced me that it was worth learning: http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain/ http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain... I'm putting my notes on github, in case anyone wants a head start. https://github.com/melling/ComputerLanguages/blob/master/ocaml.org https://github.com/melling/ComputerLanguages/blob/master/oca...

e_d_g_a_r 11y ago

For anyone looking for an OCaml quick start: http://hyegar.com/2015/10/20/so-youre-learning-ocaml/index.html http://hyegar.com/2015/10/20/so-youre-learning-ocaml/index.h...

3327 11y ago

Basically JaneStreet realized its a tough time maintaining the repo if they are the only ones using it.

cies 11y ago
Sure. Facebook? Bloomberg? Citrix? https://ocaml.org/learn/companies.html https://ocaml.org/learn/companies.html

catnaroek 11y ago

Still no support for threads running in parallel? I guess things didn't go well: https://news.ycombinator.com/item?id=9582980 https://news.ycombinator.com/item?id=9582980

Scramblejams 11y ago
There's still hope! There are a number of much anticipated features that haven't made it into this release. In particular, the multicore GC, which at one point had been expected to land in 4.03, has been pushed back, likely to 4.04.
- zerosign 11y ago
  and when exactly 4.04 will pop up ? ~~ Well, I know, it's hard. ..
  - technomancy 11y ago
    I'm guessing after 4.03 and before 4.05?
eggy 11y ago
I really wanted to use OCaml, but it is adding features way later than I can continue to wait. I've started learning Ponylang as my CSP language over Elixir ever since I checked it out several months ago. Maybe OCaml will fit the bill one day. Jane Street's inertia seems to keep it going outside of the academic world, but that's a single linchpin in the commercial world outside of its academic pen.
- amirmc 11y ago
  Many commercial companies (and startups) use OCaml, eg Facebook, Bloomberg, etc https://ocaml.org/learn/companies.html https://ocaml.org/learn/companies.html
  - eggy 11y ago
    I am aware companies, big companies, use OCaml. My point, perhaps not made clear, is that Jane Street is building useful libs, and contributing back to OCaml with 'batteries included' type libraries. Facebook creating a VM and programming language compatible with PHP may be useful to some, but is not addressing the more fundamental needs or issues like bringing multicore to OCaml.
    - amirmc 11y ago
      I think that does a disservice to the much greater number of people who are not at Jane Street but contributing useful code and libraries. You also seem to imply that Jane Street is the one 'bringing multicore to OCaml' but that's not the case. Jane Street certainly contributes a huge amount to the ecosystem, both in terms of code and other support, but they're not the only people pouring effort into it.

BWStearns 11y ago

If I were already sold on using Haskell or OCaml for a new project, what would be the big seller for OCaml being the choice? I haven't dug into SML or OCaml and I'm not expert with Haskell yet but from looking at them they don't look substantially distant from Haskell.

semisight 11y ago
Can't speak for OCaml yet; I've wanted to learn for a while but decided to go with Haskell first. On the Haskell side of things--it's biggest seller (functional purity) is also the biggest downside. To give you an idea, papers have been written about the best way to implement common data structures purely functionally. From what I've seen, OCaml has less "abstraction overhead" because it can dip into imperative code. While Haskell is really fun, it definitely has moments where you want to beat your head against your desk.
- catnaroek 11y ago
  The real downside isn't purity - purity is a good thing! What Haskell suffers from is a lack of flexibility w.r.t. the evaluation strategy of pure functions. More precisely: (0) Haskell starts with a bad default - laziness. (1) Haskell uses special annotations to introduce strictness. The presence of these annotations isn't tracked by the type system, which reduces the usefulness of the type system as a tool for understanding your program. (2) More sophisticated evaluation strategies (e.g., memoizing functions, which can be seen as a generalization of laziness) are difficult to achieve in Haskell, even though it's completely straightforward in ML.
seagreen 11y ago
I've only written Haskell, but I'll try to give a fair shakedown from my perspective: + OCaml is eagerly evaluated while Haskell is lazily evaluated. This makes it easier to reason about things like memory use in OCaml. + IO is reflected in the type signature of Haskell functions. You may find this annoying because it stinks to have to change a lot of type signatures just because, e.g., you want one of your utility functions to make a log entry when called. On the other hand, IO is often a huge deal either semantically or from a performance perspective. For big projects having IO reflected in the type system can be a huge help. + The ecosystems are different. Haskell's is bigger, though I've heard the quality of OCaml libraries tends to be very high.

zerosign 11y ago

how about SMT support for ocaml(multicore) ? Could it catch up to the current implementation (HEAD) or it's still in the process of moving its implementation ?

xvilka 11y ago

And here is the pending effort for better experience of OCaml on Windows: https://github.com/ocaml/opam/issues/2191 https://github.com/ocaml/opam/issues/2191

kxyvr 11y ago
For me, this has been the central issue for not moving many of my projects to OCaml. OPAM sort of works on Windows, but most of the packages I tried to pull broke and fixing them was difficult. Making OPAM work seamlessly on Windows would be a big win in my opinion.
- dhekir 11y ago
  I had some success using this MinGW-based OPAM repository: https://github.com/fdopen/opam-repository-mingw https://github.com/fdopen/opam-repository-mingw The packages that I needed and that didn't compile in the standard repository were working thanks to patches applied in his repository. Also, the maintainer was very prompt and helpful when dealing with my pull request. There are other forks of that repository, but when googling for "opam windows" they do not appear on the first page, which is unfortunate since they seem to me the best currently available option.
  - kxyvr 11y ago
    Thanks for the reference as I've not tried that. Unfortunately, that project just failed to install for me, but I put in a bug report for the maintainer. Ideally, there'd be an official Windows port and installer that doesn't depend on Cygwin. Certainly that takes time and effort to develop and maintain, so it's nice to see projects like this in the interim.
kevingadd 11y ago
Getting OCaml working at all on Windows was a hell nightmare early last year when we were setting it up for WebAssembly and that definitely soured people's opinions of it. We stuck with it because it had some dedicated fans in the working group (happily using it on linux, mostly) and it turned out to be worth the trouble, but otherwise we would have turned to some other language (F#, probably). So I'm really glad to see those problems are being taken seriously!

doomrobo 11y ago

Could anyone explain ephemerons further, maybe with examples? It seems really interesting.

jlouis 11y ago
The wikipedia page explains them pretty well I think, so going there is a better explanation than anything else. For a programmer, they allow you to be more precise about the point in time where an object should be regarded as a weak object. That is, an object which can be collected when under GC pressure. A weak references edges itself toward this goal, but often require some manual intervention and/or knowledge of the GC world to manage by the programmer. An ephemeron removes this additional knowledge from the programmers mind. It allows one programmer to make an interface which is truly not leaking in GC abstraction. So other programmers don't have to know about it at all.

GreaterFool 11y ago

I really hope modular implicits will make it to the language one day. While OCaml libraries are no stranger to monads they usually only include `bind` and `return`. Since I'm coming from Haskell I'm used to a vast Applicative and Monad vocabulary and making do with just `bind` and `return` is rather painful. So having a generic library of Monad combinators that one could use with any Monad would be great. Also, being able to just write `show x` is so nice! Edit: while I often see "modular implicits are being worked on" it is not very clear whether there is a concrete plan to add them to the language. Is there any place in the official OCaml repository / issue tracking system / wiki etc where one could check the status?

lpw25 11y ago
> Is there any place in the official OCaml repository / issue tracking system / wiki etc where one could check the status? You can see some things on: https://github.com/ocamllabs/ocaml-modular-implicits but you shouldn't take a lack of activity on there as a sign nothing is happening. For instance, Frederic is actively hacking on the prototype at the moment but hasn't pushed anything to that repo.
- GreaterFool 11y ago
  That's really great.
virtualwhys 11y ago
> I really hope modular implicits will make it to the language one day "I'm expecting there will be more news about those in the next six months". I'd be very surprised not to see modular implicits in 4.04 now that the foundation has been put in place with Flambda[1]: "Even if you're perfectly happy with OCaml's performance as is, Flambda is still an exciting change. That's because various upcoming language improvements like modular implicits (a feature that brings some of the same benefits as Haskell's typeclasses) will only really perform acceptably well with a good inliner in place". [1] https://blogs.janestreet.com/flambda/ https://blogs.janestreet.com/flambda/
massysett 11y ago

agentgt 11y ago

I wonder if this change will have any impact on multicore OCaml (given the reduction of allocation)? I don't know the internals of OCaml that well but multicore support has been my BS reason for not embracing OCaml albeit Mirage is looking better and better every day.