It's definitely not just buzz, it just takes time for a company to begin adopting a radically new platform with so many differences to it.
I also have many friends in other .net based orgs and they've each got similar things happening in their companies.
Release of core happen on a pretty regular basis and we've not seen any issues with Microsoft not putting time and effort into it.
We[1] have multiple teams working with it right now (we're strangling our netfx 4.6 monolith), and some of those teams have already pushed their work to production.
The big advantage that I've seen is that it puts teams in charge of their own destiny. I remember the upgrade from netfx 2.0 to netfx 3.0: it was awful. The entire codebase had to be upgraded. Customers had to be upgraded to netfx 3.0. If another vendor futzed with and broke the machine.config, we'd break. With netfx you are perpetually behind the curve and at the mercy of the admin, especially if on-prem is a concern. netcore is xcopy deployment, runtime and all. You can use netcore on alpine[2] (netfx only works with Windows containers).
> there isn't any reason for them to focus on it.
1. Even if nobody was using it, I bet Microsoft would use it themselves. It is so much better than netfx.
2. Azure. It does run outside of Azure, obviously, but the Azure integration in VS is a powerful bait and hook.
Plus, for something that there's no reason to focus on, they are certainly putting a lot of focus into it. Even if I haven't figured out the true reason to focus on it, there clearly has to be one.
> There just aren't many available alternatives to the frameworks and packages
That was an issue up until, maybe, a year ago. Most packages have netstandard (a build target that works with netfx and netcore) support nowadays. If they don't, they are probably unmaintained.
[1]: https://www.k2.com/ [2]: https://hub.docker.com/r/microsoft/dotnet/
We are a tiny bit miffed at some missing features, though (especially in System.Reflection.Emit).
F# is fundamentally a .NET language ... It's impossible to divorce
the two, even if the target runtime environment is not necessary a
.NET runtime. Those other environments inherent language design
decisions made with .NET as a target runtime. The .NET runtime
with .NET Core is indeed minimal, is natively supported just about
everywhere, and was built with cross-platform in mind. F# is a
part of this, for better or worse.
To everyone else - maybe I should have asked a better question, but it's quite clear to me now that people are in fact using this in production. That's great. My only question now is, what is Microsoft's strategy here? There's no money flow with .net core as far as I know, so why put in the effort?
Traditionally MS was laughed out of vast swaths of academia, research, and Enterprise solutions. Now, they're making ever more bank off of Azure, and want to get their products deeper into those markets where being Linux friendly, cross-platform, and all the rest are "must have" features. That's big money, and future growth.
At the same time: their current breed of engineers also struggles with some of the historic windows nonsense, and it's becoming ever less profitable to maintain. So it makes sense even for MS to transition a bit away from legacy MS.
SQL server runs on Linux now, MS hosts Kubernetes cluters and has Linux bundled in Windows, and Azure scaling is always cheaper when not paying OS licensing fees. MS stands to win a lot by having a relevant development platform, MS stands to win a lot being the tool provider of choice for cloud development, MS stands to win on cloud hosting and growth, and MS stands to win a lot with upselling to captive cloud customers (BI, BizTalk, OMS, Analytics, etc).
.Net Core is the free razor, everything else are the high-margin blades :)
Plus, Microsoft wants to get back in the game on mobile, so they need at least a platform, if not an OS. If they can put .NET reliably on top of Linux, Android, iOS, they can probably find ways to monetize that.
Come on, surely you can make a non-.NET dialect of F#. Sure, not every .NET F# program will be portable to it. There must be some considerable abstraction in F# that isn't tied to .NET.
This is a F# -> Javascript compiler and environment, itself running in your browser (in Javascript, obviously).
https://github.com/kjnilsson/fez
This is a project running F# on BEAM (Erlang).
So yes, of course you _can_ write a compiler from F# to whatever platform you choose. It's just a really major effort, in no small part because F# is a way, _way_ higher-level language than C (you'll remember 'worse is better' - a big deal with C is that it's easy to write a compiler for).
We are still feverishly at it in 2018 and there is no end in sight.
> It's just a really major effort
That is neither here nor there.
Can you make F# the language meaningful on other VMs? Not really, as F# is a deep, deep, .Net language.
This isn't about abstraction or syntax, it's that every concept, feature, and element of the toolchain bases itself on .Net capabilities and considerations. From referencing libraries, to scripting, to type generation at specific points in the compile cycle to support Type Providers... Async computation blocks...
Remember, F# came from MS research based on the established working .Net framework, and was tighly tied to fundamental framework improvements (like generics and dynamics). It was built by hardcore .Netters, it's the first "true" .Net language, and it bases major language features on deep-down .Net capabilites not found in other VMs.
The point of the quote is that if you were to try this, at best you'd get "OCaml Over There", not "F#", since F# without .Net is "OCaml". It's not the syntax, it's the deeply intertwined nature of everything else.
What are "dynamics" in this context?
>and it bases major language features on deep-down .Net capabilites not found in other VMs.
Can you give some examples of that?
The differences between the two languages are primarily in the way it integrates with the .NET platform and many assumptions on it.
If you wanted something similar on say, the JVM, starting from OCaml, you would make many different design choices and the result would be a very different language.
For example, the whole type system is based on .NETs type system. interfaces, subtyping and generics, properties and indexed properties, which are quite different on the JVM and other platforms.
F# usually relies on having attributes (annotations in Java) for compatibility with other .NET languages like C# where certain features did not fit into the OCaml syntax and semantics cleanly. These also wouldn't transfer over to other platforms very well.
Some features which F# has that could transfer over to other platforms include measure types, active patterns, and type providers. I believe some of these have already made it to other languages. Gosu, for example, on the JVM had a feature similar to type providers before F# got them, so you could argue that F# borrowed that feature.
also, on a technical point, .net core is fast, faster than .net framework and mono.
To me .net core seems more like just a buzz word to prove that they like open source and anyone can use their software. But there isn't any way to monitize it so there isn't any reason for them to focus on it.