←back to thread

.NET 10

(devblogs.microsoft.com)
489 points runesoerensen | 10 comments | | HN request time: 1.464s | source | bottom
Show context
nozzlegear ◴[] No.45890001[source]
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.
replies(2): >>45898152 #>>45898201 #
cies ◴[] No.45898201[source]
I 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.

replies(2): >>45898239 #>>45898319 #
1. madarcho ◴[] No.45898319[source]
Where 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?

replies(2): >>45898584 #>>45904656 #
2. azertify ◴[] No.45898584[source]
Doesn'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.
replies(3): >>45898753 #>>45899526 #>>45905757 #
3. pizza-wizard ◴[] No.45898753[source]
Microsoft is still supporting VB.NET, Windows Forms/WPF, and to a lesser extent VBA. I doubt F# is going away anytime soon.
replies(1): >>45899389 #
4. debugnik ◴[] No.45899389{3}[source]
Supporting 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.
replies(1): >>45901350 #
5. bonesss ◴[] No.45899526[source]
C# has incomplete and often compromised versions of the constructs F# mostly took from OCaml, and as you extend those exhaustive guarantees towards formal verification you bump into F*.

C#s adoption of language features shows their utility but they’re not a replacement, per se. Without a clear functional answer in certain language and parallel computing scenarios MS would be ignored. Scala and Kotlin are comparable answers to comparable pressures on the JVM, and even keeping pace there with new and exciting tools/libraries requires some proper functional representation on the .Net platform.

F# will disappear when/if those other languages do, and already has lots of what C# is chasing with a more elegant syntax. It inherits VM and project improvements from C#, so the biggest threat to long term investment is something like the crippling changes made to FSharp Interactive (FSI), during the .Net Core transition. Otherwise it seems to be in a safe place for the foreseeable future.

6. aryonoco ◴[] No.45901350{4}[source]
.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.

replies(1): >>45904713 #
7. banashark ◴[] No.45904656[source]
They 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.
replies(1): >>45907233 #
8. banashark ◴[] No.45904713{5}[source]
Although 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.
9. WorldMaker ◴[] No.45905757[source]
The C# team admits to looking at how F# features work, but also keeps trying to make it clear that C# doesn't have a goal of entire eating F#.

C# still doesn't see itself as a functional programming language, even as it has added so many features. It may never get first-class currying or the broader ideas like generalized computation expressions, for instance. It certainly won't get F#'s cleaner syntax with fewer mandatory semicolons and whitespace nesting rather than curly brackets.

F# probably isn't going to disappear for a lot of similar reasons that GHC (the Glasgow Haskell Compiler) didn't disappear when F# was started (nor when key contributors left Microsoft). F# often already sees more outside open source contributors than contributions from Microsoft employees.

10. nu11ptr ◴[] No.45907233[source]
I was curious so I googled. Best I can tell it is still supported, but perhaps stagnant?