6 ms·

OCaml 4.04.0 released

175 points by mseri 10y ago

jnbiche 10y ago
Damn, still no modular implicits. And no multicore yet, either. Seems like they keep getting pushed back. At least BuckleScript is progressing quickly.
- deleted 10y ago
  [deleted]
- mseri 10y ago
  True, but maybe with this switch to wa tighter release schedule we might be able to see them land in a not too distant future
- throwaway7645 10y ago
  My first reaction was to check for multi-core. I've been hearing its around the corner for years.
desireco42 10y ago
Just finishing OCaml course at Paris Diderot www.fun-mooc.fr/login?next=/courses/parisdiderot/56002S02 Really cool language and opened my eyes on how some constructs are being used. Multicore is definitely must for functional languages.(sorry random thought)
- jackmott 10y ago
  F# is very similar, and has multicore. Can't compile to native yet though, I don't think.
  - whateveracct 10y ago
    F# is a bit lower in terms of abstraction capability compared to OCaml though.
  - pjmlp 10y ago
    It can compile to native via NGEN and Mono, for .NET Native it is WIP.
- jallmann 10y ago
  > Multicore is definitely must for functional languages.(sorry random thought) ...why?
  - i_s 10y ago
    May be worth exploring this from the other side too. Why do you think it is ok for a programming language to lock people into to using just 1 core per process?
    - thinkpad20 10y ago
      I think most would agree that multicore capability is desirable, but it's clearly not a "must" as ocaml has been without it all of this time and many have used it to good effect regardless (of course it might be a must to certain people who need it for their use case). Also, the same restriction that prevents multicore in ocaml (the GIL) also affects other languages which are obviously useful, such as Python. So to answer your question it's clearly "ok" since it doesn't prevent people from productively writing effective and useful software in it, although it is of course a restriction which many would like to see go away.
    - whateveracct 10y ago
      To be fair, the current multiprocess approach that OCaml concurrency libraries use handles the most common concurrency need (concurrent io) just fine. Multicore is most useful for CPU-bound computations.
  - Scarbutt 10y ago
    Definitely not a must, I guess he may be referfing to how immutability and pure functions bring great benefits for writing concurrent programs.
  - desireco42 10y ago
    I didn't want to take it away from announcement. I see others are saying it might not be as important. I believe it to be main attraction of functional languages. We don't want to be stuck on single processor forever and immutability is allowing us to spread wings and utilize processors better. So that is why I think it is imperative ( :) ) to have this as a feature of functional languages.
- DonPellegrino 10y ago
  F# lacks all the most advanced module capabilities of OCaml, is tied to the CLR and isn't free of the Null problem.
  - pjmlp 10y ago
    Meanwhile it enjoys real multi-core, and has much better IDE support, access to 3D accelerated GUIs and high quality DB drivers and proper Windows supports.
nv-vn 10y ago
Glad the release cycle is speeding up, but kinda underwhelmed by the lack of changes which have been floating around in "for the next release" limbo here for a while (multicore, modular implicits, etc.). Either way, lots of great work went into this and I'm happy to see the state of OCaml continuing to evolve for the better. Thanks for all the hard work!
- cm3 10y ago
  I feel your pain, but the features will land when deemed stable. Without more frequent releases, those features would get into a release even later, so more frequent releases are a win either way.
murbard2 10y ago
I apologize for the plug, but I invite folks who like OCaml to check-out Tezos, a project for a self-amending blockchain in OCaml. http://github.com/tezos http://github.com/tezos I think it's a really neat piece of engineering that demonstrates the strength of the language. We have some really nice uses of the GADT and we try and squeeze as much guarantees as we can out of the type system. The modules give us a natural way to follow the principle of least authority by restricting the visible surface of each implementation layer as much as possible. Some of the core Tezos developers are also behind the recent mooc and work on the OCaml compiler.
raphinou 10y ago
I really like ocaml, but it could do with better community management I think. Eg it's been more than one week that the links of the news section on the homepage result in a white page. This might deter newcomers to even try it.
- amirmc 10y ago
  The community efforts are largely volunteer-driven by many people who also have day jobs (including me). Indeed, things could be better but given how much does get done, I'm willing to cut them some slack.
skiplist1 10y ago
I would like to see a language like haskell with no delayed or lazy evaluation so that one can better predict performance. Haskell has a great community and a charm that I would like for Ocaml. Don't know if Jane Street is still advocating their Ocaml core or kernel. F#, ml, haskell and OCaml, and a strong language for parallelism whose name I don't remember are hints that we need a better language. Haskell is not prepared for real world :), and OCaml is a turtle moving target.
- sigrlami9 10y ago
  Haskell has strict extension that removes all delayed/lazy computation from your code. Why do you think it's not ready for real world? It's used by numerous companies around the World for different kinds of software development, starting from formal verification and ending with web sites. Same for OCaml, both languages are very powerful.
- ZenoArrow 10y ago
  > "I would like to see a language like haskell with no delayed or lazy evaluation so that one can better predict performance." I believe there are a few languages that fit that description. Idris is one: http://www.idris-lang.org/ http://www.idris-lang.org/
mseri 10y ago
The changes are explained with some examples here [0]. Flambda is finally on, but comes with a regression :( [1]. [0]: https://github.com/gasche/ocaml-releases-change-explanation/wiki/4.04.0-changes-explanation https://github.com/gasche/ocaml-releases-change-explanation/... [1]: https://sympa.inria.fr/sympa/arc/caml-list/2016-11/msg00000.html https://sympa.inria.fr/sympa/arc/caml-list/2016-11/msg00000....

175 points by mseri 10y ago

Damn, still no modular implicits. And no multicore yet, either. Seems like they keep getting pushed back. At least BuckleScript is progressing quickly.

deleted 10y ago
[deleted]
mseri 10y ago
True, but maybe with this switch to wa tighter release schedule we might be able to see them land in a not too distant future
throwaway7645 10y ago
My first reaction was to check for multi-core. I've been hearing its around the corner for years.

desireco42 10y ago

Just finishing OCaml course at Paris Diderot www.fun-mooc.fr/login?next=/courses/parisdiderot/56002S02 Really cool language and opened my eyes on how some constructs are being used. Multicore is definitely must for functional languages.(sorry random thought)

jackmott 10y ago
F# is very similar, and has multicore. Can't compile to native yet though, I don't think.
- whateveracct 10y ago
  F# is a bit lower in terms of abstraction capability compared to OCaml though.
- pjmlp 10y ago
  It can compile to native via NGEN and Mono, for .NET Native it is WIP.
jallmann 10y ago
> Multicore is definitely must for functional languages.(sorry random thought) ...why?
- i_s 10y ago
  May be worth exploring this from the other side too. Why do you think it is ok for a programming language to lock people into to using just 1 core per process?
  - thinkpad20 10y ago
    I think most would agree that multicore capability is desirable, but it's clearly not a "must" as ocaml has been without it all of this time and many have used it to good effect regardless (of course it might be a must to certain people who need it for their use case). Also, the same restriction that prevents multicore in ocaml (the GIL) also affects other languages which are obviously useful, such as Python. So to answer your question it's clearly "ok" since it doesn't prevent people from productively writing effective and useful software in it, although it is of course a restriction which many would like to see go away.
  - whateveracct 10y ago
    To be fair, the current multiprocess approach that OCaml concurrency libraries use handles the most common concurrency need (concurrent io) just fine. Multicore is most useful for CPU-bound computations.
- Scarbutt 10y ago
  Definitely not a must, I guess he may be referfing to how immutability and pure functions bring great benefits for writing concurrent programs.
- desireco42 10y ago
  I didn't want to take it away from announcement. I see others are saying it might not be as important. I believe it to be main attraction of functional languages. We don't want to be stuck on single processor forever and immutability is allowing us to spread wings and utilize processors better. So that is why I think it is imperative ( :) ) to have this as a feature of functional languages.
DonPellegrino 10y ago
F# lacks all the most advanced module capabilities of OCaml, is tied to the CLR and isn't free of the Null problem.
- pjmlp 10y ago
  Meanwhile it enjoys real multi-core, and has much better IDE support, access to 3D accelerated GUIs and high quality DB drivers and proper Windows supports.

nv-vn 10y ago

Glad the release cycle is speeding up, but kinda underwhelmed by the lack of changes which have been floating around in "for the next release" limbo here for a while (multicore, modular implicits, etc.). Either way, lots of great work went into this and I'm happy to see the state of OCaml continuing to evolve for the better. Thanks for all the hard work!

cm3 10y ago
I feel your pain, but the features will land when deemed stable. Without more frequent releases, those features would get into a release even later, so more frequent releases are a win either way.

murbard2 10y ago

I apologize for the plug, but I invite folks who like OCaml to check-out Tezos, a project for a self-amending blockchain in OCaml. http://github.com/tezos http://github.com/tezos I think it's a really neat piece of engineering that demonstrates the strength of the language. We have some really nice uses of the GADT and we try and squeeze as much guarantees as we can out of the type system. The modules give us a natural way to follow the principle of least authority by restricting the visible surface of each implementation layer as much as possible. Some of the core Tezos developers are also behind the recent mooc and work on the OCaml compiler.

raphinou 10y ago

I really like ocaml, but it could do with better community management I think. Eg it's been more than one week that the links of the news section on the homepage result in a white page. This might deter newcomers to even try it.

amirmc 10y ago
The community efforts are largely volunteer-driven by many people who also have day jobs (including me). Indeed, things could be better but given how much does get done, I'm willing to cut them some slack.

skiplist1 10y ago

I would like to see a language like haskell with no delayed or lazy evaluation so that one can better predict performance. Haskell has a great community and a charm that I would like for Ocaml. Don't know if Jane Street is still advocating their Ocaml core or kernel. F#, ml, haskell and OCaml, and a strong language for parallelism whose name I don't remember are hints that we need a better language. Haskell is not prepared for real world :), and OCaml is a turtle moving target.

sigrlami9 10y ago
Haskell has strict extension that removes all delayed/lazy computation from your code. Why do you think it's not ready for real world? It's used by numerous companies around the World for different kinds of software development, starting from formal verification and ending with web sites. Same for OCaml, both languages are very powerful.
ZenoArrow 10y ago
> "I would like to see a language like haskell with no delayed or lazy evaluation so that one can better predict performance." I believe there are a few languages that fit that description. Idris is one: http://www.idris-lang.org/ http://www.idris-lang.org/

mseri 10y ago

The changes are explained with some examples here [0]. Flambda is finally on, but comes with a regression :( [1]. [0]: https://github.com/gasche/ocaml-releases-change-explanation/wiki/4.04.0-changes-explanation https://github.com/gasche/ocaml-releases-change-explanation/... [1]: https://sympa.inria.fr/sympa/arc/caml-list/2016-11/msg00000.html https://sympa.inria.fr/sympa/arc/caml-list/2016-11/msg00000....