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.
What is the case against F#? (2009)
31–40 of 107 posts
Re: What is the case against F#? (2009)
#32GC 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…
While GC can be a factor to work around its also a religious issue (e.g. when C++ devs transition to C# they often fight it as a subjectively perceived foe) which always make it suspicious to put to the top especially in contrast to 2009. What's the difference there? You've still got a server that you're thrashing in both cases. Did something significant change in the GC implementations between 2009 and today that makes it _less_ suitable to use as a backend server?
Re: What is the case against F#? (2009)
#33GC 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, Microsoft Trill has been running trillions of operations a day on single machines since 2012 as a .Net library [3].
[1] - https://www.bing.com/version
[2] - https://devblogs.microsoft.com/dotnet/azure-active-directory...
[3] - https://www.microsoft.com/en-us/research/project/trill/
Re: What is the case against F#? (2009)
#34F# 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.
Re: What is the case against F#? (2009)
#35F# 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?
Linux has been a first class target of F# and C# since .NET Core
Re: What is the case against F#? (2009)
#36Earlier quoted context omitted.
F# syntax is so much better than C# for functional programming - and arguably for object programming too. However, it is sufficiently different that you really need to jump in with both feet. Don't assume it will be easy because you know C#. However, once you start to grok the syntax, you begin to see how the language features elegantly tie together, and the language design decisions make perfect sense. Unfortunately…
I know OCaml and F# are super similar, but how similar is rust syntax?
Rust is kinda like F# with curly braces and no garbage collection. =)
There are many more differences than that, but definitely if you know F#, Rust feels very familiar, and vice versa.
Re: What is the case against F#? (2009)
#37our 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?
Re: What is the case against F#? (2009)
#38Earlier quoted context omitted.
What's wrong with that attitude and what do you think should be better by now?
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 Rust and F#)
But other things like, passing partially applied functions to other functions, that to me is still really hard to reason about, especially with type inference on those function signatures. Immutable data structures, while nice to reason about sometimes have huge performance downsides. And computers aren't really getting faster in ways that help that much anymore.
Re: What is the case against F#? (2009)
#39When I was learning F# I felt the biggest barrier was lack of good documentation. I’m used to languages like node.js, ruby, and elixir where APIs/guides are straightforward. programming language maintainers need to think about UX. I’ve started building a web server library[1] in F# to address this. Other libraries took for granted that I had no knowledge of .Net and required lots of .Net boilerplate. [1]: https://wiz…
This is great. I appreciate the "for dummies" approach in the tutorial
Noticed one typo in https://wiz.run/api/#api-run — the second `setHost` should be `setPort` but also probably you don't need either of those in that `run` example
Re: What is the case against F#? (2009)
#40GC 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#