171–180 of 466 posts
Earlier quoted context omitted.
>20x times shorter that's giant, but I don't think that "just" language / environment difference makes this huge difference
I would say 2x-5x shorter is pretty realistic.
Earlier quoted context omitted.
Refusing to support System.Speech is why my project will remain locked to .NET Framework. Apparently the Microsoft Speech team is part of Azure now, and has decided nobody needs local speech synthesis that doesn't require a subscription to a cloud service.
IIUC, System.Speech was simply a .NET wrapper for the Microsoft Speech API (SAPI), which has been part of Windows for a long time. If you want to move to .NET Core, you can use SAPI via COM interop. Disclosure: I currently work at Microsoft on the Windows accessibility team. We don't own SAPI or System.Speech, but we consume SAPI in Narrator (via COM in C++).
Microsoft should prioritize fixing this over other tasks with .NET, if they value accessibility users.
It'd be nice for a cross-platform local speech library to be available on .NET, and it'd be nice if the Speech team wasn't likely incentivized to push Azure, but at minimum, existing accessibility functionality should be understood to be crucial.
So, on the plus side with the new .net, I recently made a .net core web app on Linux, and generally it's been pretty easy. I'm also impressed at just how fast asp.net core is compared to asp.net, the time it takes to open your site in debug mode has dropped dramatically, from what used to be 1/2 minute in asp.net to a few seconds in .net core. On the bad side? Mainly the asp.net core team and their push for Dependenc…
Agree with your complaint on async. And on asp.net, async doesn't disrupt that much the workflow (but creates the possibility for deadlocks). But if you are dealing with a UI and make a method async, then suddenly you have a ton more problems to deal with, like what happen if the user changes the state while you are waiting for an async call. That increases a lot the complexity of the code. Which is why I am lukewarm…
In my experience, the complexity is vastly reduced by not having to implement tricky asynchronous APIs (Task Paralell, thread pools, BackgroundWorker, etc).
Earlier quoted context omitted.
There may well be some niggles that affect a small number of people doing some niche things under specific circumstances, but I don't think that's enough to claims it's not cross-platform. Since dotnet core became a thing, I've been building cross-platform apps with great success - mostly Windows and Linux, occasionally MacOS too, and mostly x64, but also ARM too.
A GUI application that is not web-based is not a niche use case. A build system is not a niche use case. I see you have been posting Wintel news. Do you have any affiliation?
Frankly, at this point native, cross-platform GUIs are a niche. I used to write a lot of Windows-only GUIs (mostly WinForms, some WPF), but haven't written a desktop GUI for around 10 years now. If I was to now, I'd try one of those aforementioned OSS libs, or maybe use Electron. I know Electon gets a lot of hate on HN, but VS Code shows it's possible to do well.
Not sure if you meant it that way, but accusations of shilling are forbidden here on HN. I've no affiliation with Microsoft, I'm just a long-time, dotnet developer that loves C# and the ecosystem.
Earlier quoted context omitted.
why doesn't MS just release the SAPI wrapper as a windows only nuget package since it already exists?
One thing I've learned in my time on the accessibility team at MS is that even at a company as large as Microsoft, any given team has limited resources and only so many person-hours in a day. So every task has to have a business justification. There probably hasn't been enough demand for releasing System.Speech as a NuGet package to justify it. That's just my guess though; I haven't talked to the speech or .NET teams…
"Microsoft is committed to revolutionizing access to technology for people living with disabilities—impacting employment and quality of life for more than a billion people in the world."
"To enable transformative change accessibility needs to be a priority. That’s why we have begun to manage it like a business and developed our Accessibility Evolution Model to track our progress."
I feel if these statements are true, Microsoft executives should require good maintenance of APIs heavily depended on by accessibility features, and should direct the appropriate teams to prioritize this issue. Because today, in pushing developers to move to a platform that doesn't support System.Speech, Microsoft is moving backwards.
Earlier quoted context omitted.
I agree with the DI for config and async push. Too much ceremony for a very simple task. Async being used by auth can certainly be frustrating if you have sync code that needs to use it at some point. Then suddenly you have to redo all sync code that calls the async method. I’ve been experiencing the same issue with some Azure SDKs that only expose async methods rather than both async and sync. Frustrating to have to…
You can actually just use `.Wait` or `.Result()` most of the time if you just want to make it synchronous if it's just scrappy code. Though you'll probably hit the `async void return` runtime bug at some point where you accidentally return void from a method you tried to make async but then got bored of rewriting everything, so just whack in a .Wait or .Result() but haven't returned Task and the damn thing fails at r…
You call .GetAwaiter().GetResult();
and avoid mixing sync and async where at all possible.
Earlier quoted context omitted.
IIUC, System.Speech was simply a .NET wrapper for the Microsoft Speech API (SAPI), which has been part of Windows for a long time. If you want to move to .NET Core, you can use SAPI via COM interop. Disclosure: I currently work at Microsoft on the Windows accessibility team. We don't own SAPI or System.Speech, but we consume SAPI in Narrator (via COM in C++).
I recognize this. But so is WinForms and plenty of other Windows-specific APIs. System.Speech, being as you recognize, a crucial accessibility feature, and it should be considered extremely high priority, even if the usage percentage is low. Microsoft should prioritize fixing this over other tasks with .NET, if they value accessibility users. It'd be nice for a cross-platform local speech library to be available on .…
I'm the first to push for prioritizing accessibility when needed. But there's a difference between an accessibility gap that prevents a person with a disability from completing some task, and a missing convenience wrapper for an API that a developer could pretty easily use through generic COM interop. So I don't think it's appropriate to play the accessibility card in this case.
Earlier quoted context omitted.
> Why would we want that to be synchronous? Authentication is blocked by accessing storage. You cannot proceed until the storage read operation is completed. There is no parallel work to be accomplished here. This isn't UI code. There's no event loop. Why would you want this to be asynchronous? This seems like async as a dogma, rather than as a tool to accomplish something specific.
Awaiting a storage operation (ie. look up user) in C# will allow other calls to proceed until the I/O is available to read. Synchronous code locks you into the model of handling one request per thread. Given the minor overhead (both cognitive and runtime) of a sync/await, I can’t see why you wouldn’t want to do it here.
So, on the plus side with the new .net, I recently made a .net core web app on Linux, and generally it's been pretty easy. I'm also impressed at just how fast asp.net core is compared to asp.net, the time it takes to open your site in debug mode has dropped dramatically, from what used to be 1/2 minute in asp.net to a few seconds in .net core. On the bad side? Mainly the asp.net core team and their push for Dependenc…
I agree. The first thing I always do is make a custom Settings class which just loads settings via good old `Environment.GetEnvironmentVariable`. Super simple and never failed me. Bonus Points, by loading all settings at once into strongly typed properties at startup, it will fail fast if a setting is missing, which to me is a benefit. But I still pass this class via DI to the controllers for testability reasons. If…
This feature is added in the `config.AddEnvironmentVariables()` line, which is already included in the default host builder. The latest releases use very good conventions and include a lot of the typical functionality. I recommend reading the docs to avoid redoing what's already there: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/co...
Earlier quoted context omitted.
Authentication is in the request pipeline, so it makes sense that it's async if you're talking to some sort of storage engine. We're using the async APIs to pull user/client app information from our database. Why would we want that to be synchronous?
> Why would we want that to be synchronous? Authentication is blocked by accessing storage. You cannot proceed until the storage read operation is completed. There is no parallel work to be accomplished here. This isn't UI code. There's no event loop. Why would you want this to be asynchronous? This seems like async as a dogma, rather than as a tool to accomplish something specific.
Exactly. So when you await it, that thread that would have but blocked waiting for the I/O instead can be used to service other requests until the I/O has finished.