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

51–60 of 107 posts

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

#51

Post by cogman10 »

KurtMueller wrote: post #37
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.

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

Here's my stab at it (though I could be wrong). It's like perl, easy for experts to write a lot of it fast, but hard for anyone else to grok what's going on.

As an anecdote, I see it come up with clojure a lot. Some of the clojure devs in my company can spin up a lot of interesting applications and fast. However, trying to read any of there code can be nearly impossible. Why? Usually because of a generous helping of their own metaprogramming constructs that they've built up over time. I've watched them program and it's both interesting and really hard to follow.

The big problem we've ran into is these clojure projects have been really hard for teams to get into. As a result, the worst thing has happened, many of them are being scrapped and rewritten in java because they are too hard to maintain otherwise.

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

#52

Post by Smaug123 »

KurtMueller wrote: post #37
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.

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

"Hero-coding" is the kind of thing where you alone go into a fugue state for a week, and emerge on Sunday night, covered in blood and with your hair standing on end, holding a crystal redolent with eldritch power.

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

#53

Post by Smaug123 »

gameswithgo wrote: post #40
daxfohl wrote: post #20

GC was probably not a concern in 2009, but these days GC pauses will kill any moderately high throughput app. The stackoverflow blog has lots of content dedicated to the lengths they go to avoid them in C#, such that the resulting C# code doesn't look like idiomatic C# at all. In F# that would be an even bigger challenge. You could do it, but it would but way ugly. F# is my go-to language for side projects, but for a…

F# is designed so that the performance ceiling is the same as C#. Certainly you would get less idiomatic to reduce GC pressure, but I'm not sure its harder than c#

I dunno, there are some weird places where idiomatic F# allocates even when you avoid the usual suspects, but can be trivially rewritten not to allocate. (There are even bugs which cause allocation. Try iterating over an array of `unit -> unit`, calling each in turn.)

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

#54

Post by daxfohl »

motives wrote: post #33
daxfohl wrote: post #20

GC was probably not a concern in 2009, but these days GC pauses will kill any moderately high throughput app. The stackoverflow blog has lots of content dedicated to the lengths they go to avoid them in C#, such that the resulting C# code doesn't look like idiomatic C# at all. In F# that would be an even bigger challenge. You could do it, but it would but way ugly. F# is my go-to language for side projects, but for a…

Unless you're working on a SOTA HFT application where you're optimising your latency by the nanosecond, I can't see modern .Net/F#/C# being a problem in production. Given that Bing[1] and Azure Active Directory[2] run on .Net Core/.Net 5, which are among the most used applications on the entire internet, the idea that a medium-large project cant use them is ridiculous. This isn't even just with modern .Net aswell, Mi…

I used to work in the Azure Resource Manager team and we had big GC issues there. API servers would pause for 200 ms and queues would explode. Workers would grind to a near halt in certain conditions due to GC overload. Granted this was a couple years ago and running dotnet framework, so perhaps things have improved.

I think it's likely most of the serious problems there could have been fixed by smarter in memory caching: a few big objects instead of millions of small ones. However the whole experience left a sour taste in my mouth for overly allocation-happy code styles.

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

#55

Post by phillipcarter »

nojito wrote: post #41
rusabd wrote: 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.

It's not _quite_ meant specifically as a better Python, but it can play that role and there is every intention of making that something that has "product truth" to it. You can look forward to some concrete improvements along those lines this year, specifically in the notebooks tooling space and some library support!

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

#56

Post by mumblemumble »

danielbarla wrote: post #13

The case against for most people is the chicken-and-egg problem of the mainstream adoption of the language. It should be relatively obvious at this point that the outright merits of a language have little or nothing to do with its popularity, at least when compared to things like the corporate backing and will behind a language (see: Objective-C / Swift), and other factors such as positioning and luck (e.g. Javascrip…

I don't like to shy away from languages just because they won't ever become one of the top 5 languages. Moderate success for a language can often be more than enough to keep the things built on it afloat for a long time.

I also suspect that the relationship between how many people are successfully using a language, and how often you hear about it on the Internet, is non-linear. And most the popular rankings (TIOBE, SO developer survey, etc) are really measuring how often you hear about it on the Internet.

For me, the real killer feature that every language must have is an escape hatch. This is every bit as true of AAA languages as it is of up-and-coming ones. Give me a way to expose a C ABI or a COM interface, and I'll feel more confident I won't get trapped. (Though I still cry myself to sleep at night knowing POSIX doesn't have a great answer to COM or WinRT.) For one project I'm working on, I'm currently feeling very trapped in Java, of all things. Because, while Java has decent enough facilities for calling out, it's much more difficult/expensive/both to call into Java from other platforms.

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

#57

Post by phillipcarter »

daxfohl wrote: post #54
motives wrote: post #33

Earlier quoted context omitted.

Unless you're working on a SOTA HFT application where you're optimising your latency by the nanosecond, I can't see modern .Net/F#/C# being a problem in production. Given that Bing[1] and Azure Active Directory[2] run on .Net Core/.Net 5, which are among the most used applications on the entire internet, the idea that a medium-large project cant use them is ridiculous. This isn't even just with modern .Net aswell, Mi…

I used to work in the Azure Resource Manager team and we had big GC issues there. API servers would pause for 200 ms and queues would explode. Workers would grind to a near halt in certain conditions due to GC overload. Granted this was a couple years ago and running dotnet framework, so perhaps things have improved. I think it's likely most of the serious problems there could have been fixed by smarter in memory cac…

Do you think that a lot of what you experienced was before widespread use of the Span primitive in the .NET libraries and frameworks? Even if you go to great lengths to avoid GC pauses in your own code, the components you depend on may not have done that and then you're toast. Much has changed in the past 1.5-2 years to eliminate almost all unnecessary allocations across the stack.

C# and F# also got compile-time analysis for working with spans, span-like, byrefs, etc. as of 2018 so that you can write some of this code yourself and have a reasonable assurance the the compiler will keep your code from allocating. Coding like this isn't easy either, but it's far simpler than it used to be because of the underlying types an compiler analysis that can help you.

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

#59

Post by daxfohl »

phillipcarter wrote: post #57
daxfohl wrote: post #54

Earlier quoted context omitted.

I used to work in the Azure Resource Manager team and we had big GC issues there. API servers would pause for 200 ms and queues would explode. Workers would grind to a near halt in certain conditions due to GC overload. Granted this was a couple years ago and running dotnet framework, so perhaps things have improved. I think it's likely most of the serious problems there could have been fixed by smarter in memory cac…

Do you think that a lot of what you experienced was before widespread use of the Span primitive in the .NET libraries and frameworks? Even if you go to great lengths to avoid GC pauses in your own code, the components you depend on may not have done that and then you're toast. Much has changed in the past 1.5-2 years to eliminate almost all unnecessary allocations across the stack. C# and F# also got compile-time ana…

Oh, absolutely. In fact I proposed an effort and wrote up a few prototypes to bring those things into ARM codebase while I was there.

IDK if any of it ever went anywhere though, as I left the team shortly thereafter.

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

#60

Post by BadInformatics »

dragonwriter wrote: post #34
rusabd wrote: 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.

> F# is only functional language supported by big corporation It might be the only functional language developed “in house” at a major corporation, but it's not the only one supported by a big corporation, as Microsoft (under the GitHub name) is a leading sponsor of the new Haskell Foundation.

As well as employing Simon Peyton Jones.

Jane Street and OCaml would be another good example of deep corporate involvement in an ML family language.

Post reply on HN