I assume you are using VS Code with Ionide plugin? If you open a folder with an F# project (.fsproj) file, it will add an icon to the left that looks like this.
When you click that, it shows the F# Project Explorer window. You can right-click on the project and Add File. That should create the file and also add it to the .fsproj automatically. The Project Explorer is still a little rough around the edges. But helpful for basic usage.
On Windows, I've been using Visual Studio 2017. It has a robust Solution Explorer that feels like normally managing files in an editor, but it automatically takes care of the .fsproj stuff. So no need to add them through CLI. However, VS does not have a built-in terminal window, so I use the MS-sponsored Whack Whack Terminal plugin for that. (to run npm/etc. commands from within VS for Fable projects.)
I was using Ionide but had a rough go from the start and immediately fell back to the dotnet command. I'll give it another go, but I've also been meaning to start learning a bit about VS, too - might be a solid excuse. That plugin will definitely help it feel a little more comfortable. I've had an Elm project in the back of my head for a while - no reason it couldn't be Elmish!
MVU style is amazing. Go for it either way! Elm is better for learning to write pure functions TBH. Fable-Elmish is structurally and syntactically very similar while being far less restrictive. For the latter, I do recommend keeping side effects out of init/update if you want to keep the refactor/test benefits from having pure functions. (Cuz F# does not stop you from putting side effects in those functions.)
Interesting - I do love compiler-enforced discipline, but it's always nice to have an escape hatch - and F# seems like a more broadly applicable language if I'm going to invest some time in one or the other. I'll have to think about it.
Yeah, I vote for F#. But wanted to give a props to Elm for teaching me the value of pure functions. I came from C# to F# and still fell back to a lot of mutation-based/imperative solutions for a while. Elm forced me do pure functions (along with MVU, which structures most of the code to be written in pure functions) and experience their benefits. But if you understand that pure (aka referentially transparent, aka deterministic) functions produce output based only on their inputs. And if you understand the value of using them. Then it is pretty easy to understand whether you have written a pure function or not in F#, even without a compiler warning. Plus F# is great for back-end work too. (Kestrel on .NET Core is known to be a pretty fast web server.)
Awesome. I think Haskell drilled the concept in pretty well but I still always sort of miss the rigidity whenever it's gone. I'm heavily leaning F# now too - I'll have to look in to Kestrel!
Kestrel is the built-in .NET Core web server. It isn't functional or anything, but it is very fast -- look for aspcore. Giraffe is a F#/functional lib on top of Kestrel. I also wrote my own for API routing only.
Great post. :)
I assume you are using VS Code with Ionide plugin? If you open a folder with an F# project (
.fsproj
) file, it will add an icon to the left that looks like this.When you click that, it shows the F# Project Explorer window. You can right-click on the project and Add File. That should create the file and also add it to the
.fsproj
automatically. The Project Explorer is still a little rough around the edges. But helpful for basic usage.On Windows, I've been using Visual Studio 2017. It has a robust Solution Explorer that feels like normally managing files in an editor, but it automatically takes care of the
.fsproj
stuff. So no need to add them through CLI. However, VS does not have a built-in terminal window, so I use the MS-sponsored Whack Whack Terminal plugin for that. (to run npm/etc. commands from within VS for Fable projects.)Thanks so much for the advice!
I was using Ionide but had a rough go from the start and immediately fell back to the
dotnet
command. I'll give it another go, but I've also been meaning to start learning a bit about VS, too - might be a solid excuse. That plugin will definitely help it feel a little more comfortable. I've had an Elm project in the back of my head for a while - no reason it couldn't be Elmish!MVU style is amazing. Go for it either way! Elm is better for learning to write pure functions TBH. Fable-Elmish is structurally and syntactically very similar while being far less restrictive. For the latter, I do recommend keeping side effects out of init/update if you want to keep the refactor/test benefits from having pure functions. (Cuz F# does not stop you from putting side effects in those functions.)
Interesting - I do love compiler-enforced discipline, but it's always nice to have an escape hatch - and F# seems like a more broadly applicable language if I'm going to invest some time in one or the other. I'll have to think about it.
Yeah, I vote for F#. But wanted to give a props to Elm for teaching me the value of pure functions. I came from C# to F# and still fell back to a lot of mutation-based/imperative solutions for a while. Elm forced me do pure functions (along with MVU, which structures most of the code to be written in pure functions) and experience their benefits. But if you understand that pure (aka referentially transparent, aka deterministic) functions produce output based only on their inputs. And if you understand the value of using them. Then it is pretty easy to understand whether you have written a pure function or not in F#, even without a compiler warning. Plus F# is great for back-end work too. (Kestrel on .NET Core is known to be a pretty fast web server.)
Awesome. I think Haskell drilled the concept in pretty well but I still always sort of miss the rigidity whenever it's gone. I'm heavily leaning F# now too - I'll have to look in to Kestrel!
Kestrel is the built-in .NET Core web server. It isn't functional or anything, but it is very fast -- look for aspcore. Giraffe is a F#/functional lib on top of Kestrel. I also wrote my own for API routing only.
Cool! Definitely looking forward to digging deeper in to this, thank you.
Following up ...Visual Studio proper was so the way to go