Microsoft has come one step closer to delivering a parallel programming language to developers. On May 8, Microsoft made Axum, the company's foray into parallel programming, available on its MSDN DevLabs portal. Axum is a .NET language for building parallel applications. According to a Microsoft description, Axum "is a language that builds upon the architecture of the Web and principles of isolation, actors and message-passing to increase application safety, responsiveness, scalability and developer productivity."

Why? It makes duck typing easy in a static language. I don't think it is something you would want to use all the time, but there are certain types of situations where you end up basically emulating it with tons of reflection code. Being able to say "this is late bound" makes that a lot less messy.

Also, it allows for interop with dynamic languages. (AFAIK) JVM languages that interop only goes one way. Dynamic will allow you to consume ruby and python libraries from c#.

For example, generics do work with only a small subset of the language features. You can not use static methods, operators or constructors with parameters from generics. This makes generics basically useless for more complex applications than collections.

I use generics all the time. My problem with them has to do with the generic invariance. (If you instantiate a Foo<T> as Foo<string>, but try to use it as Foo<object>, you cant in C# 3) Probably my favorite feature of 4.0 is giving syntax to explicitly declare covariance or contravariance for generics.

-There are various things that behave like a function and are implemented as functions on a MSIL level: static methods, instance methods, constructors, property getters, property setters. But only two of those (static and instance methods) are compatible with delegates. To create a delegate pointing to one of the other quasi-functions (constructors, properties), you have to create an adapter.

Dumb, I agree. This is fundamental language design though, not syntactical sugar.

-There are extension methods, yet no extension properties. Why?

Because MS wanted to be as conservative as possible with the whole monkey patching thing. Even with all the restrictions, people were still freaking out about the potentials for abuse.

-Various new language features discourage factoring repetitive code into methods. For example the result of an implicitly generated type can not be passed to a method other than as an object since its type does not have a type name.

Maybe im misunderstanding you, but this

public void test()
{
var s = "hi";
test2(s);
}

private void test2(string s)
{
Console.WriteLine(s);
}
works fine.

-The new property and collection initializer syntax encourages writing mutable classes. As do many other new language features. And we all know that the single most important thing when doing multithreaded programming is to use immutable objects as much as possible.

-Scala and other modern languages generate equality and hashcode functions for immutable objects. In C# you have to do all this yourself. And not even the collection classes override equality and hashcode.

That one is dumb too, but again, a core design decision rather then a language add on.

But most language features of scala are based on a very small core. And the type system is much more refined. Just leaving out static methods makes everything so much nicer. (I hope that they will remove constructors next :-)

Honestly, I like scala more then c# too. I don't think C# is a bad language though, and I am not sure that there really is a need for one language to do all things in anymore. What we need is a good interop story, and languages that focus on certain types of problem domains. A good example would be something like erlang (for massive concurrence), or something like JavaFX (which is only appropriate for UIs).

Why? It makes duck typing easy in a static language. I don't think it is something you would want to use all the time, but there are certain types of situations where you end up basically emulating it with tons of reflection code. "

But I don't think that x.Y(1,2) is so vastly superior to x.Invoke("Y",1,2) to deserve its own syntax. And you know that it will be abused all over the place for completely different stuff. As an example, see this ugly and slow hack to use operators for generic types:

But now that you can do this kludge, they will never fix the fundamental problem!

Being able to say "this is late bound" makes that a lot less messy. Also, it allows for interop with dynamic languages. (AFAIK) JVM languages that interop only goes one way. Dynamic will allow you to consume ruby and python libraries from c#.

If you see C# as a "glue" language, interop is extremely important. But if you see it as a core language for implementing algorithms, there are about a thousand things that are more important than dynamic.

"For example, generics do work with only a small subset of the language features. You can not use static methods, operators or constructors with parameters from generics. This makes generics basically useless for more complex applications than collections.

I use generics all the time. My problem with them has to do with the generic invariance. (If you instantiate a Foo as Foo, but try to use it as Foo, you cant in C# 3) Probably my favorite feature of 4.0 is giving syntax to explicitly declare covariance or contravariance for generics.
"
Don't get your hopes up. AFAIK variance annotations will only work for interfaces. Another halfbaked extension. There is no reason whatsoever not to allow covariant return types for all classes. java does it, c++ does it etc. And it does not violate the inheritance contract.

If you are writing large class hierarchies, this lack of covariance can be a large PITA. This is another example of a fundamental problem that microsoft ignores while adding fluff.

Generics are still very limited when trying to do calculations on generic types. Try to write a generic function that calculates the average and standard deviation of an enumerable of numeric types to see what I mean.

There are some kludges like calculator classes to work around the problems, but they had 4 years to come up with a proper solution and did nothing at all!

"-There are various things that behave like a function and are implemented as functions on a MSIL level: static methods, instance methods, constructors, property getters, property setters. But only two of those (static and instance methods) are compatible with delegates. To create a delegate pointing to one of the other quasi-functions (constructors, properties), you have to create an adapter.

Dumb, I agree. This is fundamental language design though, not syntactical sugar.
"
You could provide syntax to solve this problem. For example you could allow casting from a constructor for type T to a Func returning a T.

Another very dumb thing: why can a struct not have a default constructor? That is a CLR limitation that makes implementing proper C++ on the CLR almost impossible.

" -There are extension methods, yet no extension properties. Why?

Because MS wanted to be as conservative as possible with the whole monkey patching thing. Even with all the restrictions, people were still freaking out about the potentials for abuse.
"
Then they should not have done extension anything in the first place. Extension methods have a huge potential for abuse. The real reason there are no extension properties is probably that you do not need them to implement LINQ. But I vastly prefer for expressions in scala to linq.

"
Various new language features discourage factoring repetitive code into methods. For example the result of an implicitly generated type can not be passed to a method other than as an object since its type does not have a type name.

Try to write a method that prints the name of x without using reflection.

The same is true for the type of most complex LINQ expressions. You do not know it at compile time, so you have to process it in place.

"
-The new property and collection initializer syntax encourages writing mutable classes. As do many other new language features. And we all know that the single most important thing when doing multithreaded programming is to use immutable objects as much as possible.

That is a very functional way of looking at things.
"
It is also a very correct way of looking at things. I think there is a consensus in the industry that shared mutable state is absolutely evil when doing concurrent programming. That is why erlang is so powerful: shared nothing concurrency! Yet microsoft adds more and more language features that encourage creating mutable objects for no reason at all. Combine mutable objects with PLINQ, and you are almost guaranteed to get lots of extremely hard to find race conditions and concurrency bugs.

But then I can not use initializer expressions like
new Bla() { prop="blub" };

For a supposed multiparadigm language, C# always pushes you in the direction of "mutable everything".

-Scala and other modern languages generate equality and hashcode functions for immutable objects. In C# you have to do all this yourself. And not even the collection classes override equality and hashcode.

That one is dumb too, but again, a core design decision rather then a language add on.
[/q]
Having some mechanism (attribute or something) to automatically generate the fundamental functions such as Equals, GetHashCode and ToString would be a) easy and b) orders of magnitude more useful than every new language feature in C# 4.0.

"But most language features of scala are based on a very small core. And the type system is much more refined. Just leaving out static methods makes everything so much nicer. (I hope that they will remove constructors next :-)

Honestly, I like scala more then c# too. I don't think C# is a bad language though, and I am not sure that there really is a need for one language to do all things in anymore.
"
It used to be a decent language. That is why what they are doing with it is so sad...

What we need is a good interop story, and languages that focus on certain types of problem domains. A good example would be something like erlang (for massive concurrence), or something like JavaFX (which is only appropriate for UIs).

But what if you need both massive concurrency and high performance? You need a general purpose language. There is a reason all games and large applications are written in C++. It is ugly as hell, but it is multiparadigm and fast.

C# could in theory be used for this despite all the weaknesses I mentioned. But there are some very fundamental limitations of the CLR that prevent this: