But without making things expressions, it's still gonna be clunky. First class immutability and expressions instead of statements would help propel it further. I still would feel rather limited about having no type inference on local functions, though.

What would be really exciting is if the runtime was also open for some real changes. Traits, non null, slices, maybe even ownership (so we could stack alloc, a huge perf win)... One can dream.

http://fsharpforfunandprofit.com/posts/is-your-language-unre...

Then use C. In OOP comparing objects of different types is key to inheritance. The reason their example works is because everything in C# inherits from object, so you'll always find some commonality to compare.

You could have the compiler generate a warning when object.equals is used (rather than overridden) but getting rid of comparisons between different object types completely is backwards and will reduce efficiency.

So yes, shipping F# with VS is a good step, and technically it's supported, it's obvious MS has some discomfort there. Which is too bad, cause F# is a rare jewel, nothing else has the combination of language features, interop/library, performance, and tooling.

Hopefully with F# in open source hands now this can continue to improve. In the meantime, I'm studying up on C# and .NET, so that I hopefully have at least the bare minimum familiarity to work around these limitations.

Even now, doing MVC websites is far more difficult out of the box if I code F#. MS still lacks JS backends, so we need third party compilers for that model... Maybe because they don't want to upset or look less than 1000% behind typescript.

I will say though otherwise I'm happy. In using F# to run my server apps with smooth pinvoke into my Rust code, which is expressive enough to offload a lot of logic. And with VS soon to be free, and Mono working fine, MS might not get any money from it. (Why deploy any sort of scale on Windows when it's line $35/core/month?) So, in that sense it's selfless and I'm quite grateful.

This is just something that takes time and commitment from the community. It's only ~7 years old at this point, and if everyone just sits back and whines about the lack of tooling without, y'know, building & releasing something themselves, it'll be an ongoing problem. It's the "take take take" mentality - often disguised as being an open source advocate - of most software devs where they want everything for free (guilty as charged, myself).

That said, WebSharper is out there, which is a pretty solid framework for a lot of tasks. I've been thinking about ways to creatively encourage/solve the tooling problem though, starting with exhorting all of us in the F# community to reduce the whining and redirect the energy into creating solutions. Tooling is only a self-fulfilling prophecy if we continue to act as-if the outcome is out of our hands.

But more to the point, I am pointing out that Microsoft is not treating F# like C#, not giving it the same resources. No one says C# users are just whining when they wanted, say, edit and continue.

Has any community, ever, stepped up and offered an experience as good as Visual Studio's? I mean, that's sort of a major reason Microsoft makes and sells that product.

Yes WebSharper is pretty awesome. But I still don't see why we shouldn't criticize MS for not doing something like that directly. After all, MS got flack over ASP.NET Web Forms then went and put resources into MVC.

You will never sell the typical VB.NET/C# enterprise .NET developer into F#.

I find very commendable what Microsot has done so far, even if it feels too little.

It rises the visibility of the language, specially to managers and drives CLR design decisions that help FP implementations, like TCO.

Let me know when Oracle gives at very least the same level of support to Scala in Netbeans and JVM design.

MS doesn't need to sell the typical enterprise dev. They just need to not sour-coat things and be honest and complete in their statements. It'd also be nice if MS viewed shipping actual language independent code, instead of stuff that takes dependencies on C# compiler details.

MS gained a huge amount from the F# folks by getting CLR generics from them - that's one major benefit over the JVM. Just on that alone perhaps they owe them that (maybe, I've little clue of internal politics, except that there is some resentment towards F#, and at least a bit of censorship on publishing things that make C# look poor).

Let me know when Microsoft starts shipping Rust-level features, so we can deal with memory safely and reduce bugs without losing perf.

Is Rust 1.0 out yet?

They are on Microsoft research.

While the world still isn't ready for the likes of Singularity and IronClad, Spec# and Dafny, at least part of the technology has landed on Windows Phone 8 and .NET Native compilers.

In a few years time when Rust has the same eco-system has F# offers today to Windows devs, then we can compare the current state of the languages.

The real power of Tuples only comes with deconstruction and matching, such as "var (a,b) = GetSomething()" and "case (_, y)".

So these features would go hand in hand. Deconstruction and matching requires lang level tuples, and lang level tuples are pretty lame without deconstruction and pattern matching.

See http://en.wikipedia.org/wiki/Nominal_type_system and http://en.wikipedia.org/wiki/Structural_type_system.

So while I can write

    var x = { FirstName = "Riff", LastName = "Raff" }

    void Display({ string FirstName, string LastName } nameRecord)
    {
    }

In the future, I hope that FP will be the default design choice, with objects being used where needed such as for components, plug-ins, and ad-hoc dictionary-passing-style tools.

After all, simplicity is the most important property of any software system - http://www.infoq.com/presentations/Simple-Made-Easy

C# is still one of my favorite languages (even though I use F# most of the time now), but I do admire Java for making it significantly more painful to write mutable rather than immutable classes; it's too bad that fact was lost on so many programmers.

Kudos for sharing the Rich Hickey video; it's one of my favorites of all time.

Out of curiosity, how does it do that? As far as I know, everything in Java is mutable by default.

    class Foo {
      private int x = 0;

      public void bar() {
        this.x += 1; // Whoops!
      }
    }

    Foo x = new Foo();
    x.bar(); // Mutating call.

To be clear, I'm the guy that insists on defining classes as either abstract or sealed, and almost always marks fields as readonly. But, I'm okay with the kind bounded mutability that you mentioned; clients of a `Foo` instance have to treat it as immutable.

Here is how I do OOP:

* I make classes to hide state, and hidden state is the same as being stateless.

* As I learn more about the problem, I start subdividing classes into smaller classes (not necessarily via inheritance).

* So, as my understanding of the problem increases, the number of class division increases, and by the pigeonhole principle, the amount of state approaches zero.

You're making an either/or distinction here without any reason. You could just as well say, "The number of cars that recently added anti-lock brakes gives significant evidence that ABS is winning out over seat belts."

I don't see these languages removing any OOP features, so I think what it shows is that functional features are either useful independent of OOP features, or complement them. (My personal belief is the latter: the languages I enjoy the most have both.)

Too short a road from the obvious to the assumed...

C# already has the fantastic Task stuff, and while they aren't as cheap as go's go-routines they work very well. Channels would just ice the cake so well. :D~~~

And while I'm at it. I did some testing recently and realized that manually currying in a for loop is faster than using function composition with delegates by about 40% :| It feels like in theory it should be compiled down to code with the same efficiency? This is probably more of a CLR/JIT issue though?

I wish more people knew about it. As someone else mentioned, Reactive Extensions are also great - I believe they will be getting backpressure support which will allow similar semantics to channels (but with first-class error handling)

I solved the problem by avoiding lambdas altogether in code where performance is a concern, using delegates instead and ensuring all arguments are passed in rather than closed on (so structs would remain structs, GC pressure is avoided).

There was, maybe is, some work being done on systems C#, not sure about the status though.

You just have to annotate or analyze the functions that don't takeover/leak a reference to something.

For something like List.ConvertAll (aka map), ConvertAll does not leak the lambda, it's pure in both input and output. So a stack allocated lambda works just fine. So the type signature for ConvertAll would indicate that it's Pure for parameters passed in. With that info, the compiler is free to pass lambdas on the stack to it.

So whenever the lambda is going to be created, the C# compiler just needs to look at the usage of it - is it passed only to Pure functions? If so, then no need to allocate a whole new object on the heap.

They could make it even cooler by doing Haskell's "fusion" which also contributes to deforesting. We just need the CLR (or even the C# and F# compilers) to provide real inlining. Then when you pass a lambda to an inlined function, you can avoid creating the closure in the first place! For common patterns like "xs.Select(...).Where(...).Aggregate(...)", if each function was inlined and pure, the resulting code could literally be equivalent to a big loop, as if you had hand-written the thing. No allocation all over the place, and much better resulting JIT'd code. I've wanted this in F# for a while (and F# does have inlining so you do get better code than C#), but Rust actually implements it, so lambdas are cost-free in many cases. That is progress.

Interesting. Do you have this benchmarking code posted somewhere? What do you mean by "manual currying"?

Some syntactic sugar a la await could be nice though.

1.) In the StartSenders method, you're violating the Rx grammar by calling channel.OnNext concurrently. Wrap it on a lock statement.

2) In StartReceiver you're missing out messages the way you handle the channel. Replace the loop with a call to channel.Subscribe

From http://blogs.msdn.com/b/csharpfaq/archive/2014/11/20/new-fea...

"Await in catch and finally blocks has been disallowed until now. We’d somehow convinced ourselves that it wasn’t possible to implement, but now we’ve figured it out, so apparently it wasn’t impossible after all."

I'm hoping this is one of those 'Clark's first law' situations: http://en.wikipedia.org/wiki/Clarke's_three_laws

'When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.'

They've got quite a lot of smart folks working on C#, and it's heartening to me to see them taking another look at non-nullable reference types.

Good, no copy interop with native code would also be awesome. Particularly for machine learning.

For example, Kotlin has:

• Nullability in the type system

• Good support for efficient functional programming, e.g. you can do collection.map { it * 2 } and it's as fast as an imperative for loop as the compiler inlines the block.

• Strong support for meta-programming / DSL features, so there's less need to make code generators. JetBrains are still working on this but basically the language has a lot of features that don't initially seem all that significant, but can be combined to create useful DSLs.

• Lightweight data classes that support immutability and editing via copy construction (using named arguments)

• Traits

• Delegation

• etc etc

... and it's all here today, with good IDE support, and compatible with Java 6 even.

For good native interop there is JNA and there's a research project over at Oracle looking at how to do something better than JNA directly integrated with the JVM in a future version. So don't be too jealous.

Specially in the eyes of managers.

Native code interfaces were already reasonably fast, allowing more no copy semantics and array slice behaviour is going to do wonders for native library performance.

(Well, technically C# and the related libs are fully OSS now too, IIRC).

I didn't say it's different, or that it's not open source for that.

I asked because the parent said: "If you want to contribute actual code and have it actually incorporated into the language, then all you need to do is follow the contribution guidelines here"

Anyways, maybe I misunderstood the that, so my apologies if I came off rude.

I just said, "if only open source languages had the same resources".

Because that's what I mostly get to use, and because I don't run Windows but OS X, so I don't get to play with a fully supported C# environment.

I'm just spitballing here but something I'd really like to see stuff like code contracts and unit testing, but more integrated with the language, less verbose and requiring less to setup. Being able to let the "meat" of a method be separated from all the error-checking, post, pre conditions etc would really make things cleaner.

Current implementation feels like it requires too much setup with separate classes, duplicate method signatures in several places etc etc. It would be really cool to have something like

  public int SomeMethod(int a, int b)

  pre 
  { 
    Requires (a > 5);
    Requires (b >= 0, new Exception("something something"));
  }

  {
     // DoStuffHere
  }

  post
  {
    Ensures (result > 0, new Exception("needs to be above 0"));
  }

Full signature would simply be without the body:

  public int SomeMethod(int a, int b)

  pre
  {
    Requires (a > 5);
    Requires (b >= 0 ,new Exception("something something"));
  }

  post
  {
    Ensures (result > 0);
  }

  Conditions.SomeMethod
  {
    pre
    {
      Requires (a > 5);
      Requires (b >= 0, new Exception("something something"));
    }

   post
   {
     Ensures (result > 0);
   }
  }

  public IEnumerable<int> Sort (IEnumerable<int> list, Order order)
  test
  {
     (list = {3,5,6,2}, order = Order.Ascending) => result == {2,3,5,6};
     (list = {3,5,6,2}, order = Order.Descending) => result == {6,5,3,2}
  }

The specifics and syntaxes of these things requires some thought but I love the basic premise, am I rambling?

edit: I saw that something in this direction if not as extensive was actually discussed

If you instruct the compiler to treat all warnings as errors (so that variables must be defintitely assigned), then the following code gives you what you want:

	 public PositiveInt SomeMethod(GreaterThanFive a, NonNegative b)
	 {
	 		//do stuff;
	 } 
     
	 public struct GreaterThanFive
	 {
	 	readonly int n;
	 	
	 	public GreaterThanFive (int n)
	 	{
	 		if(n < 5)
				throw new ArgumentException("n must be greater than 5")
			
			this.n = n;
	 	}
	 	
	 	public static implicit operator GreaterThanFive(int n)
	 	{
	 		return GreaterThanFive(n);
	 	}
	 	
	 	public static implicit operator int (GreaterThanFive n)
	 	{
	 		return n.n;
	 	}
	 }

	//Similar definitions for NonNegative and PositiveInt

It also might not be super amenable to static analysis.

The verbosity will be mostly ameliorated with primary constructor. I propose going further by allowing programmers to annotate constructors so that they can be used as user-defined conversion operators.

Thus, the aforementioned code could become something like:

	 public struct GreaterThanFive implicit (int n)
	 {
	 	readonly int n = n;

	 	if(n <= 5)
	 	    throw new ArgumentException("n must be greater than 5");	 	

	 }

I meant the verbosity of having to create a custom type for each kind of restriction, versus some inline "int n [n > 5]" notation.

http://dlang.org/contracts.html

Multiple bracket blocks is not the most esthetic of solutions I think but it's the best I can think of. Attributes feels too clunky and just stacking contracts as lines after the class statement feels too disorganized

Oh god, I want it SO BAD.