One way to look at it, but consuming OOP libraries doesn't turn code into OOP.
Also, FSharp.Core (which most F# code leans heavily on) is not OOP at all.
F# promotes object programming, doesn't proscribe mutability, encourages function and data approach.
It offers simple access to the different paradigms, with some opinionated choices (e.g. preventing leaning on OOP beyond an arbitrary stretch, like no "protected", only explicit interface implementation, etc.).
I don't see how that changes things. You'd have to async it all the way to the top but the syntax is still cleaner than F#. If you're using an Asp.Net controller you just declare the handler as async Task<IActionResult> and it's fine. Even program main methods can be async these days
It's absolutely not exactly the same; let! is only available within a computation block. If you want to return some value from the computation block and return to Functional land without having to pause the thread you need to use a continuation, which C# has built in syntactic sugar for in async/await and F# does not.
It's actually sort of the other way round. C# has hardcoded syntax for async/await. F#'s syntax for async/await is a fully-general user-accessible mechanism.
They're not so different in that regard. C# `await` can be adapted by making an awaitable and awaiter type[1], which isn't to dissimilar to how a computation expression in F# needs to implement methods `Bind`, `Return`, `Yield`, etc.
In both languages these patterns make up for the absence of typeclasses to express things like a functor, applicative, monad, comonad, etc.
* community pressure so that F# libraries could standardise on better things that Choice1Of2 = Ok and Choice2Of2 = Error, or using a bare tuple (which is very not clean for APIs)
* F# ought to remain flexible in terms of not pretending of totally abstracting away the fact that most of the dotnet base class library or the overall dotnet ecosystem, uses exceptions, it is not like Result type was created to abstract runtime exceptions away.
For all other needs, one is just one wrapper / or abstraction (for library that don't "meet our standards" in terms of exception safety) away, along with a bit of adhoc tooling around leveraging FSharp.Compiler.Service for sake of adding static analysis, for architecture astronauts, dealing with behemoth or safety critical codebases, requiring even more screws turned, but even there, F# (and so many other languages) may not meet the bar if those are the critical properties for a project involving code.
Overall, F# is just pragmatic for the 99.99%, and not trying too hard beside the steady core language idioms, and how the organic community wants it over time, to satisfy hypothetical and intellectual pursuits of the highest abstraction and safety.
The culture of F# is mostly about throwing productivity parties and being done with it (while not suffering so many of the wrong choices done by C, C++, Java and it's famed sibbling, C#), rather than the higher conceptual type theory perfection that (sometimes ?) lead to code that is not less kludgy, or easier to maintain, in the grand scheme, for the masses of developers, that are not yet expert in Haskell, Scala, etc.
It is probably not too dissimilar to OCaml culture, while embracing some aspects that are familiar to more people, due to relationship with dotnet ecosystem.
(There are languages more similar to C# than Java and vice versa, and of course the underlying type system differences between JVM and .NET also add to this rift, C# was intended as a successor to C++ just as much as it was to Java)
In context of adding burden of having someone to translate for you in Japanese, the statement he made seems good enough and to the point.
Maybe you are far too pre-assumtpive that there was any ill effect, or even ill intent, in the statement being made, especially if the same fact is accounted for in gnuplot FAQ.
It scores much higher to me on journalism than whatever came in US press.
It seems people in US don't value defending free speech, and tend to get offended easily due to taking things only on first degree.
In that frame, they should care more about defending the first amendment of their constitution, and try to get other degree when interpreting words they have negative reaction to.
I don't know how to solve the issue, but I've started trying tackling some of this in context of code of conducts affecting many sofware communities:
The closest thing is https://github.com/rspeele/Rezoom.SQL which once compiled in your F# project, can be used in C# by referencing the generated assembly.
Although this is nothing to do with string interpolation, the "typed string interpolation" refer to the F# printf format specifiers.
You could also build such tool separately using FSharp.Compiler.Service (possibly using the analyzer infrastructure for ionide: https://github.com/ionide/FSharp.Analyzers.SDK), AFAIU there will be consolidation of this type of tooling relying on FSharp.Compiler.Service in the future to make this integrated to all F# tooling.
Also, FSharp.Core (which most F# code leans heavily on) is not OOP at all.
F# promotes object programming, doesn't proscribe mutability, encourages function and data approach.
It offers simple access to the different paradigms, with some opinionated choices (e.g. preventing leaning on OOP beyond an arbitrary stretch, like no "protected", only explicit interface implementation, etc.).