I know this isn't a common rant, but I hate so-called functional language still bowing to the "infix mathematical operator special case" dogma, when those are just binary (variadic in Lisp) functions.
Always found it pretty appealing, otherwise. And no ";;"!
Though one thing I doubt c# ever gets that I love when I'm writing f# is pipeline operators. I love the way they read, from object/collection being worked on and then a list of operations being run on it in order from left to right (or you can do right to left if you need to for some particular reason).
This is a practical side of F# that doesn’t get enough spotlight — but one I’m using daily.
The flagship editor is Visual Studio, not vs code.
I’m not a dabbler in exotic languages, so this definition of “popular” was puzzling. I’ve literally never seen that operator before. Maybe I need to get out more.
It has been "stuck" at Stage 2 for a while, though.
We even do the frontend in it using Fable and Elmish, which is to say: we basically write our frontends in Elm, but the platform is .NET.
That also, IMO, makes untangling/splitting up parts of the codebase easier as well.
I only used F# at its command line, fsi.exe, to give me commandline access to .NET for exploration, testing, and munging data. Over time, I built up quite a library of usable functions that I'd have the fsi.exe program pre-load when I kicked it off, leaving me at the prompt with all .NET namespaces and my code ready and accessible.
Once you get access to your database's data, it's easy to write queries against it and then play with the data. I could then port the F# processing bits that worked into my C# projects as necessary, but it was far easier to do it that way than to write the logic deep within complex multi-project solution files, where the various classes are spread throughout the projects' files.
I also just really enjoyed using F#.
I just gave a talk about how we use F# at REN: https://vimeo.com/1070647821
It's the one programming language that changed how I think about programming.
I'm only talking about the version before type providers. Then it got messy.
Before that, we could (and I did) recompile fsi.exe to do some custom prompt manipulation. It was a slog, but it worked, but then Microsoft faded from my life. Still, that early version (I believe 2.0) F# is just magnificent.
My current work needs nothing the .NET environment provides that I can't use python's standard libraries to get done, or bash and C if I need to.
But I'm lucky to no longer be in a corporate environment, so I don't need to consume commercial services, which was much easier using WCF within .NET. Back in my previous life, constructing n-tiered services on top of SqlServer using WCF was slick, indeed.
To any who are interested in how to construct such n-tiered applications simply but securely and precisely, I highly suggest Juval Lowy's IDesign system. He had three specific videos that I watched three or four times each until I understood his distillation of his vast expertise. Of course, Mr. Lowy is one of the co-designers of WCF, which was an excellent bit of tech.
It is controlled by Microsoft. It's not going on my Linux or BSD boxes.
I know how they work, and I want nothing to do with them.
Separately installed software? Not a bit of it.
Plus, I'm not going to be downloading, configuring, or running any separate code at runtime. The project is the project, it's going to process some files, communicate with some services, and communicate with the UI, if any.
If I need to consume a service, it should be defined such that I manifest the interface module (perhaps via WCF) and then connect to it progressively from stub to ever greater functionality in test to final implementation. Trying to write a program to do all that at runtime is not sensible, IMO.
Metaprogramming via reflection, however, was useful for exploring the vast .NET framework, and I used those to great effect, especially in exploring .NET's various UI frameworks (WinForms and Silverlight), but never to create code at runtime via the emit functionality. No, that's my job: to emit code that is tested and works and is comprehensible.
As for type providers in general, I don't think databases are the best example of their typical use case. Most type providers don’t interact with external systems; they usually parse schemas, configuration files, or other structured data to generate strongly typed representations. The database-backed approach is just one variant, not the norm.