I do wish people would give the language that has (relative to this ^ trend) 'already arrived' a chance.
Right now most companies (in the .NET world) just run on C# and no one tries anything new except when it arrives in C# (and even then its a struggle - even though the situation has improved a lot in recent years). A mixed model would also open other scenarios.
The mixed compilation is something that current web tech (using bundlers) has in advance. I can do crazy things and end up with the best (optimized) output using a common denominator.
On the F# track I fully agree - its a wonderful language that more people should try out.
> Basically a single assembly has to be written in the same language.
This is like saying a single js file has to come from only js files, still bundlers today merge all kinds of types in there - in a single sweep.
I am not writing this since I think mixing C#/F# is the future (well, it would be cool), but because it could allow the C# ecosystem to improve. Right now the best thing we have for metaprogramming in C# is Fody; and I personally think we could do better.
Hopefully this expressed my idea a little bit better.
Or, you know, use ILMerge, which is pretty much the equivalent of the JS bundlers you mention. With some custom MSBuild targets you should be able to create a project file that contains C# and F# files, both of them compile to intermediate assemblies (although you can't have circular dependencies between both), and a step afterwards merges the assemblies into the actual one.
This is actually untrue - though the tooling does not make it easy.
If the output type of a 'project' is set to `module` instead of `assembly`, it can be added as a module reference to another project which builds an assembly.
The downside used to be that completion in the IDE didn't work, but as far as I'm aware there's no real reason why multi-module assemblies couldn't easily be exposed by tooling if it was considered important enough.
I watched a talk about F# on YouTube recently and the guy said they used F# for domain logic and C# for plumbing code and he showed them working together...
> While early adopters may accept some problems on the way (like immature tooling), the majority expects a definite productivity improvement without disrupting the way they work (evolution instead of revolution).
Tooling in F# was/is bad for ages, and also lags in other areas. You have to put up with some disruption to your normal workflow to really embrace it.
