Is it going to be more difficult for Julia to become a tool for the data analyst? R and Python together in RStudio …
1 Like
Julia just needs to keep at it. Nothing stopping rstudio from supporting Julia in the future.
For me, there is little incentive to move my workload to Julia atm because some R functions are faster and Python has a huge library of tools aimed at deployment and implementation.
I think Julia’s time will come. Ironically, Julia’s speed isn’t shining through for data manipulation because data.table is just so fast.
8 Likes
@xiaodai
“Julia just needs to keep at it. Nothing stopping rstudio from supporting Julia in the future.”
I see. At the moment it seems difficult to convince data analysts of Julia. You’ve already given reasons. Now R 4.0 is just around the corner and that won’t make it any easier for Julia. And then concepts are “knocked over” (I think of Flux and DataFrame), which also challenges the patience of the willing data analysis. But I believe in Julia and think that the “system” Julia & Packages will behave more harmoniously in the near future. Don’t hope that this will be altruistic…! 
1 Like
I see it kinda differently. I think R Studio could support Julia - but, I don’t see a huge benefit in interop between R and python in the first place? Similarly I don’t see a benefit between Julia interop with python or R really. Projects based on interop make my palms sweaty. Prototypes - fine. Don’t misread that, I’m not saying this shouldn’t be an effort, it’s important or project saving for some people to have good interrop.
But I see PyCall statements as laziness. Don’t get me wrong, it’s nice for some people to maybe have scikit learn in their back pocket at the cost of performance and potential instability. But… It took me like a week of afternoons to write the methods from scikit learn or specialized R packages that I like to use in Julia from scratch. In any other language it would have taken at least double and been far less performant. The framework I wrote for handling modelling and analysis overtime has become something I prefer (opinion), and is way less bloated and more intuitive.
Yea maybe datatable is fast, but with adequate structuring of data, Julia’s ETL can be extremely fast as well. Where it lacks has been negligeble in my use cases. For other people - that may not be true.
I’m not saying Julia is perfect for data analysis/science. It’s not. But, if someone knows what they are doing, and wants to make a tool quickly that isn’t easily approached by off the shelf cookie cutter function calls - julia is the absolute best way to do that right now. You’re right though, watching all of Flux break after an update,or all of my historic code become completely unusable after minor version changes because I had to hack around things, is not a good experience. That being said, it’s also not a version 1 release, so it is fair, although frustrating.
Right now I’m paying the price with my own package for using other peoples packages. Twice now I’ve had irreperable errors occur from other peoples packages breaking mine. All to support one function. A good part of me just wants to remove that function. I can’t imagine how hard it is for people who are maintaining packages with many immature dependencies. People got mad when I told them I preferred not to leverage other peoples code unless I absolutely had too - all I can say is I’m glad right now I made the decision I did because I don’t have time to support other peoples immediate changes…
I could make some pretty obvious suggestions for things Julia is missing or could improve to become a staple language in these fields. But, I’d risk sounding like a dictator, and don’t have the time to build them so it’d be pretty silly to do so. Really what we need is more time, and to encourage package maintainers to reach a point where their syntax is solid, only the backend changes, and to document their code. I couldn’t tell you how many packages have 0 documentation, yet are widely used and have CI/CD build errors. It’s not inviting to someone new to the scene.
8 Likes
If people want to use {R, Python, Julia, C++, FORTRAN}, great.
6 Likes
R and Python together have a very large “market share” when it comes to data analysis. And with regard to the above mentioned article/link I wonder if the “market share” is not even bigger. Nothing more. And when I read this…
But… It took me like a week of afternoons to write the methods from scikit learn or specialized R packages that I like to use in Julia from scratch.
… I’m really impressed. Not everybody can do that. And from my own experience I know how difficult it is to build working and stable packages. And I also have no real idea about the developer years that went into R and Python packages.
That being said, it’s also not a version 1 release, so it is fair, although frustrating.
And my personal opinion is that I would never provide a package that is not sufficiently stable. I think that’s fair, because I spare the nerves of the users and their time.
2 Likes
@Gunter_Faes we share the same perspective on what should be a public package it looks like :). I lock down essentials first, and only shift things that don’t matter to the user around.
1 Like
What is so special about R 4.0? Just curious
1 Like
This is the announcement with some preview of the 4.0 changes.
With such a version leap, it can be assumed that a lot will be tidied up and optimised under the bonnet. R 4.0 is announced for spring 2020 and I am very excited!
2 Likes
Yes it sounds like they are finally addressing language issues. Something python often neglects. Definitely worth keeping an eye on - but knowing what I’ve experienced using R, it needs a lot more work.
2 Likes
I recently set up Julia and R on VS Code. It works really smoothly and it’s painless to go back and forth. You lose the workspace but I just type something on the terminal if I need to check something and the plots go in a separate window (which I prefer).
I haven’t tried something similar on Atom but I don’t think this is necessarily something to worry too much about for the Julia community. With a little bit of work and trial and error, one can set up Julia + another datascience oriented language like R, Python in an editor of one’s choice.
4 Likes
Yea I use python and Julia in atom pretty regularly. R in Atom is a bit painful from what I remember… I think the main point here is, for people who are locked into the R paradigm this could be a gateway drug to python for them. While, Julia will be left out.
That being said… I don’t see the real benefit here for a diehard R user. Opening 2 windows for a lay person cludging things together isn’t a big deal.
2 Likes
Yeah, I agree with your point of view. I did briefly use Julia on VS Code and R on RStudio before just doing everything in one thing. It wasn’t ideal but I didn’t lose my mind either 
The way I see it though is that R and python compete on similar things while Julia is positioned, in my opinion, for things that might be too slow to do in R/python. A common thing I hear often is “I do my heavy programming in Julia/C/Fortran and do data-analysis in R/Python”. In my field heavy programming often means MLE/optimization and data-analysis usually means running loads of descriptive linear regressions.
So I’m not sure if this recent development of RStudio is a significant disadvantage for newbies looking to experiment with Julia, but I agree with your sentiment that this could potentially serve as a gateway drug to python leaving Julia out.
2 Likes
One thing I realise is that Julia is also great for general purpose programming. Once TTFP is less painful then it will just take time for Julia to pick up more general libraries.
4 Likes
It honestly wouldn’t take that much effort on their part to start supporting Julia in RStudio. I looked into it a while ago and the underlying text editor they use is all based on Cloud9’s Ace which if you try out there online editor here: Ace Mode Creator, you can see it already has some support for Julia syntax highlighting. I’ve commented on an issue on the RStudio github page but haven’t seen any response.
3 Likes
As already mentioned, R and Python are currently the preferred tools for data analysis. However, one must not forget that “RStudio” pursues economic interests. Understand me correctly, I have nothing against economic interests, but for me, this is the main drive to integrate R and Python into RStudio.
If something good for the community comes out of it, that’s fine by me. If Julia was already so popular, we would be talking about an R & Julia integration today.
Gunter… You are aware that Julia interops with R (https://github.com/JuliaInterop/RCall.jl) and that Julia can be called from R as well (CRAN - Package JuliaCall) right? And that going the opposite way, IE: including R into an editor that also works with Julia is easy.
RStudio sells all these little things that kind of compete with Julia Computing. That could be part of why they aren’t considering it, or they just don’t estimate it as profitable yet. But yes R studio definitely realized it was losing business by excluding python.
3 Likes
I should also say that the official stance from the stakeholders in R has never been “Use R or nothing” - which is wise. Largely because anything done in Python could be done in R, and versa vice. Really the differences between the two are pretty superficial, thats why I find the feud between them over social media hilarious. They both just wrap C/C++ and are entirely driven by the community made ecosystem. They both do OOP in their own way, with speckles of FP in the mix for convenience(almost entirely in the same places). R just focused on numerical computing a bit more to be more like Matlab really.
The big mistake in my eyes isn’t “R vs Python” it’s “Why aren’t we all using Julia yet?”. If both parties combined their ecosystem cleanly into Julia it would be a done deal. Julia learned from the mistakes of both of these languages and corrected them from day 1.
6 Likes
I have read that announcement and the detailed NEWS file linked from there, and I am still not sure why R 4.0 is considered such a big leap. Sure, there are some neat minor changes there, but nothing fundamentally changes about R.
4 Likes