Live data from Hacker News

.NET 10

devblogs.microsoft.com

431–440 of 605 posts

Re: .NET 10

#431

Earlier quoted context omitted.

Any recommendation of good alternatives to Telerik? We've been using it for years, but I'm open to considering alternatives even though it doesn't cost me anything to pay for the license.

Depends on what layer of Telerik [0]. Honestly of late since I'm extra rusty on frontend I just get Copilot with Claude to help generate UI widgets since that's allowed. Before that, years ago, I just YOLOed with WebSharper and built composition helpers to make 'spartan but correct' UIs that could be prettied up with bootstrap if needed. That said, alas, Bolero (what replaced WebSharper) is F# specific rather than al…

We're planning on using Blazor, so any Blazor UI components that you recommend?

Re: .NET 10

#432

Earlier quoted context omitted.

I'm not sure it is more powerful but it might be more ergonomic. The strange part about both (today - it made sense 20 years ago) is the whole bytecode thing. That should go away imo.

What’s wrong with bytecode? Using something abstract helps with porting between OSes and architectures. .NET supports compiling to native executables, but only a limited subset of projects is supported, because reflection is not available in native AoT mode.

I think cross compilation has gotten a lot better so there is basically no need for it today. Obviously nothing is for free and would be hard for .NET to completely get rid of it at this point but I don't think a greenfield project would take the bytecode approach. Bytecode still makes sense in something like WASM as it is a sandboxed environment but otherwise skip the VM abstraction if you can imo.

Re: .NET 10

#433

Earlier quoted context omitted.

I will pile on that I don't use any commercial libraries in .NET at all. Ironically, I do purchase a commercial library for front-end JavaScript. I agree that the commercial library offerings seem much more "in your face" with .NET but I don't find the actual breadth and depth of the free and open source library situation to be that troubling. It certainly continues to get better every year. .NET is very "batteries i…

Every company should give developers $100 per year to donate to the open source project of their choosing. Right now the conditions are such that maintainers are incentivized to rug pull.

every company must pay enough to allow developer to donate from his own pocket (and each state to allow vat free donations without paper work).

Re: .NET 10

#434

Earlier quoted context omitted.

Start-ups should strongly consider F#. It's a force multiplier when you have a small team of strong developers.

Seeing that any startup is more likely than not to fail, why would I work for a company that is using a niche technology that isn’t going to be in demand when I look for my n+1 job?

How important is being a language expert in x vs all your other skills as a Software Engineer? My opinion is that "higher level" skills (like system design/architecture, product thinking/planning etc.) are so much more important than language minutia (outside of specialized fields).

If a business is turning away candidates because they "don't have n years of experience in x" that doesn't sound like a very dynamic/interesting place to work, it sounds like a code monkey job. AI is going to eat code monkey jobs.

Re: .NET 10

#435

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.

Unity C# is arguably its own thing.

The way you use C# is much different than anywhere else. The Unity implementation lags by a few versions. It’s an awesome language though

Re: .NET 10

#436

Earlier quoted context omitted.

Every company should give developers $100 per year to donate to the open source project of their choosing. Right now the conditions are such that maintainers are incentivized to rug pull.

every company must pay enough to allow developer to donate from his own pocket (and each state to allow vat free donations without paper work).

Surely you don't expect someonoe that uses a particular piece of software only during work to donate to that from their own salary.

Re: .NET 10

#437

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…

> C# has way to many features, it feels bloated

Could not agree more. Too many -- WAY too many -- "features" from Javascript and functional languages have been jammed into C#, and the language has suffered for it. Every time I see "var blah" in C# code I cringe at how lazy you must be to not use strong typing when declaring a variable.

Same goes for "astink / await". If you need asynchronous multi-threaded code, use the damned Thread Parallel Libraries that Microsoft provided over a decade ago. Being forced to have every damned thing you write in C# wrapped with astink is just one giant code smell.

Yes, I'm old. Thank ghod I'll be retiring very soon, because as far as I'm concerned the tooling and languages I've used over the past 50 years have taken one step forward and at least three steps back in the past five years...

Re: .NET 10

#438

Earlier quoted context omitted.

Every company should give developers $100 per year to donate to the open source project of their choosing. Right now the conditions are such that maintainers are incentivized to rug pull.

every company must pay enough to allow developer to donate from his own pocket (and each state to allow vat free donations without paper work).

One need to see how many developers are already getting paid enough and out of them how many actually donating to OSS projects.

AFAIK developers are full of excuses like "these trillion dollar companies need to pay fair share while my hundred thousand dollar salary in this big expensive city leaves me with nothing to donate.

Re: .NET 10

#439
post #436

Earlier quoted context omitted.

every company must pay enough to allow developer to donate from his own pocket (and each state to allow vat free donations without paper work).

Surely you don't expect someonoe that uses a particular piece of software only during work to donate to that from their own salary.

Obviously that'd be completely unheard of.

Re: .NET 10

#440

Earlier quoted context omitted.

Last I checked they stubbornly insisted on reinventing the wheel and ignoring everything in System.Runtime.Serialization so you had to redecorate everything with their new attributes. For example https://github.com/dotnet/runtime/issues/29975 . So we stuck with Newtonsoft for the time being.

There is a 3rd Party library for that now: https://github.com/zcsizmadia/ZCS.DataContractResolver I haven't tried it because it has generally seemed easiest to use the new attributes. Though a large part of that is the shift from the WCF-era "opt-in" approach of DataContract/DataMember [0] versus the "opt-out" JsonIgnore approach where most of the transition is deleting lines because JsonIgnore is the exception rathe…

For me it was less not really about the opt-in part (after all, Newtonsoft works the same way) and more about stupid things like setting a name (DataMember), Enums, and in fact opting out (IgnoreDataMember)

It's especially annoying in libraries because the consumer might not even be using System.Text.Json, but you have to pull in the library anyway to apply its own attributes if you want it to work right. Just an overall awful smell given the existence of first-class framework attributes to do the same thing to avoid just that problem

Case in point: https://github.com/dotnet/efcore/pull/28084/files

Post reply on HN