3 ms·
> Ah the usual argument that good programmers never make mistakes. Not my conclusion at all. I am saying that tooling and base libraries have matured enough to
by ko27 3y ago
> Ah the usual argument that good programmers never make mistakes.
Not my conclusion at all. I am saying that tooling and base libraries have matured enough to prevent those issues from happening.
> because basically now it is too late to retrofit them into .NET
Nope, read the conclusion. There are other factors not just backwards compatibility (which isn't even a blocker).
- pjmlp 3y ago> not my conclusion at all. I am saying that tooling and base libraries have matured enough to prevent those issues from happening. Big if, not everyone is using .NET latest on VS, with latest version of every library using async/await. > Nope, read the conclusion. There are other factors not just backwards compatibility. Again, I wrote the Github issues regarding green threads on my comment, so I don't know, maybe I actually already read them?
- ko27 3y ago> Big if, not everyone is using .NET latest on VS, with latest version of every library using async/await. The analyzers are part of the build, they work everywhere (command line, VS code). Either way, I am glad we finally agree that async await "works fine" for modern .NET. > so I don't know, maybe I actually already read them? I did, I even responded to your links with the official conclusion from the NET team on those issues. Now maybe your turn to read?