Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Case for C# and .NET

chrlschn.medium.com

Post reply on HN
Print view View original

121–130 of 376 posts

Re: The Case for C# and .NET

#121

Post by johnfn »

labrador wrote: post #5

> For the front-end, JavaScript is unavoidable (for now) Author really needs to give Blazor a try. I wrote some comments last week speculating that I'd use Dart or TypeScript with C# .NET on the client because WebAssembly doesn't do DOM manipulation, but turns out I should have waited to learn it better before making a comment. I've learned I can add events and event handlers to elements without ever leaving C#. Then…

Man, I tried out Blazor over the last few days. I really wanted to love it (I love C#), and it looks like it might be good one day, but I found it sadly lacking. I couldn't even add a mouse event to a canvas element. I had to install an extension package to even use a canvas (BECanvas), and then that extension package didn't even have mouse events. I have to say, thats so absurdly basic of a thing to be missing that it made me call the entire library into question: what other extremely basic things could it be missing as well?

Re: The Case for C# and .NET

#122

Post by int_19h »

j0057 wrote: post #26
Barrin92 wrote: post #8

Earlier quoted context omitted.

any software project or language can die, but I honestly struggle to think of a company that has a better history of long term support than Microsoft. You can fault Microsoft for quite a few things but their ability to maintain software and provide stable interfaces for devs is second to none.

MS discontinues a UI library project and then hypes up a new one every few years. Today Blazor and Maui are hot, but there's a lot of abandonware that came before. You can see it in Windows too, where you can burrow deeper and deeper into progressively older settings dialogs, because they reshuffle the Control Panel every few years.

OTOH even stuff as old as Windows Forms (which literally shipped with .NET 1.0 - that's 2001!) still works and it actually has maintainers. You don't have to chase the shiny new stuff.

Re: The Case for C# and .NET

#123

Post by oaiey »

dustinmoris wrote: post #89
CyanLite4 wrote: post #88

This thread shows there is still a large amount of FUD around .NET and it’s community. Folks here still think it’s Windows-only and comparable to Java. Yet latest TechEmpower benchmarks shows .net running on Linux and being faster than Go, Python, Node, and Rust.

The dev experience is Windows only, STILL: https://news.ycombinator.com/reply?id=32220935&goto=item%3Fi... (Also the benchmarks are a cheat, look at the source code of C# vs the source code of Go or Java)

Every benchmark is a cheat and not a real-world problem.

I also thought their benchmark is a cheat. But it is not. It is testing exactly what the benchmark was testing in that scenario. That is why TechEmpower Benchmark suite is so powerful. It uses different web server scenarios (connection, JSON parsing, database connections, ...). The different test case implementation .NET and others have are making sure no other factor is influencing this. For example: when you benchmark connections why dealing with MVC, validation and database connections.

It is not .NET who cheats, it is the others who do not properly isolate the tested performance aspect.

And to make the comparison a bit more real and day-to-day applicable, you need to pick the right framework configuration (like aspcore-mw @ 80% / aspcore-mvc @ 37%) and compare with other reasonable scenarios (like express @ 1% / spring @ 2% / quarkus @ 8%). Both are then far of the top 10 ten list but still comparable. The top 10 combinations are for cases where developer productivity does not matter but throughput is the key (e.g. a DoH resolver or a system like a Cache / Database).

Re: The Case for C# and .NET

#124

Post by zdragnar »

tus666 wrote: post #61
zdragnar wrote: post #29

Earlier quoted context omitted.

> from the perspective of recruiting in Australia. Even accounting for that line from the comment?

Even more so. Python is huge in Australia. Can't count front-end as Python is not applicable there.

There's no reason to discount front-end work from "programming languages". You choose python over typescript for machine learning because the ecosystem is there.

You choose typescript over python because Brython and JavaScripthon and Transcrypt have no ecosystem that makes more sense than using NPM, and the people who like to program in python prefer the challenges of other domains than what's in the web browser.

That just makes "most popular programming language" a silly metric. It doesn't mean that nobody uses the language because you ignore all the people who use it for things you aren't interested in.

Re: The Case for C# and .NET

#125

Post by osigurdson »

bayesian_horse wrote: post #112
osigurdson wrote: post #96

Earlier quoted context omitted.

Obviously there is some degree of subjectivity as what a given language's competitors are. In some sense all languages compete with one another but I do think there is some natural clumping of languages/ecosystems. In my view Python and Ruby are not natural competitors to C# as they are dynamically typed and (in Python's case) interpreted. Similarly Rust, C, and C++ are not natural competitors to C# as they do not ha…

This obsession of dynamically typing vs static typing is not useful. ASP.net is used to develop web applications. C# does have better performance than Python, but I highly doubt most applications will ever need or care about that. Choosing C# over Python (or Ruby, JS etc) for performance reasons is premature optimization at best. Maybe you have some legacy codebase in C# that you need to leverage. All other reasons t…

I certainly hope that the Python language maintainers do not see C#,Go or Java as their competition. I like Python as is.

Re: The Case for C# and .NET

#126

Post by chaostheory »

ivraatiems wrote: post #101
chaostheory wrote: post #58

Reading this post, it seems like the author never tried Typescript which seems to be heavily influenced by C#. I hate JavaScript as a language, but Typescript is very palatable. Like it or not JavaScript and Typescript are the franca lingua of programming for now

The problem with TypeScript is that because it's compiled to JavaScript eventually, it's broken whether it wants to be or not. TS might make sense on its own, but the medium is the message. You can't escape the bizarre stuff JS does when it's right there, under the hood, waiting for you...

That is true, but its strengths tend to outweigh its weaknesses.

Nothing is as universal as typescript / JavaScript. Unlike other languages you also don’t have to context change when you’re transitioning from working on the backend to the front end. Everything also tends to be rewritten for node eventually.

Re: The Case for C# and .NET

#128

Post by AtNightWeCode »

Hot reload for ASP.NET works fine nowadays in VS and even with older versions of .NET.

Dependency handling is still a large problem with .NET. Especially since current is often used instead of LTS. There is also no good way of sharing code between applications.

Arrow functions, btw, solves the this/that problem in JS making React development easier etc.

Re: The Case for C# and .NET

#129

Post by nso »

AtNightWeCode wrote: post #128

Hot reload for ASP.NET works fine nowadays in VS and even with older versions of .NET. Dependency handling is still a large problem with .NET. Especially since current is often used instead of LTS. There is also no good way of sharing code between applications. Arrow functions, btw, solves the this/that problem in JS making React development easier etc.

What do you mean when you say there is no good way to share code between applications?

Re: The Case for C# and .NET

#130

Post by bob1029 »

CyanLite4 wrote: post #88

This thread shows there is still a large amount of FUD around .NET and it’s community. Folks here still think it’s Windows-only and comparable to Java. Yet latest TechEmpower benchmarks shows .net running on Linux and being faster than Go, Python, Node, and Rust.

The performance really is astonishing in many areas now.

The part that keeps me hooked is the fact that I can stand up something capable of producing those numbers in 30 lines of code using 1st party dependencies only. I can then have a full prototype to demo by late afternoon, again having antagonized over exactly zero 3rd parties.

For me, the performance numbers aren’t just about speed while in production. It’s also about speed to production. Having the confidence that it’s almost certainly going to be fast enough by default keeps me from worrying about optimizing random bullshit throughout.

I still haven’t seen anything that comes remotely close to the combination of speed and stability offered here. I do some pretty nasty things with the runtime and it just copes. GC seems like pure magic now too. I continue to avoid things like LOH allocations with streams, but I don’t worry about it like I used to in the 4.x days.

Post reply on HN