Hacker News new | past | comments | ask | show | jobs | submit login
.NET Core 3.0 (microsoft.com)
426 points by hmexx 23 days ago | hide | past | web | favorite | 179 comments



I have been developing in .Net MVC 5 and now the last 6 months in .Net Core 2.1. Core is pretty awesome, I would say the learning curve is pretty high, but I'm very satisfied. Previously, I used Java in school. The .Net stack offers a lot of jobs in enterprise companies, if you are someone that dislikes SV mindset.

Also, Visual Studio is an insane IDE. Although, I recently did have some nasty bugs but updates are coming out pretty quickly.

Edit: Microsoft has also added many new videos to help beginners, these cover various topics https://dotnet.microsoft.com/learn/videos.


VS is very good but I've been using Rider since the start of this year for most work, I found it to be a very strong competitor.


I've been Rider almost exclusively for about 2 years now, ever since I've been coding Core. VS is fine, but VS w/Resharper is a dog. With Rider, R# is a first class citizen, which makes a huge difference. Not to mention that the vim emulation and other addons are solid due to being shared with the intellij suite of apps.


VS 2019 has been integrating lots of new refactorings that were only on R#. It appears that they are more and more between small releases.

I'm happy to never need to use R# anymore.


Refactorings are but one feature of Resharper. The code hints/suggestions are still far better than vanilla VS, unfortunately (imo).


Rider blows Visual Studio out of the water for anything F# as well. It is really a shame that Microsoft no longer seems to care about it.


I switched to Rider from VS with R# after growing weary of the frequent pauses and the constant whining of my laptop fans.

It took a while to configure the colour scheme to something I was comfortable with, but otherwise the experience has been really positive - I love it!


Same, I’ve been using Rider whenever I can, VS only when I have to. Much better IDE overall.


Visual studio crashes and hangs on me multiple times a day. Rider is just solid.


Visual Studio does this for me a lot as well, especially when projects become larger. The number of times the typeahead caused the app to hang is too numerous to count.

Part of me misses .NET, but I've been mostly working with Golang and Node lately. Visual Studio Code is pretty stellar. Maybe someday VS will catch up to VSC. :)


I also have problems with VS resource usage. It appears to depend on what file type the focussed tab has open. It's still 32-bit, which can't help.

Never had perf issues with VSC, which is surprising considering it's web tech. It's a different class of app to VS but much nicer to use, and of course it's cross platform.


I haven't used VS in about 2 years now, so this experience may be too many versions out of date to be relevant anymore, but for a while I had very similar problems. And then I uninstalled ReSharper, and VS all of a sudden became very snappy.


You can get most of snappiness back even with ReSharper installed. If you dig into the ReSharper option menu, under "Product and feature", and untick everything in the feature section except "Navigation and search", you still get the amazing refactoring and writing-code support but without your computer slows to crawl speed.


I try to avoid anything by Jetbrains, as the process of reporting bugs and trying to get show-stopping bugs fixed has been a nightmare with them. This was during their RC phase of Rider, where I had a number of bugs. They went ahead and shipped it to full release (where it was no longer free of charge) without fixing a single one of the bugs I reported and even followed up on. What is the point of an RC beta test if you are so behind on bug fixes that you're not even able to triage all incoming reports? Seems like it should still be called beta at that point.

To their credit, I've had great experiences with RubyMine, but that was the exception to the rule for my experiences with Jetbrains IDEs.

Edit: Before anyone else downvotes, I'll point out that I realize this is not the experience others have had, but I was not exaggerating these claims.


That’s about the opposite experience that I’ve had, they’ve always been quick to respond and resolve my reported issues, they’ve even created tickets themselves when I’ve reported them over Twitter.


This bug has been open for 3 years (and not touched for 2 years). It's stuff like this you see everywhere: https://youtrack.jetbrains.com/issue/RIDER-3461


Our team uses Rider at work. We love it. The UX blows VS out of the water. Nice and fast too. Unit tests are a first class citizen in Rider too.


It's usually a good idea to wait for the patch release before updating. This applies to most software, including VS, VSC and .NET Core.

Being an early adopter sucks unless you're just testing it out. If it's your job then wait for it to stabilise and for the real-world bug fixes.

The next Long Term Support version of .NET Core will be 3.1. It should be out in November.


.Net 3.0 has gone through about a dozen preview releases and the last 4 have a go-live production license. It's much better tested than the old .NET Framework with its monolithic releases.


I can at least name two bugs. both bugs do not apply to everybody and one is fixable with some additional code. I reported both in preview9, one should be included into 3.0 but was not. the other will be fixed in 3.1:

- https://github.com/aspnet/AspNetCore/issues/13696 - https://github.com/aspnet/AspNetCore/issues/13715

(Edit: corrected first link)


That's very much true for tools like Visual Studio, but not for the runtime itself.


Microsoft have been running things like Bing on it for a while


As a recruiter, I have to say that .Net is still used by startups, especially in Europe and cities like Manhattan with a large European population. I am shamefully plugging the fact that I am recruiting for said roles :-)


Here in NZ its very popular as well.


Re: I would say the learning curve is pretty high

If you had to rank and list the top rough spots in the transition, what would they be? Entity-Framework changes are often cited, but what else is different enough?


Having just come into a .NET shop in the last couple months, having spent much time with Spring / Java the documentation and clarity of what to use is troublesome. I really expected Microsoft to have great documentation, but sadly I’ve not found it great.

So far I’ve done some WCF SOAP work, and an ASP.NET MVC 5 application. Figuring out what the latest frameworks and tools is a bit of legwork. Things aren’t always clear, and not always well integrated.

Figuring out authentication was not clear, whether to use Membership, Identity, where OWIN fit into the picture. If you need custom authentication finding details is hard. Ultimately I figured it out, but it’s clear as mud from a fresh eyes standpoint.

Then setting up DI, which container? Well I had Core DI available, figured that would be a good choice. Except I have to write a good bit of glue code to make it work.

I’m definitely enjoying C# as a language and the standard library. But the ecosystem is a bit clunky.


If you want a more batteries-included less-glue-requiring IoC container, can't recommend Autofac enough. Always up-to-date, responsive developers, thorough documentation. I chose it over ten years ago after reading https://www.manning.com/books/dependency-injection-in-dot-ne...? and have never looked back.


its very simple to get .net core DI working, shouldn't be much code other than registering your types / service.

await new HostBuilder().ConfigureServices((context, services) => { // services.AddTransient.... }).UseConsoleLifetime().Build.RunAsync()


I’m talking DI for ASP.NET MVC 5, non-Core.

That required a custom provider (trivial), and non-obviously a custom ControllerFactory as I picked Core DI instead of a more fully-fledged solution.

Unfortunately there is very little obviousness in documentation and germs often get conflated and confused. Perhaps this is MS trying to get me to take one of their infamous certification courses?


That is because MVC 5 did not support DI out of the box. This has been fixed with Core. It is quite easy now, since I was able to figure it out haha.


It depends where your starting point is. Core bundles a lot of stuff together that was previously separate or just good practice. If you are familiar with MVC / WebAPI / EF / OWIN and already doing DI / Logging etc. then it's not much of a leap.


This is correct. I did not use DI before moving to Core and that was probably the toughest. Once learned, DI is great.

MVC 5 to Core should be a pretty easy transition if you know DI.


I feel "DI" in the context of .NET Core is often the IoC container you feel forced to use. DI is a pattern, but even trying to use the logger extension without the service provider is a pain.


Rough spot for me is the way Startup.cs works. I mean, I'm glad it works at all, but I find the UX a bit nasty compared to how to configure SpringBoot applications.

It just feels very clunky in comparison. I have to remember so many things, which I invariably can't so I have to look them up.

I find EF Core pretty straightforward.


I went from developing front-end only with the MEAN stack, to full-stack with Webforms, to MVC...and I was easily more confused with the transition to MVC than anything else. Even being accustomed to EF now, I still would bet money that I could write data access code twice as quickly with half as many issues. I fail to see what's so much better about working with an object than understanding SQL and your data. Everyone claims MVC is a more natural, transparent web development paradigm, which I sort of agree with, but anyone who hasn't written APIs or worked with EF before will find themselves trading a lot of productivity for it.


It's great to see the enterprise world catching up with the tech world


Wait, wait, Visual Studio has been way ahead since forever


I fail to see what the point of trying to use VS Code for .NET development would be. I suppose if you like tying one hand behind your back and making things more difficult for yourself for some reason. Or maybe you like cobbling together a rickety pile of plugins.

If cost is a concern, there's Rider or even MonoDevelop.


OmniSharp is the official C# plugin and all you need for .NET projects, and it's usually installed by default. VS Code starts faster, runs lighter, and provides 80% of the functionality of VS for most major products, and it's getting better every release. I find it more productive than VS for typical web projects.


For proper .NET projects I've used both VS Code, VS and Rider.

VS Code doesn't come close.

I use VS Code when doing front end stuff with Vue/TypeScript and I love it for that, but .NET Core was painful on VS Code compared to Rider.


Vscode is lightweight, I don't really refactor all that often, and it's code search function is first class (so is it's vim emulation), and it has a terminal.

Since dotnet core includes a CLI executable, I interact with the project through the CLI. I manually edit the config files. I could run the stack from a netbook if I wanted to.


I work mainly in multi-project F# solutions. VS Code Ionide plug-in seems pretty solid for single project F#, but every time I've tried to use it for multi-project I run into some sort of situation that sends me back to Visual Studio.

VS has had it's own F# problems. The latest Preview edition is pretty solid, with one annoying bug. Almost every time I open my big multi-project solution I need to rebuild to get Intellisense to eliminate the red squigglies, and then close VS and re-open. It's a known issue. Hope MS fixes it soon.


What's crazy is that this is what C# should have always been. I was into Mono way back because I thought niavely it was going to be more successful, but I think if C# had gone this route earlier -> the whole python / go etc popularity boom might have been softer and MS would have had a first class player that would have increase # of folks easily able to build in windows.

That and I never got to develop successfully beyond Forms - which I wish was not in preview from designer standpoint. I know old tech, but frankly for older programmers I find it easier and quicker to get stuff up with.


I’ve thought about this but I doubt it. The big change has been the perception shift.

.NET was always really solid tech. Microsoft has always had stellar developer technology. But the love affair with open source and the super villain role that Microsoft played, is what kept people away, not the tech itself.

I remember wanting to give a talk about how amazing C# was to a ruby group. I never did it, but it was definitely a quaint idea in 2011. But rubyists would’ve loved C#.


> But rubyists would’ve loved C#.

As a Rubyist, I'll admit that C# is the least bad of the C++/Java style of static OOP languages, but it was that it was always too tied to the .NET ecosystem and heavyweight enterprise tooling more than Microsoft's “supervillian role” with regard to FOSS that made it unattractive for lots of places where I would want to use Ruby. That's improved with Core, somewhat.


I was a fulltime ruby developer before I became a full-time .NET developer (usually by accident). And things like Linq, Visual Studio, and Resharper ultimately allowed me to create code that was highly organized, while never sacrificing productivity or performance.

The thing I always hated most about the .NET ecosystem was having to run on Windows Server, so that's definitely a welcome change with .NET Core.

But C# has always been a wonderful language to work with. And you never really feel the static typing slow you down, yet get all the benefits of not having to write a bunch of useless tests that replace what a compiler should do in the first place.

(Not trying to make this a dynamic/static flame war by the way. I'm a full-time elixir developer nowadays, so I'm still in dynamic-land and enjoy it. Just not dogmatic about any of it)


More than windows it was the GUI centered developer tools and server setup. With powershell and the dotnet CLI things have improved massively. Now that we can just run on Linux I'm absolutely in love. I still use Java for some projects because of library dependencies (and kotlin also makes the work enojayble) but I prefer .net for Greenfield projects


It improved with mono and it's great to see continuation with core by ms. I don't use it atm but I remember learning c# from their beta book before v1, it was better than java even at that time. I've used c# from objective-c macos app maybe 6 years ago, it was pleasure to write c#/objc interop with mono and see same codebase used on windows app working fine (even faster) on macos via mono. The state must look much nicer now whan 6y ago, if I see opportunity to write some c# code now, I won't have any personal reservations, I'll do it with pleasure.

ps. my personal favourite programming languae at the moment is by far Julia and I encourage anybody to have a peek at it - I've missed it somehow[1] [2]; followed by crystal

[1] https://youtu.be/DRKKAFYM9yo [2] https://youtu.be/HAEgGFqbVkA


There was a brief window where mono was in the default Ubuntu distribution along with several mono-powered open source Linux productivity and media applications such as Banshee (media player), F-Spot (photo manager), at least one note taking app, and probably at least one more application I'm forgetting.

There's a parallel world out there where the Gnome project and Linux distributions rallied around C# as a strong way to write applications, instead of the weird backlash/demonization they all soon received that ended such a brief "golden age".


Yeah, .NET Framework was an absolute pain to work with also, there was a lot of boilerplate, especially when it came to ASP, and like you said it was tied to Windows and Windows API. Now with Core it's multiplatform and they're opening up all of the traditionally Windows-based SDKs to Core architecture and making them multi-platform while having them open source.

.NET Core is an absolute pleasure to work with, and while I'm not into Razor views, the web startup modularity and extensability of the pipeline make swapping out solutions a breeze. I can run a full React app in some a wwwroot folder that has almost 0 dependencies on the outer C# code, such that I can plug out the folder and copy it into a new directory and run it like any other React application - that was mind-numbing with ASP non-Core. I love it


ASP.NET MVC was much easier to work with, and WebAPI was even easier (especially with annotation support). Each time, you had even less boilerplate code.


As someone with a Ruby background in a new job doing C# stuff, I really love C#!

Now the Windows exclusivity of .NET is no longer a thing it's much, much more appealing (who wants to run Windows Server over a Linux server if they can avoid it?).


We have been selling a relatively complex product built using C# for many years now. It is perhaps unusual in that it was built on Linux for Mono primarily, and then ported to .NET on Windows subsequently.

What we have seen over the years is:

1. Deploying on Windows became less popular, partly because it was much harder to manage at scale than Linux, and partly because of the price of licensing.

2. Mono was seen as a toy, and is often considered a critical risk by purchasers. This was even true after Microsoft bought Xamarin, and thus de-facto control of the project, and despite the fact that it was far easier to patch bugs in the open source runtime than in the closed-source .NET Framework (and we ran into several in each).

C# (and even more so F#) is a great language, but was hamstrung early on by Microsoft's approach to competition - I think had this been different early on, the world would look very different with respect to popularity for critical infrastructure vs the JVM. Whether it's late enough to salvage something for a large number of non-traditional-MS is debatable - it will be interesting to see how it plays out over the next few years.


I actually went from C# (WebForms) to Ruby (Rails) and then back to C# (MVC).


Rails is still pretty good. I'd probably use it if I were starting a new project still.

Can even do Type-checking now thanks to Stripe! https://sorbet.org/


The ecosystem is what drove me away from C# (as well as not wanting to do enterprise work). I started dabbling with Ruby and Node and the sheer number of free third party libraries blew my mind. C# simply didn't compare.


One of the nice things about .net is you don't need to download half the internet to do most of the things you want to do.


This is a very weird criticism. I'm a Ruby dev, but I spent eight years working with C#, and I can't remember any times where a Ruby gem was more readily available than a NuGet package.

If anything, I'd say there's less choice in the Ruby world, especially in the data science and ML fields.


Depends. I think it's valid. There are a tonne of libraries available in both ecosystems but I find they tend to optimize for different things.

I came from the Java ecosystem to .NET and even they are different. The .NET ecosystem was held back a little by the lack of embracing open source at the beginning and being super commercially focused. So things like finding a good library for easily working with PDF will set you back $400 rather than just using the defacto library that everyone has used forever and is free. I've encountered that with PDF libraries, rules engines, workflow engines, job scheduling libraries.

It's still a decent ecosystem, it just is different because of its roots.


Totally agree. The tech was so awesome that it lured Miguel de Icaza away from Gnome.



Now you can easily write the following state machine in C#:

    static State ChangeState(State current, Transition transition, bool hasKey) =>

    (current, transition) switch

    {

        (Opened, Close)              => Closed,

        (Closed, Open)               => Opened,

        (Closed, Lock)   when hasKey => Locked,

        (Locked, Unlock) when hasKey => Closed,

        _ => throw new InvalidOperationException($"Invalid transition")

    };


To be clear, this has nothing to do with .NET Core 3.0 but rather is a feature of C# 8.0, which depends on compiler support that can be targeted to any previous version of .NET Core or Framework, all the way back to Framework 2.0 (tested myself, although MS says not to target 2.0 or 3.5).


C# 8 needs .net core 3.0 for some features to work at all like default interface method implementations, and for some to work meaningfully like nullable reference types.


Still no exhaustiveness checking like a true match expression unfortunately, which is what would give it parity against the traditional subclass/polymorphic approach.


Heard it’s being championed for C# 9.


It's so amazing to me how many features from F# or other functional programming languages make their way to C#, and the devs who were otherwise never gonna try those features use them because they are 'normalized'.

I do wish people would give the language that has (relative to this ^ trend) 'already arrived' a chance.


That's not the root of the problem. Personally, I wish MSBuild would be more powerful and would allow mixed compilation where some files are in C#, some in F# (or VB.NET or some other language targeting the CLR).

Right now most companies (in the .NET world) just run on C# and no one tries anything new except when it arrives in C# (and even then its a struggle - even though the situation has improved a lot in recent years). A mixed model would also open other scenarios.

The mixed compilation is something that current web tech (using bundlers) has in advance. I can do crazy things and end up with the best (optimized) output using a common denominator.

On the F# track I fully agree - its a wonderful language that more people should try out.


This isn't really due to MSBuild, as the C# compiler has that limitation already. MSBuild just calls it. Basically a single assembly has to be written in the same language. You could probably get something similar with multiple assemblies and ILMerge.


I don't expect the C# compiler to understand F#, but in my opinion there should be language independent ways to create CLR assemblies. MSBuild (which calls the right compiler for each project) could also understand (and did iirc) compiler-independent project types that still produce assemblies, however, from mixed sources. Now the C# compiler would only be called for the C# sources.

> Basically a single assembly has to be written in the same language.

This is like saying a single js file has to come from only js files, still bundlers today merge all kinds of types in there - in a single sweep.

I am not writing this since I think mixing C#/F# is the future (well, it would be cool), but because it could allow the C# ecosystem to improve. Right now the best thing we have for metaprogramming in C# is Fody; and I personally think we could do better.

Hopefully this expressed my idea a little bit better.


The C# (and other .NET compilers) treat an assembly as the smallest unit they will emit. You'd have to change that to some semblance of "object files" instead along with a "linker" step afterwards to allow for an assembly to be made up of different languages. Again, this is how the compilers work currently, so MSBuild (well, the default targets) just go along with this. This has nothing to do with MSBuild, which basically just tracks items, properties, targets, and tasks. It doesn't care about the semantics of all that.

Or, you know, use ILMerge, which is pretty much the equivalent of the JS bundlers you mention. With some custom MSBuild targets you should be able to create a project file that contains C# and F# files, both of them compile to intermediate assemblies (although you can't have circular dependencies between both), and a step afterwards merges the assemblies into the actual one.


> The C# (and other .NET compilers) treat an assembly as the smallest unit they will emit.

`<OutputType>module</OutputType>` in your project file (or `/target:module` at the command line, and you get a smaller unit.


Ah, learned something new today. Thanks.


> Basically a single assembly has to be written in the same language.

This is actually untrue - though the tooling does not make it easy.

If the output type of a 'project' is set to `module` instead of `assembly`, it can be added as a module reference to another project which builds an assembly.

The downside used to be that completion in the IDE didn't work, but as far as I'm aware there's no real reason why multi-module assemblies couldn't easily be exposed by tooling if it was considered important enough.


well there is some mixing at the solution level. You could have an F# project containing your domain model, and a C# project in the same solution just fine - but it would be nice to mix in the same project.


I thought you could actually do that already?

I watched a talk about F# on YouTube recently and the guy said they used F# for domain logic and C# for plumbing code and he showed them working together...


The 'normal' approach to this is two different assemblies. There is, however, support in the CLR (I assume it still exists) for assemblies built from different languages - it's just not well exposed by tools.


Ah that must have been it.


As explained in today's https://news.ycombinator.com/item?id=21049374

> While early adopters may accept some problems on the way (like immature tooling), the majority expects a definite productivity improvement without disrupting the way they work (evolution instead of revolution).

Tooling in F# was/is bad for ages, and also lags in other areas. You have to put up with some disruption to your normal workflow to really embrace it.


i actually just did this in f# using the MailboxProcessor. it's beautiful. although, f# has had this since the beginning and is much cleaner being able to define the states and transitions using discriminated unions and having exhaustive pattern matching.


List of performance improvements is mind-boggling:

https://devblogs.microsoft.com/dotnet/performance-improvemen...

How could a mature standard library / frameworks have so much performance gains to be had?


And in 2.0 https://devblogs.microsoft.com/dotnet/performance-improvemen...

And in 2.1 https://devblogs.microsoft.com/dotnet/performance-improvemen...

3.0 has new JIT capabilities like CPU hardware intrinsics; devirtualization; Span etc which in turn enable new techniques in the standard library.

Though 3.0 is a vast set of improvements compared to the previous two


The "core" library was designed for portability and it's not as old as the .NET used for Windows desktop development, which is very mature and very performant.


.NET Core is faster than .NET Framework


One can hardly call .NET Core "a library." It's an API surface area (.NET Standard), a cross-platform implementation of said surface area (.NET Core), a cross-platform runtime (CoreCLR), and a CLI tool (dotnet). It's already introduced numerous performance enhancements over .NET Framework (e.g., Span<T>, Memory<T>, and the runtime itself).

IMO, .NET Framework should be relegated to the dustbin of history. There is no longer a reason to use it unless you are writing legacy code (which, granted, is a legitimate reason in many cases). For greenfield projects, I hope you're using .NET Standard and .NET Core.


I believe most of these are from Span which allows doing a lot of operations (e.g. substring) without allocating a new object.


Well, in the traditional desktop space performance was not that critical as it is with cloud deployments. Also hardware intrinsics are a new toy they have available.


Seems to me it was fast enough on the desktop and uniformly responsive to events. If you wanted a Windows CRUD desktop application, really nothing better.

I suspect that the CLI and the JVM are about as fast, about 2 to 10 times slower than C++. But that .nets libraries are more performant.


.NET started to barely surpass JVM with .NET Core 2, of course this is just a general tendency, actual performance depends greatly on the problem domain, how cleverly program, what counts as "java" and "c#" and so on.


To the point. Doing it right has a much higher influence than the platform. The later might be a barrier but at that stage, that often does not matter anymore. Even PHP utilized the right way (looking at swoole) can performance wise beat other stacks.

Disclaimer: I do not generally encourage the usage of PHP :)


A lot of work was done recently with compiler optimizations and using hardware intrinsics for core functions.


Would be really nice to see performance comparisons against a chromium equivalent for the same UX.


Memory usage difference should be something like an order of magnitude better with .NET.

It's not a direct comparison, because the features aren't quite the same, but the Electron Teams app uses about 10x more memory than the relatively heavy WPF Skype for Business client that it's supposed to replace.


Would be nice to get a source for this interesting claim.

But I'm far more interested by real world user facing performance metrics such as: FPS, vsync consistency, input latency and comparing cpu and gpu usage (thus allowing to infer battery usage).


Skype has been replaced by an electron app https://electronjs.org/apps/skype


Skype for Business is entirely unrelated to Skype. It's mostly a renamed version of Lync.


Chromium is naturally bloated and heavy, what would be the goal in comparing it to WPF


The goal would be to challenge your belief.

If you were knowledgeable, you would know for example that chromium 2D rendering engine (skia) is the current state of the art. Benchmarking fps, vsync stability, input latency, etc would be enlightening. There are order of magnitude more engineers working at optimizing chromium than WPF.


I think the OP meant "bloated and heavy" in terms of the sheer size of the thing, not the performance of it. And it is. It's very difficult to use _just_ the 2D rendering part of Chromium, you bundle the whole thing, warts and all.


Binary size is only one "performance metric" and arguably the less important one.

Anyway, did you know that chromium is the GUI framework that allow you to have the smallest Binary size? Instead of bundling it like you would with most GUI frameworks (GTK, QT) you can just use the locally installed chrome instance through Carlo.


I think it's a combination of monopoly effects plus the benefits of open source: back when .NET was closed-source and only available on Windows, the only way to ship a performance improvement was if an individual developer at Microsoft could convince his boss it was worth it. And it was rarely worth it, because .NET only ran on Windows, its only customers were .NET-only enterprise shops who weren't about to move to an entirely new framework because of perf problems, and there was always a long list of feature requests that PMs would give priority to.

But now that .NET runs everywhere, it has to compete with projects that have been shipping performance improvements all along. Happily, since it's now open-source too, it can accept those changes from anyone.


It is more about backwards compatibility than anything else. Remember that .NET Framework is something that ships with an operating system (Windows) and has components built on this shared runtime: not only devtools like SSMS and Visual Studio but core Windows components like MMC applets and things like ADFS / Remote Desktop Gateway as well. This puts up a bar regarding backwards compatibility. Not only code that is written against the runtime need to be compatible, but also code hosting the runtime, debugging the runtime, the profiler API, and I could go on.

This yields some constraints in whatever is possible changing. Want to add new IL instructions? No can do. Need to change the debugger API? No can do.

Please also see this: https://news.ycombinator.com/item?id=18364032


The "proprietary" .NET was very performant. It's the new "open" one that has to catch up.


You have posted something along these lines twice, it is not correct. .NET Core has been better performing than Framework from the start. You may be thinking of Mono.


Just an aside: Thanks for using "better performing" and not the non-existent word "performant." ;)


.NET Core isn't based on Mono.


Non nullable reference types are so awesome! I'd love for the C# team to publish some posts on the creation of this feature. Most of the non nullable type systems exist in functional, or pseudo functional languages (Rust has rather functional semantics). It's very neat to see a honest to god mutable object oriented language implement non nullability. They probably had some interesting implementation challenges.

Also, is Java working on this too? I heard that they have Maybe, but that's pointless without non nullability.


PHP has non-nullable reference types!

There are some really good write-ups by the C# team on the creation of non-nullable types and how it's implemented but my google-fu is failing me on it.

It's obviously a bit a of hack involving annotations/attributes but for the end user the result is pretty seamless.


Java does indeed have `java.util.Optional`. As a non-primitive type, it can itself be `null`, or be non-`null` but not contain a value.

In other words: I used to have `null` problems. Then I used `Optional`, and now I have two `null` problems!


Don't know about Java, but last I checked there were plans to add non-nullable reference types to Dart.


Kotlin has them too.


When I was in University people loathed .NET and idolized Java. Back then I choose C# instead of Java for my main language/toolset; People thought I was crazy. That was 10 years ago. So happy to see how much C# ecosystem has improved and keeps improving; Only thing missing for me is an official full featured C# to C++ transpiler; Only way, right now, of reaching game console platforms is by converting from C# to C++ unfortunately;


Or use Unity?


Yeah. That or using Monogame's Brute compiler. But a standard way would be good to have;


It's nice to see Alpine on the list of supported operating systems. The image mcr.microsoft.com/dotnet/core/runtime:3.0.0-alpine3.9 is 86.7MB.


I recently did a live coding tutorial on using SIMD intrinsics which is one of the big new features in .NET Core 3.0. It covers the basics of what is SIMD, what are intrinsics, and I do some live coding/benchmark examples in C# where I cover how to lay out data and use SIMD effectively:

https://www.twitch.tv/videos/482930779?t=00h09m01s


Is anybody using Blazor for anything that isn't a toy? I'm interested in using it at work but because it appears that the payload is relatively large I wouldn't want to use it for anything that wasn't internal facing.


Client-side Blazor is not production-ready with Asp.NET Core 3.0. It's coming in a later release and only server-side Blazor is launched today.

We've been using the server-side components for lots of internal apps. It's very fast and productive to work with, and a great option for internal/enterprise/LOB apps that don't have a lot of users and can handle an occasional reconnection/interruption.


We're exploring using server side blazor for a desktop app. You just bundle the "server" right into the app together with a webview to show your UI. No performance issues because there's only ever one user and you're not relying on a network (or mono or wasm). More exciting, it feels like C# in the browser, but there's no sandbox or threading limitations to speak of. So far it's pretty awesome.


>it appears that the payload is relatively large

Not knowing much about Blazor, what are you referring to here? The size of the WASM blob for your own code, or does Blazor have an associated runtime that's large? And what is considered "large"?


I guess I was hoping the WASM/IL trimming would be more aggressive. My comparison isn't very scientific, I'm mostly comparing things like https://fsbolero.io/TodoMVC/ which is done with Blazor vs https://yew-todomvc.netlify.com/ which is done with Yew. The former is nearly 6MB in total, the latter is 135KB.


Blazor client-side works by using the Mono runtime which is compiled and run as WASM. Your application is still delivered as standard DLLs and interpreted by that runtime.

They're working on making the runtime smaller and faster to start still a lag since your code has to be parsed and interpreted everytime, although the DLLs are pretty small already and easily compressed.


You might want to check out Oqtane for a Blazor framework. https://www.oqtane.org/


It would have been great if it allowed to make .NET Desktop apps for macOS and Linux, in addition to Windows.


We're trying to do that over at https://github.com/AvaloniaUI/Avalonia if you're interested. Doesn't have MS (or any other company's) backing, and is still in beta, but quite usable for creating x-plat apps. You can see some projects built on it here https://github.com/AvaloniaUI/Avalonia/wiki/Projects-that-ar...


I was surprised when the PowerShell team announced that Out-GridView made a reappearance in PowerShell Core, built with Avalonia. So at least someone at Microsoft took notice.

I'm really rooting for the project to gain some support. Right now I'd love to try porting our custom UI component at work to Avalonia, just to try it out. But that's time not well invested in something with little backing and potentially few customers for us.



Scott Hunter today presented a Blazor based Electron App in the .NET 5 timespan.

I am not the biggest fan of HTML, but considering the maturity of that ecosystem, design tools and knowledge among designers, that could be a very valid move.


.NET Core 3.0 will be available with RHEL 8 in the Red Hat Application Streams, after several years of collaboration with Red Hat.

That's a big deal! Nice.


If you dont know already:

Azure has started investing heavily in offloading the task from CPU to GPU and FPGA. There are really good framework on .NET to achieve the same.

NVIDIA CUDA GPU - https://devblogs.nvidia.com/hybridizer-csharp/

GPU scripting and CUDA - http://www.aleagpu.com/release/3_0_4/doc/

FPGA - https://hastlayer.com/project, https://netfpga.org/site/#/


> Nullable enables you to directly target the flaws in code that lead to NullReferenceException. The lowest layer of the framework libraries has been annotated, so that you know when to expect null.

I hope Java gets this one day.. would be a cool feature


In the JVM land you can check out Kotlin, which does this.


You can try checkerframework [1], which uses annotations to perform extra typechecking at compile time, including nullable/not-nullable checks. Works properly altough it has a few issues: the biggest is that support is still stuck at java 8, and the framework is sometimes not smart enough to see that you already checked if a nullable field is null or not and you can safely use it.

[1] https://checkerframework.org/


Annotations don't work for local variables, though. So you only get nullability checking around calling methods and accessing fields, right?


Annotations in general do work for local variables, although this is specified on a per-annotation basis.

If I remember correctly, for example, the @NotNull annotation in javax.validation.constraints cannot be used for a local variable, but the one provided by the checkerframework can.


Optional ? But redoing the standard lib would be no go in javaland ? It's the non nullable reference I find interesting.


The API hasn’t changed, and remains backwards compatible. However it has been annotated, so that when targeting it with a compiler configured to validate/verify nullability you get a better (read: safer) experience. It can configured as an error or a warning.

MS does this sort of thing a good amount, preserving backwards compatibility but enhancing the experience.


Too bad FreeBSD support didn't make it into this version.


Or indeed Linux x86 support :(


The only way to get C# 8 is to move to .NET Core, I can't really avoid this anymore. And for me it means moving to ASP.NET Core...

Anyone recently migrated projects from ASP.NET MVC to ASP.NET Core? I hope there is a gradual way, like this: https://www.hackernoon.com/how-to-migrate-project-from-aspne...


Not migrated, but we do a lot of CRUD based applications for clients and have a small dev team so it feels like we're kinda porting it over.

The largest change is dependency injection and Entity Framework. DI is insanely better and just more intuitive. EF is really a move from EF to EF Core which has quite a few differences that can introduce some road bumps.

In my opinion, I've gained the most from moving from HTML helpers in Razor to Tag Helpers. It's basically just components for Razor, but it allows us to make a really nice UI library and cuts down on so much of our markup without having to write a bunch of overloads for the same helper.

As far as MVC vs. Razor Pages, I'm still not in love with Pages. It feels a bit too much like ASP.NET Web Forms did. I still use MVC practices and it's almost the same exact experience. AJAX forms are a bit better this time around, but I'm really waiting until Blazor becomes more viable before I make a jump like that.


Doing a quick skim, it feels like that migration guide should still cover the basics. (I don't think there is a big developer-facing change between ASP.NET Core 2.1 and 3.0; small subtle things like the Generic Host Builder. But you should be fine using the guide here to migrate to 2.1 and you can find simple posts on the 2.1 to 3.0 changes.)


> The only way to get C# 8 is to move to .NET Core

That isn't true. You can target .Net framework 4.0 onwards.


I'm not convinced ASPNETCore 3.0 is ready to be used in anger yet. Perhaps this thread from a couple weeks ago is not representative, but I've seen other similar feedback

https://twitter.com/RickStrahl/status/1171285693244436481


For anybody interested, here for a short video on how to containerize an ASP.NET Core 3.0 Web API: https://youtu.be/Po9jQS7WBDQ


Sorry for a basic question, can this be used to make desktop apps across platforms?


Yes - while WPF and Windows Forms are still Windows-exclusive, there are several cross-platform UI libraries for .NET Core, like Eto.Forms (https://github.com/picoe/Eto) and Avalonia (https://avaloniaui.net/).

It's also possible to build an Electron wrapper around an ASP.NET Core web app: https://github.com/ElectronNET/Electron.NET


Docker is a better way to distribute apps than Electron, in my opinion. From a developer point of view you just build a regular web app, so better than Electron. From the user's point of view, Docker is better because of isolation, and because there is nothing to install. You run just one command to download and run the image. If you want the app to have its own window then use Chrome's "Create shortcut" command. This is indistinguishable from an Electron app, but better. See an app written in this fashion here: https://hub.docker.com/r/eurekasearch/eurekasearch


"From the user's point of view, Docker is better [...] run just one command" Nope. Your "better" solution just became fundamentally impossible for 99.9% of users.


See https://kitematic.com/ it is a UI for starting containers.


For the end user there is something to install - specifically, Docker, which is quite... hefty on Windows


I've had to debug every install of docker for windows that I've done because it doesn't set something up correctly. Usually this involves googling the error message, finding a github thread where people are talking about which builds this affects, and then trying one of three or more powershell commands to fix whichever part of the install failed. In the most recent attempt, the error message told me to enabled virtualization in the BIOS, but it was actually that HyperV had not been enabled properly[1]. It was installed and the UI ran, but if you tried to start any VM, it would fail. I doubt debugging this sort of thing is feasible for an end user.

[1]: https://stackoverflow.com/questions/39684974/docker-for-wind...


If I remember correctly it also requires windows pro or enterprise.

These 2 requirements make this fundamentally unusable for most.

- Windows 10 64-bit: Pro, Enterprise, or Education (Build 15063 or later). - Hyper-V and Containers Windows features must be enabled.


Docker Toolbox, although less polished, is based on VirtualBox and happily runs without Hyper-V. The only thing I've found missing is the control panel GUI.

https://github.com/docker/toolbox


Don't forget it requires HyperV as well


A basic requirement for distributing desktop apps should be not requiring root to install/run them.


I don't know about Eto.Forms but from what I have tried of Avalonia I'd say It could only be used for toy projects: there is almost no documentation, there are missing features like app icons, system tray, etc. Maybe in a few years It might be good, but I'd stay away from .net if the purpose is to have a cross platform GUI app


The short answer is yes.

How you approach this is very dependent on where you're coming from (i.e. existing solution) but with WPF and Winforms now part of Core 3.0 you can then build a native, single exe by specifying the target architecture (ex: win x64) and then bundling the framework with your app. They do some trimming as well (i.e. tree shaking) to get the exe size down but have admitted it's still in early stages and sometimes drops required framework components. You can fix this by adding an explicit reference to the assembly in your project source though...

There are a million ways to get onto different platforms though, ranging from the above, to xamarin to electron (via blazor), to net-new apps, etc.


This is a good leap release from msft.


C# (the default .Net lang) has so much ceremony, boilerplate/scaffolding and IDE dependence (IDE programmers) and OOP overhead that it requires 5x more lines of code than the same app in Python or Go. Every time my interest peaks, I take a look leave with the same feeling that it's a dated/bloated OOP relic and would take all the joy out of programming. I've also noticed that most C# programmers don't usually know another language (other than a little JS) and seem totally dependent on Visual Studio; if all they had was a text editor they'd be lost. That's not a good place to be.


C# has very minimal boilerplate for a lot of uses. I can throw together a simple CRUD UI app in WinForms in well under a day. Visual Studio handles writing all the data binding code for me, code that I'd have to write myself in any other language.

Using one of the enterprise frameworks, sure, those all have boilerplate, in any language, especially the older frameworks.

And for some tasks, the amount of boilerplate is tiny. I can write out a struct/class with property names matching my JSON, and watch as C# automatically data binds the JSON to a UI. The amount of boilerplate I need to do that in the browser is pretty much identical, or I can learn / figure out some fancy auto-binding toolkit that has its own boiler plate and learning curve.

You can be seriously functional in C#. Passing around lambdas and using functional techniques to manipulate data has been idiomatic C# for over a decade.

> I've also noticed that most C# programmers don't usually know another language

Stereotyping is not good. I <3 C#, but I've written embedded C, C++, JavaScript, Typescript, and Python.

If you go to most corporate dev places, you will find a significant population of single language devs. Same things happen with any popular corporate language. While I agree that learning multiple programming languages makes for better developers, blaming a language for being popular is hardly fair.

Heck the number of developers who have historically only worked in C/C++ was really high for multiple decades.


Under a day ?? Make an app with pyqt5 or kivy and it's under an hour...


> Under a day ?? Make an app with pyqt5 or kivy and it's under an hour...

Last CRUD app I did in WinForms:

1. Auth

2. Real time push updates from my database

3. Platform native looking UI

4. Automatic 2 way data binding between my backing JSON and my UI controls.

I hadn't used C# for ~2 years, I had never used that particular DB library or done any work with JSON in C#.

I got it done in under 4 hours.

If I did it now, yeah, even faster.

The amount of code I wrote is insanely tiny. I wanted some custom date/time formatting stuff so I had to implement that myself.

I just checked the source out, I wrote under 120 LOC total, and that is including the repetitive ~70 LOC I did for handling days of the week and auto-formatting user entered times. (Time sucks, working with time sucks.)

Without that my code would've been limited to:

1. Wiring login button up to sending username/password to the DB 2. Attaching a listener to the DB (C# has had native event handling as a primitive type since forever!) 3. The save button to push stuff to the DB.

Did I have to drag and drop some UI elements onto a page? I sure did. It was rather nice.

WinForms was the go to solution for CRUD apps for a reason. Sure VB6 was probably better at popping CRUD apps out in no time, but after that died out, WinForms was a really good replacement.


It would be cool if you had a demo to show this off. That way you can add a lot more heft to all of your arguments about this subjects, and we can all learn something from it.


Kivy is a broken pile of patches. You must be trolling.


I think you might want to take a slightly different look at it as I have found the opposite.

You also might need to find better C# programmers as I honestly don't know any C# programmers who only know one language or one editor. An awesome IDE is big perk to development. I don't think that should be considered a con.

.NET also has tons of "magic features" like Data Annotations & Attribute Tags for those who want some magic that reduces code & helps get stuff done faster.

JS & other languages reference it when looking to introduce new features.

C# is anything but dated. One could call it bloated as it is one of the most flexible languages with about 10 ways to do anything. That is a strength & a weakness of any language that positions itself as a Swiss army knife type tool that wants to be able to be used everywhere. With C# you can write a lot of nice fairly functional programming style code & OOP code which is a nice perk.


If you're interested in .net and the clr, you could replace c# with f#.

It's the most practical functional language that I've tried. Great for domain modeling and it can used in C# projects.

I also think that c# is too verbose so what I normally do: asp.net core mvc for routing, templating, authentication / authorization, data access etc and then reference an f# project that contains the domain logic. The best of both worlds.


As a complete newbie to .net, I’ve tinkered around with f# for a web app and quickly got frustrated. I like the sound of your approach. Do you have any links / resources for the best way to get started with your approach?


Don't try to start with a web app. I'd recommend looking into Fable (the F# to js compiler). Write f# and run it in the browser, I found it to be a better and faster feedback loop when compared to a .net project.

Play around with the f# language (don't touch the js inter-op) until you can figure out if you actually like f#. Take it slow, it's not just a new language, it's a different paradigm. If you get frustrated, take a break for a few days, watch some f# videos and let the knowledge settle. You'll eventually start having evrika moments.

Look into other functional languages. Maybe you'll like others more. Accumulate knowledge and experience until you start thinking "I could do this a lot simpler in f# (or other lang)".

Then, if you want to use f# in a c# project you just need to learn how to reference a project in another project.

If you want some resources: https://fsharpforfunandprofit.com/video/ some of these videos can get you "hyped up" for functional languages

https://www.youtube.com/watch?v=4YO4XmtPFQw

https://www.youtube.com/watch?v=EPfpO_6uFAA

the entire https://fsharpforfunandprofit.com/ site is a good resource to learn everything from the basics to the wizard level stuff.

As an editor you can use Visual Studio but I'd recommend Visual Studio Code with the Ionide extension.


If your writing a web app I've heard good things about Giraffe (https://github.com/giraffe-fsharp/Giraffe). It seems to even have a project template via the "dotnet" command to get a quick web app running. With F# I personally find Rider or VsCode better IDE's than VS as well. The workflow in F# is more like my experience with scripting languages than something heavy like Java/C#; you don't lose much by going to a more lightweight IDE and a lot can be done via CLI commands and text editing in .NET Core.


If you're writing boilerplate code in C#, it's either because you prefer to be explicit, or because you don't know how to use reflection and dynamic compilation yet. Using C# without reflection is like using Scheme without macros. That said, just like macros lead to DSLs, reflection leads to custom frameworks which then have to be explained to newcomers. It's definitely a cost/benefit thing, and there's an argument against ever using reflection. I can't live without it at this point though. You could say I've 'gone through the looking glass'.

If you're a C# dev who hasn't dug in to reflection yet, the gist is that all the things that the MVC, ORM, DI frameworks do, you can also do. This allows you to build custom frameworks which eliminate boilerplate.


I'm not sure about the comparison to Go as that can get very verbose. Same with Python. And JS is an absolute mess compared to C#/.NET which has a fantastic standard library and many conventions to get going fast.

.Net (and Java) run the Fortune 1000 so there will of course be lots of devs specialized in that. There's nothing wrong with being very good with 1 language and stack when you're paid to be productive for the company. Also you can definitely write C# with a simple text editor if you have to, and VSCode is pretty slim already, but why would you want to when there's such a powerful IDE available?

This sounds like a purity argument about how to be a "real programmer", but I would much rather work with people who are good at what they do and get things done instead.


That was a lot of predispositions. I can say for sure I've never scaffolded anything in C#, I can write a fully functional web app using Notepad++, the different parts of the startup are not hard to memorize, and I can't imagine scaffolding being useful in a console application.

Yeah, it requires more lines to achieve the same thing in other languages, that isn't a pro or con.

And myself personally, I started with Basic, and have used C++, C, Python, Java, JS and C# throughout my career, but I'm also sure you can find many more Python/Go developers who only know Python/Go

It'a unfortunate you don't like the language and I hope Microsoft and the open-source developers continue to add more features so that one day you'll find the joy may developers have found in using C#


> console application

I wrote a console application to splat some addresses in a hex file with version info and keys. Difficulty you want to be able to diff the files afterwards. Was pretty trivial.


I don't get why people don't like IDEs. If you're digging a ditch you're dependent on your shovel (or even better, an excavator). You can do it with your hands, but why would you want to? Just as the shovel magnifies your digging capacity, the IDE magnifies your capacities as a coder.


C# developer here. I picked up Java very quickly... most other OOP languages comes pretty easily as well, after learning the syntax that is.

But I definitely lean on the intellisense of the IDE fairly regularly, I don't think I would completely lost, but it would take me longer.


Break the bubble, talk to more C# devs from different kinds of businesses.


Often, you have to make a serious effort, and that goes for all sides.

"talk to more C# devs from different kinds of businesses"

As a PHP dev who's done C#, Java, Perl, CF, VB and more... I'd rarely find any other PHP devs at our local MS and Java user groups. In a few cases, I was the first "PHP developer" some of these people had ever met.

Java/C# tend to be used in larger enterprises, and they tend to be used by people who are... somewhat more 'corporate' in their life. Go to work, do the job, go home - going to local groups/conferences and socializing with non-work tech folks is often not high on their priority list (family, etc may rank higher).

Maybe it's generalizing some, but it's also a lot of my experience over the past 20+ years. I've met some phenom tech/dev folks at pretty much every event I go to, and I meet more "professional" polyglots today than I did 15 years ago, but I found I had to make an effort to find them (beyond just going to my own favorite events).


Friend of mine mentioned their boyfriend is a corporate dev who programs in C#. Guy doesn't seem to mind that the work is boring and repetitive. Just he gets paid well, doesn't work too hard. Gets 6 weeks of vacation. Which is helpful because his mom and cousins all live in China. And his coworkers aren't a bunch of assholes. (If you're too much of an asshole where he works the boss pushes a button and you get managed out)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: