Comments

@Matthew

1) Strings. Calling by method name (i.e. string) has the high road in terms of loose coupling. To gain the local typing, could always wrap in a typed client proxy class (or the tool could build them like service references). Not sure how enums would be used in terms of calling methods. But auto generated typed proxies from meta-data on the uri seems to work fine in other remoting frameworks. And the lower layer stays loose. I suppose a win-win. I am curious if a meta-data public interface method will be added to return method/property names and return types.

2) Reflection. I am not clear where you feel reflection would be required in a method body. Maybe a use case example would help.

3) Message passing.  Sync or Async, it is message passing either way.  You can layer async on any sync method or visa-versa.  AFAICT their Pub/sub is orthogonal to the subject of sync or async method invocation (i.e. message passing).

4) State Machines. I see nothing stopping one from implementing state machine in the actor and methods do actions based on current state. If, on the other hand,  IAsyncState consistency is the concern, then that appears to be handled by correct construction of running delegates syncronously on a single thread. I may have missed your intention.

Is there a way to solve the late binding method name deal so you can leverage .Net intellisense and compile time checking for method names?

Trying to build and run sample. Ran into two issues.

1) Namespace is "$safeprojectname$", which fails to compile. Is this a left over from internal build system?

2) Project references System.Fabric, which is broken link. Where does System.Fabric exist?  I did install the msi already.

TIA

@n4cer:Completely agree. I was thinking same as I was watching. Why on earth not just make a common IL.  All languages (including xaml) would only have to compile down to common IL. IL would be much easier for committee to agree on also as naming and such would not be a major issue as it would be abstracted anyway. Already well known in the art so don't have to start from stage 1.  Language vendors could then also supply decompiler plug-ins for their language for the developers (users would not care or need a decompiler) to view page code in their language of choice.  Because libraries and tooling would use IL also, the language of choice could interact with language constructs on the language of choice (i.e. public interfaces, Casing, etc). Win-win.

This would completely stop the issue of language discussions and what is best. As Anders has pointed out in past, language design is hard and is almost never right out of the gate and incorrect assumptions are always made and you can't change it after release which means you have to spend 5-10 years on beta before release for something this big.  It seems forcing javascript on everyone in the browser goes against the whole open INET mentality from the start. 

I agree with Walpy if we are talking improvement ideas.  Make it easy to cut N seconds from an mp3 or any media track and Send to ringtone. Simple and done.  New sales montra for ya.  Get To Done.

Good talk. Charles, agree that way forward for concurrency may be to do it less and copy more at least for shared state. As strange as that sounds. I have thoughts on a new sync primitive called "sync" that combines thoughts from monitor, reader/writer, and actors messages, but keeps things in the imperative world. Thoughts here. Comments welcome.

I like the improvements Scott. Good job. Needed your web touch.
Still have some issues on the billing side. I have a sub for $10/mth and one month is $34.00. You go to click on that bill and you get "Resource not available." Funny it happens to the only bill I have questions on?

Shards and multi-tenant is really welcome feature.

I find the "share" language a bit odd and backwards. "You share 70% with us"?  I think that is the other way round. The developers share 30% with you. We are the customers, and we make the apps and share 30% with the retailer (i.e. the store).

Dave seem to like Access.  Should note that Acces in the cloud and in Azure is now called MS LightSwitch.  IMO, even better than access, 3-tier by design, no walls, and native sql backend. to boot. Good stuff.

Nice. So in the future, a user could hit a exception, then "click-dump" the process (as a button in the exception window) and email to me. I could open that in VS debuging and be right in the context of the issue and even see what happened before the exception.  Probably could also add a 20 sec reply window replay what user was doing 20 seconds before the issue for even more local context.  Now that itself is a game changer. Also a neat way to publish working VS solutions for samples and demos, or office documents. The target user does not even have to have office installed and could even open from over the web. Big game changer. Nice what senerios that could enable.