Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Update to the .NET language strategy

devblogs.microsoft.com

Post reply on HN
Print view View original

61–70 of 151 posts

Re: Update to the .NET language strategy

#61

Post by foobarbaz33 »

bmitc wrote: post #56
LAC-Tech wrote: post #52

Earlier quoted context omitted.

I remember that being missing for years. Nice.

The transition from .NET Framework to .NET Core and then to .NET 5+ was rough on F#, but it's been a net positive in the end. The .NET SDK and thus F# is one of the easiest things to install on nearly machine.

> to .NET Core and then to .NET 5+

Just to nitpick. Core -> 5+ was not really a transition. Just a rename to drop the word "Core". Core is still itself, still Core, just no longer called Core.

The old .NET is frozen at version 4.8. So Microsoft felt there was no longer a need to refer to Core as "Core" once it hit version 5+. Maybe a bit premature as the old .NET is still in heavy use. Now it's always unclear which .NET someone is talking about because they say ".NET" which may refer to the old .NET or maybe the new .NET formerly known as "Core".

Re: Update to the .NET language strategy

#62

Post by malkia »

JonathonW wrote: post #36
jimbob45 wrote: post #30

Don’t they offer C++ on .NET to some degree? I know it’s not supported on the same level as C# but it’s still there, is it not?

That's C++/CLI; it's still around but isn't really a priority nor is it considered a "core" .NET language these days (it's an optional install in VS2022): https://learn.microsoft.com/en-us/cpp/dotnet/dotnet-programm...

AFAIK, it relies on MSVC and OS specifics, hence may never see the light beyond MSVC/Windows. There were several big github issues of folks converting from C++/CLI to other ways..

Actually this survey from 2020 - https://github.com/dotnet/runtime/issues/40484

Re: Update to the .NET language strategy

#63

Post by mythz »

jameshart wrote: post #57
viraptor wrote: post #15

Earlier quoted context omitted.

* for serverside

Unity3D is probably one of the most widely used cross platform native app development platforms, and it’s taking c# .net code to Linux, macOS, android, iOS and browsers via wasm.

This doesn't speak to the cross-platform .NET Core runtime as Unity3D is built with C++ and still uses their modified fork of Mono to run C# code whilst their WASM uses their IL2CPP tool to convert .NET byte code to C++ before using Emscripten to convert to WASM.

Re: Update to the .NET language strategy

#64

Post by jayd16 »

zengid wrote: post #38

Hot take but I wish they’d start a new lang in the spirit of what’s happening in swift/Kotlin instead of evolving C#. I use it everyday. I love the new pattern matching, it simplifies a lot of gnarly reflective type checks and feels good. Records are nice too. I see discriminant unions are coming soon. But they’re painting themselves into the corner in terms of syntax and overcoming OOP defaults. A fresh start would…

So what's happening in swift or kotlin that's out of reach for C#?

Re: Update to the .NET language strategy

#65

Post by jchw »

bmitc wrote: post #45
jchw wrote: post #27

Earlier quoted context omitted.

On Linux, I don't think Mono is irrelevant. It would not be abnormal to have both upstream dotnet and Mono on the same machine for desktop Linux.

For a new project that isn't Unity or Godot based?

Mono's toolchain is entirely open source, but crucial parts of Dotnet core are not, such as the debugger. Linux developers are significantly more likely to care about this discrepancy.

Re: Update to the .NET language strategy

#67

Post by jchw »

mattmanser wrote: post #42
jchw wrote: post #17

Earlier quoted context omitted.

C# support should be pretty good. You've got options. You can use the Mono ecosystem, including the MonoDevelop IDE, Mono runtime, and libraries like GtkSharp; these have been around for a while and some Linux desktop apps use it. You can also use the official Dotnet SDK and runtime, which lacks some stuff that Mono has for compatibility (like Winforms) but should have a good developer experience in either VSCode or…

This seems like completely out-of-touch info. You can run C# with .Net Core on linux now easily, no Mono involved and have been able to for years. TBH, I thought Mono was dead. If it's not it's an extremely niche thing of people who want to write desktop apps for linux in C#, a tiny slice of the market. I've run production ASP.Net core apps on linux (basically websites in C#), trivial to setup, even though I develop…

I mentioned the official Dotnet SDK. You're out of date; it's not called Dotnet Core anymore; just Dotnet.

Mono is not dead. It's used in a bunch of commercial software for one thing, including Unity and Godot.

> If it's not it's an extremely niche thing of people who want to write desktop apps for linux in C#, a tiny slice of the market.

Can you think of why, other than marketshare, that I might mention Linux C# desktop apps in a thread about C# on Linux?

Re: Update to the .NET language strategy

#68

Post by mythz »

jchw wrote: post #67
mattmanser wrote: post #42

Earlier quoted context omitted.

This seems like completely out-of-touch info. You can run C# with .Net Core on linux now easily, no Mono involved and have been able to for years. TBH, I thought Mono was dead. If it's not it's an extremely niche thing of people who want to write desktop apps for linux in C#, a tiny slice of the market. I've run production ASP.Net core apps on linux (basically websites in C#), trivial to setup, even though I develop…

I mentioned the official Dotnet SDK. You're out of date; it's not called Dotnet Core anymore; just Dotnet. Mono is not dead. It's used in a bunch of commercial software for one thing, including Unity and Godot. > If it's not it's an extremely niche thing of people who want to write desktop apps for linux in C#, a tiny slice of the market. Can you think of why, other than marketshare, that I might mention Linux C# des…

> it's not called Dotnet Core anymore; just Dotnet.

The platform has been renamed to ".NET" (since v5), the SDK is ".NET SDK" the executable is named "dotnet", but it has never been branded that way.

Re: Update to the .NET language strategy

#69

Post by jp0d »

starik36 wrote: post #29
ricksmith1962 wrote: post #6

Earlier quoted context omitted.

Absolutely. Saying this as someone who codes 100% in VB supporting applications that are 25+ years old. Honestly, I couldn't be happier with the language strategy as I was wholly expecting VB to be discontinued.

.NET itself is about 20 years old. How are you supporting VB apps that are 25+?

Visual Basic is more than 40 years old. The .Net version of the language was released somewhere around 2002, if I recall correctly.

Re: Update to the .NET language strategy

#70

Post by layer8 »

BenGosub wrote: post #58
Arnavion wrote: post #48

Earlier quoted context omitted.

.Net itself is fundamentally OOP. Lambdas are implemented as classes with an Invoke method, F# enums are implemented as classes with variants as subclasses, etc. So if "overcoming OOP defaults" is the goal then making a new .Net lang that isn't OOP doesn't achieve much. So it would have to be either be a new native language, or a new managed language that also comes with a whole new managed runtime. For the former, R…

How come classes are being used in a functional language?

Closures and objects are very similar: a bunch of data with associated code that you can call.

See also https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent.

Post reply on HN