atheriel
1. Use R packages to bundle up the models with a consistent interface.
2. Create thin Plumber APIs that wrap these packages/models.
3. Build Docker images from these APIs.
4. Deploy API containers to a Docker Swarm (but you could use any orchestration).
5. Stick Nginx in front of them to get pretty, human-readable routes.
6. Call the models via HTTP from C#.
This stack works pretty well for us. Response times are generally fast and throughput is acceptable. And the speed at which we can get models into production is massively better than when we used to semi-manually translate model code to C#...
Probably the biggest issue was getting everyone on board with a standard process and API design, after a few iterations. And putting in place all the automation/process/culture to help data teams write robust, production-ready software.
An Autoconf Primer for R Package Authors
I tried my hand at saying something more original about this debate recently: https://unconj.ca/blog/for-and-against-data-table.html
On the other hand, it's nice to see some criticism of RStudio and Hadley, even if it does stray into the conspiratorial. They've done a lot for the R community, but they do have some obvious blind spots.
For instance, why does R use <- instead of = for assignment? Because initial versions (of S) predate C -- developed down the hall -- the language that first introduced = for assignment.
For and Against R's data.table Package
Copyright in Closed-Source R Packages: The Right Way
Why There Is No ImportFrom() Function in R
Communicating with UDP Sockets from R
(In fact, differential enforcement by regional police departments was one of the more compelling arguments in favour of decriminalization.)
As per usual in international trade agreements, this provision merely codifies the present status quo. There's no reason to expect that it will affect the GPL.
[0]:https://www.gnu.org/software/emacs/manual/html_node/elisp/Mi...