45 karma · joined March 27, 2014
My advice would be to only use it now if you are starting from scratch and you have no business goals in the next 6 months (you are building an MVP and can take the hit of some random bugs in production). I know that at least one startup is using it for critical services, but they are also committed to fixing the dotnet core source code when they run into a problem and I believe are part of the reason for the good pref of kestrel (new web server), I think unless you are willing to do that you should wait a bit longer.
Separate the declaration to 3 lines because the 2nd and the 3rd declarations depend on each other. Keeping them on the same line makes the reader think this is a simply declarative code but in fact it's the opposite.
Avoid using the slice shift combo but use slice with a start of 1 plus direct index access to the arguments[0] to get the first argument. this way i'm not mutating the args array and that makes the code easier to follow.
Rename the object variable to '_this'. Giving the reader a hint as to what it is used for.
And of course if this is actually to be used in production I assume it will be wrapped inside a check to see if the bind function is already defined.
As for project.json. I actually liked using JSON over XML, but it's a personal preference thing, can't really make a case that it's better.
After having to configure camalCase for json a couple of times I like the new default.
But migrating an existing app at this point is out of the question, when I no longer need to have nugget packages with rc in the version name we might do it.
The things I know are never coming to c# (like data providers) are not important to me.
So for me c# is the greatest block against f# adoption.
Add the output css to source control, now you can always deploy that in an emergency.
it would be nice to have more info about how you monitor the connection and prevent any Trojans from going around the monitor point.