Microsoft Outs .NET Core 3.0 With Continued Linux Support & Better Performance

[devius]

My 2 cents...

You missed the point that smitty was making a joke.

[kpedersen]

I can't wait to see all of the comments complaining about how they'll never use this as it's from Microsoft.

This is a pretty exciting release for .net core, which is fast becoming a swiss army knife solution to a lot of different problems.

No. I will never use it because the whole idea of a big monolithic, difficult to port VM is archaic; dating back to Styx / Limbo on Plan 9 and at least made marginally portable (or at least ubiquitous) by Java.

I will never use C-sharp because it is time wasting to integrate this to our existing middleware written in industry standard C++ (which is what well engineered software is generally written in).

And finally, I will never use any technology from Microsoft because it will be dead long before a substantial project using it is finished XD

[Vistaus]

And finally, I will never use any technology from Microsoft because it will be dead long before a substantial project using it is finished XD

Eh, aren't you confusing Microsoft with Google? Google is the one that constantly introduces new things and then kills them off whenever the devs get bored. Microsoft usually supports a lot of stuff for many, many, many years.

[Kushan]

The new Java!

*runs* :P

Oh, you! 😂

I watched the day 1 youtube video, when Olga published the tiny simple Weather app, it produced a 89MB exe in around ~50sec of publishing time. When she launched the same compiled app, it took 22 seconds, from the launch to the app openeing on the desktop. I'm waiting to see metrics on a real big app.

The framework may be out of beta, but I'm not sure I would use that in production.

Also take note that by default, it send telemetry information to Microsoft by default (even on linux). You must disable it manually when you launch your app with an environment variable.

Yeah, the "single EXE" output is currently massive because it contains....well, everything, every library, mscorelib, the whole shebang. It needs serious optimising for it be useful beyond "use this single .exe without needing anything else installed". They even said it's basically a self-extracting archive containing your real .exe and DLL's, that's why it took so long to start up, though they claim that's a one-off startup (extract) cost, I wouldn't want to use that in production.

[QUOTE=kpedersen;n1128128]

No. I will never use it because the whole idea of a big monolithic, difficult to port VM is archaic; dating back to Styx / Limbo on Plan 9 and at least made marginally portable (or at least ubiquitous) by Java./QUOTE]

It's not that big or difficult to port at all. The work has been done already, hence why it works on x86, x64 and ARM. Your "big VM" runs on anything from a fully-fledged server to a tiny IoT device. Hell, you can even run it in your web browser now.

I will never use C-sharp because it is time wasting to integrate this to our existing middleware written in industry standard C++ (which is what well engineered software is generally written in).

Quite a few blanket statements here! I wouldn't want anyone to use C# where it doesn't belong. Use the right tool for the job. As for C++ - it's great and has its place, but I'd argue Linux is well-engineered software and it sure isn't written in C++.

And finally, I will never use any technology from Microsoft because it will be dead long before a substantial project using it is finished XD

.net has been going for near 2 decades now. They have a roadmap for .net core that extends to at least 2024, with 3-year (minimum) LTS versions every 2 years. It's also all completely open source now. It can't die.

[kpedersen]

As for C++ - it's great and has its place, but I'd argue Linux is well-engineered software and it sure isn't written in C++.

Linux isn't middleware. C is much easier to bind to using other languages than C++. Unfortunately industry standard middleware is C++ and to bind to that from other languages you have to end up writing a C wrapper around it and then a i.e .NET wrapper around that. Big ol' waste of time. Use the right tool for the job and since C++ exists, that is never C-sharp / VB.NET

It's not that big or difficult to port at all. The work has been done already, hence why it works on x86, x64 and ARM. Your "big VM" runs on anything from a fully-fledged server to a tiny IoT device. Hell, you can even run it in your web browser now.

Porting it to the web is the reason why UE4 (via Emscripten) supported pluginless web exporting over 3 years before Unity.
Unity as an example invested in a transpiler to convert the .NET bytecode to C++ to compile for the web. The reasons why they did that is all great evidence as to how the .NET platform is unportable. Also, more platforms exist than x86 and ARM XD.

.net has been going for near 2 decades now. They have a roadmap for .net core that extends to at least 2024, with 3-year (minimum) LTS versions every 2 years. It's also all completely open source now. It can't die.

That is a very small amount of time; especially if you consider the breakage in that time and try to compile or run a relatively complex bit of C# 1.0 code on a current VM, you will see that it doesn't work too many libraries have changed. Try to get an ASP.NET app from 10 years ago running as an example.

Also open-source can very much die if it is not portable and does not have maintainers. Hence why Qt 1.x, KDE 3.x (including forks), dotgnu, Microsoft Rotor (shared source) are not in most repos. Heck many distros can't even keep 32-bit binaries alive these days, this is especially crucial for things like .NET's JIT and low level compilers.

[fuzz]

Unfortunately industry standard middleware is C++

What is this "industry standard" you keep mentioning? In my industry, the standards are C# and Java. Could it be that your perspective is limited to the work you do?

[pal666]

I'd argue Linux is well-engineered software and it sure isn't written in C++.

it was written when c++ wasn't available

[ed31337]

And finally, I will never use any technology from Microsoft because it will be dead long before a substantial project using it is finished XD

This. So much this. Microsoft has a long and proven track record of pulling the rug out from under their third party developers, over and over again.

How else could they make money if they didn't come out with something new all the time to obsolete all the old stuff? Meanwhile, I've been using gcc off and on ever since the DJGPP days. The same old code still compiles and runs just as it always did. And when Qt came along, it made cross-platform GUI's so easy. Qt had it's own changes over time, but they were gradual and gentle enough to not become a problem the way Microsoft made things always problemic.

[ssokolow]

it was written when c++ wasn't available

It's possible to incrementally switch a codebase from C to C++ but that's not the big problem.

Both the Linux kernel developers [2] and the Microsoft kernel developers agree that lots of C++ language features don't play nice with requirements for kernel-mode coding, so you wind up using a very restricted subset of C++ if you go that route, removing most of the worth in doing it and risking adding "subtly problematic language constructs creeping in" as another threat to be audited for.

The OSDev Wiki gives a neutral rundown of what you have to implement, modify, or disable/avoid to make C++ suitable for kernel development.

[pal666]

It's possible to incrementally switch a codebase from C to C++ but that's not the big problem.

it is possible to switch, but it is harder to switch than to do it since beginning

Both the Linux kernel developers [2] and the Microsoft kernel developers agree that lots of C++ language features don't play nice with requirements for kernel-mode coding

lol, you are quoting people who think that c++ is object oriented language. garbage in - garbage out. all this on top of extensive manual oop in kernel
ms post discusses something entirely irrelevant for linux kernel. and for non-msvc c++ in general. nevertheless, in summary it says "Microsoft neither endorses nor prohibits the use of C++ for kernel-mode drivers." and "Microsoft is actively investigating ways of making C++ more usable in the kernel"

, so you wind up using a very restricted subset of C++ if you go that route, removing most of the worth in doing it and risking adding "subtly problematic language constructs creeping in" as another threat to be audited for.

i know many large projects using restricted subset of c++ and none of them wants to switch to c. btw, kernel is already written in very restricted subset of c, so this point is moot.
arduinos are programmed in restricted c++ because nobody told them that restricted c is better.
it's like "if you are going to lose your legs, why don't lose your hands at the same time".
plain c has no shortage of problematic language constructs like pointer casts or macros

The OSDev Wiki gives a neutral rundown of what you have to implement, modify, or disable/avoid to make C++ suitable for kernel development.

no, this wiki discusses some (compiler-specific)implementation details, not something inherent to c++.

in any case, to disprove any number of "it can't be done" i need only one counterexample. https://en.wikipedia.org/wiki/IncludeOS