Comment

Comment by reader_mode

I haven't been in .NET for a couple of years but I've worked on quite a few .NET projects over the years. I've seen F# being added to 3 (as far as I can remember), in completely different companies/teams/contexts - and it always ended up being the same - some enthusiastic guy (or a few of them) tries to sneak in F# as a part of the system. They don't really gain traction with the rest of the team because people have shit to do and no time to study a new language at work, so it becomes "their own thing". Regularly the tooling breaks (eg. visual studio intellisense stops working on C# projects if you don't disable F# projects, builds randomly start to fail, etc.) The person who introduced it becomes the go to guy for these problems, coupled with no traction for his pet project and being a motivated developer - they leave and now the project has this magic F# part that nobody really knows how it works but everyone knows how to work around.

IMO C# is picking up a lot of small things that make it incrementally better than it was before, and at some point it's not worth the hassle to go to F#. F# features are gradually added to C# so C# developers have time to pick them up as well.

I've heard of F# only projects doing great, but I think you need to have a team committed to doing F#. Back when I was into Clojure they had this mantra of "add Clojure to your work projects as a library and pretend it's just this small thing you used to solve some problem because it's all on JVM and Java compatible and then keep expanding on it" - I think this turns out terrible in practice.

parent reader_mode 5 years ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton