[stevecooperorg]

C# 4 added serious dynamic typing, so that you can make ruby/pthon/js-style dynamic objects;

    // properties not declared anywhere; runtime property definitions
    dynamic myObject = new JavaScriptStyleObject();
    myObject.firstProperty = "hello";
    myObject.secondProperty = 1;

C#5 added async/await, which I think is one of the most 'integrated' ways I've seen of doing async programming. Think node.js with a lot less syntactic cruft around the callback functions; in C#5 you could write, say;

    // evented I/O using the 'await' keyword;
    var fileContent = await ReadFile(@"c:\foo.txt");
    Console.WriteLine(fileContent);

rather than;

    fs.readFile('c:\\foo.txt', 'utf8', function (err,data) {
      console.log(data);
    });

This eliminates the need to write lambdas while retaining the evented I/O style.

Both of these seem pretty significant.

[MichaelGG]

Both of which have been in F# for years, and C# re-implemented them later, poorly. F#'s dynamic is extensible (and around since 2007? 2008? earlier?)). If you wanted to implement a "dynamo" object, go ahead. If you want loosely typed CSV-reader access, go ahead. (You get the ? and ?<- operators to define as you'd like.)

C#'s async comes from F#'s async (available since Oct 2007), which in F# is just a library. That's because F# supports workflows aka computation expressions aka warm fuzzy things. What F# does as a library feature, C# requires baking into the compiler.

So for 5 years now, MS has added these two features. They've still yet to deliver a REPL, or finish implementing type inference, or any such stuff. It looks like Anders Hejlsberg, the main C# designer, seems more interested in adding some basic features to JavaScript, lately. C# seems fairly abandoned, language-wise, to me. They seem to be content to have put Java in its place, and leave it at that.

P.S. C#'s a great language, and I'm not trying to insult the people that have done great work on it. As a popular language, it's one of the nicest ones out there IMO.

[stevecooperorg]

I would dearly love for the C# type system to get a bit stronger and less verbose. It's also confused, I think, because you have explicit classes, anonymous types, and dynamic, and they aren't always very well put together. I actually also like what Anders did in TypeScript around structural types, and wouldn't mind some of that mojo in C#.

I take your point about pace, though. I wonder how it compares over the same timeframe vs other languages? In the 5 years for C# to cover that distance, what have other languages achieved? The biggies are particularly interesting (JavaScript, Python, Ruby, Java, C++, etc) because users probably demand more in terms of support and compatibility. (For others contributing, I'm thinking language-specific, so not libraries, frameworks, or runtimes, just pure syntax.)

It's also worth throwing uptake into the mix here; it's not much use if there's a version of the language defined in a spec but everyone's using the compiler from 1999 (JavaScript, I'm looking at you) I'm not a pythonista but I understand Python 3 has struggled with uptake, too. Not too sure of the details; happy to be corrected.

[rbanffy]

> C# 4 added serious dynamic typing, so that you can make ruby/pthon/js-style dynamic objects;

So you can match the so-so performance of dynamic languages (which is debatable, BTW) with C#'s horrid (when compared to Python or Ruby, at least) syntax.

I fail to see the advantages here. If I'm doing something that demands dynamic types, I do it in Python. If I need static-types, I do it in C, C++, Objective-C, Go, Java- whatever better fits the problem.

[jpalomaki]

The purpose of dynamic is not to turn C# into a dynamic language. It was added to make it easier to interface with certain other parties. Sometimes you just don't have the type information (practical example is handling JSON data) and dynamic can make the code cleaner in these cases.

More about this: http://msdn.microsoft.com/en-us/magazine/gg598922.aspx

[pdwetz]

Dynamic typing support helps in a pinch in C#, as you can avoid a lot of code in some cases where performance isn't paramount. I've personally used that in a few cases in the past.

[NicoJuicy]

Develop in Asp.Net MVC and change your viewmodels to dynamic (ExpandoObject) types.

You'll notice the advantages :)

ps. want to iterate over the object like in reflection, just convert the object to a (IDictionairy<string,object>)

[bryan_rasmussen]

What problems are there that you would consider choosing a statically typed language for them, because of the typing?

[rbanffy]

Static typing helps generating very concise and fast native code. I'd go with C or C++ when speed and or very precise control are absolute requirements. It also doesn't hurt you when you have a clearly defined problem that will never change - when you know you'll never receive a float instead of a 64-bit integer.

But there are other reasons to pick static typing. Using Java is natural for writing Android apps, Go has a very natural syntax for expressing concurrency and C# is the best choice when you want to write a Windows app. A programmer should always pick the language that better fits the problem it has to solve.

[gngeal]

C#5 added async/await, which I think is one of the most 'integrated' ways I've seen of doing async programming.

What's with the C# developers ans async/await? Almost every time I read their exhortations it feels like they're blissfully unaware that other languages have already had their own mechanisms for doing concurrency.

[sitharus]

Having worked in a few languages over the years, all with different ideas of concurrency, the C# system is one of the nicest.

It's a bit tough to get your head around, but it does a good job of keeping code readable while correctly blocking and descheduling threads.

A lot of developers get async wrong, so anything to help get it right is a plus.

Personally I prefer the F# async system, but it's harder for a curly-brace developer to learn F# than a new C# keyword.

[stevecooperorg]

We're talking languages here; the way a grammar construct helps the programmer.

The C# async language effectively writes a whole batch of code that you'd need to write yourself in other languages; try/catch blocks, callback functions, thread synchronization code, code to wait for results, etc. In effect, it makes into a language feature something that has previously been considered a design pattern.

So something like this in C# 5;

    01 var foo = await LongProcess1();
    02 var bar = await LongProcess2(foo);
    03 var baz = await LongProcess(bar);

does a significant amount of work. If I were to code it without the language support, I'd be writing a great deal of crufty code to handle errors, to make sure one thread completes before using the result in another thread (see foo set on line 01 and used on line 02 for an example) and it avoids the callback hell problem of languages like JavaScript, which become apparent in Node.js programming, for instance.

I'd be interested to know what other mainstream languages have as complete a solution for asynchronous programming -- afaik, JS, Python, Ruby, Java, and C++ don't have this. I'm guessing erlang probably has it built right in, but I'm not sure. Anyone care to share?

[gngeal]

We're talking languages here; the way a grammar construct helps the programmer.

So do I. We've had CSP, Occam, Newsqueak, Alef, Limbo; now we have Erlang and Go. I'm just puzzled by the walled garden phenomenon present in such communities as that of the .NET programmers. The very fact that you're comparing C# to Node.js (!), of all things, just confirms it. It isn't very difficult to beat Node.js in terms of the language quality. Hardly seems like a fair fight to me.

[stevecooperorg]

It's hard for me to see how I'm living in a walled garden here. If there is a Microsoft walled garden, Hacker News is very much outside the wall, isn't it? I'm here, not on MSDN, trying to have a reasoned conversation with intelligent people from different backgrounds, showing code samples, and asking openly for information about other languages. What else should I be doing?

> The very fact that you're comparing C# to Node.js (!), of all things, just confirms it.

The node.js comparison is fair, I believe. We're talking about language support for asynchronous programming, particularly the evented I/O programming idiom. That's exemplified by C#/await, and the Node standard libraries, and python/twisted, and I'm sure a lot of others.

Node is a very popular, visible platform which takes evented I/O as a core concept, so it's reasonable to compare the implementation of the idiom in C# to the current poster child. Is there a better comparison I missed?

> We've had CSP, Occam, Newsqueak, Alef, Limbo; now we have Erlang and Go.

Agreed. That's fine, and I specifically called out Erlang and asked for more info. However, the others you list suffer from not being mainstream development languages -- TIOBE[1] doesn't list any of them in the top 50 languages. Occam may well do it better, but since I can't pay the bills writing Occam, I'm more interested in the languages I mentioned -- JavaScript, Python, Ruby, Java, and C++. Feel free to throw in C, PHP, Perl or Objective-C. Do any of these languages have better language or core library support for async programming? Do they result in shorter, more readable, or more reliable code for parallel and async operations?

Your original reply -- "Almost every time I read their exhortations it feels like they're blissfully unaware that other languages have already had their own mechanisms for doing concurrency." -- suggests I'm unaware of something. Can you please start telling me what it is.

  [1] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
  [2]: http://www.paulgraham.com/avg.html

[MichaelGG]

Because it allows a nice syntax for async callbacks, instead of callback hell like JavaScript and C# APIs prior.

[statictype]

Built-in to the language itself?

Very few mainstream languages have that.