The real problem with F# is that the .NET Native UWP runtime isn't .NET compliant, therefore doesn't allow F# code. See this link explaining the problem https://news.ycombinator.com/item?id=15026396 We wouldn't need to evangelize F#, if it just worked everywhere C# does with proper tooling support.
The Problem with F# Evangelism
131–140 of 203 posts
Re: The Problem with F# Evangelism
#132I'm the lone F# developer in a shop full of experienced and talented C# developers. I have clout, but not enough to convince any of them that F# is a better choice for many of our purposes. It's frustrating, but I try to understand that people are just naturally resistant to big changes like this.
Re: The Problem with F# Evangelism
#133I think that the problem with F# is that it feels more or less abandoned by MS itself. It's already F# 4.x, but I can't remember any significant new features in last 3 releases at least, neither in language nor in the standard library.
For features added see https://en.wikipedia.org/wiki/F_Sharp_(programming_language)
Named union type fields Extensions to array slicing Type inference enhancements Printf on unitized values Extension property initializers Non-null provided types Primary constructors as functions Static parameters for provided methods Printf interpolation Extended #if grammar Support for 'fixed' Tailcall attribute Multiple interface instantiations Optional type args Params dictionaries Struct tuples which inter-operate with C# tuples Struct annotations for Records Struct annotations for Single-case Discriminated Unions Underscores in numeric literals Caller info argument attributes Result type and some basic Result functions Mutually referential types and modules within the same file Implicit "Module" syntax on modules with shared name as type Byref returns, supporting consuming C# ref-returning methods Error message improvements
Re: The Problem with F# Evangelism
#134I think that the problem with F# is that it feels more or less abandoned by MS itself. It's already F# 4.x, but I can't remember any significant new features in last 3 releases at least, neither in language nor in the standard library.
That's because F# 1.0 was bascially a more powerful language than C# 10.0 (C# still doesn't have proper pattern matching for example, or discriminated unions) For features added see https://en.wikipedia.org/wiki/F_Sharp_(programming_language) Named union type fields Extensions to array slicing Type inference enhancements Printf on unitized values Extension property initializers Non-null provided types Primary constru…
Re: The Problem with F# Evangelism
#135I actually work on F# at Microsoft. I've had success and some failures when it comes to evangelizing F# through Microsoft (but mostly success if my measures are accurate). I strongly believe that it can be boiled down to one major thing: Programmers learn how to program with C-style languages. C, C++, Java, C#, JavaScript, Python (sorta) . . . they're all in the same family. People, especially while learning, associa…
My previous job was working for a .NET shop that powered tons of automotive search engines etc. across the web. We moved to more and more functional concepts using C# as the team learned about them and had a lot of success with them. At a certain point, we explored using F#, but the lack of type classes & HKTs meant we kept having to repeat ourselves. We ended up choosing Scala for some new projects despite having an…
Re: The Problem with F# Evangelism
#136I actually work on F# at Microsoft. I've had success and some failures when it comes to evangelizing F# through Microsoft (but mostly success if my measures are accurate). I strongly believe that it can be boiled down to one major thing: Programmers learn how to program with C-style languages. C, C++, Java, C#, JavaScript, Python (sorta) . . . they're all in the same family. People, especially while learning, associa…
Re: The Problem with F# Evangelism
#137The real problem with F# is that the .NET Native UWP runtime isn't .NET compliant, therefore doesn't allow F# code. See this link explaining the problem https://news.ycombinator.com/item?id=15026396 We wouldn't need to evangelize F#, if it just worked everywhere C# does with proper tooling support.
Barely anyone uses UWP. It's irrelevant.
Re: The Problem with F# Evangelism
#138Earlier quoted context omitted.
That's because F# 1.0 was bascially a more powerful language than C# 10.0 (C# still doesn't have proper pattern matching for example, or discriminated unions) For features added see https://en.wikipedia.org/wiki/F_Sharp_(programming_language) Named union type fields Extensions to array slicing Type inference enhancements Printf on unitized values Extension property initializers Non-null provided types Primary constru…
For library, see https://github.com/fsharp/fslang-design/blob/master/FSharp-4...
Re: The Problem with F# Evangelism
#139I built Tsunami IDE. It is a F# IDE. I built it before VSCode or VS Community came out. I built it as a test to see if cost of Visual Studio was blocking adoption of F# and the ideas that F# codifies. The experiment was successful, I got my answer, and the answer is no. Even with free tools people have a hard time adopting F#. First let me address those who are asking for Type Classes and Dependent Types. These would…
Re: The Problem with F# Evangelism
#140Earlier quoted context omitted.
Incredibly well-spoken. I've even had devs ask me if we can use Scala instead after a couple days!
Well can they? :) F# is ok but using it makes me really appreciate scala.