4 ms·

My perception is that F# is attracting the open source folks in the .Net community http://tomasp.net/blog/2015/why-fsharp-in-2015/ http://tomasp.net/blog/2015/w

• cies 11y ago
  But we all know F# is a gateway drug to... :)
  • ane 11y ago
    OCaml!
• daxfohl 11y ago
  Ironically, I love F# but still waiting for F# on JVM before beginning any serious work.
  • sirseal 11y ago
    Do you really believe that it'll ever be on the JVM? Why would Microsoft put any effort into that? CLR is now cross platform. If you want functional programming that is similar in style to F# (and ML-family of languages), check out Scala.
  • srean 11y ago
    Yet more irony: One of its prime attractions is that it is not tied to JVM. JVM is a pretty well optimized system till you have to touch JNI
  • sklogic 11y ago
    JVM is incapable of running anything like F# efficiently.
    • ectoplasm 11y ago
      How come?
      • sklogic 11y ago
        It's got some severe built-in limitations. Firstly and most importantly, there is no support whatsoever for the proper tail calls (and F# is using the .tail prefix quite a lot). Secondly, no stack allocation (value types in .NET). Another thing which may harm optimisation significantly (although not sure if F# is using it - but the other functional languages most definitely would have benefited from this) is a very low hard limit on a method size, which forbids any extensive inlining and specialisation.
        • ectoplasm 11y ago
          Thanks for clarifying. I think tail call conversion to iteration for Java bytecode could be added to a JVM implementation without changing the spec, and you could also do it when converting F# to bytecode. Apparently it's on the todo list but not high priority. Stack allocation is trickier if it's specified in F# code, because it isn't part of the VM spec, but automatic stack allocation for Java has been demonstrated in a research context and I think either HotSpot or J9 can do it too. The method size limit is something like 2^16 bytecodes, but even if that's a problem, JITs are free to inline beyond that as much as they want. So, I agree it would take some work but I don't think it's fundamentally impractical. Adding stack allocation to the class file format would be the hardest thing to push through I think.
          • sklogic 11y ago
            > I think tail call conversion to iteration You cannot convert a tail call to an iteration in a generic case. Consider the following: `let f g x = g x` Here, call `g x` is a tail call, and you've no idea what `g` is, so you cannot statically inline it or convert to a loop. > JITs are free to inline beyond that as much as they want JITs are primitive and do not have much time to do anything interesting. Inlining is very important alongside with partial evaluation - which is very heavyweight and must be done statically. Anyway, without proper tail calls inlining on JIT level won't help much. > it's fundamentally impractical Everyone who ever tried implementing any ML-like language on top of JVM failed miserably.
• CmonDev 11y ago
  Not really, they struggle to gain any significant traction.