Glad to hear they're doing well. I've been slowly tinkering with the tryfsharp.org tutorials and I'm liking what I see. It might be the first MS language I've actually liked since QBASIC.
I'm aiming that comment less at you than just generally because the general publicity around that is probably a bit lacking - but if things like that matter to you, F# is still a great place to look :)
Hope you carry on enjoying F# - the community is one of the friendliest, do come and say hello!
Things may have changed. I wasn't turned off by the fact that Linux support was so far from where it needed to be. I expected that. It was the toxic response that turned me off.
As for F#, I've been using it since beta. All I did was get the books and slog through them. Coming from a strong OOP background, I had quite a bit of "this makes my head hurt!" before the light started coming on, but once I came to grips with the power of the language, I didn't look back.
Yes, not all libraries are available on linux. I program F# almost exclusively on linux, and that doesn't bother me at all. The number of libraries that are available, compared to other platforms, is astounding. A couple of times I needed some kind of weird library, so I went and found an open source windows F# version (or C# version, gotta love CLR), then just added the project to my solution. Presto chango, I built both projects at the same time and got a huge amount of functionality for the price of an hour or so downloading code and building it.
(disclaimer: I write microservices any more. No GUIs)
Biggest problem I have with my set up is remembering some of the switches and tweaks to get the thing to build. My code runs so great without my having to horse around with it, so it might be months between getting out the tools. That's usually a couple of hours of banging my head against the wall, but once I've got the build cycle nailed, it's a sweet setup. Best I've used in a long time.
On the other hand, it's possible to "not get it" and write messy code in even the most bondage-oriented languages.
The language gives you plenty of tools to enforce the appropriate coding style for a given project.
1- In the more general case, you cannot enforce a rule to disallows clumsy/inelegant code. You cannot force proper use of the language.
2- In the Option/null case, this is an education problem. My boss is an old-school programmer with lots of experience (and I've seen him successfully solve and/or prevent real problems at work that bit every other team, so by no means I want to sound disrespectful of his experience), but he simply doesn't understand why Option is needed. He claims "defensive programming should be enough" (i.e. checking for null at every turn). He claims "academia is not good for anything", and I guess he sort of believes Scala is an academic language full of fancy but not really useful constructs. He is not completely sold on functional programming, pattern matching, etc. So I cannot simply have the language complain about nulls, because I must justify the enforcement of this rule to my boss, and he isn't convinced. (Note: this isn't limited to Option values; think of almost every feature/coding style from Scala that might sound unfamiliar to Java programmers, and it's the same problem with my boss).
[1] https://github.com/clojure/core.match [2] https://github.com/lazerwalker/clojurescript-koans/blob/mast...