16 ms·

Announcing the F# 3.1 Compiler/Library Code Drop

87 points by stevecooperorg 13y ago

CraigJPerry 13y ago
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.
- sixbrx 13y ago
  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.
- throwaway344 13y ago
  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.
- tbirdz 13y ago
  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?
  - MichaelGG 13y ago
    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.
    - bunderbunder 13y ago
      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.
  - snotrockets 13y ago
    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.
- bunderbunder 13y ago
  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.
gaze 13y ago
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!
- dragonwriter 13y ago
  > 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.
- marshray 13y ago
  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.
- lucian1900 13y ago
  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.
profquail 13y ago
* Mac OS X: F# ships as part of the Mono distribution. * Linux: http://fsharp.org/use/linux/ http://fsharp.org/use/linux/ * FreeBSD: http://fsharp.org/use/freebsd/ http://fsharp.org/use/freebsd/
jzelinskie 13y ago
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.
tikhonj 13y ago
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.

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.

sixbrx 13y ago
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.
throwaway344 13y ago
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.
tbirdz 13y ago
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?
- MichaelGG 13y ago
  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.
  - bunderbunder 13y ago
    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.
- snotrockets 13y ago
  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.
bunderbunder 13y ago
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.

gaze 13y ago

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!

dragonwriter 13y ago
> 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.
marshray 13y ago
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.
lucian1900 13y ago
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.

profquail 13y ago

* Mac OS X: F# ships as part of the Mono distribution. * Linux: http://fsharp.org/use/linux/ http://fsharp.org/use/linux/ * FreeBSD: http://fsharp.org/use/freebsd/ http://fsharp.org/use/freebsd/

jzelinskie 13y ago

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.

tikhonj 13y ago

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.