Of course, you can't get funding for something that unambitious, so I understand the tack. Still...
I look forward to trying this out once more significant work has been done. I'm a big fan of OCaml-like languages, if that wasn't already obvious.
We should want to see examples grow not just for F# or Ocaml but also Haskell, Rust, Scala and others. Then we should prioritize as much as possible, inter-operation of libraries, model definitions and outputs.
What? Why would they do it? Unix is a standard in the field of scientific computations, so wrapping blas and lapack totally makes sense. Besides, OCaml already had good blas, lapack bindings.
OCaml works great in windows and have good .Net bindings. LexiFi earns money nearly solely from OCaml on windows.
>F# works just fine in Linux.
Does it have bindings for the majority of popular libs? For example are there Gstreamer and Gtk F# bindings? Do they work on both .Net Core and Mono?
Perhaps I should clarify. While the language itself might work, the ecosystem didn't seem great. The last time I checked (less than a year ago), opam was mostly broken on Windows. opam is the officially recommended package manager. I didn't want to invest in a system where the official support was virtually nonexistent. Looking at it now, there does seem to be a port of opam for Windows, and the first commit in that repo was less than a year ago, so quite possibly after I last checked.
If it works, I may just switch to it (although in my opinion any software requiring cygwin still means poor Windows support...).
>Does it have bindings for the majority of popular libs? For example are there Gstreamer and Gtk F# bindings? Do they work on both .Net Core and Mono?
There is GTK#[0], which claims support for both. There is Gst#[1], although they claim it is in early stage development.
[0] https://www.mono-project.com/docs/gui/gtksharp/ [1] https://gstreamer.freedesktop.org/htdocs/bindings/dotnet.htm...
opam had windows version based on cygwin for a long time [1].
> any software requiring cygwin still means poor Windows support
And software requiring .Net has good linux support? Since when requiring an additional runtime means poor support?
>While the language itself might work, the ecosystem didn't seem great.
Sure, just like .Net ecosystem, which is totally absent on linux. No wpf, media foundation. And bindings to local facilities, like gstreamer, are lacking.
Yet the only real metric of the maturity of the support is the fact that people use it in production. And people heavily use OCaml on windows in production.
Which ones ? A free one analogous to libmath that works with float32 would be a good start.
Am serious, would love to know of some .Net libraries for number crunching that one would miss if one were to move out of the .Net platform. Or did you mean non-numeric libraries ?
That I would have to (i) write my own cos or (ii) take a dependency on a commercial 3rd party library that will likely not be around for long or (iii) call a native library through and FFI, for something as simple as a cos of float32 is not terribly exciting.
BTW I did not intend to mean that you are being unhelpful. Scientific computation just isnt a first class citizen of the .net ecosystem. Either you have to write your own or take a dependency on a commercial library for even the simplest stuff and pray that they will be around.
https://github.com/mathnet/mathnet-numerics/commit/3a0d55fd2...
https://github.com/mathnet/mathnet-numerics/pull/481/commits...