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

What is the case against F#? (2009)

stackoverflow.com

Post reply on HN
Print view View original

91–100 of 107 posts

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

#91

Post by narag »

sweeneyrod wrote: post #81
amelius wrote: 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.

What are some situations where you need parallelism? I am not convinced there are many. I have never heard anyone say they are using .NET instead of JavaScript or Python in order to get parallelism.

Web server programming is inherently multithreaded. I'm not sure if that's a convincing answer, but web performance is definitely a common rationale to use .NET or Java over Python or JS.

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

#92

Post by teddyh »

nojito wrote: post #88
teddyh wrote: post #85

Earlier quoted context omitted.

Nothing which was initially developed inside a large corporation has a reasonable chance of becoming truly independent. The only example I can think of is Unix and C, and that’s only because AT&T was (for complicated reasons) legally restricted from selling it as a product, and the project was taken over by various other actors in both business and academia. But C#, F#, Go, Swift, Dart, etc.? They are initially popul…

Kafka? Airflow? Javascript? The list goes on.

The only one of those that I have heard of is Javascript, and that was initially implemented by Netscape, but the language was then taken over by the industry at large as Netscape’s market share dwindled. Javascript is also unusual in that it had a specific and restrictive design goal, and a very short initial development phase before the language was mostly frozen. This meant that not a lot of Netscape culture could be put into the language, partly because the language itself was small, but mostly, I think, because of the very fast initial development by a small team (a single person over a period of days, IIRC).

So, yes, even though I don’t like Javascript as a programming language, I would not shy away from it merely because of its corporate roots.

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

#93

Post by phillipcarter »

nojito wrote: post #89
phillipcarter wrote: post #86

Earlier quoted context omitted.

Oh yeah, it’s a great feature. People like it a lot more than we thought they would, and we already had high hopes for it! Still more improvements to make there, though.

Just need some firm locking/pinning and I think you have nailed truly reproducible analytical workflows.

You can actually do that today by specifying a version number. The docs cover it here: https://docs.microsoft.com/en-us/dotnet/fsharp/tools/fsharp-...

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

#94

Post by gher-shyu3i »

cies wrote: post #22
short_sells_poo wrote: post #5

Earlier quoted context omitted.

C/C++ have not fallen to the wayside but most major programming languages have now inherited quite a few functional paradigms. I haven't kept up to date, but don't both C++ and Java have lambdas now? Don't they also feature currying? C++ is of course not Haskell, but that's not the point. Functional programming has become commonplace by procedural languages adopting the simpler/most-useful aspects.

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.

Incidentally, pattern matching that Java is getting is superior and more fully fledged to the one that exists in Kotlin. You can also have null safety in Java by means of annotations.

You can also check out C# since it fits your requirements. It has pattern matching, but sum types are still in the works.

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

#95

Post by amelius »

sweeneyrod wrote: post #81
amelius wrote: 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.

What are some situations where you need parallelism? I am not convinced there are many. I have never heard anyone say they are using .NET instead of JavaScript or Python in order to get parallelism.

Any situation where you want to keep latency under control and thus asynchronous programming is not adequate.

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

#96

Post by nojito »

teddyh wrote: post #92
nojito wrote: post #88

Earlier quoted context omitted.

Kafka? Airflow? Javascript? The list goes on.

The only one of those that I have heard of is Javascript, and that was initially implemented by Netscape, but the language was then taken over by the industry at large as Netscape’s market share dwindled. Javascript is also unusual in that it had a specific and restrictive design goal, and a very short initial development phase before the language was mostly frozen. This meant that not a lot of Netscape culture could…

You are just wrong and speaking like it's still the 90s or 2000s.

I just mentioned 3 very popular and effectively best in class technologies that started at a corporation and now have robust open communities supporting them.

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

#97

Post by akra »

gameswithgo wrote: post #38
rendall wrote: post #30

Earlier quoted context omitted.

I can't speak for melling but as for me, that attitude struck me as dismissive not only of the capacity of the average developer to understand fp, but a bit of fp itself as too hard. 11 years later, fp concepts are more generally understood, accepted, and used; and the attitude has shown to be incorrect. fp is not that hard. It is, in fact, easier than OO

Well, SOME ideas have proven easy to understand. The use of higher order functions like Filter/Map etc are definitely widespread now and have proven their usefulness. The idea of keeping functions pure, when you can without making a mess of things, has pretty wide agreement. The use of Option types instead of Null is getting to the point of being widespread (C# 9 sorta does it, Zig kinda does it, people love it in Ru…

"partially applied functions to other functions" - In C# you do this anyway via Fluent interfaces and/or lambda Func arguments. The only difference is in F# any function can be made into a fluent style pipeline (|> operator) due to this partial application whereas in C# the function has to be built specifically for it. Partial application for me is one of the reasons F# code tends to be nicer than C#/Java code there's less need for things like DI containers, and other big frameworks each with their own learning curve and corner cases. It feels more like I'm coding in a static version of JS/Python once you get used to it vs C#/Java which have a lot of ceremony - expect that type inference you mention means those partially completed functions are much less likely to be used wrong.

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

#99

Post by fulafel »

babarganesh wrote: post #21

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.

Could it be that you are just observing productivity? It seems plausible that anything which slows things down helps people work on a thing as a team because it's easier to keep up and there is more time and energy available to organise teamwork.

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

#100

Post by Seirdy »

teddyh wrote: post #85
oaiey wrote: post #82

Earlier quoted context omitted.

Just that F# other than C# is a bad example in that argument. There is a pretty independent F# Foundation with even the lead Microsoft / F# personell advocating it.

Nothing which was initially developed inside a large corporation has a reasonable chance of becoming truly independent. The only example I can think of is Unix and C, and that’s only because AT&T was (for complicated reasons) legally restricted from selling it as a product, and the project was taken over by various other actors in both business and academia. But C#, F#, Go, Swift, Dart, etc.? They are initially popul…

- Kotlin (Jetbrains)

- Chez Scheme (Cisco)

- Erlang (Ericsson)

- Rust (Mozilla)

- Java (Sun Microsystems, Oracle)

The above examples show languages that outgrew the companies that developed them.

Typescript might follow a similar path in the future.

Post reply on HN