1. 32

  2. 4

    I’m running .netcore on some nixos servers for one of my clients. It works surprisingly well! It’s nice that I don’t need to manage a set of windows servers anymore and just focus on my linux ops/infrastructure.

    1. 3

      A very good breakdown of how we got to where we are today. I’m also glad the author took time out to talk about the lineage of F#.

      1. 3

        I tried .NET ~2 years ago, wanted to try to make something with Monogame (which is a rewrite of discontinued Microsoft XNA). Seems that nothing had changed with tooling, and it’s still hard to use outside standard “Windows + Visual studio” setup. I remember I had to manually add each source file to xml with cryptic format designed for Visual Studio, which was repurposed to be used by non-gui build system. I had to use yeoman (!) in order to create initial template for project, because it’s impossible to write configuration by hand from scratch.

        Also, F# had, and still has, separate tooling: paket, which is something like Ruby’s bundler, and Fake build system. I remember one of these tools rewrited .csproj files, but only partially, in parts where dependencies were specified, or something like that. Maybe nicer tools, but still based on horrible msbuild below them.

        Another problem I had at that time is documentation: Monogame didn’t have its own documentation because it implements API of Microsoft XNA, and XNA docs on Microsoft website were horribly slow to load (the same for standard library). Again, you are probably supposed to read it in MSDN application installed locally.

        1. 2

          The reliability of F# tooling like Paket and Fake two years ago and today is like night and day. Also there’s a language update to F# and compiler updates intervening.

          1. 2

            That said, the upgrade from FAKE 4 to FAKE 5 is painful and not trivial. There is a better way to do FAKE 5 which is this https://github.com/vbfox/FoxSharp/blob/master/src/BlackFox.Fake.BuildTask/Readme.md which makes a compiled build program instead of a build script. Much easier (read: possible) to debug, among other benefits.

        2. 1

          What has happened in the .net ecosystem, and the industry at large, is a gradual shift from component-based Visual Basic-style gui applications to web applications. In later versions of .net Framework, the main selling points are no longer the gui builder tools, but the asp.net framework. With .net Core, this is taken an additional step further: there are no longer any gui builder tools; it’s all about the web.

          I’m guessing it’s also about the fact that implementing a cross platform GUI layer is a non trivial thing to do well, and ongoing effort to keep up s new operating systems and their associated APIs are released.

          1. 3

            I think the same thing could be said about web browser-based GUIs. If we spent half the effort needed to uglify and babelify and shim web GUIs to make them cross-browser compatible on instead making a native cross-platform GUI toolkit we’d get a long long way.

          2. 1

            Nice article! I skimmed over Syme’s “The Early History of F#” and this was a good complement to it.

            I didn’t quite get the motivation for .NET Core though?

            Why not port the original Windows code in .NET Framework to Unix and other platforms? Was Windows somehow too deeply baked in?

            And now that they’ve acquired Mono, what are they doing with it?

            It seems like a very odd situation. I get that one improvement is portability. Is that it? It seems like a very high cost to pay. Are they also trying to remove some other legacy?

            I would be also interested ot hear how other languages fare on the CLR. You mention that F# has significant constraints. And I remember that VB.NET was completely incompatible with VB6.

            Although Syme’s paper said they went to a lot of pains to make the CLR language agnostic? Did that not really pan out? I know that the JVM is pretty language-specific, but I thought that the CLR did better.

            1. 2

              The .NET framework is build for Windows, and was never intended to be ported.

              As such, the .NET Core is built ground up to not assume that it is running on Windows

              Microsoft acquired Xamarin (A native mobile framework which enabled C# on Windows Phone, Android and IOS), and they had made Mono part of the effort to support these platforms. That’s why Microsoft ended up with Mono.

              There’s quite a few projects that has ported other languages to compile to CIL and to run on the CLR.

              A few examples are: PHP on the CLR - https://www.peachpie.io/ Iron Python - https://ironpython.net/ Java - https://www.ikvm.net/

              The CIL/CLR is language agnostic. There’s even an older project called Iron Ruby which was Ruby on the CLR. Amongst the few things I remember, the dynamic keyword was added to create support for Python and Ruby.