Live data from Hacker News

The Problem with F# Evangelism

thomasbandt.com

131–140 of 203 posts

Re: The Problem with F# Evangelism

#131

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.

Barely anyone uses UWP. It's irrelevant.

Re: The Problem with F# Evangelism

#132

I'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.

Get them to do a training course like "Fast Track to F#"

Re: The Problem with F# Evangelism

#133
post #78

I 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 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

#134
post #78

I 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…

For library, see https://github.com/fsharp/fslang-design/blob/master/FSharp-4...

Re: The Problem with F# Evangelism

#135

I 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…

Is there anything about using F# that you would see as a plus over Scala or Haskell?

Re: The Problem with F# Evangelism

#136

I 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…

I feel like someone invented a toaster oven that doesn't catch fire, but everyone wants to stick with the model that does catch fire all the time.

Re: The Problem with F# Evangelism

#137

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.

Barely anyone uses UWP. It's irrelevant.

Nonsense, UWP is everywhere

https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many...

https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many...

https://www.reddit.com/r/programming/comments/6tdqmv/after_s...

Re: The Problem with F# Evangelism

#138

Earlier 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...

All those features mean nothing to seasoned .NET developers when you can't use the language natively on Microsofts primary application platform.

Re: The Problem with F# Evangelism

#139
post #99

I 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…

I'm surprised that this comment isn't at the top of this thread.

Re: The Problem with F# Evangelism

#140

Earlier 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.

I mean they can but we won't get paid if our megacorp overlords don't get their .NET drivel.
Post reply on HN