This latest thing with #dotnetcore and #dotnetstandard is understandable, but also unavoidable, I think. Core lets the team move faster and break things because you don't have to upgrade it globally on a box; you can have 2.0 and 2.0.4 and 2.1 apps in isolation. 1/
You can't do that with full NetFX (or Mono?) so updates have to be much more cautious. Going from 4.7.2 to 4.8 will affect all apps running on that box. And with the Core 2.1 changes, a LOT of BCL APIs have changed. 2/
I suspect there will be a lot of internal discussions and meetings about getting, for example, the Span/Memory APIs into a shared .NET Standard, making sure the implementations and semantics are properly understood by everyone who needs to implement them. 3/
People who suggest that the Standard should be written in stone before the first implementation is complete would probably be pretty upset if that were imposed on them in their own projects. 4/
You always discover things while implementing features that change the design of those features, often for the better. Being constrained by a strict abstract specification would not result in the best API, and we'd all lose. 5/
#dotnetstandard is like W3C specs. It grows out of implementations. A high level requirement is identified, implementations are tried, and eventually a standard emerges that all vendors can agree on. 6/
.NET implementations are like browsers. Some iterate faster than others, and sometimes there are cool new features that you can only use in Chrome and Firefox until Edge and Safari catch up. And sometimes you'll get a browser implementation that doesn't match the final spec. 7/
Sometimes a feature can be "polyfilled" until everything catches up, which is nice. Sometimes it can't (e.g. JS property accessors) and you either have to wait or support only a subset of implementations. That sucks, but it is what it is. 8/
The right attitude is to think "oh, this is cool, can't wait till this lands in X so I can use it." If you've got a million lines of .NET 4.6.1 code, I'm sure you have more pressing issues than whether Stream supports the Span APIs. 9/
If you're a library author and BCL-integrated Span APIs would create enough benefit for a big enough subset of your consumers, then create a netcoreapp2.1 variation. If you think extension methods could viably bridge the gap, write them. 10/
What we don't need is public displays of rage and petulance on Twitter, because it makes the .NET community look bad and gives the haters more ammunition. "Haha, look, Microsoft have fucked over the derps again, they'll never learn." 11/
#DotNetCore 2.1 is amazing. It's a modern, fast, efficient application framework that builds on a strong ecosystem. Personally I believe it's the best choice right now for building web apps and services and microservices. 12/
The world is not perfect, and change is difficult. But please, let's be constructive in our feedback, and be patient, and trust the various teams to do what's best for their projects and their customers. 13/13
