I'm VERY Interested in that .d.ts for promised-io!
@Levente Nagy: You're talking about the VB type switch feature?
Type switches are needed sometimes. "Polymorphism" traditionally means that the method implementation is chosen based on the type of a single object, AKA "single dispatch". But this means it is no use if you have two objects and you need to use different code for different combinations of types, AKA "multiple dispatch".
Often when people encounter a situation like this they think "Oh, I must have designed my program all wrong. If I'd done it right, this situation wouldn't have happened". But it's not true. Some situations involve dynamic dispatch based on the type of more than one object.
Just adding my voice to the clamour for Desktop support!
Would love to see a way to statically link those parts of the .NET framework that I'm using into a native code EXE or DLL, allowing it to be used to write shell extensions, office extensions and other kinds of native components that have previously been hamstrung by heavyweight side-by-side runtime versioning issues.
Lots of critics saying "why not just use an existing language"? One thing people seem to be missing about TS is that it already has a BETTER type system than most previous mainstream high-level languages.
It's structural instead of nominal. In C# and Java you can have an interface IFoo with method Bar, and a class C that has method Bar with exactly the right signature, but C doesn't implement IFoo unless you edit the definition of C accordingly.
Whereas in TS, C already implements IFoo merely because it has the right structure.
This is already an excellent improvement, but when they add generics to TS it's going to be a big improvement on C#. An interface could be used to specify a constraint on a generic parameter, but it doesn't mean that a generic argument has to nominally implement the interface. It just has to have the right structure.
Obviously there are advantages to TS being a very thin layer over JS, so the output code is recognisable (having tried it the results are very impressive I think).
The main difference here is improved tooling enabled by static type declarations. What does that remind me of? The "concepts" feature that was originally mooted for C++0x. Like a lot of people, when I first read through the C++0x feature list, I weeded out the stuff that compiler implementers would do last (or possibly never bother with). And concepts stuck out like a sore thumb. And sure enough it got dropped from the eventual standard.
TypeScript is a very similar project, in that it overlays a system of declared structural typing over an existing system that already works okay without it, with the aim of improved tooling.
Yes, TS adds classes and modules, but (as the examples show) it doesn't really need to do very much to implement those. They are easy patterns to follow. (Okay, classical inheritance gets tricky when you start inheriting implementation, but most modern OO books warn against doing that too much anyway.)
The => syntax is nice, but I'd class that alongside CoffeeScript - not interesting in itself, because all it does is make the code "look" pretty in the most superficial possible sense (to me, it's already pretty in the sense that matters!) I wouldn't turn down => as part of a bundled deal, but it's not a deal-maker in itself.
Having played with TS for a day, it's a beautiful demonstration of how static typing is a genuinely valuable productivity tool. And this implementation of it is unusually good (it already appears to be better than Java and C#, due to the underlying structural nature, as opposed to dumb nominal typing).
However, the number one, constant, irritating pain is the lack of support for continuations in the language. Fix that somehow in TS and I will jump at it like a starving leopard. (Async/await, or even just the yield keyword as implemented in Mozilla).
Then the static typing and other bits of sugar will be a fantastic bonus.
The more I read/watch about WinRT, the more it seems the list of "things you can suddenly do" seems inescapably identical to the claims being made nearly 10 years ago for the CLR.
A common type system (which in fact builds on a metadata format taken straight from the CLR), a common platform that multiple languages can interoperate with, a big and ever growing library of APIs exposed via that platform, starting with a common system of collections, and then a common way of doing generic types, etc.
Just as C++/CLI meant that C++ was part of the CLR environment, in precisely the same way we now have C++/CX for WinRT as described in this talk. As the team discovered, C++/CLI has a lot of good stuff in it, so it just makes sense to do it that way. One reason for this is that the CLR (while by no means perfect, lacking multiple implementation inheritance) has a lot of good stuff in it, and C++/CLI was an elegant projection of that feature set.
IL code can have pointers and can so corrupt the entire process address space if it feels that would be helpful (available in C# via unsafe code). So that is not a unique capability of native code. Again, CLR and WinRT are (sadly) of one mind on that score.
So far all I've been able to detect that is different between the two is that CLR has a compacting generational mark/sweep garbage collector and WinRT does not.
Viewed from this angle it seems largely like an exercise in repeating the entire CLR design program but this time not using a sophisticated GC, substituting in its place very basic reference counting in a free store, per OLE circa 1990.
Is there anything being announced here that could not have been achieved by building the whole WinRT atop the CLR? Bearing in mind that Herb's advice (use ISO C++ everywhere except at the boundaries) could also be followed in exactly the same way in C++/CLI.
The flat memory space is just an abstraction. It is not necessarily a more fundamental underpinning than any other (it has to be simulated by the virtual memory system). And if you are concerned about security, it's a poor choice of abstraction for application programming, to judge by the constant stream of exploit opportunities being discovered and patched in code that has buffer overruns, dangling pointers, etc.
So, not a step backward (because all the old stuff is still there), nor a step forward (because it so closely resembles a subset of the old stuff). A step sideways?
The piece I'm missing from all the talks/articles is a justification, a philosophical basis, an over-arching motivation, for why Microsoft needs (and MS thinks the world needs) something exactly like the CLR but without the GC.
It becomes more of a problem as a project evolves over several years, especially with independently developed components going into it.
Over time, the number of cases where proxy classes are needed grows until they blot out the intention of the "actual" code, which is when a language feature becomes valuable.
Bah... based on this, I'm guess the answer is no.