Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Problem with F# Evangelism

thomasbandt.com

Post reply on HN
Print view View original

71–80 of 203 posts

Re: The Problem with F# Evangelism

#71

Post by smithkl42 »

phillipcarter wrote: post #33
d--b wrote: post #27

F# problems from a C# developer point of view: #1 tooling: visual studio integration of F# is poor. You don't get cross language usage reference, so you lose all the benefits of static typic. Projects and references are a mess. Being primarily a scripting language, it feels like a toy language #2 compatibility with C# is poorly done. That F# functions cannot be consumed as C# lambda is a real mess. Boxing / unboxing…

> #1 tooling: visual studio integration of F# is poor. You don't get cross language usage reference, so you lose all the benefits of static typic. Projects and references are a mess. Being primarily a scripting language, it feels like a toy language Could you clarify what you mean here? Although things like Go to Definition and Find all References don't work across C#/F# boundaries (yet), but you absolutely get Intel…

And FWIW, I remember complaining about this to Don Syme something like 5+ years ago, and while he gave lip service to the idea that F# needed better tooling (and better tooling interop with C# specifically), I don't think he was really convinced.

Re: The Problem with F# Evangelism

#74

Post by jmull »

F# isn't generally solving problems... well, it can but rarely at the same level as it introduces problems.

People can have awfully cavalier opinions about switching languages, but it's a very heavy-weight change with strong implications for existing code, dev training (new syntax, new patterns, new pitfalls), available frameworks (often resulting in more new patterns), technology stack (which can reverberate out to testing, scalability, etc.)

Even if you assume F# is only better than C# and in no way worse, it's usually major investment to switch... typically at least an order of magnitude bigger than that bullet list of ways F# is better than C#.

Re: The Problem with F# Evangelism

#75

Post by TensorMetric »

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.

Re: The Problem with F# Evangelism

#76

Post by phillipcarter »

pjmlp wrote: post #60
phillipcarter wrote: post #56

Earlier quoted context omitted.

I'm sorry, but what you're saying is factually incorrect . Can you please update your comment so as not to spread misinformation?

Updated with the blog quote.

This is for the .NET Core tooling support part of F#, and as we've stated in the blog post, we prioritized the quality of cross-platform usage here. You're free to disagree with this prioritization, but please don't craft a narrative about the relationship between F# and Microsoft that can mislead people as you did before.

Re: The Problem with F# Evangelism

#77

Post by AnthonyLloyd »

brianberns wrote: post #45
zubspace wrote: post #34

Good post. I really hoped for some f# code after listing all those scenarios where c# fails. Anyway. I work in a c# shop with a large monolithic code base developed by a small team with lots of fluctuations over more than 10 years. I have no functional programming experience at all. I love c# because we actually try to keep the code as simple and linear as possible and only introduce complexity in certain areas if pe…

Is your programming language unreasonable? or, why predictability is important http://fsharpforfunandprofit.com/posts/is-your-language-unre...

This is it for me.

Large projects in OO often end up as mutable monoliths which become harder and harder to work with. New features sometimes require large painful and scary changes. Hacks are irresistible. Of course you need refactoring tools because you have to change many things in many files.

OO promised modularity but the languages never delivered because of their unreasonable design.

Highly reasonable, concise and refactorable code is the answer to complex systems.

Re: The Problem with F# Evangelism

#78

Post by galkk »

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.

Re: The Problem with F# Evangelism

#79

Post by strayamaaate »

I’m a C# developer, love the language and how easy it is to express what’s in my head as code.

I recently had a chance to play with F#. After being completely lost for a bit, I found I had to really rethink how I was reasoning about problems and the right way to solve them.

But that’s the point I want to make. I don’t expect to be good at FP for a while - it’s going to take time to grow, along with the tooling and community. But I appreciate having a way of framing a problem differently, and like the direction F# is headed.

It doesn’t mean I’m going to drop C# any time soon, I’ll likely just use both - e.g. my more math heavy libraries will be F#, and my networking and Web API code in C#.

Re: The Problem with F# Evangelism

#80

Post by pjmlp »

phillipcarter wrote: post #76
pjmlp wrote: post #60

Earlier quoted context omitted.

Updated with the blog quote.

This is for the .NET Core tooling support part of F#, and as we've stated in the blog post, we prioritized the quality of cross-platform usage here. You're free to disagree with this prioritization, but please don't craft a narrative about the relationship between F# and Microsoft that can mislead people as you did before.

If the issues faced by your team were related to C# I assume management would have taken other path.

And this is the reason why none of our customers wants to even discuss integrating F# into C# projects.

Post reply on HN