37 ms·

.NET Myths Dispelled

• wrs 5y ago
  I agree .NET is fantastic technology. I think a lot of the hesitancy in adopting it is from the historical churn described in the article. It’s normal for languages/runtimes to have churn in their features, performance, and library. .NET has that in spades, plus continual churn in its very reason for existence. The corporate and cultural forces behind .NET may be aligned with your situation right now, but five years from now, who knows? There’s not yet historical evidence that it will remain stable.
  • bennysomething 5y ago
    The switch from full fat .nets support life cycle to the current dot net cores totally confusing life cycle is currently pissing me off and the higher ups in my firm. Which should be worry for ms. I want stability , not breaking changes.
    • thrower123 5y ago
      Yes, this. We will see how well support for the supposedly LTS DotNet 6 actually is long term... I'm not a great fan of how the whole dotnet open source ecosystem has sped up to monthly and biweekly releases. Official Microsoft packages are some of the worst.
      • HideousKojima 5y ago
        It's supported for 3 years after release. I think ut ought to be longer but it's really not that confusing: a release every year, and every other release is LTS (3 years support).
        • runevault 5y ago
          My one concern (as someone who is still supporting Framework code at the day job) is if they do major backwards compat breaks again. We still haven't decided our path forward to move our web code that uses various Libraries that were not ported.
    • hackerfromthefu 5y ago
      Yeah agreed, the incredibly long term stability and backward compatibility was a real strength of the .NET framework. But the industry as a whole has moved to fast releases and MS responded to keep up with the industry. This includes faster releases, and shorter support timeframes.
  • spaetzleesser 5y ago
    That’s the problem. They don’t have a steady design approach. They do something here, something there, then abandon the first, then go back to it. Desktop is a complete mess. Core looks quite good but who knows what they will do in a few years?
• EMM_386 5y ago
  > (Note: there’s some debate on whether it’s 20 or 21 years, but Microsoft’s Professional Developers Conference in October, 2001 definitely already referenced .NET in production systems) I can clear this one up. I was lead on a .Net production system launched in August, 2001. It's 21 years.
  • Yoric 5y ago
    Out of curiosity, did you also work on EMM386, as your username implies?
    • 300bps 5y ago
      Now we just need commentary from a user named himem.sys and we’ll be all set.
      • petespeed 5y ago
        smartdisk anyone?
        • hackerfromthefu 5y ago
          dumb terminal wants an ack
      • DeathArrow 5y ago
        command.com sends you best regards.
  • hackerfromthefu 5y ago
    Second this was writing production .NET in 2001, and betas were available in 2000. ASP.NET was originally named ASP Plus in the beta!
• DoctorOW 5y ago
  > Myth 2: It’s Slower than Node/Python/Go/Rust This feels disingenuous. The author uses this heading for proof that ASP.net performs faster than similar frameworks in Node/Python. I could be convinced C# is faster than Go, but absolutely not for Rust. The simplicity modern C# provides (look at those code samples) comes at the cost of runtime performance optimizations.
  • pharmakom 5y ago
    Benchmarks would be required to prove it, but I could actually see .NET outperforming Rust in a few scenarios. First, C# can be written in a way that stack allocates almost everything (much like Rust) and second, the runtime information and JIT compilation may allow it to make better optimisations.
    • Yoric 5y ago
      I'm a big Rust fan but I fully expect that C# can beat Rust in some benchmarks and actually in some useful scenarios. However, claiming outright that .Net outperforms Rust feels like an apple-to-petticoat comparison.
    • DoctorOW 5y ago
      Only if you're including compile time in the benchmarks. Binary to binary, JIT is a great example of Rust having a compile-time optimization that .NET implements at runtime.
      • Yoric 5y ago
        Well, some optimizations can only be implemented at runtime, so comparing Rust and C# without knowing the actual scenario doesn't seem to make much sense.
      • woodruffw 5y ago
        Optimizing compilers and JITs are difficult to compare directly: JITs have optimization pressures (e.g., selecting instructions/register slots as rapidly as possible) that AOT compilers don't (and vice versa), and (similarly) tend to have simpler IRs. In general, even the best JIT is going to underperform an AOT optimizing compiler for those reasons. Microbenchmarks (and compiler quality) will always vary, but the macro picture is difficult to change.
• spaetzleesser 5y ago
  I have worked with .NET for a long time and recently did some work with Java, node and python. .NET has a lot going for it but i feel MS is making things more complicated than they have to be. When I need to achieve something a little off the beaten path in the non .NET technologies this is often pretty straightforward to achieve whereas in .NET I have to find some obscure interface and overrides to implement and then deal with weird side effects. I think .NET has become too big for its own good to be maintained by one party. The documentation also has a lot of volume but almost no structure. When .NET started out it was pretty coherent but in the last few years it felt very disjointed without a central design philosophy. Don’t even mention desktop development which is a complete mess since Windows 8. Maybe I am too negative on .NET but personally find the open source alternatives easier to work with and more fun.
  • R0b0t1 5y ago
    The .NET frameworks (blazor, etc) are too complicated. Peak FizzBuzzEnterpriseEdition there. The interop layer than you have to go through to do a lot of stuff is actually quite tame. It just needs more time on Linux.
    • tester756 5y ago
      >The interop layer than you have to go through to do a lot of stuff is actually quite tame. It just needs more time on Linux. What do you mean? I have software on prod on Linux for years and the only problem I had was lack of some fonts installed that made some problem when it comes to pdf generation
      • R0b0t1 5y ago
        Binding to C/C++ libraries or other system libraries is not something that's well documented, officially. On Windows there's a lot of 3rd party effort that is easily searchable. But for a long time the interop layer was not (and still may not be?) working on Linux. The first iterations of .NET were just for webapps. You could only work with and call .NET code, the only functions provided were basic IO and network.
• johndfsgdgdfg 5y ago
  .NET is an amazing tech built by MS. I wish more people would use .NET ecosystem instead of Go, which is pushed by Google so Google can make more money.
  • steve_taylor 5y ago
    How much does Google charge for Go?
    • DoctorOW 5y ago
      I disagree with the point that Go is a big money maker for Google. I assume the implication is that Go helps make sales for Google Cloud the same way .Net acceptance leads to Azure sales. That said, in my experience this isn't true. Some of the biggest adopters of Go (Uber, Netflix, Twitch) are AWS based. The real profitable part of Go for Google is the scalability and efficiency of the language for Google projects but that's not a very effective argument to switch away from Go.
  • phillipcarter 5y ago
    .NET exists because it is used by Microsoft to make Microsoft more money. That's literally what a platform play is. What is bad about Google doing this with Go?
  • hughrr 5y ago
    I have used both from day one. I prefer Go. 900% less faffery with it.
  • bayindirh 5y ago
    > .NET is an amazing tech built by MS. I wish more people would use .NET ecosystem instead of Go... After years of witnessing or being on the receiving end of the things Microsoft did, I'd rather not develop with .NET. Same goes for Google's Go. Rather I'd happily use C++ / Python / Rust / Java / Perl, and never look back. I think it's bitter to be associated with acts done to undermine and stifle competition for whatever it takes rather than being a tech company known with good products. Yes, I pay for an Office license and like their hardware, but I can't forget what they've done over the years.
• oconnor663 5y ago
  > Myth 2: It’s Slower than Node/Python/Go/Rust I guess apples-to-apples benchmarks are so hard to agree on that any statement of the form "A is slower than B" is always to some degree a myth. If that's the author's position, fair enough. But if we actually want to make comparisons, "C# is faster than Rust" is a bold claim.
  • Yoric 5y ago
    ...especially when in two out of the author's three screen captures, C# is actually shown as slower than Rust. I didn't spent time to investigate further because I feel that this headline is not really useful in the first place.
  • phillipcarter 5y ago
    The reason why it's a myth worth dispelling now is that The (legacy) .NET Framework, which used to be ".NET" back in the day, actually was hilariously slow for any kind of web or networking work. It had decent CPU crunching power, but also only on Windows machines. Comparisons of benchmarks with C# vs. Rust or whatever are unproductive and it's a shame that the article focuses on that. The reality is that you can write C# or F# code today, focus on solving your problem instead of performance, and have it handle a production workload admirably well. That used to not be true circa ~2010. Thankfully it is true now :)
    • bastardoperator 5y ago
      This is my experience with dotnet. Considerable amount of legacy code coupled with different web frameworks along the way. While the app was slow, I found the amount of time it took to make changes to be the unbearable part, mostly a whack a mole situation. Maybe I worked with some bad developers, but they all acted as if dotnet was the best thing ever with constant mentions of dependency injection and blaming the GAC for problems they clearly created..
      • nightski 5y ago
        All ecosystems have churn. While .NET has had a fair share of churn, to me it seems in line with any other platform that has not only survived but thrived for this long.
• cglan 5y ago
  Gonna be honest, .NET seems to have a weird cult following on here and Reddit but I find the naming to be absolutely atrocious and I hate developing with it. Everything is .Net including .net classic but not everything is compatible making documentation a huge pain to find. It’s also ridiculously over complicated and enterprisy with a lot of heavy weight boilerplate that reminds me of Java. It also copies a lot of the mistakes of the spring framework where you’ll have side effects or code paths that occur that aren’t really able to be found with a debugger. The language itself is fine but the framework around it is just repeating all the same mistakes of everything else One of the reasons I love go is that everything seems to be explicit. Notice something occurring? Well chances are you can set a breakpoint and trace what’s happening
  • tester756 5y ago
    >It’s also ridiculously over complicated and enterprisy What does it mean? dependency injection?
    • radicalbyte 5y ago
      There are some older libraries which are horrible enterprise-ware: WCF (Windows Communication Foundation, think SOAP) and older Entity Frameworks in particular. From the tone of the OP I would assume that things such as encouraging good engineering practises such as good interface design and using appropriately sized units of code are also "problems" with .Net. You hear that a lot from inexperienced developers. The thing is - the modern framework is far nicer and has largely avoided the problem. Even to the point that I prefer occasionally having to deal with some of the ugly enterprise libraries to the constant hunting down of broken dependencies, vague runtime bugs or massive framework churn you see in the Python/Javascript world. Or having an overly verbose and ugly language like Go or Java.
      • hackerfromthefu 5y ago
        Awww gee .. enterprisey used that way just seem to mean 'has features i don't need right now'. WCF had problems with configuration complexity, but that was because it was ambitious! It had so many capabilities and provided a uniform configuration interface for all of them, so it was complex. .NET was built as a platform to allow ALL sorts of programming, not just beginners level - therefore it comes with a degree of complexity. I've come to appreciate that mostly people calling it 'too complex' or 'enterprisey' just haven't understood why someone else needs the features they don't understand yet.
• renox 5y ago
  So this article claims that .Net is portable, what about GUIs? I doubt very much that this is the case..
  • grokys 5y ago
    https://github.com/AvaloniaUI/Avalonia https://github.com/AvaloniaUI/Avalonia
  • pelorat 5y ago
    GUI are not part of NET5 and NET6
  • DeathArrow 5y ago
    .NET MAUI, the cross platform toolkit, will going to be released in a few days. https://docs.microsoft.com/en-us/dotnet/maui/what-is-maui https://docs.microsoft.com/en-us/dotnet/maui/what-is-maui
• stakkur 5y ago
  The author makes a few good points (mostly about performance), but the 'myths' about open source friendly, enterprise development, and cost are disingenuous at best, and just plain wrong at worst. I work in a large corporate environment, and .NET is expensive. Nobody just 'uses the Community Edition', because there are pre-established licensing arrangements and costs. I've seen the costs. .NET, whether it's good or not, is slowly going the way of the dodo. What keeps it around is the corporate lock-in they've established for the Microsoft stack, and that's a hard thing to crack.
  • neonsunset 5y ago
    Senior SE working in a company which has its services built almost exclusively in .NET. C#/.NET is not a major contributor to our expenses - the language of choice could've been Go, Rust, Python or, god forbid, Java - just replace Rider or VS Code with IntelliJ or other tooling and use a different base image when deploying to k8s. If you use MSFT products you might be incentivised to use C#. However, there is no incentive to not go C# when you use something else. I also found OSS process for the core libraries and runtime to be very inclusive - everyone can contribute as long as the change produces measurable and meaningful improvement serving interests of a wider audience.
  • hackerfromthefu 5y ago
    SQL server is expensive, and windows, office etc can add up. Postgres works fine in from .NET. As for Visual Studio, Professional is all you would need and it's not too expensive, I saw $45 a month mentioned, which is around $2 a working day. In my opinion, it's actually kind of a good thing that it's not the cheapest option, because it tends to avoid the bottom feeding employers who are more likely to scam their employees.
• formerly_proven 5y ago
  In terms of language C# always seemed to me like it was a language that expects you to use a (the) IDE, much like Delphi. Which is really unfortunate in my opinion, because I usually read code outside an IDE and also spend more time strictly reading code than writing.
  • cm2187 5y ago
    Don't you want an IDE to navigate through the code (go to definition/implementation, find all references, etc)?
    • javcasas 5y ago
      Not sure about you, but I prefer environments that can be navigated without IDEs so that when I add IDEs and tools I become an overpowered developer; instead of having to add the best tools available just to become an average developer.
      • manigandham 5y ago
        All environments can be navigated without IDEs. You can write code in notepad, it's just text after all. The tools don't make the developer, and the truly expert developers focus on productivity and results, regardless of environments.
        • javcasas 5y ago
          Yup, all environments can be navigated with notepad, but some environments are easier to navigate than others. For example, Yaml vs unindented Json. They represent the same, yet in one I can see what's going on with the indentation, and in the other I have to go hunting for closing braces.
  • blaxis 5y ago
    doesn't help that the delphi IDE isn't very good
• alexklark 5y ago
  Author should submit it to ms propaganda/evangelist department to get a MVP medal for best bs of the month. Of course MS bs regarding .NOT is nothing new. It was windows only for 21 years and marketed as portable/high speed/modern/backward compartible all that time. All that time it was a cherry picked lie. For the last 6 years they not even mange to offer GUI library. Try to use Winforms. You can’t? Too bad, linux is just for servers anyway, right? Go get Xamarin trash and suffer. “We are on journey, busy with our foundations/pr so fk off.” The right answer was not changed for 10 years: - never use ms tech for web, or you be vendor locked and ripped off - ms technologies in core not changed since 00s, it is same old st in a layers of chocolate. As soon as you get inside, you puke. - never trust ms or you be vendor locked and end up with inferior legacy technologies, without reach to support and with huge tech debt and eventually need to just throw away everything you build - remember, facebook and google not using ms, your grandma do
  • achtung82 5y ago
    If the language and framework has been changing isnt it a good idea to inform about these things that used to be true but no longer is. "never use ms tech for web, or you be vendor locked and ripped off" How exactly do you mean this, .Net can be run on most platforms. Or could it be that you didnt read the article since you assumed it was propaganda?
    • omginternets 5y ago
      The charitable interpretation of the parent post is that the .NET team has lost all credibility, and that one should not trust them to make developer-friendly decisions. I don't know whether or not that statement is true, but I think this is the point worth discussing.
      • tester756 5y ago
        >but I think this is the point worth discussing. then somebody has to say some some specific stuff instead of "ms will lock you"
• FridgeSeal 5y ago
  > .NET isn’t open source friendly The language runtime might technically be open source, but it’s got a huge number of closed-source packages and the ecosystem appears to be only begrudgingly open source. > It’s slower than Node/Python/Go/Rust One of 2 of these things, aren’t like the others. I’d believe modern .net can outpace Python, but matching or outpacing Rust is something I’d have a hard time believing, especially in the “vast majority of code” sense-I’m aware that .net can be written to stack allocate everything. I’m also aware that basically no .net code I’ve ever seen in business world has ever done that (precluding games here, because I’ve not worked with them). > It’s for boomer enterprise development Yes. Uncharitable presentation and framing, but yes. Every single place I’ve worked at that has used .Net has had the same attitude and approach to solving problems and writing code. Use Kafka for our events like every other company in industry? Nah, use some bizarre MS thing that nobody outside of .Net has heard of or can use. Use websockees or SSE? Nah, use some bizarre .Net version instead. Use Postgres because it’s more than good enough and other teams might need to use the database? Nah MSSQL, and all the tables are named and optimised according to EntityFramework and if you have to suffer through ODBC issues that’s a you problem! Never mind the obtuse naming and the dogged insistence on dependency injection at every possible turn. Am I not a fan of .Net? Correct. Is it because every time I’ve had to touch it, it’s a painful and frustrating experience.
  • radicalbyte 5y ago
    You know that Rx in .Net kind of inspired all of the popular reactive libraries/frameworks, right? Other than that: if you go to a .Net shop who want Microsoft Certified Developers and you expect anything than low quality-stay-on-the-Enterprise-support-contract-rails then that's the problem. > Nah MSSQL, and all the tables are named and optimised according to EntityFramework and if you have to suffer through ODBC issues that’s a you problem! That's not in any way true - it's an ORM and it can handle any database naming scheme you happen to have. I still wouldn't use it - ORMs in general are a bad idea outside of a couple of use-cases (i.e. CRUD-heavy systems).
  • Salgat 5y ago
    Look up the Microsoft Community/Open Specification Promise and their patent promise https://github.com/dotnet/runtime/blob/main/PATENTS.TXT https://github.com/dotnet/runtime/blob/main/PATENTS.TXT .NET Core is open source, free, and comes with the guarantee of no litigation from Microsoft. As far as the ecosystem, it fully embraces open source too. At my company, all .net libraries we use are free and open (AWS, Consul, Elasticsearch, EventStore, Kubernetes, etc).
• ramesh31 5y ago
  Unfortunately Nuget package management is abysmal, and a development environment lives and dies by that nowadays. There's also the legacy reliance on XML that shows itself everywhere in C# development. It's easy to forget that the reason Node took off exponentially when it did is not really because it was that great itself, but because NPM (and its' small package philosophy, in combination with JSON based config) was a bit of a revolution in package management that led to network effects of adoption.
  • tester756 5y ago
    >Unfortunately Nuget package management is abysmal, and a development environment lives and dies by that nowadays. are you saying that there should be more packages in nuget? >There's also the legacy reliance on XML. you mean project file? or WPF's XAML?
    • ramesh31 5y ago
      >you mean project file? or WPF's XAML? Those, and many other things. XML is just an embedded idiomatic part of the language. There's nothing really wrong with XML, but the web runs on JSON now. And all other modern languages (Go, Rust, NodeJS, etc.) are built with that in mind first.
      • tester756 5y ago
        Well, .NET has Newtonsoft Json which makes working with Jsons pretty easy, the built-in System.Text.Json probably works well too (I didnt use it directly yet) When it comes to XAML, then XML-like structure is way better for describing interfaces than Json After all, the web is built on HTML which's kind of similar.
        • smackeyacky 5y ago
          System.Text.Json is a handy improvement over the Newtonsoft stuff. Faster and has great support for annotating your classes to do things like remove properties that aren't required when you send them externally. A bit painful to move across but well worth it.
• ourmandave 5y ago
  The actual title is: 6 .NET Myths Dispelled — Celebrating 21 Years of .NET And they forgot 2... Myth 7: The .NET branding dept sucks. Myth 8: The .NET desktop strategy has sucked since Build 2011. Oh wait, both of those are still true.
  • gfody 5y ago
    > The .NET desktop strategy has sucked since Build 2011 only if you need cross platform. WPF is pretty good and WinForms still ain't broken. oh you said strategy .. I think the strategy is wait for something to get popular, maybe something will happen with BlazorWebView
    • ourmandave 5y ago
      Winforms is my 9-to-5. But hHow many new official-way-to-do apps have there been? I've lost count. Actually, what's the current one(s)?
    • foepys 5y ago
      Do not start new projects on WPF. WPF is considered done, meaning no bug fixes whatsoever. There is nobody working on it, not a single person.
      • int_19h 5y ago
        WPF is still used heavily in Visual Studio.
      • lloydatkinson 5y ago
        This is a ridiculous piece of FUD.
        • foepys 5y ago
          You say that it's "FUD" but why is point 1 of the roadmap still "Incorporating .NET Framework servicing fixes into .NET Core 3.1, .NET 5 and .NET 6"? It has said this for years now. Nearly all commits are bot commits updating dependencies, some are to keep the CI process up to date, and all others only fix typos or other strings. 2 months ago somebody fixed a few things but no activity since then. Microsoft is trying to transition WPF into a community project as indicated by the current roadmap and I don't see this meaning anything different that them abandoning WPF for good.
• lucidone 5y ago
  I used .NET Core for a backend API relatively recently (3.1) with no background in .NET prior (mostly javascript/typescript, php, and ruby). I found it incredibly productive and to be an enjoyable developer experience. Entity framework is one of the best ORMs I've ever worked with. Solutions and projects took some getting used to but I like it in retrospect. I now use IntelliJ products as a consequence of having used Rider for that project (developing on a mac) and enjoying the experience. C# as a language is now one of my favourites. I find it hard to convince colleagues and peers to give it a chance (mostly ruby and javascript devs) which is a shame.
  • manigandham 5y ago
    > "incredibly productive" That's the best summary of the .NET stack, unfortunately it requires first-hand experience to figure it out.
    • oneplane 5y ago
      Same goes for Elixir and Scala, it's mostly because from an outside-in view it really hasn't changed much (when 'looking' at the language and framework in question). Technical changes are relatively easy, cultural changes.. not so much.
    • dnndev 5y ago
      It depends what your trying to do and anything worth using has some learning curve. Hardly something I would say is a downside of .net
      • juniordevv 5y ago
        In rails I can drop into console and play with APIs in repl. What’s the .net equivalent?
        • detaro 5y ago
          .NET languages have REPLs too.
• skeeter2020 5y ago
  Most of these are strawman setups, except for #6 (Boomer code) which is not a myth but a truth. I've spent a lot of years in the MS ecosystem and despite their attempt to entice many younger developers to .NET (and making the world more complex as a result) it's grey-haired devs like myself that have stayed loyal.
  • TillE 5y ago
    Zillions of young nerds out there are writing Unity games.
• jmull 5y ago
  I don’t have any problem with the idea that .net is a fast, capable, modern language suitable for many purposes. But I had to laugh at their example that “crushes” (why the embarrassing phrasing?) node.js. Why, returning plain text is as simple as declaring a private “PlainTextActionResult” class that implements the IActionResult and the IActionResult method ExecuteResultAsync, creates an HttpContext.Result, sets the status code symbolically and the content type textually, manually calculates the content length, and returns an asyc Task object! “Crushed it!” (with Enterprise-y code).
  • Merad 5y ago
    Whoever wrote that code either doesn't know the framework or perhaps is doing a custom implementation for some performance optimization. All you need to do to return a plain text response from an action method is `return Content("text goes here")`
  • kumarvvr 5y ago
    Try building a serious app with node. Its a pain to build and maintain. In .net, you can have teams of people working on business logic DLLs, Data Access DLLs and have a few person team tie them all up in a web app. I hardly think that is possible in node. All the enterprisey things in .NET are a god send in a 10k loc web app with solid debug and profiling capabilities. And all that will save you time and money. So many developers try to compare the structures of different stacks based on "hello worlds", whereas, the actual issues crop up in actual web development.
    • karottenreibe 5y ago
      Why do you believe the same thing can't be achieved with packages in node that you feel is so useful for multi team orgs in your DLL scenario?
    • jmull 5y ago
      Well, I have. With both .net and nodejs. They both do the job fine (you mention 10K LOC, but I’m not sure that you mean because that’s still comfortably tiny — a one-person app at most, where pretty much anything works.) In my experience they both scale just fine. Your limiting factors are much more defined by your app architecture, dev group politics (as reflected in response to management), and what I’ll call your dev workflow process (how many minutes is it, between when you as a dev make a final, correct source change, and the change makes it far enough that another person can see and evaluate it in the software?)
• hajile 5y ago
  What's not a myth is that they got rid of their JSON configuration in .NET Core in order to keep their XML abomination. I really wish they'd revisit that and at least allow both options.
  • e-master 5y ago
    At first I thought that to be a mistake also, but I gotta admit I don’t mind at all using xml in the new sdk-style csproj files now, it certainly made upgrading legacy project files slightly simpler.
  • aliswe 5y ago
    the "abomination" is like 1% of its former size, i dont really understand what merits this name...
  • manigandham 5y ago
    Modern .NET csproj/sln files are a few lines at most. As config files grow, XML is far better than JSON because it's much more structured (even if it has more verbosity). Do you have a problem editing HTML? Because that's quite literally XML.
• GartzenDeHaes 5y ago
  At a technical level, one of the biggest myths is that it doesn't require, or doesn't support, memory management. For high volume server-side development, not using "using" will cause resource and performance problems.
  • aliswe 5y ago
    Not using "using" is an error tbh. But I think its wrong to call it memory management tbh, its about disposing anything NOT memory related (ie normal objects) like filestreams, sockets, custom things ...
    • metaltyphoon 5y ago
      It is memory management in a way. “Using” is releasing unmannaged memory most of the time.
      • int_19h 5y ago
        It's releasing OS handles most of the time, actually. And you'll run out of those much faster than out of memory.
• binarynate 5y ago
  Some of the negative comments here illustrate how some cling strongly to old biases, despite that a lot has changed in .NET (and in Microsoft more broadly) in the past decade. I'm still bullish on .NET because I see the value it provides first hand and see the awesome things that teens and newcomers are making over in https://reddit.com/r/Unity3D https://reddit.com/r/Unity3D . If there's one thing I wish I could convey to those who troll .NET, it's that no language is perfect, and each has its own unique strengths and weaknesses. It's not a zero sum game, and I think we all benefit from having different high-quality tools to choose from.
  • deleted 5y ago
    [deleted]
• th3h4mm3r 5y ago
  No, thank you.
  • deleted 5y ago
    [deleted]
• parkingrift 5y ago
  Hard disagree on the tooling costs. VS Enterprise is $250/month per seat. VS Code is way too limited for most .Net projects. …and that’s if you can even figure out how to manage your VS licensing within the deep abomination that is the MS sign-on and management. Most frustrating experience of my life entire professional life was dealing with O365, Visual Studio, and Azure subscriptions.
  • joe_guy 5y ago
    $250 is several hours of most developers pay. If it saves them any amount of time it's incredibly easy to justify. It's also rare to need what Enterprise has that Professional does not.
    • cerved 5y ago
      It doesn't. It wastes time and it's only used because your stack is built on EF6 database first and it's the only method to update your ORM entities
      • joe_guy 5y ago
        That's an extremely aggressive response for an entirely subjective viewpoint.
  • rr808 5y ago
    Rider is $349/year
    • runevault 5y ago
      Note this is the organization price. If you are buying for individual it is $149 or you can get the full suite for $249 (going down $50/year for years 2 and then 3+ stays at $149)
    • cerved 5y ago
      Rider is also a good piece of software. VS is garbage
• naoqj 5y ago
  • deleted 5y ago
    [deleted]
• oneplane 5y ago
  After giving the article a few reads it seems that the points are a bit cherry-picked... > Myth 1: .NET is for Windows It depends what you mean by .NET, doesn't it? In-ecosystem a .NET-enjoyer might be thinking about .NET Core, and thinking about building a nice new web API service. But besides that specific case, it still is all just Windows. And I'm not talking about API and ABI dependencies or hard-coded win32 assumptions, I'm talking about making a first-party GUI Desktop application or an application that works together with the OS, natively. And no, until MS dogfoods MAUI in production for a few years, that isn't the silver lining it seems to be (just like SwiftUI doesn't help at all if you're trying to escape NIBs and XIBs - same problems, different flavour). None of this should come as a surprise, Microsoft does after all still make a separation between 'free' stuff with C# and 'making money' with C#, where the latter is designed as a funnel towards buying something from Microsoft and making sure that it works with Microsoft's stuff (which is: Windows). This isn't a "haha .NET bad" thing, it's just a reality. The same goes for the .NET Foundation. It's essentially still just a shell, controlled entirely by Microsoft. Again, no surprise, but a bit dishonest at the very least. > Myth 2: It’s Slower than Node/Python/Go/Rust A few examples where it can be marginally different (faster and slower) but nothing extreme that would make it 'the best choice'. This whole "my language is better because performance metric X" thing might make sense if we're talking orders of magnitude, but we're not (mostly). Also, the bust points out bandwidth, but here is a surprise: bandwidth matters a lot less when it's not the amount of bytes you need to have flowing, but the latency at which the flow starts. > Myth 3: It’s a Legacy Platform It's not a legacy platform because you can build new things with it, it's a legacy platform because everything .NET that is already out there is largely legacy. Ironically, this can work out both ways, since well-written C programs can both be legacy and current at the same time. But for .NET, the problem lies with the rather recent pseudo-community opening up and not with only the very last most recent .NET Core release. > Myth 4: The Tooling is Expensive It is still expensive because the good tools are always expensive. That is not always a bad thing, if you make money, good tools can be worth their money. But pretending that all tools are the same and therefore the expensive ones don't count as "the tooling is expensive" is not really honest. Again, if you were to make a new project, in isolation, targeting building a self-contained CLI application or API server, you can do that with any text editor. But we're not really exclusively writing code for those, are we? (more on this later) > Myth 5: .NET Isn’t Open Source Friendly It's looking friendly but is also very dishonest. See earlier text about the foundation (and earlier posts in HN about the same issue). > Myth 6: It’s for Boomer Enterprise Development Not sure how this myth came to be. Existing long-lived applications definitely start entering the Boomer Enterprise Development zone, but that applies to pretty much any language and framework that's been around for a while. See rant about greenfield development and the reality of existing software above. Now, don't get me wrong, none of this makes .NET explicitly good or bad, but it does smell like a "we are really good, why don't you love us" type of Myth-post. When you start a new, non-Desktop, non-GUI application with proven technologies, then .NET works fine, just like Go, Python, NodeJS and even Java. But in that same sentence, a problem pops up: it always irks me personally that you apparently can't say C# on its own. It's always C#, with a .NET Framework, and a .NET Compiler, and a .NET Runtime. None of that is really swappable, you can't just say "I want to use a different framework" or "I'd like to compile to a native binary". The "one true solution" doesn't exist. A compiler that wants you do use its one and only project management structure seems wrong to me. Perhaps nobody wants that anymore, or the concept of monoculture being generally bad hasn't landed everywhere yet, but when thinking about a concept of a language, a framework, a compiler and a runtime becomes muddy and developers generally cannot detect a distinction anymore, that just smells enterprise to me. And not in a good way.
• NGRhodes 5y ago
  Early ASP.net was a fairly awful experience for the web stuff I did. ASP.net 1 and it was missing a lot of basic functionality that came in .net 2 and was not compatible with the stuff we had created in .net 1 to fill the gaps. Visual Studio was fragile, it would work great one day/week, then one system update or one change to a project setting would be enough to make it crawl or crash. And to top it off we had the burden is having to use visual source safe as well. Then add the need to have a local IIS and SQL Server, required a seriously beefy spec desktop to run. The ASP.net viewstate was geared up for single page CRUD applications and trying to do any kind of multiple website required serious abuse of session storage (DB backed and hideously slow to serialise and unserialise each time) to maintain state across pages. We created a handful of helpers to utilise querystrings efficiently. ASP form validators often suffered edge case bugs, the javascript validations often fail and hard to debug, server side validation added an extra layer of slowness and trying to juggle everything to load, save, validate, update the html between the layers of state management (application, session, view etc) lead to some horribly complex code to work around the opaque-ness of asp.net state management. Entity framework was welcomed, but it was almost unusable to start with it as suffered critical inconstancies between 32bit and 64bit machines in the way it handled the length of integers and stored them in the EF defined databases. But it was not all terrible, C# was a pleasant language, polymorphism useful, unit testing (nunit) worked well, Team Foundation Server is worth a mention for being a zillion times better than Source Safe. Linq was a sane abstraction. By 2007/2008 MVC looked promising and Visual Studio Pro ran quite reasonable on current spec machines and the things around .net such as SQL Server and IIS were far more pleasant to install and work with on desktop machines. PS, Let's not forget the MSDN library, documentation and software on CD/DVD and having to strategize what you can fit on your HDD and what you will load from disk.
• cjvirtucio 5y ago
  I've worked with .NET in the past few years and I've been pretty happy with it. The syntactic sugar is great, and it seems like we get interesting new features every release. My favorite from .NET 6.0 has to be the integration of dotnet-format as a subcommand. I regularly use vim so being able to format code without opening an IDE has been really helpful.
  • hackerfromthefu 5y ago
    For the VS coders, Ctrl+Shift+D is the autoformat shortcut!
• msla 5y ago
  > Of course, there are cases where .NET will lose to Go, Python, and Node. This is especially true when it comes to “cold starts” because of the nature of the just-in-time compilation to machine code (plus other nuances of how .NET processes start) and thus making it unsuitable for certain types of applications such as CLI tools or serverless functions that require near instant response for a single request. Not really dispelling the notion that ".Net is MS Java" there, but I suppose similar technologies will have similar performance, even if it's politically impossible to acknowledge the lineage. Also, responding to claims that your runtime is slow by bringing up Python, Node, and Go is conceding the point that C is faster, but I find it especially humorous that Java isn't explicitly mentioned. Can't compare Our Product to Brand X, I suppose.
• sylens 5y ago
  I've returned to the .NET ecosystem this year and have been slowly exploring everything they've added and changed to both C# and .NET since I last used it in 2011. I've been impressed so far. The author does a good job pointing out that it probably can't be the only language you will need to use - for AWS Lambda functions I still reach for Node instead.
  • starik36 5y ago
    C# works fine for AWS Lambda. I think they just added support for .NET 6 recently.
• yayr 5y ago
  One of the major innovations I miss still in C# is more flexibility regarding interfaces and inheritance. Like e.g. protocols in Swift. Their synthesized implementations are a great and productive method to ensure standardization and code reuse without much boilerplate. C# is still on the old OO path coming from Java with respect to that and decorating something with multiple base implementations is still a pain.
  • int_19h 5y ago
    Multiple inheritance of code is possible with interfaces and default methods.
    • yayr 5y ago
      thanks, C# 8.0 indeed seems to bring that, awesome. https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/default-interface-methods https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
  • logbiscuitswave 5y ago
    I totally agree. The protocols feature of Swift is really cool and it’s great how simple it bridges default implementations and extension methods. C# 8.0 adds default interfaces which are like protocols but they don’t work with older .NET Fx code. I’m working on a C# project right now where default interface implementations would save me thousands of lines of kludges with extension methods and duplicated class code. Sadly, it’s stuck on .NET 4.8 and can’t be migrated to .NET 6 right now.
• javcasas 5y ago
  Do you remember in the early 2000s where Microsoft added to the .net runtime licence that you weren't allowed to perform or publish performance benchmarks? Since then, I think It's fair to consider performance benchmarks coming fom Microsoft to be less than trustable.
  • javcasas 5y ago
    To all the people so eager to downvote me, tell me this never happened. https://bytes.com/topic/c-sharp/answers/230230-visual-c-net-standard-eula https://bytes.com/topic/c-sharp/answers/230230-visual-c-net-... > 3.4 Benchmark Testing. The Software may contain the Microsoft .NET Framework. You may not disclose the results of any benchmark test of the ..NET Framework component of the Software to any third party without Microsoft's prior written approval.
    • manigandham 5y ago
      That did happen. The downvotes are likely because it's 20 years later and TechEmpower benchmarks are neutral and open-source: https://github.com/TechEmpower/FrameworkBenchmarks https://github.com/TechEmpower/FrameworkBenchmarks
• wokwokwok 5y ago
  > These days, I do most of my C#/.NET in VS Code > And it works (mostly) flawlessly. It’s very hard not to roll my eyes when I read this. No it doesn’t. It’s not mostly flawless, it’s slightly better than using notepad. It’s considerably worse than the general experience of using vscode. This has been gone over many times in the past, and I would put it as my #1 c# myth: 1) you can just use vscode Microsoft has made a business decision to cripple the c# support in vscode to prop up their visual studio division. It doesn’t “happen to no be as good yet but it’s getting better”. It will never be a first class c# experience until the business priorities at Microsoft change. It’s free. So is the visual studio community edition; honestly, if you have to use c# just use that.
  • deleted 5y ago
    [deleted]
  • skinnyarms 5y ago
    > Slightly better than notepad C'mon now, syntax highlighting, build integration, debugging, code navigation... > It’s very hard not to roll my eyes when I read this. It's not as good as Visual Studio proper but Microsoft has put a lot of effort making C# work well in a variety of editors. VS Code, VS for mac, VS Community Edition are all free to use and I'd argue that any of them offer a better experiences than you'd get with a lot of other languages. Rider is my IDE for C# now, macOS and Windows, so I'm having a hard time buying your argument that Microsoft is trying to aggressively protect this particular turf.
  • adamdusty 5y ago
    Do you have any actual examples? I do all my c# in vs code and prefer it to vs proper.
  • equasar 5y ago
    proof?
    • wokwokwok 5y ago
      come on, do your own research. It's as hard as scrolling down to the search box at the bottom of the page. https://news.ycombinator.com/item?id=28972431 https://news.ycombinator.com/item?id=28972431
• zamalek 5y ago
  I have used it since 2001, though Friday (and continuing next week and for the forseaable future). My biggest problems are: * OOP is celebrated in the ecosystem. It's time to face the truth: the mainstream (i.e. not smalltalk) implementation of OOP is fundamentally flawed. I have done some pretty fancy stuff with aspnetcore and, OH BOY, does it take a while to unravel and understand that decoupled OOP wet dream. * Nobody does the high performance stuff in the real world. DDD (which has several valid merits) has many idioms in netcore that are fundamentally incompatible with writing high performance code. You might be able to dilute DDD to achieve tighter code, but if you value explicit clarity above all else then you have limits. Modern procedural languages suffer from fewer opinions when approaching the best of both worlds. Really this is a rant about OOP and, disagree with me about OOP being broken or not, OOP and OOP idioms are deeply entrenched in netcore (F# included).
  • spyremeown 5y ago
    >the mainstream (i.e. not smalltalk) implementation of OOP is fundamentally flawed Any nice readings you could link me about this view? Thank you!
    • zamalek 5y ago
      Here's a really popular video that touches on many of the contentions: https://youtu.be/QM1iUe6IofM https://youtu.be/QM1iUe6IofM My personal tipping point was the realization that OOP forces you to first figure out how you solution maps to OOP, before figuring out (or iterating on) how it maps to code. It creates nothing more than accidental complexity: https://emangini.com/2021/07/05-accidental-complexity/ https://emangini.com/2021/07/05-accidental-complexity/
      • masterofmisc 5y ago
        Its hard to know what people mean when they say OOP anymore. Im just watching now and he advocating for your code to be "procedural" rather than "object-oriented". And when he says "procedural", he doesnt specificlly mean "functional programming". So, when he says "imperative procedural programming" he means that you have no explicit association between your datatypes and your functions/behavours. And just to be clear they are not saying its a problem to see an object in your code!! Its the traditional OOO (Object Oriented Objects) that have state and method calls/behaviours. And thats pretty much the way I code in C#. My data objects are just that. Simple data! And I have other objects that are a collection of functions that take in POD (Plain Old Data Types) objects or return PODs. He goes on to explain how encapsulation is the problem. Thats where you have an object that holds state/information hidden behind a public interface as well as methods to mutate the state. And when you call that method, it might call through to many other methods on other classes. And if thats the case, it means the object your calling the method on has references to those other classes it depends on. Which means those dependencies/objects must be provided to it via construction. I have not watched the whole video but I tend to agree with what he is advocating.
• pleb_nz 5y ago
  It irks me when websites disable zoom on mobile... Sigh... Why would you take that capability away
  • aliswe 5y ago
    agree!
• zmmmmm 5y ago
  > Myth 1: .NET is for Windows I kinda had the opposite myth, that .NET core is cross platform, in my head. Then one day someone handed us something to actually run on Linux so off I went to try and install .NET on our linux box and run it. That's when I found it was anything but trivial and in fact, nearly impossible to install it without root permissions on the server we were using (HPC compute cluster where admin access is forbidden). Then we ran into all sorts of problems with having the wrong version so about 3 or 4 random attempts at different versions later and after emulating the install in a VirtualBox clone of the OS so we could manually fetch out dependencies, we finally got a version of it that ran. So yeah, maybe it's technically cross platform but it's a far cry from the portability and deployment story that other languages like Java or even Python offer.
  • pbiggar 5y ago
    I don't know what this is about. There's binaries to install, packages for debian, pre-built containers, everything. I've been doing .Net for about 18 months, entirely on Mac and Linux, and everything just works.
    • frank_nitti 5y ago
      Must have been some lack of research or expertise on that person’s team, or some obscure linux distro. You can compile with the platform/arch specific flags to get a regular linux exe that doesn’t require the .NET runtime to even be installed on the system, and that’s advertised on page 1 of the docs
  • kumarvvr 5y ago
    Looks like a bit of beginner stumble, rather than an issue with .NET.
    • Beltiras 5y ago
      If x-platform is your thing then you better make deployment easy for beginners. Otherwise ppl tend to just stick to the tooling they are used to.
• labrador 5y ago
  I like how they threw Steve Balmer under the bus > Like many .NET myths, this one originates from the days of Microsoft under Steve Ballmer
  • kevin_thibedeau 5y ago
    With Ballmer it's chair throwing.
• LAC-Tech 5y ago
  Can you produce a stand alone executable with ASP.NET these days? I had a look at how to deploy a modern ASP.NET thingee the other day and it was super enterprisey. It doesn't produce a single file, it produces a 'publish' folder, and you need something called a "kestrel" server... Say what you will about node.js but you just run the script and slap caddy or nginx in-front of it.
  • DoctorOW 5y ago
    Yes and no. You can publish a single binary but all those assets are just embedded inside it so the file is pretty large compared to everything else.[0] Also Kestrel is built into ASP.net, not something that needs setup.[1] You can slap Caddy or Nginx in front of a .NET program just as easily as anything else. [0]: https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file/overview https://docs.microsoft.com/en-us/dotnet/core/deploying/singl... [1]: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-6.0 https://docs.microsoft.com/en-us/aspnet/core/fundamentals/se...
  • Merad 5y ago
    Kestrel is the web server that Asp.Net Core runs on by default. It's part of the application. Building an app that has the runtime bundled with it (no need to install .Net) or a single file executable is just a matter of setting a few build flags.
  • kumarvvr 5y ago
    Yes. You can create a kestrel server based web app, and simply run it, for use in localhost. Adding an nginx as a proxy is also simple. Nothing enterprisey about it. Also, the "Publish" folder is basically the "build" folders you get from other stacks.
  • ledgerdev 5y ago
    Yes, but it will be large, ~40mb zipped. Net6 release broke trimming (tree shaking) with entity framework at least which caused an app of mine to balloon quite a bit. Native AOT is on the roadmap for net7 which is good but very minimal support. For instance asp.net mvc is a non-goal (https://github.com/dotnet/runtime/issues/61231 https://github.com/dotnet/runtime/issues/61231), so probably another 3 or 4 years before it's well supported.
• kapildev 5y ago
  The only thing I dont like about C# and .NET by extension is the method naming convention, which is extremely uncomfortable and throws every instinct out of the window -- taking long and painful hours/days to adjust
  • int_19h 5y ago
    C# naming convention is PascalCase, which is as old as, well, Pascal. How does it "throw every instinct out of the window"? If you come from camelCase or snake_case, of course it's going to be different - but that's habits, not instincts.
• _8j50 5y ago
  I love .NET malware. If you know anyone that writes malware please encourage them to use python or .NET.
• jchw 5y ago
  Some notes: - Yes it’s cross platform. However, that does not include Winforms or WPF. Apparently the “multi-platform” in MAUI is “Android, iOS, macOS, and Windows” which means if you don’t care about Linux, you have a potential cross-platform UI option. However, the decision to not include Linux, while not really a terrible act in and of itself, does hint at a bit of the limits of Microsoft’s “friendliness” towards open source. - Dotnet Core makes async easy, and that’s great. However, when playing around with it, I did notice that it’s the kind of “async” where you need to manually yield if you are not heavily IO bound. It’s not quite idiot proof and you can cause a lot of trouble by holding it wrong. This is not any different from JS or Rust, but it’s worth noting. - Big eyeroll at the knock on Go regarding generics. I’ve written a lot of Go code and while I think adding generics will be helpful, I can think of exactly one place in existing code I definitely want to put generics after 1.18. It’s one thing to expound on C# language design, which I agree has its merits, but getting into tit for tat comparisons with other languages that have vastly different design goals like Rust and Go is losing enough nuance to be basically meaningless, and then using that to elevate your opinion is just poor form. - Friendliness towards open source is still sketchy. They did indeed do most of the important things, including, well, move almost everything into the open. Well, almost. But not quite. Not the debugger for example. See this long-standing issue for some backstory: https://github.com/dotnet/core/issues/505 https://github.com/dotnet/core/issues/505 (There was also some issue with .NET governance that pissed off the community, but I’m not in-the-know enough to grok it, so I’ll just not attempt to poorly explain it.) Microsoft seems to have a tendency to do this. They give you almost everything, but they hold back some important components. It’s the same with VSCode; try using VSCode OSS. No remoting, no liveshare, no official extension repo. Mozilla doesn’t lock off access to AMO from Firefox forks. Chrome doesn’t lock block access to Webstore from Chromium or its forks. Open source Firefox can log into Sync. Open source Chromium can log into Sync, too. Open source Edge… well, no. Edge is closed source. Microsoft is indeed not the company that it was under Ballmer. That’s not all sunshine and rainbows, though. For what it’s worth, I’m not saying that Microsoft is obligated to do anything, or that we’d be better if they never changed. Even vscode-oss and monaco editor are quite nice to have. That said, Microsoft bills themselves as being allies of open source when I feel like this is a pretty dubious position. They’re clearly operating very strategically here; there is little guise of actual goodwill. At risk of sounding like a nut job, I suspect MAUI not supporting Linux is perfect to go alongside WSL2. From my perspective, Microsoft doesn’t seem to just want to mutually benefit from open source in the traditional way, they also seem interested in trying to shift the community in a certain direction where Windows and Microsoft binary blobs are an important part of open source developers toolkits. A slowly increasing number of killer features will rely on closed source blobs, allowing Microsoft to exert substantial control over the ecosystem, while still maintaining the ability to say “why are you so afraid? VS Code is open source*!” I still use VS Code despite my concerns, so I’ll leave it up to you to decide what that says about me.
• zoom6628 5y ago
  Have used .Net for a long time as a casual user; generally just to get a task done. C# is vastly easier to approach in 2022 for a casual user. .Net Core is great strategic step and IMHO should be the only .NET platform there is. For those wanting a simple browser UI then use the Nancy framework. Its brilliant for tooling and simple desktop apps. fav language of all time is Python having used since 2001. There are libs and examples online for everything and then some. Now learning Go and after that plan to tackle Lua. Nothing wrong with most mainstream languages for 90% of use cases in their chosen domains. Sometimes the road is rocky but if the basic premise of the language suits your use case then stick with. The speedbumps are good learning experiences.
• scrame 5y ago
  > .NET is for Windows yes, mono exists, but the language is created and steered by Microsoft for windows. you can also run a lot of windows apps with WINE, but that's not gonna make me write windows apps for Linux. > It’s slower than Node/Python/Go/Rust literally never heard this complaint, and the first 2 languages have never held the torch of being fast. > It’s a legacy platform as I understand, it's pretty actively developed and gets newer features more regularly than Java, but again, it's a Microsoft language. > The tooling is expensive Of course you can write and compile C# with other tools. This is the same strawman as #1. > .NET isn’t open source friendly TFA said that Microsoft is friendly to OSS since Ballmer retired. K. > It’s for boomer enterprise development This is a stupid argument. Another strawman. Look, I'm not arguing the merits or tech of the dot Net platform or C# or anything there. By and large, I think it's a good platform, but it's Microsofts baby, so setting up a bunch of strawman arguments for why non MS platforms should adopt a proprietary tech from a company that is overall hostile to open source efforts just comes across as corporate propaganda.
  • kevingadd 5y ago
    .net has had first-class linux support for a long time. I do over half of my development in a linux VM using a linux toolchain (working on .net's wasm support) without touching any windows software. Then for my personal projects I use visual studio on windows
• sandreas 5y ago
  I'm still learning C#, but I think it is just awesome. You can build for: - Linux (x64, arm) - even raspberry works fine - Windows (x64, arm) - MacOS (x64, arm) The only thing I'm missing atm is BSD, although it might work with Mono, it is not officially targeted. More: https://docs.microsoft.com/en-us/dotnet/core/rid-catalog https://docs.microsoft.com/en-us/dotnet/core/rid-catalog Some libraries / frameworks I came across that are definetely worth checking out: - https://github.com/gnaeus/OperationResult https://github.com/gnaeus/OperationResult - Rust style error handling for .net - https://github.com/Tyrrrz/CliFx https://github.com/Tyrrrz/CliFx - Command Line Parser library - https://github.com/Tyrrrz/CliWrap https://github.com/Tyrrrz/CliWrap - Shell exec for c# - https://github.com/Zeugma440/atldotnet https://github.com/Zeugma440/atldotnet - Audio tagging - https://avaloniaui.net/ https://avaloniaui.net/ - Cross Plattform UI (WPF Style) - https://github.com/quozd/awesome-dotnet https://github.com/quozd/awesome-dotnet - Other awesome stuff - VS Code and JetBrains Rider - alternative IDE for c# development
  • DeathArrow 5y ago
    >You can build for: - Linux (x64, arm) - even raspberry works fine - Windows (x64, arm) - MacOS (x64, arm) You can also target Android, iOS, game consoles and microcontrollers.
    • sandreas 5y ago
      Yeah I also already experimented with native Apps (Xamarin)... Maui is still on my list, a shame, that Linux is not officially supported.
• Shadonototra 5y ago
  > It’s slower than Node/Python/Go/Rust It is , it also is slower to start than Go/Rust, and it takes a while to reach steady state due to the JIT nature of the language > trailing node.js yes, it's a shame to be behind node.js > It’s for boomer enterprise development It kinda is, other than ASP.NET and Entity, what else do you have? it's bloated enterprise stack only You need to configure your project with XML, you need to do build scripting with XML, and you can't cross compile, and you can't properly deploy without spitting 400 dlls in your directory > It’s a legacy platform It kinda is, containers are all in Go, there is no SwiftUI like frameworks, it still is split between WinForms/WPF/WinUI, and you need freaking XAML scripting
• sriku 5y ago
  Any thoughts / experience on F# with .net?
  • retendo 5y ago
    I found it to be quite pleasant to work with. Context: I’m mostly working as an iOS Developer, but I do have some experience with other languages that are not Swift/Obj-C. I did not have any prior experience with the dotnet ecosystem, though. When I chose F#/.NET Core for my side project 2 years ago, I was looking for something similar to Swift in terms of pragmatism and reliability (big chunk of available standard/first party libraries), but more mature as an API technology and slightly more functional. Why more functional? Because I was interested in it. I’m not a religious person. F# ticked all the boxes. Most libraries you’ll find, that interact with the outside world, are basically functional wrappers around established, mature C# libraries. Those are either first party (ASP.NET Core) or “the standard” (Npgsql for interfacing with Postgres). A couple of tools and libraries that I use, off the top of my head: Saturn, Npgsql.FSharp, FluentMigrator, NLog, Flurl
• Volrath89 5y ago
  I've been a .NET dev for almost 8 years now and I agree with the general positivity sentiment in the comments, but... As many senior devs I also want to retire early from tech. But unlike many, even if I spend hundreds of hours in leetcode, mock interviews, etc. I'm not sure if my work experience would be even considered for an interview at FAANG. Of course I could interview at Microsoft, but it's the only one. Google, Amazon, Facebook, they don't use/hire C# devs at all. I'm guessing the only path is to learn some Java and sell myself as a C#/Java dev in order to be able to at least get an interview. Any former dotnet dev here that has successfully transitioned into a FAANG position that wants to share advices/experience?
  • ozim 5y ago
    I think if you don't land FAANG job out of the university you will not get a FAANG job after 8 years of experience in other places.
    • azinman2 5y ago
      Not my experience
    • Volrath89 5y ago
      It's probably an order of magnitude harder, especially because after university you have many CS concepts fresh, and after 8 years you have totally forgotten about inverting a binary tree... But I think it's possible. Most FAANG now are just another big corporation and they are always hiring for all levels of experience. Especially since so many developers seem to retire early I think its doable
  • jmkni 5y ago
    Fuck FAANG, just focus on being good at what you do/delivering value, there are plenty of very well paid senior roles out there for dotnet devs not at FAANG companies. As an aside, I'd be surprised if any of those companies hired specifically based on programming language, surely Are you good at programming is more important than the specific language you have experience with? If you have learned one, you can learn others.
• DeathArrow 5y ago
  I love .NET. It is highly productive, reasonably performant and you can competently write any kind of software using it beside systems programming. It is an excellent jack of all trades, and you can move with ease from game programming, to web applications, to desktop software, to small glue programs and utilities, to mobile apps, to web frontend and what not. In the future even systems programming might be possible with push towards native apps and direct memory access. If at some point it will be possible to disable the garbage collector and manually manage memory, .NET could be used for everything. For a company investing in .NET is a good idea since you can move with ease a developer from one role to another. And even if you don't move the developer, having a mobile developer who can read and understand the code for the backend APIs can be quite beneficial. For me, personally, working with .NET was quite a win. I moved from desktop apps to web, then, when I got bored I moved to the gaming industry as a game developer and now I am again a happy web developer writing microservice based web apps. Meanwhile I also developed a few mobile apps for myself.
  • throwuxiytayq 5y ago
    > If at some point it will be possible to disable the garbage collector and manually manage memory, .NET could be used for everything. While I haven't seen anyone disable the GC completely, plenty of people avoid using it in the Unity/gamedev world. You simply avoid allocating memory (outside of loading) and the GC isn't a problem when it has no work to do. Making sure none of your code allocates at runtime is only difficult if you "don't optimize prematurely" (write shit code without any understanding or regard for performance).
    • mapmap 5y ago
      What is the technique to do this? Object pools?
      • throwuxiytayq 5y ago
        In case of Unity specifically, yes, re-using entire GameObjects whenever possible goes a long way. In game code, you can use structs instead of managed objects to avoid touching the GC. Unity provides NativeCollections, which are some standard collection data structures that can be used to store structs outside managed memory (which lets you avoid the GC). In real life it's next to impossible to avoid GC completely (especially if you rely on assets/libraries/even built-in engine features), but that isn't the goal - it's enough that you avoid allocating managed objects during gameplay simulation. GC can do its thing during level loading, cutscenes, in UI, etc.
• ncmncm 5y ago
  The author has nothing to offer for either of the main arguments against .Net: 1. It remains a walled-garden language, subject to Microsoft whims. The only reason Java ever took off was that it offered people freedom from Microsoft sharecropping. It is deeply foolish to yoke yourself and your career to Microsoft again: Microsoft will always ensure they get the major benefits on the platform, not you. 2. It is still almost as badly designed, as a language, as Java.
  • deleted 5y ago
    [deleted]
• Illniyar 5y ago
  I love C# and working with it is often a great fit for a lot of use case, and most of those points are valid. But point #5 - "Myth 5: .NET Isn’t Open Source Friendly" is unfortunately still not good enough. It's not enough that Microsoft is no longer actively hostile to open source (especially in .NET), the ecosystem needs to be too, and right now the ecosystem is dominated by first-party offerings and have little serious third party involvement, even when they do exists a lot of them are not open source.
• erikbye 5y ago
  Compilation is still surprisingly slow, the new CLI tools are not a joy to use. Just look at his example and how slow dotnet run is, even for a program just outputting hello world.
  • aliswe 5y ago
    Are you comparing this to something? Serious question!
    • erikbye 5y ago
      E.g. Rust. Not comparing for large compiles. Like the article says, the problem is cold-start performance.
  • metaltyphoon 5y ago
    dotnet watch Now you can get a lot of your work without the app restarting.
    • erikbye 5y ago
      How does this improve startup time for CLI tools? That only helps the developer.
      • metaltyphoon 5y ago
        > Compilation is slow dotnet watch only helps the developer by not compiling the entire project all the time. Until .NET 7 aot comes, ready to run is the best it can do.
• jbverschoor 5y ago
  Myth1: Sometimes it feels like I’m the only person tendering that the initial betas for .NET were available on FreeBSD
• zgiber 5y ago
  I feel that the comparisons are quite one dimensional (crushes Rust, Go etc..) picking one or two metrics. Why is the memory footprint almost fully ignored in the article? Application speed is rarely the bottleneck in platforms I work with, but it does matter a lot how many instances you can run in a cluster where memory is often a limitation. For me personally it's also important how easy is to write concurrent code to work around IO bottlenecks.
• insaider 5y ago
  Absolutely love the .Net framework, it's my bread and butter. Super excited for the new app development framework being released in a few weeks, check it out - https://docs.microsoft.com/en-us/dotnet/maui/what-is-maui https://docs.microsoft.com/en-us/dotnet/maui/what-is-maui
  • victor106 5y ago
    This looks great but they use Mono for non windows apps which I think is super slow at least from my past experience