6 ms·

C# is, in my opinion, a fantastic language. I haven’t used it in a long time, but the “ergonomics” were really nice. The downside of C# was microsoft, but mayb

C# is, in my opinion, a fantastic language. I haven’t used it in a long time, but the “ergonomics” were really nice. The downside of C# was microsoft, but maybe thats changed now? I know they made a lot of effort to make the .NET framework more cross platform.

throwawaymaths 4y ago
The downside of c# is it's easy until you run into the 80 flavors of async it has.
- schemescape 4y ago
  What is there besides Task<T>?
  - legulere 4y ago
    First there was APM https://learn.microsoft.com/en-us/dotnet/standard/asynchronous-programming-patterns/asynchronous-programming-model-apm https://learn.microsoft.com/en-us/dotnet/standard/asynchrono... then there came TPL (using Task but without async await but ContinueWith) and finally async await with some later refinements like ValueTask. Generally you just use async await nowadays with maybe the complication of when to use Task or ValueTask
    - vips7L 4y ago
      C# tends to have this problem with multiple ways to do the same thing. Look at construction: var a = new A(); A a = new(); A a = new A();
      - schemescape 4y ago
        When did that second one get added? I haven't written C# in a while, but I don't remember seeing that one. I skimmed the C# grammar and didn't see it there either, but I only glanced and might have missed an entire section.
        vips7L 4y ago
        C# 9.0: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-9#fit-and-finish-features https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... I'm honestly surprised they haven't add the ability to drop the `new` keyword like Kotlin: val a = A();
        schemescape 4y ago
        Thanks! For anyone else who’s curious, these seem to be called “Target-typed new expressions”.
- api 4y ago
  Async is a wart, period. It’s an ugly hack around poorly scaling threading abstractions. It basically implements light weight threading but in a way that forces the developer to constantly think about it and clutters up the language with ugly complex async crap. Go is the only language that gets concurrency right. Rust async is ugly but it’s ugly because async is ugly and as a systems language there are limits to how much of that ugliness it can hide. If we could fix threads to scale better at the OS or core library level we’d save insane amounts of developer time.
  - ithrow 4y ago
    Async in the nodejs ecosystem seems to be doing perfectly fine?
    - eyelidlessness 4y ago
      async (the keyword) is doing fantastic because it’s better than all of the available alternatives. Those alternatives: - ad hoc callbacks, which had a great Result-ish type signature but really do warrant the “hell” in “callback hell” - Promise APIs, which are semantically equivalent to async the keyword, unless you care about call stacks, and have a lot of the same hellish problems as the ad hoc callbacks they were meant to address (less nesting! same everything else!) - Um fibers? Good luck making sense out of whatever that’s doing. It’s a good idea, but it’s also all opaque magic when you try using it. - Actual threads and child processes… there are valid use cases, and they’re worth pursuing if you have a valid use case, but the facilities for development with them are basically “here’s a bunch of low level concepts that closely mirror their system level counterparts, hope you know/figure out what you’re doing!”
      - ithrow 4y ago
        By async I was referring to node's asynchronous event-driven runtime abstraction which the GP refers to as an ugly hack. I'm not sure if this abstraction is better than all of the available alternatives if you compare it to high-level features multi-threaded runtimes offer like thread-safe collections, atomic updates, concurrent hash maps, immutability, structured concurrency, etc... as in Java/Clojure. Most Java programmers don't work with the low-level thread primitives. The author of esbuild gave up trying to code esbuild with nodejs/worker threads and switched to Go for a less limited/restricted concurrency environment.
KRAKRISMOTT 4y ago
The problem is the .NET ecosystem. Most of the truly useful frameworks and libraries are either commercial or freemium, and Microsoft is happy to play along and support this cottage industry instead of releasing free in-house versions and crushing the overpriced third party ecosystem. Another issue is that Microsoft 's first party libraries are now increasingly designed to funnel you into Azure services. The language is great, but the ecosystem is rotten.
- easton 4y ago
  I think this very much depends on what you're doing. If it's the typical web app, pretty much everything you'll want is open-source, and most of the time there's some first-party MS thing for what you need (auth? caching? ORM?). We use it at work and don't use any commercial libraries and don't have problems, although it's your typical microservice/distributed pattern. I'm guessing for developing desktop software there's a lot more gremlins. It actually helps a lot that everything's so open source, because often companies will spit out a SDK for .NET to check a box and not have good docs around it because most of their customers aren't using .NET except for a few enterprise whales. > Microsoft 's first party libraries are now increasingly designed to funnel you into Azure services. Outside of the solution for scaling Blazor being "Azure SignalIR service" I'm having trouble with this one too. Their docs often call out Azure, but there's not a ton of bias in support (again, totally might just be that I don't get in the weeds enough).
  - KRAKRISMOTT 4y ago
    Their official ASP.NET OAuth documentation requires you to either pay for the third party Duende IdentityServer or use Azure cloud services. https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity https://learn.microsoft.com/en-us/aspnet/core/security/authe...
    - easton 4y ago
      It says you can use AAD or IdentityServer as OIDC providers, but the doc goes on to explain how to do it yourself with Entity Framework storing user data in a DB and the open source Microsoft.AspNetCore.Identity hooking it into the app. It would be odd if they only gave like Cognito as an example (especially considering AAD is free). And I didn’t know people really used IdentityServer as much in new apps, there’s other ways to do that.

throwawaymaths 4y ago

The downside of c# is it's easy until you run into the 80 flavors of async it has.

schemescape 4y ago
What is there besides Task<T>?
- legulere 4y ago
  First there was APM https://learn.microsoft.com/en-us/dotnet/standard/asynchronous-programming-patterns/asynchronous-programming-model-apm https://learn.microsoft.com/en-us/dotnet/standard/asynchrono... then there came TPL (using Task but without async await but ContinueWith) and finally async await with some later refinements like ValueTask. Generally you just use async await nowadays with maybe the complication of when to use Task or ValueTask
  - vips7L 4y ago
    C# tends to have this problem with multiple ways to do the same thing. Look at construction: var a = new A(); A a = new(); A a = new A();
    - schemescape 4y ago
      When did that second one get added? I haven't written C# in a while, but I don't remember seeing that one. I skimmed the C# grammar and didn't see it there either, but I only glanced and might have missed an entire section.
      - vips7L 4y ago
        C# 9.0: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-9#fit-and-finish-features https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... I'm honestly surprised they haven't add the ability to drop the `new` keyword like Kotlin: val a = A();
        schemescape 4y ago
        Thanks! For anyone else who’s curious, these seem to be called “Target-typed new expressions”.
api 4y ago
Async is a wart, period. It’s an ugly hack around poorly scaling threading abstractions. It basically implements light weight threading but in a way that forces the developer to constantly think about it and clutters up the language with ugly complex async crap. Go is the only language that gets concurrency right. Rust async is ugly but it’s ugly because async is ugly and as a systems language there are limits to how much of that ugliness it can hide. If we could fix threads to scale better at the OS or core library level we’d save insane amounts of developer time.
- ithrow 4y ago
  Async in the nodejs ecosystem seems to be doing perfectly fine?
  - eyelidlessness 4y ago
    async (the keyword) is doing fantastic because it’s better than all of the available alternatives. Those alternatives: - ad hoc callbacks, which had a great Result-ish type signature but really do warrant the “hell” in “callback hell” - Promise APIs, which are semantically equivalent to async the keyword, unless you care about call stacks, and have a lot of the same hellish problems as the ad hoc callbacks they were meant to address (less nesting! same everything else!) - Um fibers? Good luck making sense out of whatever that’s doing. It’s a good idea, but it’s also all opaque magic when you try using it. - Actual threads and child processes… there are valid use cases, and they’re worth pursuing if you have a valid use case, but the facilities for development with them are basically “here’s a bunch of low level concepts that closely mirror their system level counterparts, hope you know/figure out what you’re doing!”
    - ithrow 4y ago
      By async I was referring to node's asynchronous event-driven runtime abstraction which the GP refers to as an ugly hack. I'm not sure if this abstraction is better than all of the available alternatives if you compare it to high-level features multi-threaded runtimes offer like thread-safe collections, atomic updates, concurrent hash maps, immutability, structured concurrency, etc... as in Java/Clojure. Most Java programmers don't work with the low-level thread primitives. The author of esbuild gave up trying to code esbuild with nodejs/worker threads and switched to Go for a less limited/restricted concurrency environment.

KRAKRISMOTT 4y ago

The problem is the .NET ecosystem. Most of the truly useful frameworks and libraries are either commercial or freemium, and Microsoft is happy to play along and support this cottage industry instead of releasing free in-house versions and crushing the overpriced third party ecosystem. Another issue is that Microsoft 's first party libraries are now increasingly designed to funnel you into Azure services. The language is great, but the ecosystem is rotten.

easton 4y ago
I think this very much depends on what you're doing. If it's the typical web app, pretty much everything you'll want is open-source, and most of the time there's some first-party MS thing for what you need (auth? caching? ORM?). We use it at work and don't use any commercial libraries and don't have problems, although it's your typical microservice/distributed pattern. I'm guessing for developing desktop software there's a lot more gremlins. It actually helps a lot that everything's so open source, because often companies will spit out a SDK for .NET to check a box and not have good docs around it because most of their customers aren't using .NET except for a few enterprise whales. > Microsoft 's first party libraries are now increasingly designed to funnel you into Azure services. Outside of the solution for scaling Blazor being "Azure SignalIR service" I'm having trouble with this one too. Their docs often call out Azure, but there's not a ton of bias in support (again, totally might just be that I don't get in the weeds enough).
- KRAKRISMOTT 4y ago
  Their official ASP.NET OAuth documentation requires you to either pay for the third party Duende IdentityServer or use Azure cloud services. https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity https://learn.microsoft.com/en-us/aspnet/core/security/authe...
  - easton 4y ago
    It says you can use AAD or IdentityServer as OIDC providers, but the doc goes on to explain how to do it yourself with Entity Framework storing user data in a DB and the open source Microsoft.AspNetCore.Identity hooking it into the app. It would be odd if they only gave like Cognito as an example (especially considering AAD is free). And I didn’t know people really used IdentityServer as much in new apps, there’s other ways to do that.