Hacker News Reader

F# isn't "just a[n] MS implementation of OCaml, with a few small differences". F# did start out as an OCaml port for .NET, but the language has grown organically from there, especially since the first public, supported release (v2.0, in VS2010).

The foremost difference is the ability to easily and closely interoperate with existing .NET code; this sounds very simple, but it's very tricky to get it right, and in fact this is widely considered to be a major strength of F#.

F# also has computation expressions (like monads in Haskell), sequence/list/array comprehensions, type providers (for strongly-typed data access), and built-in async support. Not to mention, since F# runs on the CLR, it has a well-tuned, high-quality, multicore garbage collector at it's disposal.

I know some of the folks from OCaml Labs, and I have nothing against OCaml. I just want to dispel the notion that there are no differences between OCaml and F#.

".NET applications only run (officially)" -- what's that even mean? I can rephrase it: "Mono applications only run (unofficially) on Microsoft's CLR".

The actual runtime is an ECMA spec (which has been unchanged since v2, as all MS has added since are implementation changes and more libraries). C# and the core parts of the runtime are under Microsoft's Community promise[1]. But you're right that MS could try to assert copyright over parts of the extended APIs, and some companies might be worried about that. OTOH the Oracle versus Google thing should alleviate a lot of concerns.

As far as F#, it's quite a bit more than a few small changes.

1: Writeup by Xamarin here: http://tirania.org/blog/archive/2009/Jul-06.html

> ".NET applications only run (officially)" -- what's that even mean?

If MS feels threatened by Mono, it changes its runtime and kills interoperability. From that point on, Mono is playing catch-up and who knows what happens to the users caught in the middle.

That's one of the least-plausible Microsoft trickery ideas I've heard of. Anything that makes Mono play catch-up also hurts every existing .NET program.

Even if they had some magical changes that kills interop (like, what, I don't know), Mono still works with all current apps at that point, and only developers adopting the new, not-compatible system (and thus discarding all their old libraries) would be affected.

Microsoft sorta has done this, with Silverlight and WinRT. They required different stdlibs and a bit of runtime tweaking, as I understand. Silverlight was handled by Mono, and WinRT - not sure if anyone is interested, as it's really for Windows Metro applications.

What kind of change could Microsoft make to their runtime to "kill interoperability" with Mono without affecting backwards compatibility for everyone else using .NET?

There are enough people (especially enterprises, their most important customers) using .NET now that Microsoft has to be very careful about any changes they do make to avoid breaking existing applications and upsetting their paying customers.

There's a lot more to F# than its OCaml origins. It's obviously heavily based on OCaml, but the directions have diverged.

One of the most powerful features I've found is part of the LINQ framework - the expression tree output. You can specify parts of code to be 'half-compiled', it leaves an AST fragment in the output in addition to the regular code.

This means you can do runtime transformations, for example to JavaScript or HTML.

The pattern matching extensions also make these transformations easier than you'd expect.

Don't knock the practical value of seamless interop with the .NET ecosystem.

A few years ago I tried to introduce OCaml to a company I was working at, an Oracle shop, and immediately hit a snag - the Oracle bindings hadn't been maintained in years and wouldn't compile with the current GCC or OCCI. ISTR there were also 32/64 bit issues. Anyway, I actually went ahead and wrote my own, styled to look a bit more like the classic OraTcl to make adoption easier. I say this not to blow my own trumpet but to illustrate that there is more to a language then the language. And not to knock the OCaml guys, just that their research priorities are different than my corporate data processing priorities.

Anyway, the OCaml world is playing much more nicely with others now, the book Real World OCaml is almost out, OCamlPro are doing some good work. But in F#, you can "hit the ground running".

> Microsoft could discontinue it, make the terms of use more restrictive, etc...

> .NET applications only run (officially) on MS platforms,

Not only that - non-Microsoft platforms have a huge choice of languages, platforms, runtimes and other tools Windows can't match. With all that going on, it would be surprising if someone decided for .NET to run on non-Windows boxes.

The only reason to target .NET is to build Windows-compatible software. It's an important requirement, sure, but there is a lot more happening these days on spaces Windows simply can't reach.

Also, Microsoft have patents not just on .NET itself, but also on fairly broad ways of using particular .NET functionality. Needless to say, patent infringement by your code isn't covered by any of their patent promises or licenses. I'm pretty sure at least Gtk# infringes on at least one such patent I found some time ago; since essentially every graphical C# application uses either that or WinForms which is also covered by multiple patents, running any C# GUI app anywhere other than Windows is legally risky.

Microsoft, Oracle, HP, IBM, and others also hold a variety of patents related to garbage collection algorithms. The legal risk isn't limited to C# on non-Windows platforms; I'd guess that any garbage-collected language is potentially open to litigation: C#, Java, Python, Ruby, Haskell, OCaml, etc.