3 ms·

The temptation to whine, cry and complain is too high in developer communities, as always. It's either "just the way I want it exactly" or "unusable", any smal

The temptation to whine, cry and complain is too high in developer communities, as always. It's either "just the way I want it exactly" or "unusable", any smallest and most accessible but slightly different option from preferred way to make things work be damned. I'm really sad to see a part of F# community being persistently vocal against .NET which makes F# viable and possible in the first place.

Capricorn2481 3y ago
That's an extremely uncharitable take of my comment. I wouldn't call the many days I've spent investigating and opening issues that the F# community didn't even know about (because it's on life support) to be whining about small things. I can't tell you how many times things just don't work and the community kinda shrugs it off and says "use C#". If you look in the database section of F# websites, maybe 20% of those libraries work. If you bring it up to people online, they'll say "yeah use Dapper, it's the only thing that works". This just isn't the case in Clojure and I don't think the expectation is that it should be.
banashark 3y ago
I'm happy with how usable F# is as the moment, though it's not hard to sympathize with the sentiments that get thrown around. F# has had a good run with a lot of open-source efforts in different domains, but as some core parts of the domain evolve (asp.net), if there are changes made which make it more complicated or prohibitive to use F# (t4 templates, roslyn analyzers, custom code-behind behavior), it can seem like F# is on-track to become deprecated by the moving-target that is it's native platform tooling. I don't have much of a doomer mindset about things, since from the evidence of the F# team's priorities, it's keeping up with CLR and C# specific features (check the F# releases for how many features are compatibility-focused) while also delivering on some very cool F# specific things (SRTP, nested record copy/update, etc).

Capricorn2481 3y ago

That's an extremely uncharitable take of my comment. I wouldn't call the many days I've spent investigating and opening issues that the F# community didn't even know about (because it's on life support) to be whining about small things. I can't tell you how many times things just don't work and the community kinda shrugs it off and says "use C#". If you look in the database section of F# websites, maybe 20% of those libraries work. If you bring it up to people online, they'll say "yeah use Dapper, it's the only thing that works". This just isn't the case in Clojure and I don't think the expectation is that it should be.

banashark 3y ago

I'm happy with how usable F# is as the moment, though it's not hard to sympathize with the sentiments that get thrown around. F# has had a good run with a lot of open-source efforts in different domains, but as some core parts of the domain evolve (asp.net), if there are changes made which make it more complicated or prohibitive to use F# (t4 templates, roslyn analyzers, custom code-behind behavior), it can seem like F# is on-track to become deprecated by the moving-target that is it's native platform tooling. I don't have much of a doomer mindset about things, since from the evidence of the F# team's priorities, it's keeping up with CLR and C# specific features (check the F# releases for how many features are compatibility-focused) while also delivering on some very cool F# specific things (SRTP, nested record copy/update, etc).