Live data from Hacker News

.NET Core 3.0

devblogs.microsoft.com

131–140 of 183 posts

Re: .NET Core 3.0

#131

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

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

Re: .NET Core 3.0

#133

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 an…

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.

Re: .NET Core 3.0

#134
post #102

Earlier quoted context omitted.

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 y…

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.

Re: .NET Core 3.0

#135
post #61
post #46

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.

Re: .NET Core 3.0

#136
post #128

Earlier quoted context omitted.

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.

Re: .NET Core 3.0

#137

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,…

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!

Re: .NET Core 3.0

#138
post #25

Earlier quoted context omitted.

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.

Re: .NET Core 3.0

#139

Earlier quoted context omitted.

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. Thi…

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

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.

Re: .NET Core 3.0

#140

Earlier quoted context omitted.

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. Thi…

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

Don't forget it requires HyperV as well
Post reply on HN