5 ms·

Kinda wish they had gone with F#. Would've been less work for them to write nice functional wrappers around existing .NET libraries. Of course, you can't get f

by krapht 7y ago

Kinda wish they had gone with F#. Would've been less work for them to write nice functional wrappers around existing .NET libraries. 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.

mseri 7y ago
What are the main missing features that make you wait?
ernst_klim 7y ago
>Would've been less work for them to write nice functional wrappers around existing .NET libraries. 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.
- profquail 7y ago
  It's been feasible to run F# on Unix for years, first via Mono, and more recently with .NET Core.
- BeetleB 7y ago
  F# works just fine in Linux. Better than OCaml in Windows. It is the reason I decided to pick F# over OCaml.
  - ernst_klim 7y ago
    >Better than OCaml in Windows. 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?
    - BeetleB 7y ago
      >OCaml works great in windows and have good .Net bindings. 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/ https://www.mono-project.com/docs/gui/gtksharp/ [1] https://gstreamer.freedesktop.org/htdocs/bindings/dotnet.html https://gstreamer.freedesktop.org/htdocs/bindings/dotnet.htm...
      - ernst_klim 7y ago
        >The last time I checked (less than a year ago), opam was mostly broken on Windows 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. [1] https://fdopen.github.io/opam-repository-mingw/ https://fdopen.github.io/opam-repository-mingw/
srean 7y ago
> around existing .NET libraries. 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 ?
- pjmlp 7y ago
  There used to be some like IMSL, now discontinued, I guess there are others still.
  - srean 7y ago
    That's the problem. Everybody has to guess. Everyone thinks there is something out there that somebody else knows. This is a problem I dont have in some of the other ecosystems. 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.
    - pjmlp 7y ago
      I have to guess because that kind of work was only relevant to me 5 years ago, so I lost track of what everyone doing data analysis with .NET is using nowadays.
      - srean 7y ago
        Oh I have been guessing all year long for several years although it is very relevant to what I do. 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.
- metta2uall 7y ago
  What about Math.NET?
Cybiote 7y ago
Ocaml and F# are great languages but, rather than lament what language this excellent math library/framework is implemented in, lament that there is no F# equivalent or that projects like Owl outside Python don't really get the attention they need. While having multiple such frameworks per language makes little sense, each language having its own mathlib ecosystem makes a lot of sense from a diversity perspective. 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.

by krapht 7y ago

mseri 7y ago

What are the main missing features that make you wait?

ernst_klim 7y ago

>Would've been less work for them to write nice functional wrappers around existing .NET libraries. 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.

profquail 7y ago
It's been feasible to run F# on Unix for years, first via Mono, and more recently with .NET Core.
BeetleB 7y ago
F# works just fine in Linux. Better than OCaml in Windows. It is the reason I decided to pick F# over OCaml.
- ernst_klim 7y ago
  >Better than OCaml in Windows. 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?
  - BeetleB 7y ago
    >OCaml works great in windows and have good .Net bindings. 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/ https://www.mono-project.com/docs/gui/gtksharp/ [1] https://gstreamer.freedesktop.org/htdocs/bindings/dotnet.html https://gstreamer.freedesktop.org/htdocs/bindings/dotnet.htm...
    - ernst_klim 7y ago
      >The last time I checked (less than a year ago), opam was mostly broken on Windows 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. [1] https://fdopen.github.io/opam-repository-mingw/ https://fdopen.github.io/opam-repository-mingw/

srean 7y ago

> around existing .NET libraries. 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 ?

pjmlp 7y ago
There used to be some like IMSL, now discontinued, I guess there are others still.
- srean 7y ago
  That's the problem. Everybody has to guess. Everyone thinks there is something out there that somebody else knows. This is a problem I dont have in some of the other ecosystems. 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.
  - pjmlp 7y ago
    I have to guess because that kind of work was only relevant to me 5 years ago, so I lost track of what everyone doing data analysis with .NET is using nowadays.
    - srean 7y ago
      Oh I have been guessing all year long for several years although it is very relevant to what I do. 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.
metta2uall 7y ago
What about Math.NET?

Cybiote 7y ago

Ocaml and F# are great languages but, rather than lament what language this excellent math library/framework is implemented in, lament that there is no F# equivalent or that projects like Owl outside Python don't really get the attention they need. While having multiple such frameworks per language makes little sense, each language having its own mathlib ecosystem makes a lot of sense from a diversity perspective. 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.