Live data from Hacker News

Update to the .NET language strategy

devblogs.microsoft.com

41–50 of 151 posts

Re: Update to the .NET language strategy

#41
> F# explores new language possibilities and the community provides a rich experience across platforms.

There are several interesting observations to be had here. For one, F# already explored (past tense) new language features and has long been essentially feature complete. It gets little features here and there, which are generally quality of life type of things (like anonymous records, for example).

Another interpretation is that F# is just viewed as a .NET/CLR playground and prototype lab to bring features into C#. This is already a common sentiment, but it looks like Microsoft just came out and said it here.

I'll need to read their full strategy, but the blog post is just the same old story: C# is everything, we'll limp along F# with the community doing most of the work, and, oh yea, Visual Basic.

I read through the F# strategy documents, and there's not really anything of substance there. I'm also not sure it's in F#'s best interest to be forced to comply with new C# features (of course F# needs to adopt new .NET features though). F# already does not support several C# features, for good reason, maintaining only what it needs for interoperability purposes. This just furthers the idea that F# is C#'s playtoy.

It's all unfortunate. F# is one of the best designed modern languages around. I wish people would embrace it like Elixir has been embraced. F# could truly be one of the more popular languages and doesn't have to be used at just ".NET shops".

Re: Update to the .NET language strategy

#42
post #17

How well are F# and C# supported on the Linux platform?

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 on Windows.

Re: Update to the .NET language strategy

#44
post #39

How well are F# and C# supported on the Linux platform?

At work our C# codebase never touches Windows (all developers except me use MacOS, I am testing Linux). Production is Linux. We all use Rider, which pretty good (but extremely crashy when debugging). Probably in the region of 500Kloc.

What sort of system is it? Linux is reportedly around 30Mloc, Chrome around 5Mloc.

Re: Update to the .NET language strategy

#45
post #27
post #22

Earlier quoted context omitted.

F# comes with the .NET SDK. Once you install it, you get F#, so F# isn't behind at all. Mono is largely irrelevant except for legacy applications things like Godot and Unity that use Mono.

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?

Re: Update to the .NET language strategy

#46
post #44
post #39

Earlier quoted context omitted.

At work our C# codebase never touches Windows (all developers except me use MacOS, I am testing Linux). Production is Linux. We all use Rider, which pretty good (but extremely crashy when debugging). Probably in the region of 500Kloc.

What sort of system is it? Linux is reportedly around 30Mloc, Chrome around 5Mloc.

My bad, I corrected the unit.

Re: Update to the .NET language strategy

#47

Sounds like Visual Basic will be a second-class citizen going forward.

VB.NET should never have happened. It has only superficial similarity with VB6. It was sold as upgrade path from VB6 but that never worked.

I disagree. It only broke backward compatibility with VB6 when VB6 didn’t make any sense. Like byref arguments by default, or the useless “set” keyword, or collections being inconsistently 0 or 1 based, stupid constraints on what types you can expose as a field or property in a class, or no way to distinguish empty strings and null. Having done the transition from VB6 to VB.net, yes there were a few things to learn but that was the only way to move on from legacy design choices.

Re: Update to the .NET language strategy

#48
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…

.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, Rust is already satisfying that need within Microsoft. For the latter, there's even less demand both inside and outside.

Re: Update to the .NET language strategy

#49

How well are F# and C# supported on the Linux platform?

My day job is to work on the .NET runtime and I do 99% of my development in a debian VM (remoting in with VS code as my text editor). I can't remember the last time I hit a platform specific roadblock or needed Windows to do something.

Re: Update to the .NET language strategy

#50

Earlier quoted context omitted.

Huh? F# has Microsoft Research building it and its libraries and optimizing compilers, no?

I think GP gave a cynical, but fairly accurate summary. If F# is worked on by MS research, they certainly didn't communicate that in the strategy they just published. C# >We will keep evolving C# to meet the changing needs of developers and remain a state-of-the-art programming language. We will innovate eagerly and broadly in collaboration with the teams responsible for .NET libraries, developer tools, and workload…

Yeah, it is strange that they did not mention that part of F# directly, only obliquely in saying that they maintain compilers and toolchains and runtimes with extensive community support, or something similar, perhaps on the linked page.

https://www.microsoft.com/en-us/research/wp-content/uploads/...

There's an example of a Microsoft Research paper on F#.

Post reply on HN