Announcing the F# 3.1 Compiler/Library Code Drop | Hacker News Reader

Announcing the F# 3.1 Compiler/Library Code Drop

blogs.msdn.com

On Linux making a standalone binary is surprisingly easy:

    $ fsharpc file.fs  # can run the generated file.exe via mono at this point
    $ mkbundle --static file.exe -o file

Now ./file is a statically compiled binary. Easy deployment.

Wow, I had no idea things have progressed this far in the F# world on Linux. I might have to try it on my next numerical project. Thanks for posting.

That is awesome. I've been working pretty extensively with F# (several small projects, and a current bigger one), and I really love the language. Has all the functional constructs that I like plus mutable variables when I need them. And pretty boilerplate-less.

I was interested in the language, but was put off by the .NET connection for using on linux. Is F# running on mono on linux comparable, performance-wise, with the windows stack?

Mono is generally slower, with a few exceptions. It's not "slow" though - maybe half the performance of the CLR? I'm not sure where it stands after v3, which includes a proper GC. Mono also has an LLVM option which increases startup times, but provides a ~30% bonus at runtime.

One of the possible exceptions is number crunching. .NET has no equivalent to Mono.SIMD, so for numerical tasks it's conceivable that code written for Mono could end up being far faster.

Depending on what you're doing, the performance difference might not matter in practice. Mono's (historically, at least) done worse with super OO-y code because of its poorer GC performance, but oftentimes that kind of code also ends up appearing in applications where overall performance is dominated by I/O and CPU efficiency ends up being negligible.

Whenever splitting Microsoft is mentioned, I pray for them to spin off the devtools.

F# is better Scala than Scala, C# better Java than Java. Both suffer from a meh runtime (compared to other offers) on non-Windows platforms.

One potential gotcha there: The Mono runtime libraries are licensed under the LGPL, so beware of using this option if you've got licensing restrictions that prevent you from distributing binaries that are statically linked to LGPL code.

You can always leave the --static flag off, but then your binaries will require the Mono run-time to be installed.

I rather like the idea of "functional first" as a paradigm. It underscores the crucial fact that all the common functional languages (even Haskell) are multiparadigm; they just default to functional programming instead of defaulting to imperative programming the way other "multiparadigm"languages do.

* Mac OS X: F# ships as part of the Mono distribution.

* Linux: http://fsharp.org/use/linux/

* FreeBSD: http://fsharp.org/use/freebsd/

Grrr. Why won't Microsoft open the CLR? It's so fast and has such amazing codegen! I don't want performance to degrade moving from Windows to some platform that requires I run mono!

> Why won't Microsoft open the CLR? It's so fast and has such amazing codegen!

Watch how you are about to answer your own question.

> I don't want performance to degrade moving from Windows to some platform that requires I run mono!

Yes, but Microsoft, who sells Windows licenses, does want performance to degrade when you move from Windows to some other platform.

While it's not the same insanely-optimized JIT-compiled runtime implementation that you're asking about, note that the .Net micro framework has been released as Apache 2.0.

The solution is to ignore .NET entirely and only use Mono, even on Windows. Then you get the same platform everywhere, as you would with the JVM.

I watched a video the other night of a demo of F# and was pretty impressed with some of the dev tools: especially IntelliSense on APIs and being able to provide an example URL to generate classes for incoming JSON.

Reply on news.ycombinator.com