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

Why F# evangelism isn't working (2015)

ericsink.com

Post reply on HN
Print view View original

121–130 of 333 posts

Re: Why F# evangelism isn't working (2015)

#121

Post by caseysoftware »

ericsink wrote: post #68

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

Another "blast from the past" for me too..

Your "career calculus" article has been top of mind for me recently as I've talked about it a bunch of people. Amusing how those core concepts don't change much.

Re: Why F# evangelism isn't working (2015)

#122

Post by epgui »

2h wrote: post #42
xupybd wrote: post #37

I love F#, I use it professionally. But I agree with everything written in this post. I hate that F# is not a safe choice yet. I wish that it were but it doesn't have the critical mass. That means hiring others is not going to be as easy as finding an existing F# developer. Functional programing is different. I don't think it's hard but it's not what most developers have spent years practicing. So there is a learning…

> Functional programing is different. I think the problem with this line of thinking is that some people insist on using functional tactics EVERYWHERE, even when it doesn't make sense. I get that its ugly to mix functional and imperative code, and maybe some languages dont even allow that. but they should. thats why I like Go, because sometimes a simple for/while loop IS the correct answer.

> some people insist on using functional tactics EVERYWHERE

It’s difficult to relate to this without specific examples (I don’t think I agree with the sentiment on balance, but I could also imagine all kinds of obviously-bad things), but FP really does transcend other programming paradigms. Languages such as Java and C++ code definitely do benefit from FP approaches, even if these languages are perhaps not the best at facilitating the approach.

Re: Why F# evangelism isn't working (2015)

#123

Post by Turskarama »

d--b wrote: post #74

This is all very true. Mostly what I have seen happening is people really loving F# convert to using C#. The tooling being the main reason. What this article isn’t saying is that F# is awful at interoping with C# and windows APIs in general. Mostly that F# functions cannot be used as Func objects. So even in a C# environment, bringing some F# is a pain. Definitely didn’t help the adoption.

Yes, it would actually help so much if F# libraries could be painlessly used in C#, it might be all that was needed. Unfortunately it's not the case. Maybe if discriminated unions are ever added to C# some real cross compatibility could be made,

Re: Why F# evangelism isn't working (2015)

#124

Post by somenameforme »

topkai22 wrote: post #94
Hasnep wrote: post #77

Earlier quoted context omitted.

I'm a data engineer, it's a fairly new role so it's not well defined yet, but most data engineers write data pipelines to ingest data into a data warehouse and then transform it for the business to use. I'm not sure why using a static language would make translating data types difficult, but I add as many typehints as possible to my Python so I rarely do anything with dynamic types. I guess they're saying for small t…

A major problem with doing data transformation in statically typed languages is that its easy to introduce issues during serialization and deserialization. If you have an object [{ name:”ex obj” value:”a sample value” extraProperty:”I’m important” }] And the code class myDTO{ string name; string value; } var myObjs= DerserializeFromFile (filepath) SerializeToFile(myObjs, filePath2) filepath2 would end up with without…

"Most" (I mean "all", but meh - I'm sure there's some obscure exception somewhere) parsers will have the ability to swap between a strict DTO interpretation of some data, and the raw underlying data which is generally going to be something like a map of maps that resolves to strings at the leaf nodes. Both have their uses. The same can also be done easily enough by hand as well, if necessary.

Re: Why F# evangelism isn't working (2015)

#125

Post by throw868788 »

banashark wrote: post #69

I find it interesting to compare F# with Kotlin. F# had Jet as the one large success story of a full f# shop, but outside of that there weren't many large companies using a lot of F# (except microsoft internally, and they didn't blog about it _too_ much). Kotlin on the other hand is seeing server-side adoption in quite a few large companies. Google is recommending it as the server-side JVM language for new services g…

Seems like a common theme that people prefer the F# language, but try to explain reasons why it hasn't succeeded from a technical view. I think the reasons IMO aren't technical but what the author has stated - C# is probably worse (that's my opinion) but people who are working in it don't see the pain. Its marketing, the vibe, etc. Most of the tech issues people state wouldn't be there if adoption was bigger.

This is in contrast to Java which for a significant time wasn't showing any evolution which sparked many alt langs on that platform. Sometimes things succeed but silently, and sometimes things that should succeed just don't and maybe there isn't a real explanation. In fact I think the latter across most products is actually the most common outcome, not just in programming languages.

TL;DR I agree with the article, it suffers from an adoption chasm. Pain and herd safety are important especially when people are considering their career progression.

To your dot points:

* I think F# has .NET which is a "proven" and good enough ecosystem as well. You won't get stuck by picking F# even if it means using a C# library. Have to do the same in Scala/Kotlin and the like typically as well.

* Editor has caught up, my surprise is that you can write with Vim and kinda get away with it - only find that works in terser/scripting like languages anyway unlike C#. It has wrappers and libraries for doing things in a more F# FP manner if you wish although when I was doing F# I avoided them (i.e. I avoid things like ScalaX most of the time too).

* F# has a good scripting story; I've seen F# scripts used quite often by people even if coding in C# to check things and REPL program.

* These days F# just works too mostly. `dotnet new webapi/console/etc -lang F#` and you have a webapi for example.

* There are F# libraries around for similar things (Http, Collections, Async seq, etc). They are probably maintained to the level they realistically need to be, I would argue they still do their singular job quite well. At some point a library just does what it needs to do.

There's things I prefer in the .NET ecosystem as well - value types, inlining, etc. Having said that I seen quite a few people use it professionally to good success but they often don't brag about it and are usually quite senior and reserved about their language choice often citing other worries/risks to a project's success.

Re: Why F# evangelism isn't working (2015)

#126

Post by ThinkBeat »

systems wrote: post #84
ericsink wrote: post #68

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

I don't think it matters how good or bad C# is, Object Oriented Programming is a mess Learning, how to use an Object System (a tree of objects/classes) is inherently hard The current problem with F# is that it doesnt do enough to shield you from objects, it does what it can, but still to use F# effectively, you still need to learn some C# and a lot of API that basically Objects inside Objects inside Objects calling O…

Every system if allowed to become too complex. No single paradigm of programming is perfect for all cases.

OO is one way to structure and model a system.

No matter what language you use will end up with some form of a struct, a set of values that belong together Then you will have list of some structs and trees of some structs

You will almost certainly have to create list/collections/groupings of structs. Because those are quite useful and universal

How you act on those collections is different between different idioms.

In other words you will create a model of data one way or another and you have to maintain it / change it, as required over time.

The data structures themselves are rather often based on or more database schema where the data will be extracted and saved.

Re: Why F# evangelism isn't working (2015)

#127

Post by ThinkBeat »

ericsink wrote: post #68

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

C# in its current state has IMHO acquired many features from F#. You can get close to writing purely functional code in C# now.

I think with all the changes and extensions over time to add ever more features to C# so you can write whatever paradigm you want in it is a bad idea.

I would much have preferred to keep C# OO and use F# when you want to go functional.

Or just create G# which is the everything mashed together language that C# is close to being.

Re: Why F# evangelism isn't working (2015)

#128

Post by c00lio »

epgui wrote: post #102
lambdaxymox wrote: post #96

Earlier quoted context omitted.

F# always struck me as one of the most terribly underrated languages. I'm a lover of MLs in general, but F# lands on one of the sweet spots in PL space with ample expressive power without being prone to floating off into abstraction orbit ("pragmatic functional" is the term I believe). It is basically feature complete to boot.

> without being prone to floating off into abstraction orbit What do you mean by this?

"Oh, you _also_ need to print something? Lets stack a few monad transformers..."

"But remember that you need the TemplateExplicative and NullUnderstanding compiler extensions!"

Re: Why F# evangelism isn't working (2015)

#129

Post by devmunchies »

systems wrote: post #84
ericsink wrote: post #68

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

I don't think it matters how good or bad C# is, Object Oriented Programming is a mess Learning, how to use an Object System (a tree of objects/classes) is inherently hard The current problem with F# is that it doesnt do enough to shield you from objects, it does what it can, but still to use F# effectively, you still need to learn some C# and a lot of API that basically Objects inside Objects inside Objects calling O…

The worst part of OOP is that all the properties of an object can be a mishmash of values and are mutable. In any method, you never know if the object is in some undesirable state without checking properties within the method itself. Multiply that headache across all methods and all other classes and it becomes a mutable mess. It makes it weird that we pass around objects as types when they encapsulate so much state and logic. They aren’t really a concrete data types, they are an entire living village.

With functional languages, it tries to enforce some explicit type signatures in the function arguments so things are cleaner within the functions themselves.

Re: Why F# evangelism isn't working (2015)

#130

Post by epgui »

heywhatupboys wrote: post #115
epgui wrote: post #109

Earlier quoted context omitted.

This comment shows a total misunderstanding of what functional programming is…

While tongue in cheek, this is one if the OP in non-OP patterns that is used heavily for large projects in FP alike.

I'm not seeing that in the example, and I'm not even seeing anything very relevant to FP in the example either. I guess there isn't much mutation happening, and functions are called? But that's not what FP is.
Post reply on HN