3 ms·
As a daily user of F#, I'm most looking forward to the support for "and!" in computation expressions. There are a few performance-critical pieces of code I can
by nozzlegear 1y ago
As a daily user of F#, I'm most looking forward to the support for "and!" in computation expressions. There are a few performance-critical pieces of code I can think of that are currently wrapped up in "Task.WhenAll" / "Parallel.ForEachAsync" that I'd like to extract back into "native" F# task computations.
- deleted 1y ago[deleted]
- cies 1y agoI really like F# (as I like OCaml, Elm and Haskell); but I'm always afraid MS will kill it one day. It helps that now most (if not all) parts of the stack are open source and run on Linux.
- vintermann 1y agoC# Dev Kit, which VSCode pressures you to install, is a core very non-free component.
- ganzsz 1y agoRemoving free omnisharp was the worst
- madarcho 1y agoWhere is this worry coming from? (I'm curious, not shutting it down) I might be biased from having worked with production F#, but it feels more like functional is making its way into C#, as the general industry sees value in functional principles. So F# feels like its more here to stay?
- azertify 1y agoDoesn't it feel like the functional stuff is coming into C# so that F# can disappear? Pure speculation on my part but doesn't seem unreasonable.
- pizza-wizard 1y agoMicrosoft is still supporting VB.NET, Windows Forms/WPF, and to a lesser extent VBA. I doubt F# is going away anytime soon.
- debugnik 1y agoSupporting as in maintenance mode, at least VB.NET. Thankfully F# is more community driven, but the CLR ecosystem is definitely getting C#-centric in the use of idioms and features from newer C# versions, which increasingly affects F# interop while they catch up.
- aryonoco 1y ago.NET has always been both the biggest blessing and the biggest curse for F#. We have access to millions of libraries. I look at BEAM languages and OCaml every once in a while but can’t quite drag myself over there, knowing that in .NET, just as an example, I can choose between a dozen JSON serialisation libraries that have been optimised and tuned comprehensively for decades. But then, those libraries are also our curse. If you consume them, everything is OO so you either give up on functional purity and start writing imperative F# code, or you have to spend time writing and maintaining a F# idiomatic wrapper around it. Similarly I was working recently on project to develop a library which was going to have downstream consumers. The problem lent itself really well to domain modelling in F#. But I knew that my downstream users would be C# devs. I could invest the time and write my library as “functional core, imperative shell”. But then I decided that since the interface would be OO anyway, I might as well just write it in C#. Thankfully what keeps F# going is the wonderful community around it, not Microsoft. I know some people (outside of Microsoft) have worked on a standalone F# compiler but it’s still very early stages. Maybe one day.
- banashark 1y agoAlthough you inevitably end up writing some OOP code in F# when interacting with the dotnet ecosystem, F# is a really good OOP language. It's also concise, so I don't spend as much time jumping around files switching my visual context. Feels closer to writing python.
- banashark 1y agoThey killed off VB, which if I recall the announcement correctly, noted that it statistically had a larger user base (by Microsoft metrics) than F#. There are a number of companies relying on F# for critical operations and MS has some use of F# internally which I understand has no plans of replacement, which helps balance out the fear.