4 ms·
> You'll get almost all of the benefits and most of the drawbacks go away. That's a bit overstatement. You can call .Net code from F#, just like you can call J
by ernst_klim 6y ago
> You'll get almost all of the benefits and most of the drawbacks go away.
That's a bit overstatement. You can call .Net code from F#, just like you can call Java from Clojure or Python/Rust/C from OCaml.
It just would be foreign and unidiomatic (hello, null pointers, methods, OOP).
And you can call C/Python/Rust from OCaml, we made quite a lot of wrappers for Gstreamer and some Rust libs in OCaml and it was quite painless.
So it's a bit of simplification, you can call foreign code in OCaml, it's not that much harder than F# considering there are higher level FFIs for C, Rust and Python available. Author could just use these as well.
- dfgdghdf 6y agoWriting an F# wrapper for a C# API is considerably less involved than writing an OCaml wrapper for a C API. This is because F# and C# share: * build tools * package management * garbage collector * base types (string, int, etc). The F# type-checker understands C# types, so you know that you are consuming the C# API correctly (at least at the type-level). F# can be be used as a new syntax for C#, if you wanted to go that way.
- akra 6y agoMore interestingly you can also go the other way if you use only the lower level F# features (F# being mostly a superset of C# features) and a C# developer won't realise that they are calling F# code - it's all just .NET IL in the end. Did it often when creating libraries at work; it isn't like invoking another language's binary code at all. One of the pro's I guess of working with a VM (JVM/.NET) based language - interop between languages is usually much easier and so niche languages can have a much larger ecosystem than they otherwise would have.