12 ms·

If F# ever got something akin to Scala Native, or Kotlin Native, I think it'd do really well. In my limited understanding of the F# ecosystem, I don't believe t

If F# ever got something akin to Scala Native, or Kotlin Native, I think it'd do really well. In my limited understanding of the F# ecosystem, I don't believe there are a lot of voices calling towards a multiplatform future beyond the NET world. Fable is cool, but native is a must-have for a lot of people, myself included. The docs are bad but not inexcusably so, it's a nice project within MS, I get it. The underlying machinery leaks a little into the language, things like "discard" are irritating but not unforgivable. And it's not just running native, I know NET nerds will want to tell me about corert or native or whatever it's called, but that doesn't solve the issue. F# has a weak core, it's not like Clojure where I have this wide array to choose from regardless of the platform. I can choose NET or Fable and the development experience varies wildly between those two environments, in my limited experience. All in all, I think F# will live a medium-length life. Without solving the native problem and moving beyond NET, I don't see it flourishing in many important niches. If I was going to adopt a new language, it'd probably be Nim over F#, etc.

cies 6y ago
Isn't F# pretty much OCaml.NET? So if you want native, you may also go with OCaml (or ReasonML if you prefer curly-delimited code blocks). For frontend dev't I really like Elm lately. (the article makes many refs to Elmish, the Elm-on-F# project).
- adenozine 6y ago
  Yes! Ocaml is quite good. Concurrency is kinda poor, but it's coming along. I am glad that Elm has influenced so many ecosystems. I wouldn't touch it with a ten foot pole because of the author, but I think the ideas of the project are invaluable and long overdue.
  - toolslive 6y ago
    concurrency is excellent in OCaml (Lwt, async, ....) it's just paralllelism that's a problem. multi core ocaml will eventually fix that.
    - adenozine 6y ago
      Ah, of course. Clerical mistake on my part
    - patrec 6y ago
      You make it almost sound like having a fractured eco system with two different incompatible async frameworks is a good thing! :P
  - Cederfjard 6y ago
    Could you please elaborate on what you said about Elm and its author? How come?
    - deleted 6y ago
      [deleted]
    - adenozine 6y ago
      https://reasonablypolymorphic.com/blog/elm-is-wrong/ https://reasonablypolymorphic.com/blog/elm-is-wrong/ Here's a good starting place. Look for some discussions about typeclasses and read for yourself. Ask yourself if you'd bet on this person, and if you'd build critical tools for your org with a tool dictated by them. I have no ill will for Elm. I'm grateful it exists and that we can all learn. I'd never invest in it though, it's too much a risk for things that could affect my ability to put food on the table quickly enough. I'm not a frontend guy, so if some crazy frontend bug happened and crunched up my landing page or any of my forms, I'm not confident that I could debug it fast. I hate to say it, but honestly I think TS has to be the future of front end web. It's simply too solid to consider very many other options. The one-man-running-the-show act kinda works for small things, like Tarsnap is a great example. But for languages that are powering business frontends, I can't have some goofball with a bad opinion holding up progress on something important.
  - cies 6y ago
    Works like a charm, and when the community tanks (what will most likely be due to the close access innovation model and the main authors behavior), then there is a project to convert Elm code to PureScript. :)
  - dfgdghdf 6y ago
    The Elm architecture has been implemented in F# as "Elmish". It's quite nice! I think Fable wins over Elm, simply because F# is such a great server-side language. Even if I was writing an Elm app, I would still likely reach for F# on the back-end.
- naringas 6y ago
  similarly to how C# is very much java.net ??
  - samus 6y ago
    This is a bit inappropriate since for a long time now Java was busy catching up to C#. When Project Valhalla merges, Java's type system will become very close to what C# is now: reified generics and first-class value types. Algebraic data types will also come to town. But only after Project Loom merges, Java will be firmly ahead again with a fresh take on all matters async.
    - pjmlp 6y ago
      C# also keeps copying Java stuff to this day like default interface methods. In fact, having had spent most of my focus across Java, .NET and C++ since their early days, it is quite interesting to follow how certain features keep being copied across them.
    - ecshafer 6y ago
      But C# was literally Microsoft's Java implementation that they forked after they were sued by Sun, was it not? So it is quite appropriate.
      - Jtsummers 6y ago
        C#'s development was motivated by their relationship with Sun, but J++ was MS's non-conforming Java implementation. They were sued for it, and basically couldn't develop it any further (with regard to maintaining Java compatibility, to the extent that they cared to at least).
      - TurkTurkleton 6y ago
        Microsoft's Java implementation that got them sued was J++. As part of the settlement, they weren't allowed to add any new features to it, and it quietly faded into obscurity, along with its CLR counterpart J#, the latter having finally left even extended support in 2017. C# was developed independently of J++ and J# (though J# was based on J++ to provide a transition path for J++ developers), and although Anders Hejlsberg (original lead architect of C#) did also work on J++, he also worked on Turbo Pascal and Delphi before coming to Microsoft, and I'd suspect that those influenced C# more (more conceptually than syntactically, of course).
- mumblemumble 6y ago
  In the same way that Objective-C is just C++ for Macs. They share a common lineage, but do so many things so differently that you really can't consider them to be all that similar. And the difference starts with having completely different object systems. Beyond different OOP mechanisms, some things OCaml has that F# doesn't: - Functors - Polymorphic variants - camlp4 And some things F# has that OCaml doesn't: - Computation expressions - Type providers - Quotations (as a built-in) - Units of measure - Active patterns
- sideeffffect 6y ago
  > Isn't F# pretty much OCaml.NET? Kinda yes, kinda no. There's a whole interesting story to it: https://dl.acm.org/doi/pdf/10.1145/3386325 https://dl.acm.org/doi/pdf/10.1145/3386325
- gameswithgo 6y ago
  It is, but with a syntax that most people find less odd, and a couple of very compelling features, like..the ability to leverage more than one core, active patterns, and type providers.
dfgdghdf 6y ago
.NET has native ahead-of-time compile options that are getting better all the time. F# actually works better with these tools than other .NET languages because it is less reliant on reflection etc. to build its abstractions. You can write C bindings for F# libraries compiled this way.
- whb07 6y ago
  I've toyed around on a weekend or two looking at the different ways to AOT stuffs for F#. Here is what I found: Same hello-world console app from C# runs alright with AOT. The F# does not as it relies on heavier reflection stuffs (at least thats what it seems like). The F# version did compile but just crashed on run. The suspect appears to be the way to console print seems to call a different non AOT function. The interesting part was I did write some bindings calling for a console print via CFFI that did then allow me to compile the F# app and run fine.
  - pjmlp 6y ago
    That is a well known issue, also what prevented F# to be properly used in .NET Native. https://github.com/dotnet/corert/issues/5780#issuecomment-401877015 https://github.com/dotnet/corert/issues/5780#issuecomment-40...
  - dfgdghdf 6y ago
    Sounds like things have shifted since I last used it. Here's hoping they resolve this stuff soon!
pjmlp 6y ago
Well neither Scala Native, nor Kotlin/Native are examples of world changing projects, so thankfully F# hasn't gone down that route. In fact, Kotlin/Native is a poster child example of how not to design a language breaking the memory semantics with the rest of the eco-system.
- txdv 6y ago
  Can you elaborate more on "In fact, Kotlin/Native is a poster child example of how not to design a language breaking the memory semantics with the rest of the eco-system."?
  - pjmlp 6y ago
    Sure, when Kotlin/Native was introduced they had the clever idea to force a memory model incompatible with what any JVM written code would be expecting, so you need to explicitly write Kotlin/Native aware code. https://itnext.io/why-the-kotlin-native-memory-model-cannot-hold-ae1631d80cf6 https://itnext.io/why-the-kotlin-native-memory-model-cannot-... Naturally this wasn't going to turn out well, and now they are redoing it with a proper GC. https://blog.jetbrains.com/kotlin/2020/07/kotlin-native-memory-management-roadmap/ https://blog.jetbrains.com/kotlin/2020/07/kotlin-native-memo...
nojito 6y ago
> Fable is cool Fable is a game changer and is arguably a better Typescript in terms of jacking into the javascript ecosystem. Ruby had Rails, Python had Django + Pandas..... F# has Fable
- hawk_ 6y ago
  how is fable better than ts, could you elaborate?
  - reverseblade2 6y ago
    Firstly you can share code with .net and JS side. Secondly, you can do proper functional programming with F#. Third I find type system typescript as cryptic.
  - nojito 6y ago
    F# users generally avoid hierarchal type systems that plague TS/C# etc. Don Syme has a great talk about this, but essentially things get out of hand very very quickly. https://youtu.be/1AZA1zoP-II?t=2408 https://youtu.be/1AZA1zoP-II?t=2408 With Fable you are able to take the simplicity and conciseness of F# and jack into the entire JS ecosystem without falling into the type hierarchy nonsense.
Cybiote 6y ago
I think the best way to think about such things is in terms of niches and ecosystem. The niche of functional and native is small and already well served by Haskell, Ocaml and even Rust to an extent. The .net, python and JVM contain some of the largest ecosystems. Even if small relative to C#, the niche size and health of a functional language on .NET is much larger than if it were another native langauge. Speed, documentation and tooling might not exactly match C#, but are excellent in comparison to other functional languages. In a similar vein, niche size for a transpiled functional language is much larger, more so if the language prioritizes playing well with its parent ecosystem. There is room enough for Fable, Clojurescript, elm, purescript and Reason to co-exist.
- mumblemumble 6y ago
  Concrete example: for my latest side project, I chose F# because it was the most compelling (to me) language with a decent option for cross-platform GUI that isn't Electron. (Avalonia.FuncUI, which has a nice Elm-y feel.) The reason it had a good cross-platform GUI library available in the first place is very much because it lives on .NET, and can build on of the rest of the .NET ecosystem.
- hctaw 6y ago
  Pure anecdote, but I've never seen a project become less native. Meanwhile state of the art JITs (for .NET, JVM, Swift, and other traditionally managed runtimes) are increasingly blurring what it means for a language to be native and what the benefits for "native" even are. So I don't think it's useful to think in terms of niches, because niches are constantly disappearing within our ecosystems. We're reaching a point where the implementation of a language is mostly a solved problem (throw it on top of some JIT for a bigger language) and the only meaningful innovation is in the semantics and syntax of a language for expressing intent and providing soundness. If we're skating to where the puck is going here, I wouldn't say it makes sense to ignore native compilation for functional languages because that's a well served niche, but because AOT compilation itself is becoming niche.

cies 6y ago

Isn't F# pretty much OCaml.NET? So if you want native, you may also go with OCaml (or ReasonML if you prefer curly-delimited code blocks). For frontend dev't I really like Elm lately. (the article makes many refs to Elmish, the Elm-on-F# project).

adenozine 6y ago
Yes! Ocaml is quite good. Concurrency is kinda poor, but it's coming along. I am glad that Elm has influenced so many ecosystems. I wouldn't touch it with a ten foot pole because of the author, but I think the ideas of the project are invaluable and long overdue.
- toolslive 6y ago
  concurrency is excellent in OCaml (Lwt, async, ....) it's just paralllelism that's a problem. multi core ocaml will eventually fix that.
  - adenozine 6y ago
    Ah, of course. Clerical mistake on my part
  - patrec 6y ago
    You make it almost sound like having a fractured eco system with two different incompatible async frameworks is a good thing! :P
- Cederfjard 6y ago
  Could you please elaborate on what you said about Elm and its author? How come?
  - deleted 6y ago
    [deleted]
  - adenozine 6y ago
    https://reasonablypolymorphic.com/blog/elm-is-wrong/ https://reasonablypolymorphic.com/blog/elm-is-wrong/ Here's a good starting place. Look for some discussions about typeclasses and read for yourself. Ask yourself if you'd bet on this person, and if you'd build critical tools for your org with a tool dictated by them. I have no ill will for Elm. I'm grateful it exists and that we can all learn. I'd never invest in it though, it's too much a risk for things that could affect my ability to put food on the table quickly enough. I'm not a frontend guy, so if some crazy frontend bug happened and crunched up my landing page or any of my forms, I'm not confident that I could debug it fast. I hate to say it, but honestly I think TS has to be the future of front end web. It's simply too solid to consider very many other options. The one-man-running-the-show act kinda works for small things, like Tarsnap is a great example. But for languages that are powering business frontends, I can't have some goofball with a bad opinion holding up progress on something important.
- cies 6y ago
  Works like a charm, and when the community tanks (what will most likely be due to the close access innovation model and the main authors behavior), then there is a project to convert Elm code to PureScript. :)
- dfgdghdf 6y ago
  The Elm architecture has been implemented in F# as "Elmish". It's quite nice! I think Fable wins over Elm, simply because F# is such a great server-side language. Even if I was writing an Elm app, I would still likely reach for F# on the back-end.
naringas 6y ago
similarly to how C# is very much java.net ??
- samus 6y ago
  This is a bit inappropriate since for a long time now Java was busy catching up to C#. When Project Valhalla merges, Java's type system will become very close to what C# is now: reified generics and first-class value types. Algebraic data types will also come to town. But only after Project Loom merges, Java will be firmly ahead again with a fresh take on all matters async.
  - pjmlp 6y ago
    C# also keeps copying Java stuff to this day like default interface methods. In fact, having had spent most of my focus across Java, .NET and C++ since their early days, it is quite interesting to follow how certain features keep being copied across them.
  - ecshafer 6y ago
    But C# was literally Microsoft's Java implementation that they forked after they were sued by Sun, was it not? So it is quite appropriate.
    - Jtsummers 6y ago
      C#'s development was motivated by their relationship with Sun, but J++ was MS's non-conforming Java implementation. They were sued for it, and basically couldn't develop it any further (with regard to maintaining Java compatibility, to the extent that they cared to at least).
    - TurkTurkleton 6y ago
      Microsoft's Java implementation that got them sued was J++. As part of the settlement, they weren't allowed to add any new features to it, and it quietly faded into obscurity, along with its CLR counterpart J#, the latter having finally left even extended support in 2017. C# was developed independently of J++ and J# (though J# was based on J++ to provide a transition path for J++ developers), and although Anders Hejlsberg (original lead architect of C#) did also work on J++, he also worked on Turbo Pascal and Delphi before coming to Microsoft, and I'd suspect that those influenced C# more (more conceptually than syntactically, of course).
mumblemumble 6y ago
In the same way that Objective-C is just C++ for Macs. They share a common lineage, but do so many things so differently that you really can't consider them to be all that similar. And the difference starts with having completely different object systems. Beyond different OOP mechanisms, some things OCaml has that F# doesn't: - Functors - Polymorphic variants - camlp4 And some things F# has that OCaml doesn't: - Computation expressions - Type providers - Quotations (as a built-in) - Units of measure - Active patterns
sideeffffect 6y ago
> Isn't F# pretty much OCaml.NET? Kinda yes, kinda no. There's a whole interesting story to it: https://dl.acm.org/doi/pdf/10.1145/3386325 https://dl.acm.org/doi/pdf/10.1145/3386325
gameswithgo 6y ago
It is, but with a syntax that most people find less odd, and a couple of very compelling features, like..the ability to leverage more than one core, active patterns, and type providers.

dfgdghdf 6y ago

.NET has native ahead-of-time compile options that are getting better all the time. F# actually works better with these tools than other .NET languages because it is less reliant on reflection etc. to build its abstractions. You can write C bindings for F# libraries compiled this way.

whb07 6y ago
I've toyed around on a weekend or two looking at the different ways to AOT stuffs for F#. Here is what I found: Same hello-world console app from C# runs alright with AOT. The F# does not as it relies on heavier reflection stuffs (at least thats what it seems like). The F# version did compile but just crashed on run. The suspect appears to be the way to console print seems to call a different non AOT function. The interesting part was I did write some bindings calling for a console print via CFFI that did then allow me to compile the F# app and run fine.
- pjmlp 6y ago
  That is a well known issue, also what prevented F# to be properly used in .NET Native. https://github.com/dotnet/corert/issues/5780#issuecomment-401877015 https://github.com/dotnet/corert/issues/5780#issuecomment-40...
- dfgdghdf 6y ago
  Sounds like things have shifted since I last used it. Here's hoping they resolve this stuff soon!

pjmlp 6y ago

Well neither Scala Native, nor Kotlin/Native are examples of world changing projects, so thankfully F# hasn't gone down that route. In fact, Kotlin/Native is a poster child example of how not to design a language breaking the memory semantics with the rest of the eco-system.

txdv 6y ago
Can you elaborate more on "In fact, Kotlin/Native is a poster child example of how not to design a language breaking the memory semantics with the rest of the eco-system."?
- pjmlp 6y ago
  Sure, when Kotlin/Native was introduced they had the clever idea to force a memory model incompatible with what any JVM written code would be expecting, so you need to explicitly write Kotlin/Native aware code. https://itnext.io/why-the-kotlin-native-memory-model-cannot-hold-ae1631d80cf6 https://itnext.io/why-the-kotlin-native-memory-model-cannot-... Naturally this wasn't going to turn out well, and now they are redoing it with a proper GC. https://blog.jetbrains.com/kotlin/2020/07/kotlin-native-memory-management-roadmap/ https://blog.jetbrains.com/kotlin/2020/07/kotlin-native-memo...

nojito 6y ago

> Fable is cool Fable is a game changer and is arguably a better Typescript in terms of jacking into the javascript ecosystem. Ruby had Rails, Python had Django + Pandas..... F# has Fable

hawk_ 6y ago
how is fable better than ts, could you elaborate?
- reverseblade2 6y ago
  Firstly you can share code with .net and JS side. Secondly, you can do proper functional programming with F#. Third I find type system typescript as cryptic.
- nojito 6y ago
  F# users generally avoid hierarchal type systems that plague TS/C# etc. Don Syme has a great talk about this, but essentially things get out of hand very very quickly. https://youtu.be/1AZA1zoP-II?t=2408 https://youtu.be/1AZA1zoP-II?t=2408 With Fable you are able to take the simplicity and conciseness of F# and jack into the entire JS ecosystem without falling into the type hierarchy nonsense.

Cybiote 6y ago

I think the best way to think about such things is in terms of niches and ecosystem. The niche of functional and native is small and already well served by Haskell, Ocaml and even Rust to an extent. The .net, python and JVM contain some of the largest ecosystems. Even if small relative to C#, the niche size and health of a functional language on .NET is much larger than if it were another native langauge. Speed, documentation and tooling might not exactly match C#, but are excellent in comparison to other functional languages. In a similar vein, niche size for a transpiled functional language is much larger, more so if the language prioritizes playing well with its parent ecosystem. There is room enough for Fable, Clojurescript, elm, purescript and Reason to co-exist.

mumblemumble 6y ago
Concrete example: for my latest side project, I chose F# because it was the most compelling (to me) language with a decent option for cross-platform GUI that isn't Electron. (Avalonia.FuncUI, which has a nice Elm-y feel.) The reason it had a good cross-platform GUI library available in the first place is very much because it lives on .NET, and can build on of the rest of the .NET ecosystem.
hctaw 6y ago
Pure anecdote, but I've never seen a project become less native. Meanwhile state of the art JITs (for .NET, JVM, Swift, and other traditionally managed runtimes) are increasingly blurring what it means for a language to be native and what the benefits for "native" even are. So I don't think it's useful to think in terms of niches, because niches are constantly disappearing within our ecosystems. We're reaching a point where the implementation of a language is mostly a solved problem (throw it on top of some JIT for a bigger language) and the only meaningful innovation is in the semantics and syntax of a language for expressing intent and providing soundness. If we're skating to where the puck is going here, I wouldn't say it makes sense to ignore native compilation for functional languages because that's a well served niche, but because AOT compilation itself is becoming niche.