I didn't find F# so hard to run in production, particularly after JetBrains released Rider, but even before that I didn't think it was so bad.
At Jet we managed to get to pretty decent scale with F#, and for the most part got pretty ok performance. Often I would use the C# versions of libraries simply because they were updated more frequently. Everyone says that the C# interop is clunky and I think that's just not true, I found it relatively easy to work with C# libraries and utilize the .NET Framework. I used ConcurrentDictionary and SemaphoreSlim pretty heavily, for example. For the stuff was a little cludgy, I found it pretty straightforward to simply make wrapper functions that did what I needed.
I even found the object-oriented support in F# to be pleasant, though I didn't use it a lot. The syntax was really terse but easy to read, so in the rare cases where I had to extend a class or something, it wasn't hard. If I needed to implement an interface, it was also pretty easy to write an anonymous interface and plop that into a wrapper function.
One thing that I didn't like about F# was the kind of unpredictable performance with the async monad. It was hard to measure, and it didn't seem to work completely deterministically due to some kind of laziness that I never completely understood. The task monad released a bit later seemed to fix that, but that was integrated a bit later than my time at Jet.
Still, I found it a pretty decent language, to a point where if I started a company I would genuinely consider utilizing F#.
I haven't really used the Ionide plugin for VSCode, but I did make pretty liberal use of the Emacs plugin (well, Spacemacs), and it was pretty solid. I used it almost exclusively for about a year; I don't know if the Emacs plugin uses Ionide behind the scenes, but I thought it was pretty decent overall.
Still, once Rider got a few updates and was stable, it was kind of hard to go back. I'm a pretty dedicated Vim dude normally, but for a lot of "enterprisey" things like .NET and Java the ability to do smart refactoring of lots of files and integrated debuggers really do become a pretty substantial value-add for me.
At Jet we managed to get to pretty decent scale with F#, and for the most part got pretty ok performance. Often I would use the C# versions of libraries simply because they were updated more frequently. Everyone says that the C# interop is clunky and I think that's just not true, I found it relatively easy to work with C# libraries and utilize the .NET Framework. I used ConcurrentDictionary and SemaphoreSlim pretty heavily, for example. For the stuff was a little cludgy, I found it pretty straightforward to simply make wrapper functions that did what I needed.
I even found the object-oriented support in F# to be pleasant, though I didn't use it a lot. The syntax was really terse but easy to read, so in the rare cases where I had to extend a class or something, it wasn't hard. If I needed to implement an interface, it was also pretty easy to write an anonymous interface and plop that into a wrapper function.
One thing that I didn't like about F# was the kind of unpredictable performance with the async monad. It was hard to measure, and it didn't seem to work completely deterministically due to some kind of laziness that I never completely understood. The task monad released a bit later seemed to fix that, but that was integrated a bit later than my time at Jet.
Still, I found it a pretty decent language, to a point where if I started a company I would genuinely consider utilizing F#.