You can simply contribute to https://github.com/dotnet/fsharp/, the maintainers are very friendly to new contributors in my experience (though the codebase is old and often quite hard to understand).
> though the codebase is old and often quite hard to understand
Even some new stuff is like that - and partially my fault, depending on the area :)
That said, some stuff that was REALLY tough to understand was ripped out recently, the "reactor queue" and incremental build system. They were central to how editor tooling works and utterly incomprehensible since they were working around the lack of a free-threaded compiler service. Now the entire compiler is free-threaded, so all the complex machinery to coordinate work is mostly deleted and/or reduced to like 50 lines of straightforward code.
As a note, the codebase is also huge because contains lot of code:
- FSharp.Core library, who contains most of the types and functions you want to use
- the fsc F# compiler
- the FSharp.Compiler.Service, who is the compiler as a library used by all editors/ide, written to be performant and support the logic of IDE functionalities (find references, etc)
- The Microsoft Visual F# code, who is the F# extension for Visual Studio
So is complicated repo, but for a reason.
But nice to work with given the features there
You can, but I wouldn't. The dotnet CLI contains its own version manager, so you need to have more precise control over the versions of the runtime & sdk you have installed. You can have multiple versions installed simultaneously, dotnet then chooses the runtime based on the project. IME linux package managers mess this up bad.
Fortunately MS provides a better alternative: the dotnet install scripts. [0] Make sure you add the install directory to $PATH.
> so you need to have more precise control over the versions of the runtime & sdk you have installed
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".
If you just want to learn, install the latest version of the SDK (.NET 6, currently in RC) and it will be able to build code or reference libraries from every older framework version.
Runtime versions are something you worry about when you are actually deploying / distributing applications.
...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.
It's a shame the CLI doesn't operate more like nvm or sdk man allowing you to download different sdk versions.
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.
That's exactly how the CLI operates though? Maybe I didn't explain it well enough.
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.
I wouldn't do this, as this is the mono bundle of fsharp. The blessed/supported way to go now is to install the dotnet-sdk packages[1] and then use `dotnet fsi` for interactive work, and `dotnet build/run/etc` for project-based work in F#.
