How (not) to build .NET coreclr on FreeBSD

unitrunker

Member

Thanks: 36
Messages: 75

#1
Trying this out on FreeBSD 11.1

The proper build instructions for coreclr are here:

https://github.com/dotnet/coreclr/blob/master/Documentation/building/freebsd-instructions.md

Results from the documented instructions:

# git clone https://github.com/dotnet/coreclr.git
# cd coreclr
# ./build.sh clang50 release

I get errors the build script can't find llvm-ar, llvm-link, and llvm-nm. My dirty fix for this error is symbolic links in /usr/local/bin eg, 'ln -s llvm50-ar llvm-ar' etc. Preferably done inside a jail. That gets me farther along but no joy.

Code:
-- Configuring done
-- Generating done
-- Build files have been written to: ./coreclr/bin/obj/FreeBSD.x64.Release
~/coreclr
~/coreclr/bin/obj/FreeBSD.x64.Release ~/coreclr
Executing make install -j 5
[  0%] Building CXX object src/pal/src/eventprovider/CMakeFiles/eventprovider.dir/lttng/eventprovdotnetruntime.cpp.o
[  0%] Building CXX object src/corefx/System.Globalization.Native/CMakeFiles/System.Globalization.Native.dir/casing.cpp.o
[  0%] Building CXX object src/corefx/System.Globalization.Native/CMakeFiles/System.Globalization.Native_Static.dir/casing.cpp.o
In file included from ./coreclr/bin/obj/FreeBSD.x64.Release/eventing/eventprovider/lttng/eventprovdotnetruntime.cpp:24:
./coreclr/bin/obj/FreeBSD.x64.Release/eventing/eventprovider/lttng/tpdotnetruntime.h:29:10: fatal error: 'lttng/tracepoint.h' file not found
#include <lttng/tracepoint.h>
         ^~~~~~~~~~~~~~~~~~~~
[  0%] Building CXX object src/pal/src/CMakeFiles/coreclrpal.dir/cruntime/file.cpp.o
1 error generated.
The above looks like the typical goof of using angle brackets instead of quotes. I set this aside (may come back later) to try another approach.

The convention for most cmake builds is (a) mkdir build (b) cd build (c) cmake .. and (d) make. That almost works.
Missing a version.cpp and compiler looks for etmdummy.h in the wrong place. Two features "perftracing" and "even_trace" seem to be not implemented for this platform. Adding placebos allows cmake to progress. Also - these steps do not require the symbolic link hack above.

# git clone https://github.com/dotnet/coreclr.git
# cd coreclr
# mkdir build
# cd build
# touch version.cpp
# vi ../src/inc/etdummy.h
# (insert one line -> #include "../gc/env/etmdummy.h" )
# cmake .. -DCMAKE_BUILD_TYPE=RELEASE -DFEATURE_PERFTRACING=0 -DFEATURE_EVENT_TRACE=0

This gets me further along than running "build.sh" above. cmake creates the Makefile(s). However, actual compile fails.

# make

Code:
[ 14%] Built target utilcode_dac
[ 14%] Building CXX object src/vm/dac/CMakeFiles/cee_dac.dir/__/gctoclreventsink.cpp.o
./coreclr/src/vm/gctoclreventsink.cpp:23:5: error: use of undeclared identifier 'FireEtwGCDynamicEvent'
    FireEtwGCDynamicEvent(wideEventName, payloadSize, (const BYTE*)payload, GetClrInstanceId());
    ^
1 error generated.
*** Error code 1
I do not see this symbol anywhere within coreclr. After commenting out that one line, the build progresses ...

Code:
[ 27%] Built target utilcode
[ 27%] Built target gcinfo
[ 27%] Building CXX object src/vm/wks/CMakeFiles/cee_wks.dir/__/prestub.cpp.o
./coreclr/src/vm/prestub.cpp:730:17: error: too many arguments to function call, expected at most 6, have 8
                pConfig->ProfilerRejectedPrecompiledCode(),
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./coreclr/src/inc/eventtracebase.h:614:9: note: 'MethodJitted' declared here
        static VOID MethodJitted(MethodDesc *pMethodDesc, SString *namespaceOrClassName=NULL, SString *methodName=NULL, SString *methodSignature=NULL, SIZE_T pCode = 0, ReJITID rejitID = 0) {};
        ^
1 error generated.
Still not there.
 
OP
OP
U

unitrunker

Member

Thanks: 36
Messages: 75

#2
Okay ... wiped everything. Started over with a clean git clone of coreclr. Switched to clang 4.0. Was missing pkg lttng-ust. Fixed that. The build.sh script passes the config phase (I see "configuing done"). Chokes on linking. lttng won't link.

libs are in the lib path (/usr/local/lib) ...

The cmake generated link.txt file is missing the "-L/usr/local/lib".

./src/pal/src/eventprovider/tracepointprovider/CMakeFiles/coreclrtraceptprovider.dir/link.txt:
/usr/bin/clang++ -fPIC -Wall -Wno-null-conversion -std=c++11 -g -O0 -Wl,--no-gc-sections -shared -Wl,-soname,libcoreclrtraceptprovider.so -o libcoreclrtraceptprovider.so CMakeFiles/coreclrtraceptprovider.dir/__/lttng/traceptprovdotnetruntime.cpp.o CMakeFiles/coreclrtraceptprovider.dir/__/lttng/traceptprovdotnetruntimerundown.cpp.o CMakeFiles/coreclrtraceptprovider.dir/__/lttng/traceptprovdotnetruntimestress.cpp.o CMakeFiles/coreclrtraceptprovider.dir/__/lttng/traceptprovdotnetruntimeprivate.cpp.o -llttng-ust
 
OP
OP
U

unitrunker

Member

Thanks: 36
Messages: 75

#3
[100%] built target ilasm


Wow. That works. Need to figure out how to tell cmake to do the right thing (eg. pass the "-L/usr/local/lib") so I don't have to hand-edit a generated link.txt file.
 
OP
OP
U

unitrunker

Member

Thanks: 36
Messages: 75

#4
Woo hoo! Seems to work ...


./ilasm
Usage: ilasm [Options] <sourcefile> [Options]

Options:
/NOLOGO Don't type the logo
/QUIET Don't report assembly progress
/NOAUTOINHERIT Disable inheriting from System.Object by default
/DLL Compile to .dll
/EXE Compile to .exe (default)
/PDB Create the PDB file without enabling debug info tracking
/APPCONTAINER Create an AppContainer exe or dll
/DEBUG Disable JIT optimization, create PDB file, use sequence points from PDB
/DEBUG=IMPL Disable JIT optimization, create PDB file, use implicit sequence points
/DEBUG=OPT Enable JIT optimization, create PDB file, use implicit sequence points
/OPTIMIZE Optimize long instructions to short
/FOLD Fold the identical method bodies into one
/CLOCK Measure and report compilation times
/RESOURCE=<res_file> Link the specified resource file (*.res)
into resulting .exe or .dll
/OUTPUT=<targetfile> Compile to file with specified name
(user must provide extension, if any)
/KEY=<keyfile> Compile with strong signature
(<keyfile> contains private key)
/KEY=@<keysource> Compile with strong signature
(<keysource> is the private key source name)
/INCLUDE=<path> Set path to search for #include'd files
/SUBSYSTEM=<int> Set Subsystem value in the NT Optional header
/SSVER=<int>.<int> Set Subsystem version number in the NT Optional header
/FLAGS=<int> Set CLR ImageFlags value in the CLR header
/ALIGNMENT=<int> Set FileAlignment value in the NT Optional header
/BASE=<int> Set ImageBase value in the NT Optional header (max 2GB for 32-bit images)
/STACK=<int> Set SizeOfStackReserve value in the NT Optional header
/MDV=<version_string> Set Metadata version string
/MSV=<int>.<int> Set Metadata stream version (<major>.<minor>)
/PE64 Create a 64bit image (PE32+)
/HIGHENTROPYVA Set High Entropy Virtual Address capable PE32+ images (default for /APPCONTAINER)
/NOCORSTUB Suppress generation of CORExeMain stub
/STRIPRELOC Indicate that no base relocations are needed
/ITANIUM Target processor: Intel Itanium
/X64 Target processor: 64bit AMD processor
/ARM Target processor: ARM processor
/32BITPREFERRED Create a 32BitPreferred image (PE32)
/ENC=<file> Create Edit-and-Continue deltas from specified source file

Key may be '-' or '/'
Options are recognized by first 3 characters
Default source file extension is .il

Target defaults:
/PE64 => /PE64 /ITANIUM
/ITANIUM => /PE64 /ITANIUM
/X64 => /PE64 /X64
 
OP
OP
U

unitrunker

Member

Thanks: 36
Messages: 75

#5
This works ... CMakeLists.txt ...

Before:
if(CMAKE_SYSTEM_NAME STREQUAL FreeBSD)
set(CLR_CMAKE_PLATFORM_UNIX 1)
set(CLR_CMAKE_PLATFORM_UNIX_AMD64 1)
set(CLR_CMAKE_PLATFORM_FREEBSD 1)
endif(CMAKE_SYSTEM_NAME STREQUAL FreeBSD)

After:
if(CMAKE_SYSTEM_NAME STREQUAL FreeBSD)
set(CLR_CMAKE_PLATFORM_UNIX 1)
set(CLR_CMAKE_PLATFORM_UNIX_AMD64 1)
set(CLR_CMAKE_PLATFORM_FREEBSD 1)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L/usr/local/lib")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -L/usr/local/lib")
endif(CMAKE_SYSTEM_NAME STREQUAL FreeBSD)


This avoids hand-editing the link.txt file. Need to figure out how to use the chosen clang version (eg 4.0 vs. 5.0) instead of assuming the default.
 

HL1234

Active Member

Thanks: 7
Messages: 116

#6
There is an other link to handle with building CoreCLR on FreeBSD:

https://github.com/dotnet/corefx/wiki/Building-.NET-Core--2.x-on-FreeBSD

How I do understand, one of the sence of building CoreCLR, is the following:
Running ASP.NET Core2 Websites with the build in web-server Kestrel in an ASP.NET core2 web project
( Kestrel web server implementation in ASP.NET Core see https://docs.microsoft.com/de-de/as...kestrel?view=aspnetcore-2.1&tabs=aspnetcore2x) and using apache2x or nginx as reverse proxy:

1523803944226.png

Until now there is a completed instruction for Linux, MAC and sure Windows - but I missed some what real works with FreeBSD. Later on it would be fine to have a port for installing CoreCLR.
ASP.NET core or .Net-Framework core are the "core" open source components of the proprietary .NET Framework of Microsoft for different famous OS platforms - but FreeBSD until now is missing for it
(Maybe this forum thread belongs better to Programming)
 
OP
OP
U

unitrunker

Member

Thanks: 36
Messages: 75

#7
I've set aside Microsoft's coreclr in favor of monodevelop. It is much better supported from pkg and ports. It would be cool to have an "official" CLR but this isn't a blocker.
 

drhowarddrfine

Son of Beastie

Thanks: 925
Messages: 2,806

#9
Any chances FreeBSD official repos will contain .NET Core?
I'm pretty sure the hopes and dreams of FreeBSD developers lie elsewhere.

While Windows users love to watch Microsoft slowly take over Linux, I can only hope no such thing happens to FreeBSD.

The two times my company needed to be involved with .NET, the first cost us $50,000 as Microsoft made a change to their software long ago. The second was recently and cost a client of ours an unknown amount of time and money.
 

fryshke

Member

Thanks: 2
Messages: 28

#10
The two times my company needed to be involved with .NET, the first cost us $50,000 as Microsoft made a change to their software long ago. The second was recently and cost a client of ours an unknown amount of time and money.
Was it in 1.0 days? Or 2.0 and you didn't migrate to 3.0, even if it clearly was stated 3.0 was not backwards compatible with 2.0 due to generics implementation. Or was it Mono?

Because we still have .NET 3.0 services chugging along nicely.
 

fryshke

Member

Thanks: 2
Messages: 28

#12
fryshke The first was in the 1.0 days.
Yea, dark ages, .NET was just crappy Java copy. I've only started liking .NET since 3.5, and just won't do any hobby project on anything but .NET since 4.0. Besides having official FreeBSD support, other languages (and their runtimes, if they have them) don't offer anything more than C# and aren't so feature rich or have a syntax that I like.

And what about the second time?
 

kpedersen

Daemon

Thanks: 373
Messages: 1,217

#14
Any chances FreeBSD official repos will contain .NET Core?
I am actually surprised that ports doesn't already have .NET core. Microsoft generally likes to push this kinda crud on everyone and it wouldn't have taken one of their developers *that* long to make an official port.

Oh well. No real loss. It also saves our guys the small bit of effort from removing it from ports again once Microsoft drops .NET entirely.
I am still 99% sure that .NET Core is just the first stage in Microsoft's product discontinuation strategy for the entire .NET ecosystem.
 

roddierod

Aspiring Daemon

Thanks: 144
Messages: 828

#15
I am actually surprised that ports doesn't already have .NET core. Microsoft generally likes to push this kinda crud on everyone and it wouldn't have taken one of their developers *that* long to make an official port.

Oh well. No real loss. It also saves our guys the small bit of effort from removing it from ports again once Microsoft drops .NET entirely.
I am still 99% sure that .NET Core is just the first stage in Microsoft's product discontinuation strategy for the entire .NET ecosystem.
Perhaps this should be another thread or off topic or something, but I'm really curious as to why you are so certain about .Net being dropped. I know MS is a business and they do stuff like this to keep people buying things they don't want or need, but this almost seems like a fatal business mistake to me. Normally something like this I'd just blow off. But I remember your prediction on MS starting to push C++ that at the time seemed like crazy talk, but then it happened. Since my day job invovles writting .Net apps mostly I'm really curious if I can ramp up my trying to convince management to switch to GO :)
 

acheron

Well-Known Member

Thanks: 176
Messages: 446

#16

drhowarddrfine

Son of Beastie

Thanks: 925
Messages: 2,806

#17
roddierod You should switch to golang no matter what Microsoft does. Anything involving Ken Thompson and the former Bell Labs crew is worth pursuing. Especially if it's for professional software and not Windows games.
 

roddierod

Aspiring Daemon

Thanks: 144
Messages: 828

#18
roddierod You should switch to golang no matter what Microsoft does. Anything involving Ken Thompson and the former Bell Labs crew is worth pursuing. Especially if it's for professional software and not Windows games.
I totally agree, and use it for everything I can. But I working in a corporate environment that has this huge contract with MS so I have no choice in large projects. But for smaller apps that no one cares about I use Go when I can and for any personal programming.
 

kpedersen

Daemon

Thanks: 373
Messages: 1,217

#19
(Note: This is far too long. I don't expect anyone to actually read it!)

Normally something like this I'd just blow off. But I remember your prediction on MS starting to push C++ that at the time seemed like crazy talk, but then it happened.
My "in-progress" PhD is partly touching on this topic (and I have spent far too long in completing it so far haha) so as a side effect I am either going mad or starting to be able to see trends in these kinds of development products from these kinds of companies (They cycle and repeat in such a boring way it is almost cringeworthy). Sometimes there are so many subtle hints that I actually find it hard to explain my thoughts. I will try!

I think the big one is the realisation that Limbo, Java, .NET are all the same technology and this technology is not only dated but has one crucial issue; they are themselves incredibly reliant on C / C++ because their VMs can only really be implemented in a native language. Microsoft only knows C++ so that is the obvious choice and that means they can also never really escape it.

https://github.com/dotnet/coreclr/tree/master/src/vm

You can see here that it is all C++ and more specifically it is not a very portable affair (you can see in the architecture specific subfolders). They have to manually implement arm[64] and x86[_64]. That is not a great position to be in when trying to support a platform that changes their architecture so whimsically as the mobile industry (MIPS, armv6, armv7, armhf, etc.). This is their first problem. They have to play catchup to port their fat .NET VM to a new and upcoming platform. They miss all the best cake.

Just look at Emscripten: C/C++ and any native language using LLVM can now be compiled to asm.js and WebAssembly. The big old fat JVM and .NET VM are not going to be supported any time soon because asm.js is neither arm or x86! Games engines like Unity developed an il2cpp utility to translate .NET IL to C++ code to get round this issue.

As they move over to low performance platforms (Mobiles / tablets) which was the gimmick of the day when I made my prediction, Microsoft only really had one tool left in its belt suitable for these kinds of environments that it knew it could embrace (C++), extend (C++/cx) and extinguish (i.e C++/clr: pure replaced by... C#?).

https://raw.githubusercontent.com/dotnet/coreclr/master/src/gc/gc.cpp

Then chuck in more portability and performance hoops such as this massive GC unit and you will start to see, what is the point? Does a VM platform really offer that much over modern native runtimes? Mobile platforms are so reliant on being able to call native code that most Android apps today are all JNI bindings rather than actual C++ / Java code! Same with .NET native interop when using things like Xamarin. .NET bindings are too slow to keep up with the sloppy fast moving pace of mobile.

So this isn't really anything to do with language (C# vs C++). It is entirely to do with the fact that they are finding it much harder to market the old idea of a VM platform over native in the world of sub-par mobile platforms.

Since my day job invovles writting .Net apps mostly I'm really curious if I can ramp up my trying to convince management to switch to GO :)
I am hoping that now Microsoft has pulled out of the Windows Phone market and have failed hard in making an AppStore prison, they will focus on their enterprise customers where .NET and Java are good enough in performance (i.e on full desktop PCs) and easy to architect. However, Microsoft are not sane (or rather their shareholders aren't) and would rather have nothing than the prospect of not being able to exert control over consumers (or their data) to stay relevant. To protect yourself and provide your professional due diligence whilst avoiding being "that guy who always wants to be different" then perhaps see if you can migrate your legacy systems to run on the open-source Mono implementation to keep them alive once Microsoft fscks up.

But yes, I basically think Java, .NET and of course Limbo are old dead designs that will fade away (perhaps slowly). Migrating to another platform (not even necessarily language) is a very good idea.

Ultimately the only language that will remain after the test of time is C because that will always be what operating systems are written in. However Go is powered by the same AT&T guys behind Limbo / Plan 9 and these guys are quite familiar with C and know this ;).
So where Go has something good for it is that it doesn't just bind against C unlike Java and .NET but instead it can actually consume C code directly (which is part of the main power of C++). You can actually embed C into it (albeit in a weird way). This eliminates the problem of dying bindings plaguing Java and .NET. Perhaps this will be its saving grace!
Fun fact. Early versions of Go even used to use Ken Thompsons C compiler for the underlying binary generation! Even on Windows. You could even use it standalone for C code.

Another good one is Lua. Implemented in pure ANSI-C so is 99.9% as portable as C itself (and perhaps more so because it can be implemented in other languages). It doesn't rely on virtual memory or any platform specific stuff or JIT and any architecture specific stuff. If performance is not critical, Lua is my recommendation because you are effectively just using C (just memory safe ;)).

I am going to stop my rant now. If anyone disagrees, I am very interested in hearing your thoughts. I am not religious about any of this, these are just my observations. If I have anything horrifically wrong, please let me know so I can amend my thesis haha!

Edit: One last prediction ;)... Objective-C will outlive Swift!
 

roddierod

Aspiring Daemon

Thanks: 144
Messages: 828

#20
Thank you. This all makes senses to me. I was looking at it from the MS likes to lock people in and .Net seems to do that so why get rid of it.

Enterprise wise, when I 1st started everything we did was desktop apps (C++ then Delphi). But now everything is going web based because the C titles don't want to be locked into the office and just want to pull stuff up where ever they are.
 

roddierod

Aspiring Daemon

Thanks: 144
Messages: 828

#23
Well, the C world has a solution for that!
https://learnbchs.org/

Note: I don't think you should try to push this technology in your company. .NET is probably the better idea for now haha.
Yeah, the just ignore me now anyway. I've been trying almost 20 to get them to move away from MS lockin. A FreeBSD/Apache webserver was the closest I ever got.

Also trying to get them to replace pizza parties with prime rib parties and that not going well either :(
 

wolfspider

New Member


Messages: 6

#25
(Note: This is far too long. I don't expect anyone to actually read it!)


My "in-progress" PhD is partly touching on this topic (and I have spent far too long in completing it so far haha) so as a side effect I am either going mad or starting to be able to see trends in these kinds of development products from these kinds of companies (They cycle and repeat in such a boring way it is almost cringeworthy). Sometimes there are so many subtle hints that I actually find it hard to explain my thoughts. I will try!

I think the big one is the realisation that Limbo, Java, .NET are all the same technology and this technology is not only dated but has one crucial issue; they are themselves incredibly reliant on C / C++ because their VMs can only really be implemented in a native language. Microsoft only knows C++ so that is the obvious choice and that means they can also never really escape it.

https://github.com/dotnet/coreclr/tree/master/src/vm

You can see here that it is all C++ and more specifically it is not a very portable affair (you can see in the architecture specific subfolders). They have to manually implement arm[64] and x86[_64]. That is not a great position to be in when trying to support a platform that changes their architecture so whimsically as the mobile industry (MIPS, armv6, armv7, armhf, etc.). This is their first problem. They have to play catchup to port their fat .NET VM to a new and upcoming platform. They miss all the best cake.

Just look at Emscripten: C/C++ and any native language using LLVM can now be compiled to asm.js and WebAssembly. The big old fat JVM and .NET VM are not going to be supported any time soon because asm.js is neither arm or x86! Games engines like Unity developed an il2cpp utility to translate .NET IL to C++ code to get round this issue.

As they move over to low performance platforms (Mobiles / tablets) which was the gimmick of the day when I made my prediction, Microsoft only really had one tool left in its belt suitable for these kinds of environments that it knew it could embrace (C++), extend (C++/cx) and extinguish (i.e C++/clr: pure replaced by... C#?).

https://raw.githubusercontent.com/dotnet/coreclr/master/src/gc/gc.cpp

Then chuck in more portability and performance hoops such as this massive GC unit and you will start to see, what is the point? Does a VM platform really offer that much over modern native runtimes? Mobile platforms are so reliant on being able to call native code that most Android apps today are all JNI bindings rather than actual C++ / Java code! Same with .NET native interop when using things like Xamarin. .NET bindings are too slow to keep up with the sloppy fast moving pace of mobile.

So this isn't really anything to do with language (C# vs C++). It is entirely to do with the fact that they are finding it much harder to market the old idea of a VM platform over native in the world of sub-par mobile platforms.



I am hoping that now Microsoft has pulled out of the Windows Phone market and have failed hard in making an AppStore prison, they will focus on their enterprise customers where .NET and Java are good enough in performance (i.e on full desktop PCs) and easy to architect. However, Microsoft are not sane (or rather their shareholders aren't) and would rather have nothing than the prospect of not being able to exert control over consumers (or their data) to stay relevant. To protect yourself and provide your professional due diligence whilst avoiding being "that guy who always wants to be different" then perhaps see if you can migrate your legacy systems to run on the open-source Mono implementation to keep them alive once Microsoft fscks up.

But yes, I basically think Java, .NET and of course Limbo are old dead designs that will fade away (perhaps slowly). Migrating to another platform (not even necessarily language) is a very good idea.

Ultimately the only language that will remain after the test of time is C because that will always be what operating systems are written in. However Go is powered by the same AT&T guys behind Limbo / Plan 9 and these guys are quite familiar with C and know this ;).
So where Go has something good for it is that it doesn't just bind against C unlike Java and .NET but instead it can actually consume C code directly (which is part of the main power of C++). You can actually embed C into it (albeit in a weird way). This eliminates the problem of dying bindings plaguing Java and .NET. Perhaps this will be its saving grace!
Fun fact. Early versions of Go even used to use Ken Thompsons C compiler for the underlying binary generation! Even on Windows. You could even use it standalone for C code.

Another good one is Lua. Implemented in pure ANSI-C so is 99.9% as portable as C itself (and perhaps more so because it can be implemented in other languages). It doesn't rely on virtual memory or any platform specific stuff or JIT and any architecture specific stuff. If performance is not critical, Lua is my recommendation because you are effectively just using C (just memory safe ;)).

I am going to stop my rant now. If anyone disagrees, I am very interested in hearing your thoughts. I am not religious about any of this, these are just my observations. If I have anything horrifically wrong, please let me know so I can amend my thesis haha!

Edit: One last prediction ;)... Objective-C will outlive Swift!
.Net is already running in ASM.js it's a project called Blazor has a running demo and everything.

C# is component based while C++ and C are not such as to say there is no IDL or very specific interfaces there which were a pain to implement in the past. That's a big part of the design, at least according to the creator of C#.

.Net Core has AOT as well (CoreRT) and LLVM is showing some good performance starting out with this.

The performance differences between Mono and .Net Core are vast enough that developers would not want to just stick with Mono to protect themselves. Having done significant development with both I know there is a big difference. I think on the surface maybe seeing that something is powered by C# there is some belief that it's all the same- absolutely not. I'm interested in what your experience is running NuGet for Mono on FreeBSD? .Net Core is absolutely on par with Java performance-wise now without all the licensing pitfalls. Still to this day there is an "official" Oracle Java JDK and OpenJDK due to licensing? Luckily, not an issue with C#.

Go is an amazing language and I see a lot of interest in the FreeBSD community there. I think knowing it is a priority for myself at least but what I can do in a few lines of C# compared to Go is vast. Mostly professionals using C# are not utilizing it's closeness to the metal but rather how quickly projects can get off the ground, ported to other systems, and concepts taught to other developers. I can get a "fresh out of college" developer doing significant work in about 3 months with C#. Doing this with Go I think would be much more difficult.

There are a lot of good examples and documentation out there for C# just a ton of examples and videos. You mention Lua- the docs for Lua have become more dense but still pretty minimal. Ok, so I want to cast to a string in Lua and their docs list one "tostring" method and an example- cool! The C# docs show you how to extend, overload and override "ToString" as well as a few other tricks and that's just one example. Does Lua have anything like LINQ or Entity Framework or even a debugger remotely as powerful? Just simply talking productivity here Microsoft's CLR ecosystem has an insanely great debugger. This is all before I even start in on IDE's here so we won't go there ha!

I think you would be surprised though that I do think you are right that the design is right near the end of its life for these types of languages. I think the last two weeks or so it's been weighing on me pretty heavy realizing I need to learn Go or Rust or both. I'm surprised that there isn't more "learn Node.js" in the BSD camp since, when it works, it performs extremely well and JavaScript isn't going anywhere anytime soon it looks like.

Unity uses C# one way or another and powers many, many mobile apps like it or not the damage is done and it's still C# so I think trying to say it technically isn't the same design pattern therefore .Net doesn't run on mobile is pre-emptive. Xamarin counts as well and enough developers use them both that they will continue on for a long time. This is exactly why C# on FreeBSD would benefit it is because you can keep a codebase in one language and there is support across many mobile devices and operating systems. If somehow the benefit of that cannot be seen I just don't know what else to say about it.
 
Top