Earlier quoted context omitted.
It's a real shame, but not unexpected. The vast majority of programmers I meet in the wild simply do not have training in FP and by the time they decide to learn it (if they do), it's hard to unlearn "traditional" thinking. If we want to steer programming in that direction, we should teach functional programming before "traditional" programming. However, even if we manage to do that I'm not convinced that it will mak…
As a .NET developer I don't see any reason to use F# professionally. C#/CPP are tools just like a hammer, F# is a different hammer, it doesn't seem to offer advantages in my field other than being different...
F# is gaining independence from .NET
51–60 of 181 posts
Re: F# is gaining independence from .NET
#52Earlier quoted context omitted.
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.
concurrency is excellent in OCaml (Lwt, async, ....) it's just paralllelism that's a problem. multi core ocaml will eventually fix that.
Re: F# is gaining independence from .NET
#53Earlier quoted context omitted.
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.
concurrency is excellent in OCaml (Lwt, async, ....) it's just paralllelism that's a problem. multi core ocaml will eventually fix that.
Ah, of course. Clerical mistake on my part
Re: F# is gaining independence from .NET
#54I 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?
Sure, we used Elm as well. But it sometimes helps in getting buy-in that MS is behind F# to some degree.
Re: F# is gaining independence from .NET
#55> 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…
That is pretty nice for testing, since it removes the need for depency injection, or am i mistaken?
Re: F# is gaining independence from .NET
#56Are there any startups or companies using F# in production?
Re: F# is gaining independence from .NET
#57"...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, i…
>functional messes are an order-of-magnitude worse than imperative/OO ones
Why so?
Re: F# is gaining independence from .NET
#58Earlier quoted context omitted.
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…
> Even one of the best known and oldest F# library FParsec has it's high-performance parts in C# - that's telling.
To be more specific, it has a C# library so it can use _unsafe {}_ blocks to perform manual memory management. This is one key performance-oriented feature that F# lacks.
Other than that, you _can_ write F# that's about as fast as non-unsafe C#, although it means giving up most of the nicer and safer features of F#. Use mutable structs and classes instead of immutable records, for/while loops instead of higher-order functions, magic values instead of option/result types, etc... I've done it in a couple of hot paths where it made sense, but quite reluctantly.
Inline functions are still fine though for writing zero-cost helpers, and I don't think C# has them (there's an attribute but IIRC it's just a hint, the compiler isn't required to actually obey).
Ironically, F# _could_ become the best language for high-performance .NET programming, because it supports directly inlining IL instructions intermixed with regular code (whereas C# has to go through the ILGenerator class). Unfortunately it's considered such a niche case that it's not planned to be expanded beyond the standard library, and to use it in your code you have to enable an undocumented / unsupported compiler flag.
Re: F# is gaining independence from .NET
#59Are there any startups or companies using F# in production?
This one does https://resoptima.com/
Re: F# is gaining independence from .NET
#60"...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, i…
>functional messes are an order-of-magnitude worse than imperative/OO ones Why so?
Symbol/Semantic leakage. In imperative/OO, I'm organizing as I go using well-established and understood paradigms. In functional programming, you're making these paradigms as you go along, or at least you should be. If you come in with an "I'm going to kick some ass by making these classes to solve my problem" attitude, you're already headed down the OO track whether you realize it or not. Then, sure as night follows day, you or somebody else starts using a functional paradigm, say HoF.
There's nothing wrong with any of that. As a professional, you want to be good in multiple paradigms. The problem is that you're mixing them all up, whether you realize it or not (Most of the time, programmers don't realize it) And now, every piece of code can go down two entirely separate tracks as you suss out your architecture. Not only is that not going to work, it's going to make debugging and maintenance a nightmare.
This is very, very similar to how good C++ shops work. You've got to tightly limit the way you solve problems in order for all of the programmers involved to be to reason about the code.