> the Microsoft .net core compiler is FOSS
Oh, I didn't know that.
Very cool.
Can I apt-get the toolchain?
[EDIT]: and for those interested, here's the github repo:
Oh, I didn't know that.
Very cool.
Can I apt-get the toolchain?
[EDIT]: and for those interested, here's the github repo:
Fortunately MS provides a better alternative: the dotnet install scripts. [0] Make sure you add the install directory to $PATH.
[0] - https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-in...
Oh, this doesn't sound good at all.
One thing I positively hate about Java is always having to worry about which version of this and that (sdk, vm, headless, etc...) you run on top of. The claim of write once run anywhere has not really happened in my book.
Even C++ is better in that regard these days.
I am certainly hoping the .NET / F# environment didn't inherit that attribute from the Java ecosystem, that'd be a major downer.
My goal is only to learn F# / experiment with it, and I'm certainly hoping never to have to spend a second thinking about "versions of the runtime & sdk".
Runtime versions are something you worry about when you are actually deploying / distributing applications.
dotnet build "myproject.fsproj" --runtime linux-x64 --self-contained
...it will compile your project with dotnet bundled together. So you don't need to "install" dotnet on the destination systems running your program.
It worked on some Debian and CentOS/cpanel servers that I have (never installed dotnet on them).
That command alone gives you a whole directory of files that you need to deploy. But I think it's also possible to have to completely bundle all of it into a single file.
I think this guide tells you how to do that: https://www.hanselman.com/blog/making-a-tiny-net-core-30-ent... ... haven't tried it yet though.
It was relatively easy to figure out how to install different versions alongside each other myself after digging into it. The folder structure of the distribution archives is already setup for it after all. After getting it in place it even lets you list and switch between them haha.
The CLI hides the different sdk versions. If you run `dotnet --list-sdks` it will tell you which SDK's you have installed. If you don't have the SDK you need, when you install it it should be placed in the same directory as your other SDKs. Then the CLI will recognise the different versions.
This can all go wrong if you have multiple instances of the CLI installed. That's why I recommend using the dotnet-install scripts from the start, because then you'll only have one instance and you'll be able to manage installed versions.
Unless you mean the CLI downloading the versions itself? I see your point in this case. I think that would be a nice developer convenience. From a production engineering/devops perspective, having the install scripts separate makes it much easier to automatically install the correct runtime.
In fact, F# has been open source longer than Roslyn (the C#/VB.NET compilers) and .NET Core!
There used to be a funny split in the repos: Microsoft had their own visualfsharp repo, and there was a blessed fork which was more community and Linux friendly.
Download the Sdk, who bundle both the runtime and the C#/F# compilers (everything you need to build a program) and the `dotnet fsi` REPL
All of that is open source, developed in different repos and bundled there in a nice installer.
Support all platform and can cross compile for other OS
Please do not use Mono, because contains an old version of F# and lots of quirks to use.
The current way is .NET (was called .NET Core, renamed recently) because is cross platform by design, and eventually Mono will be merged 100% there.
Plus is tons more performant and better tooling
I can indeed.
apt-get install fsharp
This is great.
How times have changed!
1: https://docs.microsoft.com/en-us/dotnet/core/install/linux-d...
Goal is not to spend a couple of hours fighting to install the stack, but to use the time learning about the language.
apt-get gives me that.
MSFT-specific stack install tool don't really sound like a no-brainer, but I'll look anyways.