5 ms·

> 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 Typ

> 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.

phillipcarter 10mo ago
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.
- cebert 10mo ago
  You can easily use the same types and libraries in your backend and frontend with TypeScript. It’s not at easy with dotnet.
  - phito 10mo ago
    OpenAPI and client generators solve this issue easily.
    - robertlagrant 10mo ago
      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.
      - littlecranky67 10mo ago
        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.
        robertlagrant 10mo ago
        True, but you can get all the way to zero duplication if you write it directly and share that code.
        deleted 10mo ago
        [deleted]
    - cies 10mo ago
      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).
    - josephg 10mo ago
      Still more work than just running the same code everywhere.
      - phito 10mo ago
        Still better than bringing JavaScript to the back end shudders
    - littlecranky67 10mo ago
      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.
  - pjmlp 10mo ago
    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.
    - petesergeant 10mo ago
      > 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.
      - pjmlp 10mo ago
        Yeah, except plenty of them are probably using Kubernetes and NoSQL, because everyone dreams to be Google.
        phillipcarter 10mo ago
        I don't think it's about dreaming to be Google. K8s is pretty easy to set up now with a hosted cloud platform if you start with it, and helm takes care of pretty much all your infra needs. Migrating to K8s is what's awful. From there, the docs have most everything you need to know and there's an abundance of helpful information online that covers most problems you'll run into.
  - DeathArrow 10mo ago
    >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.
- SparkBomb 10mo ago
  It really depends where you are. In the UK half the places seem to use .NET in some form or another. I am pretty language agnostic and I am reasonably competent programming in C# (I worked with C# and VB.NET for about 15 years), Go, Python, TypeScript and C++ these days. The issue with a lot of places that do C#/.NET stuff is that they will typically ignore new tech until it is officially blessed by Microsoft. You can have a piece of tech that everyone is using and works really well and it will be ignored if it isn't blessed by Microsoft. The other issue with .NET is all the Microsoft gumpf that tends to come with it even with the newer versions of .NET. I am also in the weird place of being a Linux user. I've had job interviews that wanted to do live coding exercise/take home code exercise and they expect you to do everything in Visual Studio with SQL Server.
  - mrsmrtss 10mo ago
    Why would they insist on using Visual Studio? At least you can run SQL Server easily on Linux using docker.
    - SparkBomb 10mo ago
      > Why would they insist on using Visual Studio? They don't even know Rider exists a lot of the time. It is also quite different visually compared to Visual Studio code. A lot of places have never used Linux at all and if they have they have it would be WSL or some RHEL box. So if you are screen sharing Gnome and with a totally different IDE and Terminal the person assessing you might not actually understand what you are doing. > At least you can run SQL Server easily on Linux using docker. 1) They normally want you to use something like SQL Server Compact or SQL Server Express and a specific version. TBH I just don't bother anymore with these interviews because it takes like a couple of hours to get all this stuff working on Windows. 2) SQL Server Projects can only be used on Windows with Visual Studio. Some places do a lot of stuff "old school" and they want you to use that.
- hshdhdhj4444 10mo ago
  > It's just .NET that's largely ignored for no real technical basis. As someone who has been developing primarily on .Net for the past decade this is absolute bullshit. 1. It’s only very recently that .Net became open source. Until then you would frequently hit issues where the only option was to rely on the few support calls you got with MS engineers with your $1000+ Visual Studio subscription to move forward. And believe me, this isn’t a pleasant way of debugging. 2. It’s only recently that .Net became cross platform. Until recently .Net meant you had to pay far more money for windows servers, get far less performance, and open your application to way more security issues. And when things broke they broke in highly inscrutable ways. 3. It’s still not a great platform. If you’re deploying on Windows, there are still things you will want to do that will require windows registry changes. 4. It’s only recently that the transition to an open source/cross platform framework has stabilized. Until now you had to deal with MS alphabet and naming goop, an absolutely muddy roadmap, and if you ever got thrown into a project you’d end up finding yourself in a mess of varying conventions, project types, incompatibilities, etc. 5. You know all those performance improvements they’re delivering with every release? There’s a reason for that. Until recently performance was so bad. Kestrel alone provider at least an order of magnitude of improvement. 6. Thank the lord for Jetbrains but other than them, to do proper .Net development you need to use Visual Studio. And Visual Studio is not a pleasant IDE or development environment at all. There were a lot of technical reasons to not adopt .Net. Even today there’s the problem of MS losing interest or making the wrong choices and there being basically no alternative, because unlike even Java, the .NET ecosystem is completely dependent on what MS does.
  - neonsunset 10mo ago
    [dead]
  - phillipcarter 10mo ago
    By recently you mean a decade ago yeah? I mean it’s fair that it was only a half-decade (.NET 5) when it was genuinely complete enough, but lots of stuff was in good shape when it was called .NET Core. It sounds like you’re projecting the problems of an existing .NET shop onto the shape of a startup without all that baggage. I can assure you, having worked with many customers running new business on newer .NET, it hasn’t been a legit technical concern since about .NET Core 3.
- pier25 10mo ago
  > Backends can be any language In +90% of cases you will still need a frontend for that backend. TS full stack is by far the best option for this.
  - phillipcarter 10mo ago
    Not really? Having come deom a TS + Go startup it’s pretty trivial to wire up domain objects across each language and define a clean API boundary with some enforcement at build time. And Go was a far better choice for the backend than TS for some lower-level memory considerations.
    - pier25 10mo ago
      With TS you don't have to "define a clean API boundary with some enforcement at build time". You can use the exact same types you're using to enforce endpoint schemas everywhere. You don't need a middle man like OpenAPI (which I've used and it's a mediocre solution).
pif 10mo ago
I wish people stopped conflating web programming with the whole realm of software development.
- charcircuit 10mo ago
  If you ignore Android / iPhone, where language choice is limited, practically all other development is web.
  - forrestthewoods 10mo ago
    > practically all Define “practically all”. I would accept “clear majority”. But practically all? Nah. I mean the hot new areas for funding right now are AI and robotics neither of which are web! I’m coming up on 20 years professional experience. Exactly none of it has been mobile or web! The programming field is so much bigger than HN likes to pretend.
    - adastra22 10mo ago
      The majority of software is probably Excel macros.
      - egeozcan 10mo ago
        This probably isn't true but I want to read a super geeky dark sci-fi novel that explores this topic.
        adastra22 10mo ago
        It's not obvious to me that it isn't true. The number of excel spreadsheets world-wide probably vastly outnumbers the number of software projects.
        egeozcan 10mo ago
        Excel spreadsheets with macros on the other hand aren't THAT many, no? :)
greener_grass 10mo ago
What are the cross-stack gains of Python? Running TypeScript on the server is a well trodden path. It can be pretty fast too. Python on the client, not so much.

phillipcarter 10mo ago

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.

cebert 10mo ago
You can easily use the same types and libraries in your backend and frontend with TypeScript. It’s not at easy with dotnet.
- phito 10mo ago
  OpenAPI and client generators solve this issue easily.
  - robertlagrant 10mo ago
    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.
    - littlecranky67 10mo ago
      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.
      - robertlagrant 10mo ago
        True, but you can get all the way to zero duplication if you write it directly and share that code.
        deleted 10mo ago
        [deleted]
  - cies 10mo ago
    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).
  - josephg 10mo ago
    Still more work than just running the same code everywhere.
    - phito 10mo ago
      Still better than bringing JavaScript to the back end shudders
  - littlecranky67 10mo ago
    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.
- pjmlp 10mo ago
  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.
  - petesergeant 10mo ago
    > 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.
    - pjmlp 10mo ago
      Yeah, except plenty of them are probably using Kubernetes and NoSQL, because everyone dreams to be Google.
      - phillipcarter 10mo ago
        I don't think it's about dreaming to be Google. K8s is pretty easy to set up now with a hosted cloud platform if you start with it, and helm takes care of pretty much all your infra needs. Migrating to K8s is what's awful. From there, the docs have most everything you need to know and there's an abundance of helpful information online that covers most problems you'll run into.
- DeathArrow 10mo ago
  >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.
SparkBomb 10mo ago
It really depends where you are. In the UK half the places seem to use .NET in some form or another. I am pretty language agnostic and I am reasonably competent programming in C# (I worked with C# and VB.NET for about 15 years), Go, Python, TypeScript and C++ these days. The issue with a lot of places that do C#/.NET stuff is that they will typically ignore new tech until it is officially blessed by Microsoft. You can have a piece of tech that everyone is using and works really well and it will be ignored if it isn't blessed by Microsoft. The other issue with .NET is all the Microsoft gumpf that tends to come with it even with the newer versions of .NET. I am also in the weird place of being a Linux user. I've had job interviews that wanted to do live coding exercise/take home code exercise and they expect you to do everything in Visual Studio with SQL Server.
- mrsmrtss 10mo ago
  Why would they insist on using Visual Studio? At least you can run SQL Server easily on Linux using docker.
  - SparkBomb 10mo ago
    > Why would they insist on using Visual Studio? They don't even know Rider exists a lot of the time. It is also quite different visually compared to Visual Studio code. A lot of places have never used Linux at all and if they have they have it would be WSL or some RHEL box. So if you are screen sharing Gnome and with a totally different IDE and Terminal the person assessing you might not actually understand what you are doing. > At least you can run SQL Server easily on Linux using docker. 1) They normally want you to use something like SQL Server Compact or SQL Server Express and a specific version. TBH I just don't bother anymore with these interviews because it takes like a couple of hours to get all this stuff working on Windows. 2) SQL Server Projects can only be used on Windows with Visual Studio. Some places do a lot of stuff "old school" and they want you to use that.
hshdhdhj4444 10mo ago
> It's just .NET that's largely ignored for no real technical basis. As someone who has been developing primarily on .Net for the past decade this is absolute bullshit. 1. It’s only very recently that .Net became open source. Until then you would frequently hit issues where the only option was to rely on the few support calls you got with MS engineers with your $1000+ Visual Studio subscription to move forward. And believe me, this isn’t a pleasant way of debugging. 2. It’s only recently that .Net became cross platform. Until recently .Net meant you had to pay far more money for windows servers, get far less performance, and open your application to way more security issues. And when things broke they broke in highly inscrutable ways. 3. It’s still not a great platform. If you’re deploying on Windows, there are still things you will want to do that will require windows registry changes. 4. It’s only recently that the transition to an open source/cross platform framework has stabilized. Until now you had to deal with MS alphabet and naming goop, an absolutely muddy roadmap, and if you ever got thrown into a project you’d end up finding yourself in a mess of varying conventions, project types, incompatibilities, etc. 5. You know all those performance improvements they’re delivering with every release? There’s a reason for that. Until recently performance was so bad. Kestrel alone provider at least an order of magnitude of improvement. 6. Thank the lord for Jetbrains but other than them, to do proper .Net development you need to use Visual Studio. And Visual Studio is not a pleasant IDE or development environment at all. There were a lot of technical reasons to not adopt .Net. Even today there’s the problem of MS losing interest or making the wrong choices and there being basically no alternative, because unlike even Java, the .NET ecosystem is completely dependent on what MS does.
- neonsunset 10mo ago
  [dead]
- phillipcarter 10mo ago
  By recently you mean a decade ago yeah? I mean it’s fair that it was only a half-decade (.NET 5) when it was genuinely complete enough, but lots of stuff was in good shape when it was called .NET Core. It sounds like you’re projecting the problems of an existing .NET shop onto the shape of a startup without all that baggage. I can assure you, having worked with many customers running new business on newer .NET, it hasn’t been a legit technical concern since about .NET Core 3.
pier25 10mo ago
> Backends can be any language In +90% of cases you will still need a frontend for that backend. TS full stack is by far the best option for this.
- phillipcarter 10mo ago
  Not really? Having come deom a TS + Go startup it’s pretty trivial to wire up domain objects across each language and define a clean API boundary with some enforcement at build time. And Go was a far better choice for the backend than TS for some lower-level memory considerations.
  - pier25 10mo ago
    With TS you don't have to "define a clean API boundary with some enforcement at build time". You can use the exact same types you're using to enforce endpoint schemas everywhere. You don't need a middle man like OpenAPI (which I've used and it's a mediocre solution).

pif 10mo ago

I wish people stopped conflating web programming with the whole realm of software development.

charcircuit 10mo ago
If you ignore Android / iPhone, where language choice is limited, practically all other development is web.
- forrestthewoods 10mo ago
  > practically all Define “practically all”. I would accept “clear majority”. But practically all? Nah. I mean the hot new areas for funding right now are AI and robotics neither of which are web! I’m coming up on 20 years professional experience. Exactly none of it has been mobile or web! The programming field is so much bigger than HN likes to pretend.
  - adastra22 10mo ago
    The majority of software is probably Excel macros.
    - egeozcan 10mo ago
      This probably isn't true but I want to read a super geeky dark sci-fi novel that explores this topic.
      - adastra22 10mo ago
        It's not obvious to me that it isn't true. The number of excel spreadsheets world-wide probably vastly outnumbers the number of software projects.
        egeozcan 10mo ago
        Excel spreadsheets with macros on the other hand aren't THAT many, no? :)

greener_grass 10mo ago

What are the cross-stack gains of Python? Running TypeScript on the server is a well trodden path. It can be pretty fast too. Python on the client, not so much.