Live data from Hacker News

.NET 10

devblogs.microsoft.com

151–160 of 605 posts

Re: .NET 10

#151
post #2

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.

I really liked working with C#. I spent 15 years or so with it and found it very productive. But no; I don’t miss the culture of C# / Microsoft shops at all.

> culture of C# / Microsoft shops at al

What do you mean?

Re: .NET 10

#152
post #2

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.

C# is massive in (mobile) gaming because of Unity.

And when the front-end is C#, it only makes sense to do the backend in .NET too so you can share classes easily.

Re: .NET 10

#153

I've worked with .NET for over 10 years and we built our startup on top of it. Here are my thoughts: Pros: * Stability * Very decent standard library * Good balance between productivity and robustness * Great package management * Extremely easy to upgrade, so essentially free goodies (performance) every year or so Cons: * Very MSFT dominated (obviously) * Subpar tooling outside of Windows (I'm looking at you C# Dev K…

> * Culturally, it feels like .NET devs are less "passionate" about their work

Only in the "stove pipe industry" as we say here. Mobile gaming is massively C#-based for example and the people are really passionate about what they do.

And for a backend dev, the scale of stuff you get to work with is cool.

Re: .NET 10

#154
post #3

Earlier quoted context omitted.

Can only confirm that. Such a smooth platform overall for web and API development. We use it with several 100 devs on it and the choice never failed us, neither in technology or hiring. And it is not that we have .NET gurus or anything.

[flagged]

> Apropos, what do they do for fun?

Odd question, but as a .NET developer myself

Mountaineering, climbing, bouldering, going to gigs, playing pool, running, music festivals, gaming, photography, watching F1, watching NBA, eating out with friends...

I'm not sure what the point of the question was ?

Re: .NET 10

#155
post #2

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.

I think the key problem is that a large number of startups are shipping software in containers, and dotnet requiring a CLR is not particularly well-suited for containerization. It's like the old school Java JVM model. You have to ship a copy of the runtime with every container, and if you're doing proper microservices it's an awful lot of overhead.

Yes I'm aware MS makes it easy to build containers and even single executables, but languages that compile down to an ELF are pretty much a requirement once your deployments are over the 10k containers mark.

Re: .NET 10

#156
post #83

C# has the best ecosystem out there. I wish CPP development was as robust as C# development is

They are very different beasts.. What problems are you having with CPP that you're not with C# ? Funny enough a lot of the 'ecosystem' is on the back of cpp..

With C# (.NET) I can click on "install package" in my editor and within seconds it's downloaded and in my project.

With C++ it's a whole different thing.

Re: .NET 10

#157

Earlier quoted context omitted.

> Do you also make everyone drive the same vehicle Good analogy. If, say, your organisation maintains a fleet of cars - it needs to keep them on the road, get them serviced, replace parts, refresh individual cars regularly etc. How many different makes and models do you support? A small org might decide that it only makes sense to support one. A larger org might have the resources for 3 or 4, so that there is 1 or 2…

But different tasks require cars, other tasks require trucks, vans, bicycles, motorcycles..

I think that question is more "how many different makes of van can your delivery company afford to maintain?"

Which is an analogy for "how many different programming languages for the same task of serving a web api can you company afford to support?"

The majority of programming languages (c# definitely included!) are "general purpose", i.e. they can be used well enough for almost all tasks. They're not so different as a truck vs. a bicycle.

The issue is not so much "we need firmware in Rust and statistical analysis in R" - that's fair! The issue is more, as others have said, web apps or similar in multiple equivalent languages. This is an overhead. If you take on that overhead, recognise that 1) it has definite drawbacks and 2) for mundane tasks, the advantages aren't large. and 3) chances are your organisation is like most orgs - you don't do all of firmware, statistical analysis and web apps, in house.

Re: .NET 10

#158
post #130

Earlier quoted context omitted.

But different tasks require cars, other tasks require trucks, vans, bicycles, motorcycles..

Yeah, .NET is a truck and React is a bicycle. Nobody sad you can't use different tools for different tasks. I'm saying use one tool for one task. One type of truck. One type of bicycle. Maybe some companies need both a small and a large truck. That's all fine as long as you actually need it. Just don't let every dev choose their own because you're gonna have a hell of a time maintaining that fleet.

> Just don't let every dev choose their own because you're gonna have a hell of a time maintaining that fleet.

Yes, this.

> I'm saying use one tool for one task.

I saw an article ages ago arguing that the number of supported languages should scale with the size of the organisation. Which makes sense to me. The threshold was larger than we might expect though, it was something large like "one fully supported language per 500 devs". In other words, small-medium orgs will have a better time supporting 1 language only.

Re: .NET 10

#159

Earlier quoted context omitted.

Where is this worry coming from? (I'm curious, not shutting it down) I might be biased from having worked with production F#, but it feels more like functional is making its way into C#, as the general industry sees value in functional principles. So F# feels like its more here to stay?

Doesn't it feel like the functional stuff is coming into C# so that F# can disappear? Pure speculation on my part but doesn't seem unreasonable.

C# has incomplete and often compromised versions of the constructs F# mostly took from OCaml, and as you extend those exhaustive guarantees towards formal verification you bump into F*.

C#s adoption of language features shows their utility but they’re not a replacement, per se. Without a clear functional answer in certain language and parallel computing scenarios MS would be ignored. Scala and Kotlin are comparable answers to comparable pressures on the JVM, and even keeping pace there with new and exciting tools/libraries requires some proper functional representation on the .Net platform.

F# will disappear when/if those other languages do, and already has lots of what C# is chasing with a more elegant syntax. It inherits VM and project improvements from C#, so the biggest threat to long term investment is something like the crippling changes made to FSharp Interactive (FSI), during the .Net Core transition. Otherwise it seems to be in a safe place for the foreseeable future.

Re: .NET 10

#160
post #2

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.

I think the key problem is that a large number of startups are shipping software in containers, and dotnet requiring a CLR is not particularly well-suited for containerization. It's like the old school Java JVM model. You have to ship a copy of the runtime with every container, and if you're doing proper microservices it's an awful lot of overhead. Yes I'm aware MS makes it easy to build containers and even single ex…

Exactly this point.

Go and Rust produce native binaries, I wish C# had an official native compiler without the big runtime needs of .Net.

Post reply on HN