Since they came out, I've been craving type providers like Smeagol The Ring.
F# is gaining independence from .NET
41–50 of 181 posts
Re: F# is gaining independence from .NET
#42More leetcode trash. If you're not using a functional programming language you're "doing it rong".
Still yet to see practical advantages of using F# which don't result in convoluted, abstruse code... besides unit conversion for a calculator app
Re: F# is gaining independence from .NET
#43> In F# the order of the files matter. I didn’t quite understand this section and it seems very counterintuitive can someone elaborate a little?
I think he means you have to write down a list of files in your project somewhere, but each file can only depend on files that come before it in the list. So the files with the fewest dependencies (e.g. utility type stuff) come first, and `main.fs` (or whatever) comes last.
You do it in the .fsproj. I wish Microsoft would add a warning to explain that, instead of just saying the modules can't be found. Really confused me for a good few hours.
Re: F# is gaining independence from .NET
#44If F# ever got something akin to Scala Native, or Kotlin Native, I think it'd do really well. In my limited understanding of the F# ecosystem, I don't believe there are a lot of voices calling towards a multiplatform future beyond the NET world. Fable is cool, but native is a must-have for a lot of people, myself included. The docs are bad but not inexcusably so, it's a nice project within MS, I get it. The underlyin…
Isn't F# pretty much OCaml.NET? So if you want native, you may also go with OCaml (or ReasonML if you prefer curly-delimited code blocks).
For frontend dev't I really like Elm lately. (the article makes many refs to Elmish, the Elm-on-F# project).
Re: F# is gaining independence from .NET
#45I also like F# a lot and have used it professionally for 3 years now. I wrote down my own take on learning F# in a post "What I wish I knew when I learned F#" http://danielbachler.de/2020/12/23/what-i-wish-i-knew-when-l... . Maybe this is a helpful additional perspective for some.
Would you have if it weren’t supported by Microsoft?
Re: F# is gaining independence from .NET
#46Earlier quoted context omitted.
It allows you to envision your application as a series of data transforms, instead of a list of steps. This allows much more proximal abstractions for tasks involving data manipulation.
You can treat your application as a series of data transforms with C#, as well.
You can use a teaspoon instead of a spoon to eat soup. That doesn't mean it's the best utensil for that specific task.
Re: F# is gaining independence from .NET
#47> In F# the order of the files matter. I didn’t quite understand this section and it seems very counterintuitive can someone elaborate a little?
In an F# project file (and thus also in all editor support), the referenced F# source files have an order. Files can only see types, values etc defined in files above them (and the same within files, with some caveats). This sounds really weird and annoying but turns out to have some surprising benefits (because it limits the mental/real search space for definitions as well). In practice it's just something that is s…
This guarantees that there are no cycles, but there are more ergonomic ways to do that. And the change would be backwards compatible.
I wish languages didn't insist on preserving quirks like this one.
Re: F# is gaining independence from .NET
#48Earlier quoted context omitted.
Oh, god no. Performance even on fairly trivial number crunching tasks is half of C#, nevermind anything where GC is important or you'd consider writing it native. It's not a performant language, that's not the point.
That's not a fundamental limitation, though. Implementations of SML (f# is effectively an ML implementation), OCaml, and Haskell are all quite performant.
F# generates weird, verbose, opinionated IL code that is often JIT-unfriendly and rather focused on reference types. JIT is tailored to C# patterns and JIT is rather simple in .NET (e.g. vs JVM), so it's easy to break or miss some optimizations.
Yes, it's not a fundamental limitation of the language itself. But considering the amount of hypothetical efforts required to fix all that vs investments from MSFT in F#, it is fundamental. F# lags by several years behind JIT and TPL improvements, the issues are mostly known. But it feels like it's not that important for F#. It's is not for writing fast libraries, but for Python-like use cases, explorative programming, or writing code fast when performance is not important (no hot loops in F# code) but strict typing discipline makes code less buggy and more maintainable from the first attempt. They used to say that "if F# code compiles, it's probably correct" - that is close to the truth, but do not expect top performance without fighting with the F# compiler. Even one of the best known and oldest F# library FParsec has it's high-performance parts in C# - that's telling.
Re: F# is gaining independence from .NET
#49"...If you are sold with F# there is one important point to highlight. Do not treat F#, just another language with different syntax especially if you are familiar with Python, Ruby, JavaScript, C#, etc. You have to embrace functional programming as a paradigm...."
I want to provide a little nuance around this, because I'd give the opposite advice.
Because F# is based on OCAML and an extremely popular IDE/framework, it is first and foremost a teaching language. In my opinion, for what it's worth, the biggest mistake other F# coders make is running off into Haskell-land and trying to drag the rest of the community with them. Yes, pure FP is love and goodness, joy and love, but that's not the place to start with your average coder who just wants to see what's cool. Fable and Elmish are
I learned functional programming by reading a lot of OCAML books and the only(!) F# book out at the time. I coded like shit. I couldn't help it; I came from a strong OO background.
But then I figured out that instead of coding everything perfectly, it was more important to finish a little bit at a time, then take a look at functional smells, things like mutation. Sometimes I could fix these smells, sometimes I couldn't. Over time I found I could fix all of them. At that point I was a functional programmer.
I love these high-level F# frameworks, and like I said it's the best way to get folks involved, but wow, folks are going to create some programming disasters using them. Yes, this happens all the time withe every new thing, but functional messes are an order-of-magnitude worse than imperative/OO ones. Good luck, guys! The destination is worth the journey.
Re: F# is gaining independence from .NET
#50If F# ever got something akin to Scala Native, or Kotlin Native, I think it'd do really well. In my limited understanding of the F# ecosystem, I don't believe there are a lot of voices calling towards a multiplatform future beyond the NET world. Fable is cool, but native is a must-have for a lot of people, myself included. The docs are bad but not inexcusably so, it's a nice project within MS, I get it. The underlyin…
Isn't F# pretty much OCaml.NET? So if you want native, you may also go with OCaml (or ReasonML if you prefer curly-delimited code blocks). For frontend dev't I really like Elm lately. (the article makes many refs to Elmish, the Elm-on-F# project).
Yes! Ocaml is quite good. Concurrency is kinda poor, but it's coming along.
I am glad that Elm has influenced so many ecosystems. I wouldn't touch it with a ten foot pole because of the author, but I think the ideas of the project are invaluable and long overdue.