Owl – An OCaml Numerical Library (opens in new tab)

Just a word of caution to set expectations. The "will be here soon" status has been there for a while, to the extent that it now evokes memories of GNU Hurd, Duke Nukem Forever. It will be ready whenever it will be ready, its in good hands, but don't hold your breath, try to work around it for now.

Strong typing with type inference makes it quick and easy to write code (no verbose declarations) that is safe to execute, meaning that the compiler catches 99% of bugs that you usually make, which other languages let through.

Algebraic data types and also a more flexible (if a bit more dangerous) kind of typing that is still type-safe and compiler-checked, but dynamic, called polymorphic variants. These features make it a breeze to define a solid foundation of types for you to write your algorithms on.

Pure functional programming (no mutation) as the default way to write code, with a lightweight and readable syntax. This is a plus because it's the most bug-free way to write code.

Classical imperative programming (loops, I/O, variable mutation) when you need it or when you find it useful for a given task (simplest example: inserting debug prints halfway through a function) without resorting to mind-bending constructs that hide what's really going on behind a facade of purity (Monads and the horrid monad stacks of Haskell, I'm looking at you.)

Compiles to machine code so no useless speed limit (as found in interpreted languages) or heavy startup time and memory footprint (as in JIT / Java)

Predictable complexity (CPU) and memory usage. This is true for most languages, except for Haskell.

Sane exception support. This is also true for most languages, except for Go.

IMHO the poor multicore parallelism issue is way overblown. Yes, most CPUs nowadays have many cores. But if you are writing server/backend code, being limited to a single-threaded model is usually not a problem, because your server will be handling tens or hundreds of simultaneous requests anyway, and handling one at a time on a single core is better for overall throughput. OTOH, if you are writing heavy numerical single-application code, you are better off handling the parallelism by hand, that is, choosing what gets palallelized and how, which library to use, and so on. We don't have hundred-core CPUs yet, so it's a bit early to worry about it. Besides, they are working on it.

PS: I recommend the book https://realworldocaml.org/ (and the Core standard library) for anybody starting with the language.

For me OCaml or the ML family hit the sweet spot of language design.

I will agree that the parallelism issue can be a problem.

Wikipedia explains it properly, if a bit tersely: https://en.wikipedia.org/wiki/Automatic_differentiation

In the case of Owl, it would appear that you have to write your functions using a set of overloaded operators contained in module Maths here: https://github.com/ryanrhymes/owl/blob/master/lib/owl_algodi...

Those operators, as explained in the Wikipedia page, manipulate "dual numbers," which are pairs of (number, epsilon) with their own specific algebra.

Yes, "algorithmic differentiation" is the modern term for what was formerly called "automatic differentiation".

> Is this native support (as opposed to there being a library for it)?

I didn't look into the details, but it seems to be essentially the "operator overloading" approach, not the "source transformation" approach. However, given the optimizing compiler and OCaml's very good module type system, the result might be the same, at least for the forward mode.

Well, the issue of open-vs-closed is less clear with things like MATLAB. Sure you can't download it for free-as-in-beer, but if you own a copy, you are free to inspect its source code, as MATLAB is mainly written in MATLAB (same for Mathematica and other similar packages).

TLAs tend to be horribly overloaded and confusing without a very obvious context.