541–550 of 605 posts
Earlier quoted context omitted.
These same restrictions exist for Go, the Go team just decided that it was easier to never support these features to begin with which has its pros and cons.
Such as? For the ones I've actually needed from the C# AOT limitations list, you can use reflection and dynamic loading just fine in Golang, with static single-binary compilation and all.
Earlier quoted context omitted.
There's still a lot of folks who consider themselves .Net experts who don't know how to program with async/await, so knowing about a niche IDE (which I also exclusively use) is asking a lot for those people.
Rider might be a niche IDE. But ReSharper with Visual Studio was a mainstay for me from 2008-2020 when I was doing a lot of .Net
Earlier quoted context omitted.
AFAIK pinvoke (DllImport) works today just like it always has if you want to create FFI calls to C libraries. It's not windows only for sure.
That brings you back to managing memory though, C++/CLI having access to managed C# handles/references for GC'd objects (and finalization) would greatly simplify any memory management at the same time as having first class access to native libaries. Granted, one could probably build some of the machinery memory management in a simple way but it'd still need to be done and probably not be coherent with other native in…
Earlier quoted context omitted.
I really doubt you’re using .NET (it literally is named in the dotcom style and refers to the interNET) in embedded software. In an article about .Net its fair to talk primarily about creating APIs and other internet focused uses.
And you just deduct that from the name? Was .NET created with a focus on web? It seems to me like a generic application framework. ASP.NET is the web part, no?
Since I can’t presume the reader has equivalent experience, especially in HN, pointing to the name, which should be a good signifier of what something does (to be fair, MS really, really sucks at naming), is a good shorthand.
The real reason .Net isn’t good for embedded devices is because MS didn’t develop it for embedded devices. They’ve only added low level memory management in the past few years.
Until recently you couldn’t even create a fully statically compiled executable.
Earlier quoted context omitted.
And you just deduct that from the name? Was .NET created with a focus on web? It seems to me like a generic application framework. ASP.NET is the web part, no?
I didn’t deduce it from the name. I deduced it from over a decade experience working primarily with .Net. Since I can’t presume the reader has equivalent experience, especially in HN, pointing to the name, which should be a good signifier of what something does (to be fair, MS really, really sucks at naming), is a good shorthand. The real reason .Net isn’t good for embedded devices is because MS didn’t develop it for…
Earlier quoted context omitted.
> 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 b…
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 ha…
If you’re a new shop that is making decisions without looking into how the company that pretty much runs the platform you’re basing your future on has acted in the past decade (we’ll ignore how they’ve acted beyond that because then it’s a no brainer) then you’re doing yourself a disservice.
I see that you’ve narrowed the goal posts to just technical concerns, which is fair, but isn’t sufficient to make a decision about what technology to choose.
Especially in a field where you have a similar alternative in Java where the sponsoring company doesn’t have half as much control, as well as several fully open source alternatives.
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…
Why is EF regarded as such a good ORM? I've encountered countless bugs in different repos related to its stateful nature after many years in .NET. Personally I found it completely illogical for my ORM to maintain state. I just want it to hold my schema and build queries.
Although the EF team has made huge progress towards keeping your entities persistence-unaware, it's still not enough and eventually you wind up building your project in Entity Framework just as much as in C#.
Earlier quoted context omitted.
[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 ?
I couldn't possibly have intended my question as a straightforward request for information about something, now could I?
That would just be weirdy-weird, if people started asking each other questions for the purpose of receiving answers.
Thanks for answering though.
Earlier quoted context omitted.
I only partly agree with you... if you're talking a web api, then code generation can go a long way with an OpenAPI doc file.
Yea, but then the other end has to serialise the HTTP API stuf to a typed object on their end. It's a lot easier when you have a single shared library you can just NuGet into both sides, client and server and then use the same correctly typed PlayerDTO for both.
If I had to manually create a client, then I'd probably go back to WCF (CoreWCF) which, again makes it easy enough to publish a client. For WCF in particular, I used to have one project with all the interface definitions and a client-generator that would allow for an "easy" single connection string as opposed to the XML bloat that is typical for WCF defaults.
All the same, you can definitely generate strongly typed clients to OpenAPI, provided the interfaces are well defined in the doc/generator/api.