Most active commenters

    ←back to thread

    .NET 10

    (devblogs.microsoft.com)
    484 points runesoerensen | 13 comments | 11 Nov 25 15:44 UTC | HN request time: 0.626s | source | bottom
    Show context
    jitbit ◴[11 Nov 25 15:48 UTC] No.45888669[source]▶
    For us, every .NET upgrade since .NET 5 has gone surprisingly smoothly and reduced CPU/RAM usage by 10–15%.

    We were even able to downgrade our cloud servers to smaller instances, literally.

    I wish .NET was more popular among startups, if only C# could get rid of the "enterpisey" stigma.

    replies(26): >>45888799 #>>45888804 #>>45889332 #>>45891939 #>>45896032 #>>45898279 #>>45898305 #>>45898358 #>>45898503 #>>45898877 #>>45899062 #>>45899235 #>>45899246 #>>45899326 #>>45899445 #>>45899481 #>>45899858 #>>45900544 #>>45900791 #>>45900829 #>>45903218 #>>45904345 #>>45904435 #>>45905041 #>>45906073 #>>45907122 #
    leetharris ◴[11 Nov 25 16:35 UTC] No.45889332[source]▶
    > I wish .NET was more popular among startups, if only C# could get rid of the "enterpisey" stigma.

    Too hard to ignore the benefits of cross-stack gains in Typescript/Python. The C# native phone, Blazor, etc just isn't quite there yet. Tried it at the last company, and full stack TS was just so much easier to do.

    The reality is that the vast majority of startups don't make it. The #1 thing startups should be focusing on is hiring the right people and product velocity. TS just makes that easier in my experience.

    replies(3): >>45890709 #>>45898233 #>>45898434 #
    phillipcarter ◴[11 Nov 25 18:06 UTC] No.45890709[source]▶
    Is it though? Backends can be any language and there's a lot more variety there -- TS+node, Go, Python, Java. It's just .NET that's largely ignored for no real technical basis.
    replies(4): >>45896164 #>>45898627 #>>45898862 #>>45904484 #
    1. cebert ◴[12 Nov 25 03:40 UTC] No.45896164[source]▶
    You can easily use the same types and libraries in your backend and frontend with TypeScript. It’s not at easy with dotnet.
    replies(3): >>45898128 #>>45898236 #>>45898276 #
    2. phito ◴[12 Nov 25 09:29 UTC] No.45898128[source]▶
    OpenAPI and client generators solve this issue easily.
    replies(4): >>45898168 #>>45898177 #>>45898181 #>>45898458 #
    3. robertlagrant ◴[12 Nov 25 09:34 UTC] No.45898168[source]▶
    No, that's not true. If you share code like this then you can do things like put the same validation code in the frontend and the backend: frontend to give a nice user experience, and backend to protect the endpoint.
    replies(1): >>45898510 #
    4. cies ◴[12 Nov 25 09:36 UTC] No.45898177[source]▶
    Or GraphQL.

    Still one lang on both ends is nice: there are some bits of code you want to run on both ends (like templating for SSR/SEO/caching; but also using them in the browser).

    5. josephg ◴[12 Nov 25 09:37 UTC] No.45898181[source]▶
    Still more work than just running the same code everywhere.
    6. pjmlp ◴[12 Nov 25 09:47 UTC] No.45898236[source]▶
    While suffering the performance loss of V8 versus CLR, JVM or any compiled language.

    One of the reasons I am back to writing more C++ code is C++ addons for node.js, as several SaaS products now only care about Next.js as extension SDK.

    replies(1): >>45898384 #
    7. DeathArrow ◴[12 Nov 25 09:53 UTC] No.45898276[source]▶
    >You can easily use the same types and libraries in your backend and frontend with TypeScript. It’s not at easy with dotnet.

    You can do that in .NET, too if you use Blazor for frontend.

    8. petesergeant ◴[12 Nov 25 10:09 UTC] No.45898384[source]▶
    > While suffering the performance loss of V8 versus CLR, JVM or any compiled language

    The number of startups for whom that performance differential matters more than developer output is tiny.

    replies(1): >>45898590 #
    9. littlecranky67 ◴[12 Nov 25 10:20 UTC] No.45898458[source]▶
    I would love this to be true, but it isn't. I've done generating types for the frontend multiple times, sometimes from C# (around 2016, using typelite), Java (openapi template generator) and most recently straight from OpenAPI spec files (.yaml) using Orval.

    It always has been a shitshow. It works well for the 90% cases, but in the 10% edge cases, things break. It becomes impossible to fix generation issues, you will often resort in working around issues in your backend/openapi code. Sometimes you report bugs upstream and hope it gets fixed. In the current project we are stuck on a ~2year old Orval version (a typescript generator from openapi) because some features broke or were removed in the latest version, and the entire monorepo (15+ LoB apps) wouldn't compile and would require major changes. This simply because a never version of the generator was broken/removed features previously present.

    10. littlecranky67 ◴[12 Nov 25 10:27 UTC] No.45898510{3}[source]▶
    OpenAPI does support patterns for fields and nullables/non-nullables - that already gets you very far regarding validation. A decently sophisticated generator (which don't exist IMHO) would generate the validation code for your respective language.
    replies(1): >>45898922 #
    11. pjmlp ◴[12 Nov 25 10:42 UTC] No.45898590{3}[source]▶
    Yeah, except plenty of them are probably using Kubernetes and NoSQL, because everyone dreams to be Google.
    12. robertlagrant ◴[12 Nov 25 11:37 UTC] No.45898922{4}[source]▶
    True, but you can get all the way to zero duplication if you write it directly and share that code.
    replies(1): >>45901344 #
    13. ◴[12 Nov 25 15:26 UTC] No.45901344{5}[source]▶