> 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".
Latest the F# folks tried to pivot the language into data science and be a safer alternative to Python, only to have Microsoft hire Guido and being the company that finally managed to push the CPython devs to focus on performance, and JIT integration.
One is that C# has partial classes but F# does not. This comes up for all the XAML tooling that C# supports but F# doesn't. Also, F# only has null for use in certain situations only for interoperability. There are others that I've seen but don't know off the top of my head. I think they are usually OOP related and at the edges. I don't much know them because I don't really know C#.
I think F# is going to do well because it is driven by the community making it an open field despite being .NET. F# developers seem to have a higher than usual lower-bound.
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.
I'm not sure about that given the amount of jobs I have had and found in Elixir, which also has a more vibrant ecosystem. I have strong confidence that I could get another Elixir job. I would be surprised if I could even locate an F# job.
2022 I started a new job where we mainly use C# and I have to say, this is my favorite language now, especially with Visual Studio and Reshaper. I've never felt so productive and at ease while coding!
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.
We are running NopCommerce (https://nopcommerce.com/) on Linux with no problems. This is ASP on .Net Core and everything works well.
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.
Not really, plenty of VS tooling doesn't exist on VS4Mac nor VSCode.
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.
Stop wasting time with VSCode when doing professional development on .NET and use Rider on Linux and Mac. The C# addon for VSCode is lacking so many features compared to VS and Rider that it's mostly a toy.
The Rider licensing cost is negligible when compared to a developer's compensation.
I don't waste time, we mostly target Windows with .NET, for UNIX workloads we usually use node and Java, as you can see by my last sentence there is very little .NET/UNIX for us, and even so, it is developed on Windows deployed on Linux.
No need to pay for Rider licenses on top of the VS ones we already have.
Besides battling Visual Studio, `dotnet` cli and C# as a language, deploying a binary built on Windows to Linux was a breeze. If you're more used to the development environment, I bet it'd even be pleasant.
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.
Unity is moving to .NET 5+ and, if I remember their documentation correctly, the hold up is entirely on their side and not due to the .NET runtime not being cross platform enough.
Yea I'm guessing there's not a ton of fresh WPF or forms desktop apps being created. We've mostly moved to ASP.Net backends with React frontends wherever possible.
Oh, there's definitely a huge amount of wpf and winforms created every day. That's what I meant. Those people just don't visit HN that often. (Then again, I created 4 windows specific wpf apps last year...)
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.
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.
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".
They went from .NET Core 3.1 to .NET 5 and a yearly release cadence. The idea with .NET 5+ was also to unify the platform with support for building Windows desktop apps (WinForms/WPF) and mobile apps (Xamarin/MAUI).
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 Jetbrains Rider, and supports the latest .NET and C# features.
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.
The point I was making is that what was once called .NET Core is now just .NET, after the merge with what was once called .NET framework. However, I think the name .NET is annoying to read and type, and it's ambiguous in a similar manner to Go, so I say Dotnet and Golang. Dotnet is literally just .net with the dot spelled out. It's not really a separate name.
> The point I was making is that what was once called .NET Core is now just .NET
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.
I love C# but this kind of Microsoft naming nonsense drives me up the wall. I'm sure it's negatively impacted mindshare since people can easily be mistaken as to what they're referring to.
Sure, it's not like .NET is Googleable either though. I thought the fact that Microsoft uses the term Dotnet (obviously, only when necessary) was good enough.
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.
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.
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.
With Rider or VS Code on Mac? I've been wanting to play around with C# but I already have Intellij Idea Ultimate subscription and I'm hesitant to add another one. I'm wondering how good of an experience would VSC be for C#.
I've used VSC as a professional for 4 or 5 years now and love it. I prefer it over Visual Studio because the latter is so feature bloated. I'm currently using and M1 Mac to develop on and it works fine. Once you learn the shortcuts, you'll be zooming around.
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.
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 be incredibly expensive and risky, but it would bring in a lot of excitement and fresh faces. /rant
.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.
Yeah I argree, making a new lang for a vm runtime doesn’t make as much sense when rust is right there, because the vm itself has a lot of baggage and limitations (OOP baked in, start up time,etc). The dotnet team seems to be moving mountains to squeeze more performance out of the VM, which is awesome, but how much further can it go?
productivity on the CLR and JVM is light years ahead of that in Rust. Rust has its niche, but it isn’t superior to broad surface that the managed runtimes provide leverage for.
You know we used to call it Microsoft Java, right?
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
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.
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).
Extension methods are "I want a function whose first parameter is this type defined outside, but the programming language shoehornes me so much into classes and objects that I have to do all this extra ~bullshit~ boilerplate to have a function whose first parameter is this type defined outside".
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.
"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."
Classes are part of the .NET intermediate representation (CIL) that the compilers emit and that the virtual machine executes. OOP is baked in at a low level.
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 };
Instead of:
var x = new Dictionary<string,int> {...};
Then automatic type mapping and conversion utilities to objects:
record class Rec(string a, int val);
var k = x as (Rec)
(Yes, can already be done with implicit type conversion operators or writing utility classes, but making it more like TypeScript would just make it easier to adopt)
Great question because I think TypeScript is the future in terms of a web stack. With the 'metaframeworks' (not just the ones from Meta, winky face) all moving towards a Server Side Rendering paradigm, I feel like a full-stack TypeScript world just makes so much more sense in terms of developer productivity.
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..)
The spirit of starting over instead of cramming more into an old language, but
making the new thing highly compatible with the old thing via transpilers or runtime sharing (Swift with Objective-C, Kotlin with Java).
Everything they are doing in swift and Kotlin are within reach. Heck, those languages _copied_ a lot from C#, so it's the Original Gangster in terms of features. It's just that there's a lot of old baggage in there in terms of syntax and language defaults. Classes aren't sealed by default. Getting immutability requires lots of extra keywords, or you use `record`s, which are nice to use. I look at the new language features they're proposing, and it just feels like they are bending over backwards to add nice things because there's already so much there that they can't mess with. A clean slate would give them some freedom.
Does anyone have any good resources to learn C# and the new net ways for someone who’s self taught and primarily codes simple tools in python? I need it for work and I get by refactoring old code, but I don’t really know how to make things better here
VB is not only for compatibility. VB is a key piece between pure development and advanced Office capabilities, more commonly found in Excel with VBA (Visual Basic for Applications) We cannot forget that the biggest competitor of any new software based startup/project is a spreadsheet created by the target users
I experienced this in first hand when doing some contracting for a lifesciences company.
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.
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 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.
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.
Last time I talked to them, the entire f# team at Microsoft was still fewer than 10 people. Language features, lsp modules, visual studio support, etc. They do technically exist but it's far from a focus at ms.
When the average enterprise starts using F# regularly, maybe it will get the same TLC as C#. Lots of complaints about F# being the red headed stepchild but people seem to miss the fact that C# absolutely dominates on the list of languages the average Windows/Microsoft shop is using.
Visual Basic had already become a second-class citizen fifteen years ago, when I worked on its compiler team. All the actual design work happened in the C# world, and our job was just to tag along and mimic whatever they had come up with.
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.
> All the actual design work happened in the C# world, and our job was just to tag along and mimic whatever they had come up with.
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
I always saw Basic as the language for non-professionals who wanted to create their own software: hobbyists, amateurs, small business owners, people who have an idea and want to automate whatever it is they're doing, but aren't trying to write code for a living. C#, by contrast, is a proper mainstream language for professional programmers.
Replace basic with Lua and read your line back. Just because a language is simple doesn't mean it can't have industrial purposes by whatever gauge you measure things. Theres a bunch of things I wouldn't use basic for just the same with C# and "popular-language-here".
Probably the most used programming language is VBA or maybe the Excel macro if you consider that a language.
Did that remark come across as a criticism? I did not mean it so; distributing the power of programming as broadly as possible has always been a central value in my career, and that's why I joined the VB team in the first place. I meant that while it made sense for cutting-edge language development to happen elsewhere, I had thought that VB would have been a great place for work on improved human factors. How can we design the interfaces for this complex system so that people who do not yet have (and may never gain) a strong mental model of its architecture will nevertheless be able to improvise their way to success? That's where I thought the value of VB was.
> while it made sense for cutting-edge language development to happen elsewhere, I had thought that VB would have been a great place for work on improved human factors.
Thanks for clarifying, this makes sense to me and it's unfortunate you didn't get to see this through to fruition
It has been for a very long time, and that's a reasonable approach IMO.
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 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.
Honestly, most people still using Visual Basic at this point probably aren’t itching for new features. Stability is a feature itself when it comes to legacy code.
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..
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".