Update to the .NET language strategy
devblogs.microsoft.com
devblogs.microsoft.com
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".
F# is a lot more popular than Elixir.
I’m sure some false positives, but I doubt enough that brings the F# count lower than that for Elixir.
ymmv
Could you enumerate some of these? My team is still using .NET Framework, so we're missing out on the new C# goodness.
F# is truly a full stack language now.
Elmish.WPF, FParsec, so much there and still things to do...like better development tooling with VS Studio Pro.
If it were a sure thing it wouldn't be a challenge or quite as interesting.
It’s fully cross platform now and works flawlessly on Mac/Linux for backend work.
Entity Framework Core has become a great ORM that’s getting better every year.
It’s in a great place to develop your next startup/project in.
I’ve switched from Python to C# last year and couldn’t be happier.
You get consistent ecosystem with top tooling, strong standard base class libs and good UX.
What language did you come from? Java?
GUI frameworks don't consider Linux a deployment target, not even MAUI with its Xamarin heritage.
Due to its Windows original focus, lots of libraries still rely on Win32, COM and other Windows specific issues. This also inhibits most big name CMSs, which still rely on .NET Framework, e.g. Sitecore, SharePoint, Dynamics,....
Targeting Linux containers is usually only done by us if writing greefield microservices without many dependencies outside the standard library.
The Rider licensing cost is negligible when compared to a developer's compensation.
No need to pay for Rider licenses on top of the VS ones we already have.
I don't even use VS on subdued installs anymore, it's no longer the better option.
Some libraries thought of as C# are bindings to Windows OS things, so those are platform specific.
You've really got to read the Microsoft Learn pages to get higher resolution for an answer, though.
I don't know much about F#, but it seems F# isn't far behind. There's a useful page about getting started and other than the omission of Mono it is similarly supported.
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.
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?
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.
Right, IMO it's important to use these official correct labels when correcting someone.
"Dotnet" looks like an unintentional Autocomplete error. The executable and repo names use "dotnet" since using ".NET" or previously ".NET Core" would be awkward and unconventional.
I'm assuming "Golang" is used because "Go" is a generic ungoogleable word, any language without this issue e.g. Python, Java, Kotlin wouldn't need to make such concessions.
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".
We've been developing on Windows and have been deploying exclusively to Linux since 2017, everything runs flawlessly. Only time where the deployed version was different was when the locale wasn't set in a Docker container.
Developing on macOS has an issue with running HTTPS/2 and gRPC endpoints which should be resolved in .NET 8 [1].
The notable part where .NET Core is lacking vs legacy Windows .NET Framework is graphics, i.e. System.Drawing and all Desktop GUIs, otherwise it's a first class cross-platform runtime.
I have a handful of smaller programs built on the SAFE stack. They're all F# and run very well on Linux. We use a lot of Excel interop so that is a no go on Linux but that is the only limitation I've found. It's not hard to have a server with an Office 365 license to run all of our Excel processing.
Azure Data Studio is on its way to being a nice cross platform environment for databases, but it's not fully cooked yet. It was progressing really well but the last few months, it's been really slow to start the execution of any query for some reason. Hopefully they will fix that soon.
Both environments are plug-in based and there are a lot of good free ones available. You should definitely check it out.
Rider is your friend.
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.
See also https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent.
I mean, going beyond the sarcasm, ultimately C# copied most (if not all) the Java design decisions:
* OOP baked in (more like hardcoded into the execution model)
* Heavyweight VM that needs to be installed apart, that tries to achieve better performance by using way more resources (runtime/VM that needs to recompile the code multiple times instead of ahead of time compilation)
* 1 main OOP language, a few second class citizen languages
* Claim to be 1 stop shop for all development needs, falls short by pretending all development needs outside what it covers to be invalid/inferior
* Sold to managers as the magic way to have cheap replaceable developers
VM doesnt have to be installed, you can deploy the single file app with it + there is AOT too
Btw. C# has reified generics
Ocaml has a VM which is included by default (70kb), and can also compile to native (skip the VM altogether). It has been like that since at least 2002 (the first time I checked it, probably before that).
Haskell has HKT, which generalize generics.
Java and C# share 95% ideas in comparison to stuff outside Java/C#. That's why the comparison is boring: there is very little to compare.
Another differences
Approach to async
Approach to ecosystem fragmentation
Approach to GCs
In general people would argue that C# > Java, but JVM > CLR
Yes, I'd like Java's ability to use and tune different GCs to be available in other places.
Async is pretty much the colored vs non-colored function discussion, for which there are good arguments on both sides.
Related to C# being better than Java, I think it is, but not in a significant way. If Java uses 100% boilerplate, C# uses around 90% boilerplate. An improvement indeed, but way more progress can be achieved. And then C# has some questionable features (extension methods: methods for a class but that are not part of the class code).
Related to VMs, JVM may be better than CLR, but again both of them have an unacceptable footprint because you have to educate the final user on managing the internals of your application (yay I have to install, update and be wary of exploits for the Java Runtime/.net redistributable, and then different versions are subtly incompatible, so to use program X I have to uninstall the version I use for program Y).
I dont think people share this opinion.
Extension methods are very handy and powerful while being simple and you can see how similar vision works well in Rust: impl trait for type
It allows e.g library makers to create strong small core and users/community to create their wrappers/integrations easily
Imagine having to create a monad, including the `pure` and `bind` operations every time you want to increment a variable. That would be bullshit, well, because it's bullshit. Even the haskell guys figured out it's bullshit and implemented types and operations (IORef) to simplify it.
C# hasn't figured out yet you should not have to wrap your function in a namespace and a class.
Extension methods are: I want to add a new method(not function) to object which I dont have control of (in the code sense)
So I can call "externalObj.MyNewMethod()", so extend its behaviour
"I want to add a new not-a-method (because it can't access private stuff, unlike real methods) so that I can do "externalObj.MyNewMethod()" because doing "myNewOperation(externalObj)" is somehow forbidden."
The language is getting complicated.
Disclaimer: I work at Microsoft, but not in the Developer Division.
I also use TypeScript every day, and I absolutely love it. I feel like the power and flexibility of it's type-system are incredible tools for an industry programmer. I think TypeScript is going to get more mileage for me personally and I'll reach for things like C# less and less, because it feels like it's not keeping up with where the web industry is going. (Who knows, maybe they will dust off ASP.NET MVC and ditch Razor pages for some kind of .tsx like experience. A dev can dream..)
Merge C# and TypeScript.
I want my C# pattern matching in TypeScript and TypeScript's fluidity in C#.
Simplified initialization in C# without new(). Unless otherwise specified, use a default generic Dictionary<T,U> and infer the types for map initialization like:
var x = { ["a"] = 1 };
var x = new Dictionary<string,int> {...};
record class Rec(string a, int val);
var k = x as (Rec)
Kotlin only matters due to Google's shenanigans on Android with Android Java, and pushing Kotlin as its replacement.
It is J++ vs C# all over again.
They could just as well buy JetBrains.
Maybe if JetBrains ever releases their own KVM, which by the looks of Kotlin/Native, is hardly something for the JVM ecosystem to worry about.
C# is our real language.
F# is a thing that gets supported to the extent that unpaid volunteers do the work.
VB is in back-compat legacy support mode.
F# has Microsoft Research building it and its libraries and optimizing compilers, no?
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 support, while being careful to stay within the spirit of the language.
F#
> We will drive F# evolution and support the F# ecosystem with language leadership and governance. We will encourage community contributions to improve the F# language and developer experience.
https://www.microsoft.com/en-us/research/wp-content/uploads/...
There's an example of a Microsoft Research paper on F#.
Many of their researchers weren't using R or Python, rather VB, as they were already quite skilled in VBA, so having IT giving them access to VB.NET was a natural evolution.
Honestly, I couldn't be happier with the language strategy as I was wholly expecting VB to be discontinued.
I say this as someone without most of the usual prejudice against VB; I used to work in a large codebase that was half VB.NET and half C#, and didn't mind VB. VB was a little more verbose for some things, but after getting used to the syntax the developer experience was basically the same in each language (yes, with a few small exceptions like XML literals).
Ultimately, that's the problem with VB; it's not different enough from C# to really justify significant investments in 2023. There are some die-hards who really like the VB syntax but they're growing ever rarer.
I had taken the talk of "co-evolution" at face value before going to work there, but after seeing where devdiv actually put its time and attention, that was clearly just a PR story meant to keep VB users comfortable while their language faded away.
What's the unique guiding philosophy or use case of VB that would justify developing bleeding edge new language features in VB first? Maybe I am just being overly critical here but I just don't see how the use cases which VB accommodates would benefit from getting new features before C# gets them, and the divergence would create unnecessary pain across the whole ecosystem
Probably the most used programming language is VBA or maybe the Excel macro if you consider that a language.
Thanks for clarifying, this makes sense to me and it's unfortunate you didn't get to see this through to fruition
I was writing stuff in VBA and a little VB6. The move to VB.NET was made easier because of the synax similarities.
My move from VB.NET to C# was made easier because by then I understood the framework, and it was just a matter of learning the syntax differences.
Maybe that's not such a big deal with a lot more people having exposure to C-like syntax languages like Javascript.
VB6 was AOT compiled and used COM as its component model, C# should have been similar but for C++ folks, basically what .NET Native came to be.
However they really botched UWP execution, when it could have been the proper .NET reboot back to Ext-VOS roots.
Actually this survey from 2020 - https://github.com/dotnet/runtime/issues/40484