Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fjord – F# programming language for the JVM

github.com

Post reply on HN
Print view View original

21–30 of 62 posts

Re: Fjord – F# programming language for the JVM

#21

Post by melling »

giulianob wrote: post #19
melling wrote: post #17

Earlier quoted context omitted.

What's the quality of code produced by Mono? How does it compare with Microsoft's compiler? I'd like to see Mono C# and F# numbers compared against Microsoft's compilers. Will I get 90% of the performance?

There are games running on Mono (e.g. Unity C# scripts, Bastion was ported to Mono to run in Chrome, etc..). I'm sure the performance of Mono may depend on your specific application but many people have been using it without any issues.

Mono has been out for years, and I'm sure there have been great improvements. Does anyone have recent comparisons of it vs C# on Windows? I'm sure people must be curious.

Re: Fjord – F# programming language for the JVM

#22

Post by cantankerous »

happy_dino wrote: post #16
fhars wrote: post #13

Earlier quoted context omitted.

scala doesn't optimize general tail calls, either (only direct tail recursion of final methods). If you want to optimize tail calls on the JVM, you must use trampolining, which adds some overhead to every call. So most languages choose fast calls without tail call elimination over slower calls with tail call elimination (i.e., speed over correctness).

Support for tail calls pretty much depends on the actual runtime implementation. If it is important to you (it certainly is to me), use an implementation which supports proper tail calls. I'm doing it and I have never looked back.

Out of curiosity, which implementation are you using?

Re: Fjord – F# programming language for the JVM

#23

Post by kvb »

fhars wrote: post #15
jon_smark wrote: post #14

Since F# was derived from OCaml, I think readers may also be interested in taking a look at the OCaml-Java project: http://ocamljava.x9c.fr/ (It's essentially what it says in the tin...)

Or scala, which is an acceptable ML if you ignore the OO parts :-).

It's really not. Scala is a very interesting language, and it incorporates many functional features, but it's not at all ML-like. In particular, type annotations are needed in many, many places where they would be superfluous in an ML-derived language.

Re: Fjord – F# programming language for the JVM

#24

Post by rayiner »

melling wrote: post #17
thomasbk wrote: post #4

Earlier quoted context omitted.

F# has an open-source compiler and runs well on non-microsoft platforms using Mono. How is it tied to the MS platform?

What's the quality of code produced by Mono? How does it compare with Microsoft's compiler? I'd like to see Mono C# and F# numbers compared against Microsoft's compilers. Will I get 90% of the performance?

Depends on what you're doing. Mono 3.0 has a stable llvm backend. For low level code it should run as fast as c modulo array bounds checks etc.

Re: Fjord – F# programming language for the JVM

#25

Post by octo_t »

quasque wrote: post #18
Raphael_Amiard wrote: post #9

To save anyone the trouble, this project is totally empty yet. It doesn't say anything about the ability of the owner to port F# to the JVM, but just know that it is just a readme, three almost empty java classes, and the beginning of an ANTLR parser. So to answer other questions here, you can't even compare it to F# on Mono. F# on Mono works perfectly. The F# compiler and runtime is huge, and getting to parity will…

Perhaps of more interest is Frege, which is basically Haskell for the JVM. Seems to be coming along nicely: https://github.com/Frege/frege

surely you could just run lljvm on the llvm IR that ghc emits and have haskell code on your JVM?

Re: Fjord – F# programming language for the JVM

#27

Post by skrebbel »

daeken wrote: post #10
jstclair wrote: post #8

Has anyone tried running the F# through IKVM[1] (.Net java)? That wouldn't solve this, but it should be possible to run F# on a JavaVM. [1] http://weblog.ikvm.net/

IKVM runs JVM code on .NET, not the other way around.

That may not be a practically relevant difference. Why would you want to run F# on the JVM? To interface with JVM code. IKVM lets you do that already.

I've rolled out multiple .NET programs that contain Java open source libraries through IKVM. It works just fine, and the amount of extra work you need to do to make the JVM->.NET mapping work is remarkably little.

Re: Fjord – F# programming language for the JVM

#28

Post by justinhj »

moondowner wrote: post #12
lysium wrote: post #11

How is this supposed to work given the JVM does not support tail calls?

Maybe someone who knows Scala or Clojure internals can answer this question..

Clojure has a loop/recur construct which makes the tail recursion explicit so doesn't need to be done by the JVM. In other words regular recursive calls should not be used for loops if you want performance.

Re: Fjord – F# programming language for the JVM

#29

Post by kvb »

jstclair wrote: post #8

Has anyone tried running the F# through IKVM[1] (.Net java)? That wouldn't solve this, but it should be possible to run F# on a JavaVM. [1] http://weblog.ikvm.net/

Not quite the same, but you may be interested in the IKVM type provider prototype[1], which allows you to write F# scripts directly against JAR files (using IKVM in the implementation).

[1] http://colinbul.wordpress.com/2013/02/28/f-ikvm-type-provide...

Re: Fjord – F# programming language for the JVM

#30

Post by riffraff »

justinhj wrote: post #28
moondowner wrote: post #12

Earlier quoted context omitted.

Maybe someone who knows Scala or Clojure internals can answer this question..

Clojure has a loop/recur construct which makes the tail recursion explicit so doesn't need to be done by the JVM. In other words regular recursive calls should not be used for loops if you want performance.

I think rail recursion can be handled automatically by the compiler without any support from the jvm (scala does it).

The issue is different for general tail call elimination.

Post reply on HN