
Contributing to the F# Language, Library and Tools - mands
https://visualfsharp.codeplex.com/
======
skywhopper
It sure feels like there's a strong force within the MS dev tools team to be
far more open, and the only thing holding them back was the CEO. I sincerely
hope Microsoft continues to open more and more products and truly integrate
the open source philosophy into their culture.

~~~
Already__Taken
I don't have the greatest grasp of licences but once they go open and take
pull requests they can't go back can they? Are they even allowed?

It would mean binning the project and starting from scratch privately right?
At the risk of being accused of stealing the open contributed code.

~~~
bunderbunder
They own the copyright, so they're free to do what they want with the code.
That's why dual licensing models (like that of MySQL) are possible.

However, code that's been distributed under an open license stays that way. So
Microsoft could add a commercial license, and even stop making updates under
an open license. But if they do that, then there's nothing stopping the
community from moving forward with their own fork of the open source version.

If I recall correctly, the Darwin operating system might be a good example of
how that sort of dynamic could play out.

------
untothebreach
Can someone give reasons why you would want to use this over, say, OCaml, when
on a non-MS platform? My understanding is that the Mono runtime on *nix is
significantly less {mature,performant,stable} that the Windows .Net runtime.

Are there any benefits besides the obvious 'write-once, run-anywhere' one?

EDIT: I just want to be clear that I don't have any negative opinion of F#, I
am genuinely curious why someone would want to use this on a platform that is
not Windows.

~~~
gecko
Lots of them, but two key ones:

    
    
      1. You have much richer libraries available.  There's a
         decent amount of stuff in OPAM these days, but that's
         dwarfed by what you can grab out of NuGet.
      2. You have a great asynchronous/multithreading story.  The F# async
         workflow makes it trivial to write multithreaded apps in
         a similar way to C#'s async/await calls (in fact, F# is
         the origin of that design), and it performs very well.
         OCaml still doesn't do very well with multithreaded
         programs.
    

You also lose some things, two of which that are most poignant to me:

    
    
      1. OCaml is faster than F# for single-threaded programs.
         This has nothing to do with Mono's maturity or speed as
         such, but does have to do with its garbage collector,
         which has not historically dealt well with F#'s allocation
         patterns.  I have not taken time since SGen landed to
         revisit that, though, so the situation might be much
         better.
      2. OCaml can produce tiny self-contained binaries.  Mono's
         AOT gets you the self-contained easily, but you'll be
         looking at relatively large executables.

~~~
profquail
Mono's SGen garbage collector is a massive improvement over the older, non-
generational GC. SGen still may not be as a good as the GC in the .NET CLR on
Windows, but the performance difference is much smaller now (especially since
Mono 3.2.x).

~~~
gecko
Have you tried with F# specifically? Even the old collector generally did fine
for C#, but F# tends to allocate a _tremendous_ number of very-short-lived
objects, which is where Mono's old GC got unhappy. I actually do fully expect
that SGen likely fixes that entirely, but I haven't had a chance to
meaningfully benchmark it.

~~~
profquail
Yes, I have tried it specifically with F#. In fact, I contributed some minor
patches to the SGen GC so it'd work correctly on FreeBSD, just so I could run
F# on FreeBSD using Mono/SGen. SGen is a significant improvement over the
older GC for any program running on Mono, but especially for F# programs.

------
Flenser
Now that they're dogfooding codeplex for such high profile projects I hope
we'll see some improvements to it.

[edit]

I suppose if I'm complaining I ought to make some constructive suggestions:

    
    
       * central page listing my subscribed/voted issues/discussions.
       * The only history link on a projects homepage is for the wiki.
         It should have a prominent link to the latest changeset
         with a date or age.
       * Project wide search: issues, code, wiki, discussions
       * In fact, remove discussions completely, everything should be an issue.

~~~
hkphooey
I like the look of Codeplex, very clean design, feels more 'professional' than
Github.

------
rjzzleep
can someone explain this to me? i thought f# was open source for years? isn't
that how most people compile it on their machines?

is it just that people don't know that half the things that were open sourced
have already been open sourced(like the asp.net stuff) or do we just copy and
paste microsoft press releases here?

OR am i missing something crucial that someone can elaborate on please?

[https://github.com/fsharp/fsharp/](https://github.com/fsharp/fsharp/)

EDIT2: thanks to the responses, it's about accepting contributions

EDIT: for those that don't know the asp.net developments had a lot of
influence from the alt.net movements. it was ms' attempt to keep the c# web
developers from moving to other frameworks that let you do similar things much
easier.

~~~
bad_user
F# has been licensed under an open-source license for some time, but in
Microsoft fashion, they weren't accepting contributions from third-parties, so
the repository was read-only.

~~~
darklajid
"but in Microsoft fashion" ...

Show me where I can directly contribute to random Apple products or where I'd
send my upstream Android improvements.

Worse, the Linux kernel is open source, but getting my own changes into the
main distribution is probably taking some work and the chance that they won't
be accepted is rather good.

No offense, but I'm really unhappy about the continued MS bashing. Yes, right
now (due to the BUILD conference) there are a good number of Microsoft related
posts on this site. Yes, Microsoft wasn't the corporate citizen most of us
wanted them to be in the past. But these news are _nice_ and the slights are
really misplaced.

~~~
wcarss
It would be difficult to submit a patch to the Linux kernel, yes. Especially
as an outsider with no history with the project. But people do submit them.
Because that is how open source projects operate.

As for apple: bugzilla.webkit.org and llvm.org/bugs - you have to invest real
time in these before you can submit patches, but they take take them.

'In Microsoft Fashion' here may be more mean than it needs to be, but I do not
think it refers to a general greed or selfishness or what-have-you. It sounds
to me like it refers specifically to the sort of open source that major
Microsoft products had previously been released under, and that was it. Any
hating ascribed to the statement is interpretation.

I agree about Android. I wish it were actually open source -- maybe someday.
:)

~~~
darklajid
Even for Microsoft open-source (as in 'anyone can send patches and might get
them accepted') is nothing new.

From [1], posted March 27, 2012 (and note the author!):

You can also now contribute directly to the development of the products by
reviewing and sending feedback on code checkins, submitting bugs and helping
us verify fixes as they are checked in, suggesting and giving feedback on new
features as they are implemented, as well as by submitting code fixes or code
contributions of your own. Note that all code submissions will be rigorously
reviewed and tested by the ASP.NET MVC Team, and only those that meet an
extremely high bar for both quality and design/roadmap appropriateness will be
merged into the source.

\--

Sounds like .. any high profile open source project: Feel free to contribute,
be aware that we might reject your work. So two years later, after opening
more projects to this model, I don't think 'the sort of open source that major
Microsoft products had .. been released under' is correct.

(Obviously there's a fair bit of interpretation going on. As it always is in
text, unless you're fairly close to the author perhaps)

1: [http://weblogs.asp.net/scottgu/archive/2012/03/27/asp-net-
mv...](http://weblogs.asp.net/scottgu/archive/2012/03/27/asp-net-mvc-web-api-
razor-and-open-source.aspx)

------
rch
I haven't looked closely -- my assumption is that despite this string of
announcements we are not really any closer to simply running pkg_add or apt-
get to install a real MS development environment (i.e. not Mono). I could be
wrong though, of course.

~~~
bztzt
Correct that you can't do this on Linux. The Microsoft CLR (.net runtime)
itself is still proprietary and available only on Windows-based platforms.

~~~
rch
Does anyone take _any_ of this activity as being indicative of some interest
in opening the runtime, at any point?

------
mands
Pretty great news to complement the open-sourcing of Roslyn I think - was
hoping to hear something about F# at Build.

~~~
srean
I am waiting for the runtime to be opened up. Although I know that is unlikely
to happen. Opening up C# and F# are indeed interesting, but as far as
engineering is concerned the real heavy lifting is done in the runtime.
Unfortunately, as a Linux user the mono runtime has left me with a bad
aftertaste. It is perhaps ok for C#, perhaps ok for use with unity, but for
functional code that depends so heavily on proper handling of tail calls, mono
is (well at least was) a mess and unstable. Further, developers in charge
refused to concede that buggy/incorrect tail call behavior was a problem (why
dont you just right loops). If anyone can report that this has changed I would
be happy to give it another shot. I wont be able to thank all of you with a
comment, but will certainly upvote.

~~~
bad_user
The latest Mono should be much better for handling F#, as it received some
love from Xamarin, as they started promoting it. You can't blame Mono for not
running F# well, when .NET itself had and probably still has its own share of
problems:
[http://blogs.msdn.com/b/clrcodegeneration/archive/2009/05/11...](http://blogs.msdn.com/b/clrcodegeneration/archive/2009/05/11/tail-
call-improvements-in-net-framework-4.aspx)

~~~
sixbrx
I agree that even the CLR itself needs improvements for functional
programming. Besides the tail calls link you gave, there is also (according to
MS) inability to implement type classes because of CLR changes that would be
necessary: [https://visualstudio.uservoice.com/forums/121579-visual-
stud...](https://visualstudio.uservoice.com/forums/121579-visual-
studio/suggestions/2228766-add-higher-order-generics-to-f-type-classes)

I think F# would benefit a lot from either ML's module system or at least type
classes as a simpler case. As it is it can only (directly) do single virtual
dispatch (mainstream OO dispatch), which is pretty limiting and makes it more
of a C# with different syntax.

~~~
profquail
F# could potentially get a module system in the future (a la OCaml or SML).
I've put together some proof-of-concept code to show how modules could be
implemented on top of the existing .NET type system, so at this point it's
just a matter of refining that representation and then implementing that in
the language/compiler.

~~~
Hakeashar
I'd love to see some kind of typeclass support in F#...

In the meantime, honest question: _what_ are modules in OCaml? I tried to read
up on it online, but my understanding of the topic is still murky. Regular
modules don't really seem that interesting (they look like modules and/or
types/classes in F#), parametrized modules seem to be something that is
missing in F#.

Second question, do you have that proof of concept code laying somewhere
around? I'm just curious how it would look in F#...

~~~
profquail
Yes, F# is missing parameterized modules ("functors"); these are simply
modules which are parameterized by other modules in the same way .NET generics
(for example) allow you to parameterize one type by another type. The reason
this would be nice to have in F# is that, while the CLR's generics are
excellent in general, there are some things that can't be expressed using the
CLR's type constraints. Supporting functors in F# would provide a nice way to
work around this and allow you to write code which is more generic.

Here's my proof-of-concept code. I'll warn you now though -- it looks quite
messy, because the goal was to show that functors could be supported on top of
the existing .NET type system. If functors are ever added to the F# language,
the syntax will be much, much cleaner.

[https://github.com/jack-pappas/experimental-
functors](https://github.com/jack-pappas/experimental-functors)

------
cjbarber
If anyone on HN works in F#.. then you should definitely check out Tachyus.com

A few of the top contributing F# devs are there, it's an amazing company.
Investors include Joe Lonsdale (founder of Palantir).

They are helping oil companies optimize oil and gas production - not your
average startup problem.

