3 ms·

Not related to the topic but how do you find ocaml as compared to python or rust? Do you think its worth learning today as opposed to rust for high level genera

Not related to the topic but how do you find ocaml as compared to python or rust? Do you think its worth learning today as opposed to rust for high level general purpose programming?

njs12345 10y ago
It occupies a slightly different niche to Rust as it has a GC. If you can live with that, it's probably going to be more productive than Rust for you. It's definitely worth playing around with a language from that family. OCaml is maybe slightly more practical than Haskell and it has some nice resources available - in particular Real World OCaml looks really good: https://realworldocaml.org/ https://realworldocaml.org/
lmm 10y ago
It is well worth learning an ML-family language. In addition to Rust, OCaml or Haskell as njs12345 mentioned, F# or Scala might be options. OCaml is probably more mature than Rust, has more libraries available, and has automatic memory management which takes some of the load off you (especially if you're writing a GUI application, IME). But it's not got Rust's "hot right now" factor, it doesn't have Rust's ease of embedding in other languages, and it doesn't have quite the same focus on high-quality documentation. If you already know Rust I wouldn't bother learning both - they're very similar languages.
krat0sprakhar 10y ago
Absolutely! If you're looking for fast, GC'd, native functional language I'd say OCaml is a great option. There's actually a very comprehensive set of blog posts migrating an open-source python based project to OCaml, that I'd recommend reading if you're looking for a more thorough comparison - http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-retrospective/ http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret... Personally, I used OCaml while at university to write a programming language (http://jsjs-lang.org http://jsjs-lang.org) and totally loved it. Real world OCaml is a great resource and I'd definitely recommend giving OCaml a try. My only regret is that I don't get to write OCaml as much as I want to due to the kind of projects I work on, but given that Bucklescript[0] and Reason[1] are moving ahead in full steam, that might change shortly too :) [0]- https://bloomberg.github.io/bucklescript/ https://bloomberg.github.io/bucklescript/ [1] - https://facebook.github.io/reason/ https://facebook.github.io/reason/
jackmott 10y ago
It is worth looking at F# as well, which is basically OCaml on the .NET platform. With the advantages of having the entire .NET ecosystem of libraries available for use, being able to use more than one core of your cpu, a solid IDE, and some other features like type providers. There are some disadvantages as well, such as not being able to compile to a native executable. Anyway the syntax is so similar you can learn one and switch to the other with very little pain.
nickpsecurity 10y ago
I'll also add to their recommendations that GC'd languages can be used for OS's or system code. You can do that with a number of strategies: 1. Go unsafe on lowest-level operations that simply can't be GC'd. Quite a few of these can be expressed as finite, state machines which can be model-checked for correctness. Static analyzers are also really good these days in whatever code you can avoid dynamic allocation in. The rest of the code is GC'd. That's what the Oberon operating systems do. 2. Use a real-time, low-latency, concurrent GC that basically knocks low single or two digit performance out of the system. Lots of products in embedded Java have special GC's for that. Buy a faster CPU. Trade dollars or performance for productivity and safety. 3. Use a mix of GC's in the system where each one is tuned for the job at hand. You might use a real-time, concurrent one in the kernel. Maybe just reference counting in one more about performance. Maybe a straight-forward one for stuff that's not performance-critical. Could even use one that's mathematically verified for correctness in that situation. JX Operating System is an example of OS that mixes up GC strategies. That's for software. Your options open up a bit if you can also deploy custom hardware. At the least, a modified soft-core on an FPGA. The LISP machines & maybe a Java CPU of the past often included hardware acceleration for garbage collection. One built the GC right into memory subsystem/interface of the processor where neither the processor nor applications had to be aware of its existence. It just did its thing in parallel to execution of the app. A concurrent, low-latency one integrated with virtual, memory hardware shouldn't take much hardware resources to pull off.

Not related to the topic but how do you find ocaml as compared to python or rust? Do you think its worth learning today as opposed to rust for high level general purpose programming?

njs12345 10y ago

It occupies a slightly different niche to Rust as it has a GC. If you can live with that, it's probably going to be more productive than Rust for you. It's definitely worth playing around with a language from that family. OCaml is maybe slightly more practical than Haskell and it has some nice resources available - in particular Real World OCaml looks really good: https://realworldocaml.org/ https://realworldocaml.org/

lmm 10y ago

It is well worth learning an ML-family language. In addition to Rust, OCaml or Haskell as njs12345 mentioned, F# or Scala might be options. OCaml is probably more mature than Rust, has more libraries available, and has automatic memory management which takes some of the load off you (especially if you're writing a GUI application, IME). But it's not got Rust's "hot right now" factor, it doesn't have Rust's ease of embedding in other languages, and it doesn't have quite the same focus on high-quality documentation. If you already know Rust I wouldn't bother learning both - they're very similar languages.

krat0sprakhar 10y ago

Absolutely! If you're looking for fast, GC'd, native functional language I'd say OCaml is a great option. There's actually a very comprehensive set of blog posts migrating an open-source python based project to OCaml, that I'd recommend reading if you're looking for a more thorough comparison - http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-retrospective/ http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret... Personally, I used OCaml while at university to write a programming language (http://jsjs-lang.org http://jsjs-lang.org) and totally loved it. Real world OCaml is a great resource and I'd definitely recommend giving OCaml a try. My only regret is that I don't get to write OCaml as much as I want to due to the kind of projects I work on, but given that Bucklescript[0] and Reason[1] are moving ahead in full steam, that might change shortly too :) [0]- https://bloomberg.github.io/bucklescript/ https://bloomberg.github.io/bucklescript/ [1] - https://facebook.github.io/reason/ https://facebook.github.io/reason/

jackmott 10y ago

It is worth looking at F# as well, which is basically OCaml on the .NET platform. With the advantages of having the entire .NET ecosystem of libraries available for use, being able to use more than one core of your cpu, a solid IDE, and some other features like type providers. There are some disadvantages as well, such as not being able to compile to a native executable. Anyway the syntax is so similar you can learn one and switch to the other with very little pain.

nickpsecurity 10y ago

I'll also add to their recommendations that GC'd languages can be used for OS's or system code. You can do that with a number of strategies: 1. Go unsafe on lowest-level operations that simply can't be GC'd. Quite a few of these can be expressed as finite, state machines which can be model-checked for correctness. Static analyzers are also really good these days in whatever code you can avoid dynamic allocation in. The rest of the code is GC'd. That's what the Oberon operating systems do. 2. Use a real-time, low-latency, concurrent GC that basically knocks low single or two digit performance out of the system. Lots of products in embedded Java have special GC's for that. Buy a faster CPU. Trade dollars or performance for productivity and safety. 3. Use a mix of GC's in the system where each one is tuned for the job at hand. You might use a real-time, concurrent one in the kernel. Maybe just reference counting in one more about performance. Maybe a straight-forward one for stuff that's not performance-critical. Could even use one that's mathematically verified for correctness in that situation. JX Operating System is an example of OS that mixes up GC strategies. That's for software. Your options open up a bit if you can also deploy custom hardware. At the least, a modified soft-core on an FPGA. The LISP machines & maybe a Java CPU of the past often included hardware acceleration for garbage collection. One built the GC right into memory subsystem/interface of the processor where neither the processor nor applications had to be aware of its existence. It just did its thing in parallel to execution of the app. A concurrent, low-latency one integrated with virtual, memory hardware shouldn't take much hardware resources to pull off.