4 ms·

> (namely, working with nontabular data, external APIs, deep learning, and productionization). I agree with all of that except for productionisation. I would h

> (namely, working with nontabular data, external APIs, deep learning, and productionization). I agree with all of that except for productionisation. I would have agreed before dealing with issues around getting consistent versions of python + libraries to run. The issues I see with Python are as follows: - pip doesn't actually check to make sure your dependencies are compatible, which causes real problems with numpy et al - conda isn't available by default, and running it on remote boxes is non-trivial (I spent a whole week figuring out how to get it running in a remote non-login shell). - This makes it really, really difficult to actually get a standard set of libraries to depend upon, which is really important for production. R, on the other hand, actually resolves dependencies in its package manager, and the R CMD BUILD for packages, while super annoying helps you produce (more) portable code (did you know that conda doesn't provide cross-platform yml files unless invoked specifically?). In terms of handing it over to engineering/non data science people though, Python is much much much better. tl;dr Python's an ace language with a terrible production story.

ekianjo 6y ago
> R, on the other hand, actually resolves dependencies in its package manager And you have packages like renv which also help isolate specific versions of packages to make portable environments even more reliable.
- klmr 6y ago
  ‘renv’ (only) does more or less what pyenv does. Contrary to what the parent comment says, R doesn’t actually do any dependency resolution at all, and the official package repository (CRAN) doesn’t even archive many old versions (though MRAN does). I strongly prefer R for data science, but its dependency management story is poor, even compared to Python’s (which, in turn, is poor compared to Rust/Ruby/…).
  - disgruntledphd2 6y ago
    That's simply not true. R doesn't store old versions, which is actually brilliant because your code breaks when your dependencies rot. Python will silently upgrade numpy as a transitive dependency and break everything, which is much worse. MRAN also has daily snapshots which is normally how i handle stuff that will never be updated. I also specified building an R package which does handle dependencies versus the python equivalent which does not. I'm not saying R is good, I'm just saying Python is way worse.
  - guitarbill 6y ago
    > even compared to Python’s (which, in turn, is poor compared to Rust/Ruby/…) Compared to Rust? Sure. Compared to Ruby? Maybe in the way that a lockfile isn't automatically generated when using pip. Hating on Python's dependency management is a meme at this point. You could do a lot worse than the current pip + venv, and upgrading to something like poetry or pipenv is pretty painless. I'm pretty sure 99% of problems occur because people don't pin stuff.
hobofromabroad 6y ago
I agree and disagree. We deploy our models via Cloud Foundry which has support for Anaconda. Model building is done in AWS with access to Anaconda. Usually we have an environment.yml for the REST API and one for model building. This makes modeling -> deployment cycle fairly easy, if not perfect. You can also use pip and env, but you have to make sure that all important dependencies are specified sufficiently specific. But that's also the case for Anaconda. (For instance, we had a problem in the API with a x.x.y release of greenlet or gevent since we only specified x.x) For R, well use packrat. R IMHO has the problem of many different algorithms with different APIs. Yes, there are tools like caret, but 'you' will run into problems with the underlying implementations eventually. sklearn makes things easier here, at least most of the time. I would also prefer R for EDA. But I don't like splitting eda and modeling that way, since there can be subtle differences in how data is read which can lead to hard to find problems later on. (Yes, you could use something like feather) I also thing that tooling for python is much nicer, pytest, black, VSCode python integration just seem more mature.
laichzeit0 6y ago
And what libraries do you use in R to generate a REST api that has Swagger 3 documentation? Authentication with JWT tokens? Monitoring, e.g. ApplicationInsights?
- disgruntledphd2 6y ago
  For that, R would not be the right choice. I stand by my comments on how difficult it is to productionise python ML applications. I think all of those things you mentioned are JVM stuff, right? There's a version of R called renjin that could be used in that scenario. Don't get me wrong, I'd love if this was better in python but right now it is far more difficult than it needs to be.
  - laichzeit0 6y ago
    Nope, none of it is JVM stuff. It's pretty standard stuff if you want to ship an API into a production environment and expect other developers/services to interact with your model. How do you know your model is failing/slow to serve requests? You need monitoring/logging. How do add security? I'm talking API security, like JWT tokens with scopes and claims. Maybe we mean different things by "productionising ML applications" but building a docker container with an R runtime and the correct package versions is not all, or even half, of what's required for production.
    - pbowyer 6y ago
      Why would you have any of this tightly coupled to your model? Set up a separate API gateway, which covers all your points (REST endpoints, monitoring, security) - there's plenty of off-the-shelf options. Route authenticated requests to the backend that runs your model.
    - disgruntledphd2 6y ago
      Depends on your model. Mine score users daily, so I don't need to worry about building an API. Logging is pretty available in both (though better in Python to be fair). I don't really see how building my model in Python would make it easier to add this API functionality either, so it's a bit irrelevant. Like my docker container (which appears to be almost essential in Python but nice in R) can call predict in any language, and then pass through to the API using the tools noted above.

ekianjo 6y ago

> R, on the other hand, actually resolves dependencies in its package manager And you have packages like renv which also help isolate specific versions of packages to make portable environments even more reliable.

klmr 6y ago
‘renv’ (only) does more or less what pyenv does. Contrary to what the parent comment says, R doesn’t actually do any dependency resolution at all, and the official package repository (CRAN) doesn’t even archive many old versions (though MRAN does). I strongly prefer R for data science, but its dependency management story is poor, even compared to Python’s (which, in turn, is poor compared to Rust/Ruby/…).
- disgruntledphd2 6y ago
  That's simply not true. R doesn't store old versions, which is actually brilliant because your code breaks when your dependencies rot. Python will silently upgrade numpy as a transitive dependency and break everything, which is much worse. MRAN also has daily snapshots which is normally how i handle stuff that will never be updated. I also specified building an R package which does handle dependencies versus the python equivalent which does not. I'm not saying R is good, I'm just saying Python is way worse.
- guitarbill 6y ago
  > even compared to Python’s (which, in turn, is poor compared to Rust/Ruby/…) Compared to Rust? Sure. Compared to Ruby? Maybe in the way that a lockfile isn't automatically generated when using pip. Hating on Python's dependency management is a meme at this point. You could do a lot worse than the current pip + venv, and upgrading to something like poetry or pipenv is pretty painless. I'm pretty sure 99% of problems occur because people don't pin stuff.

hobofromabroad 6y ago

I agree and disagree. We deploy our models via Cloud Foundry which has support for Anaconda. Model building is done in AWS with access to Anaconda. Usually we have an environment.yml for the REST API and one for model building. This makes modeling -> deployment cycle fairly easy, if not perfect. You can also use pip and env, but you have to make sure that all important dependencies are specified sufficiently specific. But that's also the case for Anaconda. (For instance, we had a problem in the API with a x.x.y release of greenlet or gevent since we only specified x.x) For R, well use packrat. R IMHO has the problem of many different algorithms with different APIs. Yes, there are tools like caret, but 'you' will run into problems with the underlying implementations eventually. sklearn makes things easier here, at least most of the time. I would also prefer R for EDA. But I don't like splitting eda and modeling that way, since there can be subtle differences in how data is read which can lead to hard to find problems later on. (Yes, you could use something like feather) I also thing that tooling for python is much nicer, pytest, black, VSCode python integration just seem more mature.

laichzeit0 6y ago

And what libraries do you use in R to generate a REST api that has Swagger 3 documentation? Authentication with JWT tokens? Monitoring, e.g. ApplicationInsights?

disgruntledphd2 6y ago
For that, R would not be the right choice. I stand by my comments on how difficult it is to productionise python ML applications. I think all of those things you mentioned are JVM stuff, right? There's a version of R called renjin that could be used in that scenario. Don't get me wrong, I'd love if this was better in python but right now it is far more difficult than it needs to be.
- laichzeit0 6y ago
  Nope, none of it is JVM stuff. It's pretty standard stuff if you want to ship an API into a production environment and expect other developers/services to interact with your model. How do you know your model is failing/slow to serve requests? You need monitoring/logging. How do add security? I'm talking API security, like JWT tokens with scopes and claims. Maybe we mean different things by "productionising ML applications" but building a docker container with an R runtime and the correct package versions is not all, or even half, of what's required for production.
  - pbowyer 6y ago
    Why would you have any of this tightly coupled to your model? Set up a separate API gateway, which covers all your points (REST endpoints, monitoring, security) - there's plenty of off-the-shelf options. Route authenticated requests to the backend that runs your model.
  - disgruntledphd2 6y ago
    Depends on your model. Mine score users daily, so I don't need to worry about building an API. Logging is pretty available in both (though better in Python to be fair). I don't really see how building my model in Python would make it easier to add this API functionality either, so it's a bit irrelevant. Like my docker container (which appears to be almost essential in Python but nice in R) can call predict in any language, and then pass through to the API using the tools noted above.