chusk3

For me the right way is never to allow non-ff merges and instead require all changes to be integrated into your branch (either via rebase or merge from base into your branch) before merging. GitLab supports this flow nicely and it has been wonderful for ensuring that the resulting product passes tests.

Don't forget Fable - F# - https://fable.io

You don't have to have separate dockerfiles. If you use multistage builds, you can name the specific terminal stages and then invoke them with 'docker build -t stagename', which will reuse the build cache as you'd expect. I've done this to export multiple app containers from a monorepo.

Promise liveview is such a cool concept. I'm keeping an eye on the repo to try to translate the concepts to my languages Pheonix-clone, Saturn.

paraphrasing from the main site(https://fsprojects.github.io/Paket/):

> Paket is a dependency manager for .NET and mono projects, which is designed to work well with NuGet packages and also enables referencing files directly from Git repositories or any HTTP resource. It enables precise and predictable control over what packages the projects within your application reference.

The big change is solution-level dependency management instead of the nuget-default project-level management, so you always have the same versions of dependencies across all projects in a solution. It also uses a lockfile for these versions so that restores are idempotent. It also allows for fetching independent files from HTTP-accessible locations or git repos, which is nice in F# because the language is succinct and enables you to reuse modules without going through the rigamarole of making and publishing nuget packages.

If you build with 'msbuild publish -r debian8.x64' or any of the other valid 'runtime identifiers', the output of the build is an xcooy-deployable folder that contains your binary and all it's dependencies including the runtime. I use this at work to make Debian packages that are standalone.

Yep, almost all of my side stuff and an ever-increasing proportion of my work stuff is in SAFE. It's actually built on Dustin's Giraffe library, which itself is built on top of Asp.Net Core. Cross platform, great ergonomics due to Giraffe, and I get to share client side/server side domain models, validations, etc due to the shared F# heritage.

No you're correct, C# async/await synchronously executes up to the first yield point. In general the tasks are 'hot' in C#, as opposed to F#'s 'cold' Async type.

I can echo this comment. Protecting websites with lua-resty-openidc was very easy and required no changes to the actual application code.

`figure` here is just an instance of Shape that was previously in scope. You've got to match on an instance of an object in this syntax.

This library is what I do all my new web services development in (or it's child Saturn). I'm actively working to migrate my legacy codebases to it. It feels pretty good given the host platform, and is easy to mix and match with non-giraffe components too.

The author mentions that the recursive way is harder to code in .net, but I wonder if this were reimplemented in F# which supports tail-recursion if that caveat would disappear. Also be interesting to see how this implementation compares/contrasts with data structures over in https://github.com/fsprojects/FSharpx.Collections

I get there mostly with a pinned terminal and 'dotnet watch test' in my tests directory

You should look at the all-F# SAFE Stack, then. It uses F# and .net core for the whole application and supports elm-style UI programming on the client side with react and server side rendering: https://github.com/fable-compiler/fable-react/blob/master/do...

The alternative is a package manager like yarn or paket where even your transitive dependencies are pinned in a lockfile. I don't see how someone can look at a version spec made of only top level dependencies and call themselves immutable.

F# records and tuples implement equality and comparison based on their members automatically, which handles the part that you mention that you're supported to do in C#. It's not reflection so much as at compile-time the compiler emits the correct implementation of these methods.

Holy smokes I feel you on the cronjob thing. They just went to beta with it in k8s 1.8, so now I'm waiting for that to get stable on GKE. That plus a managed Redis/memcached would be all that I need right now.

yeah, take a look at https://hub.docker.com/_/fsharp/ for the official images.