> But choosing .NET is a choice, and whenever anybody does it, I can’t help but ask “why?”
> Programming with .NET is like cooking in a McDonalds kitchen.
Has the author ever even used .NET? Maybe for their specific product it isn't useful, but just look at (for one example) all the games on the Xbox 360, a platform that dominated. Also, at least in my company .NET is huge internally. Fortune 500's prefer stability, and startups don't (as much), but that doesn't mean the need isn't there.
That's it's huge internally at a Fortune 500 is more or less what the article rails against, no? It's the same reason Java-the-language on a resume, at least if it's the primary environment, also makes me read closer so I can learn if they're a lowest-common-denominator developer, or just happened to also know Java.
The article doesn't say anything about there not being a need for such environments, and a Fortune 500 (or even 2000) company may be just that place.
> Startup's seem to have always argued about price and vendor lock in.
This is not an argument here.
> You can code on Windows, with a free IDE (Visual Studio Code, Visual Studio Community) and deploy to Linux.
You can't. You won't have access to Linux ecosystem and mindshare if you do that You limit yourself to extremely tiny subset of things you can do on both systems. It makes no sense.
> The 'vendor lockin' is now no more locked in than using Ruby or Go or any other language.
Roby or Go has no problem whatsoever with using full power of Linux, .Net does. Ruby and Go communities on Linux are several orders of magnitude larger then amount of people using .Net there. There is plenty of Ruby/Go developers who know how to dive into Ruby or system internals if they need to, this is not common in .Net world.
>> You can code on Windows, with a free IDE (Visual Studio Code, Visual Studio Community) and deploy to Linux.
> You can't. You won't have access to Linux ecosystem and mindshare if you do that
Though it's no longer vendor lock-in per se, even if Microsoft closes .NET
(Core) back or do something else equally nasty, since it was published as open
source at least once and somebody will just fork it (see what happened to
MySQL).
Though .NET on Linux indeed doesn't seem to be as compelling to the community
of Linux-first developers. It just has tough competitors that have been
present here since forever.
I am not arguing that it is. I am arguing that it hard to make full use of it. An example: I googled:
python sendfile: first three links point you to python modules implementing it
ruby sendfile: same thing, first links point you to some middleware that uses that
golang sendfile: first link points to stdlib implementing sendfile
asp.net core sendfile, .net sendfile: I went through all links in the first page, still have no clue if it can be used.
You can use .net on Linux. But you are restricted by Windows limitations, and you miss on the mindshare.
You don't understand what I am talking about, neither do FileStreamResult authors (I've looked at mono and ms implementations) and that's the problem I am talking about.
Linux users either know what sendfile syscall is and how to use it or use libraries whose authors know.
I'm not talking about Mono. And you're talking about premature optimization. We're barely out the gate with 1.0 and you're optimization how a file is touched. An optimization that would benefit very few people in the real world. If you're worrying about perf when you're streaming a file out of Ruby or Python to a browser then you need to rethink what you're trying to solve.
It doesn't change the fact that right now, you can write a asp.net core web application on windows and run it on linux. For free.
> And you're talking about premature optimization.
Why premature? And why should a basic library be deciding if they are premature or not?
I am using Linux only (and most startups do that too).
> We're barely out the gate with 1.0 and you're optimization how a file is touched.
Sorry, who are "we"? I am discussing using .Net in context of all startups, not some particular one. What if my product is entirely about sending files? Or anything else where some Linux specific feature can make a big difference in performance, convenience or ability to share code with other people who are also using Linux only?
> An optimization that would benefit very few people in the real world.
It was added to operating system. That means pressure to do so had to be pretty high.
And nearly all web framework on Linux are able to use it, so its no so uncommon as you may think.
> If you're worrying about perf when you're streaming a file out of Ruby or Python to a browser then you need to rethink what you're trying to solve.
Its not uncommon to stream files Python or Ruby never touched, just decided they should be sent. Its a perfect fit for this case, and performance of interpreted languages is not an issue here.
>It doesn't change the fact that right now, you can write a asp.net core web application on windows and run it on linux. For free.
Yes, you can. But you can not make full use of it. Which for me means that it makes no sense to use it there, when its competitors have no such issue.
> Programming with .NET is like cooking in a McDonalds kitchen.
Has the author ever even used .NET? Maybe for their specific product it isn't useful, but just look at (for one example) all the games on the Xbox 360, a platform that dominated. Also, at least in my company .NET is huge internally. Fortune 500's prefer stability, and startups don't (as much), but that doesn't mean the need isn't there.