Python has a wider range of applications, to start. In addition to a plethora of other tasks, such as web server and advanced UI design, you may perform data science and statistics similar to those in R. Simply put, there are more users as a result (more fields = more users = more resources). With Numpy, Pandas, and Sklearn, you can essentially do anything you do in R in Python. It might also be hard to use R in building UI and Web API’s in the future as Python has been established as the standard language today for robotics, data, finance, et.
Second, Python can be used more quickly than R. For instance, the Python3 executable comes pre-installed with the majority of Linux systems. It only needs a very little setup, which makes it much easier to publish replicable results. Additionally, it is totally independent of any IDE; for example, neither Pycharm nor Spyder employ any of the Python core developers. This is an advantage that the language has over R. The majority of developers actually utilize R studio. It is more difficult to develop R without R studio, even if R itself is independent of the IDE.
R also offers benefits, such as being very simple to learn and requiring minimal prior knowledge of computer science. Learning Python is definitely the best course of action, depending on your future projects and goals.
But here are a few Cons on R:
- R has a very limited capacity for scaling. If you need to construct something large, you have to worry about name collisions constantly. This issue is not present in Python for two reasons. First, it informs its programmers about the need for clean code. Second, since classes and exceptions are not simply strings that are appended to dictionaries in Python.
- Both from the client side and from the CRAN side, R package management can be difficult. The CRAN approach is completely flawed since it assumes that all packages will either work together or be retired, which means that a package that is there now might not be present tomorrow. Their submission policy is incredibly absurd, involving days-long debates over the placement of commas in the description. Pypi lacks these types, hence the proper application of compatibility metadata is left to maintain a consistent environment.
- R has many angles of problems. There are three conflicting object-oriented systems in it. S3 is unreliable in dispatches. S4 is difficult to maintain, and uses the @ sign instead of the $ sign to access data. R6’s flaw is that it frequently returns NULL when method names are typed incorrectly, making issues difficult to track down. It is quite challenging to conduct various refactorings when non-standard evaluation is used, and it is unclear to the caller whether the provided expression will be evaluated or interpreted as is.
- It’s a major concern if your code needs to become commercial at a later time because the entire R environment is GPL. Companies typically avoid using GPL software. While having a GPL interpreter does not prevent you from creating non-GPL code, you are unable to get around it because the entire standard library and a large number of modules are GPL.
- Programming tools for Python are ten times more effective than those for R. In the realm of R, static code analysis, reformatters, linters, and documentation generators are just old and behind.
- R is not particularly expressive. R makes it challenging to be succinct, but not always. When manipulating some fundamental data structures, it is concise, but for anything else, there is so little syntactic ease that it is usually a hassle.
- There is no clear or practical way to contribute, such as using PEP-style enhancement requests, and the R core development process is still very private and on internal SVN.