Live data from Hacker News

What is the case against F#? (2009)

stackoverflow.com

41–50 of 107 posts

Re: What is the case against F#? (2009)

#41
post #31

F# is only functional language supported by big corporation. It is not Go level but still it is safe to say that Microsoft has some serious commitment to this language.

They see it as a better Python for Data Analytics/ML/etc.

After playing around with it and porting some of my python work to F#....they may be right.

Re: What is the case against F#? (2009)

#42

our team (C#) did an extended proof of concept in F# about ten years ago. we found that it was easier to hero-code in F# but harder to work as a team over time in F#. we ended up embracing a lot of the functional paradigm in C#, which seems like a very good compromise.

> we found that it was easier to hero-code in F# What does hero-code mean?

Speculating, but based on context, probably "Cowboy coding" with heroic intent and success..

Re: What is the case against F#? (2009)

#43
I find the whole concept of the case to be off. The author is concerned that applications can’t take advantage of the increasing parallelism of computers because of the difficulty in writing fine grained parallel tasks, but misses that 1) the paucity of programs that end up CPU bound and 2) Http requests already provide an excellent threading container within which imperative code runs, meaning that the system takes advantage of parallel computing even if the program author doesn’t (so long as they don’t explicitly write themselves into a problem)

Edit: others on SO already pointed this out.

Also, IMO imperative programming generally maps better to the way business requirements are- First do this, then that, unless you see Y then do that. It’s harder to walk a BA or non technical manager through functional code and stand a chance of them tracking what’s going on.

Re: What is the case against F#? (2009)

#44
post #29
post #22

Earlier quoted context omitted.

If it's not null-safe I will avoid it for new projects. Lambda's: great! But real null-safety, strong type safety, proper sum types, pattern matching/ type destructuring, are now my requirements. I'd say Kotlin is the language with the most adoption that ticks the boxes. And it is (not surprisingly) an OO lang.

> I'd say Kotlin is the language with the most adoption that ticks the boxes. How? Kotlin is decisively an object oriented language.

That's what I mean. It ticks my boxes (of which you find most in FP langs). Though a list of langs ticket the boxes, the language that actually has a serious mainstream following is not FP.

Re: What is the case against F#? (2009)

#45

our team (C#) did an extended proof of concept in F# about ten years ago. we found that it was easier to hero-code in F# but harder to work as a team over time in F#. we ended up embracing a lot of the functional paradigm in C#, which seems like a very good compromise.

This is a good and understandable observation.

The next question is whether this is from lack of common constructs/conventions by those new to F# or if it would always pervade as seems to be the case with Lisps. e.g. Clojure was specifically made to cover more in its library and syntax to promote standard styles.

Rather than thinking F# didn't/doesn't work, what were the reasons and what could be changed so it did work well?

Maybe some workflow changes like more design discussions before putting up a PR for review, or pair programming with rotating pairs so that conventions emerge. Also over time the codebase itself if it has benefited from convergence would show repeating patterns of adopted conventions.

I see the language itself as unapproachable only by reputation/lineage. In practice it can be on about the level of Elixir which is gaining traction and success stories.

Re: What is the case against F#? (2009)

#46
post #42

Earlier quoted context omitted.

> we found that it was easier to hero-code in F# What does hero-code mean?

Speculating, but based on context, probably "Cowboy coding" with heroic intent and success..

> easier to hero-code in F# but harder to work as a team

Allowing hero-coding in any language makes it harder to work as a team, so using language that leverages hero output only makes it worse. I wouldn't say that the power of the language is the thing that should be blamed.

I can certainly see that using constructs that the team as a whole isn't ready to adopt being a problem that also comes up in adoption of Scala.

Re: What is the case against F#? (2009)

#47
post #44
post #29

Earlier quoted context omitted.

> I'd say Kotlin is the language with the most adoption that ticks the boxes. How? Kotlin is decisively an object oriented language.

That's what I mean. It ticks my boxes (of which you find most in FP langs). Though a list of langs ticket the boxes, the language that actually has a serious mainstream following is not FP.

Oh, I misread that completely.

Re: What is the case against F#? (2009)

#48
post #41
post #31

F# is only functional language supported by big corporation. It is not Go level but still it is safe to say that Microsoft has some serious commitment to this language.

They see it as a better Python for Data Analytics/ML/etc. After playing around with it and porting some of my python work to F#....they may be right.

This is exactly what I'd like to use F# for. However, I don't know if there's a good ecosystem for F# that gives me anything over Julias, for example.

Re: What is the case against F#? (2009)

#49
post #11

F# is a lot like OCaml. But OCaml still struggles with multiprocessing, while F# can run on the .NET infrastructure which has this solved.

OCaml is still pretty fast and part of RHEL. How good ia linux support for F#? And how hars is it to get mono installed?

Don’t use Mono. Install the .NET 5 SDK and you get F#. .NET 5 is .NET core renamed.

Re: What is the case against F#? (2009)

#50

Earlier quoted context omitted.

I know OCaml and F# are super similar, but how similar is rust syntax?

Rust is influenced by OCaml but has lots of C++ concepts thrown in too. I don't think it makes sense to be choosing between OCaml/F# and Rust since they are so different. If you need the performance characteristics of Rust, then the choice is made for you (and you should also consider modern C++). If not, then the borrow checker is probably a burden that you don't need. Maybe I'm missing something. Under what use-cas…

I don't think I ever would, I just knew they had common heritage and wondered if that was evident to the developer. I've been a professional c++ dveloper for the last 18 years and I've got a couple small projects now that we are using rust for. I know enough to modify rust or fix bugs but not to create an idiomatic design in it. If I don't need the speed I am usually prototyping so I use matlab. If I don't the speed and I'm not prototyping I use python, but that isn't often. I think Julia might end up having a spot in that range of options but c#/java isn't enough faster than python or enough easier to develop than c++/rust for me to consider it unless I need to use existing code.
Post reply on HN