Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
Chain.jl
A Julia package for piping a value through a series of transformation expressions using a more convenient syntax than Julia's native piping functionality.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
Dash.jl
Dash for Julia - A Julia interface to the Dash ecosystem for creating analytic web applications in Julia. No JavaScript required.
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
You can call Python directly from Julia https://github.com/JuliaPy/PyCall.jl so much of the Python library ecosystem (say, matplotlib) is available to be used in Julia programs.
That helps the adoption story quite a bit. You can do the number-crunching in Julia where performance counts, and then analyse and present the results using Python.
As sibling posts have pointed out, you can in fact do all of those things:
1. You can write a getproperty method for a tuple. It is considered to be type piracy and thus runs the risk of colliding with someone else's definition, but the language absolutely lets you do it.
2. You can broadcast over the fields of a NamedTuple by defining appropriate methods. Again, it's type piracy, so take that into consideration but the language lets you do this easily.
3. The https://github.com/JuliaArrays/PaddedViews.jl package implements exactly what you're saying Julia won't let you do.
If anything, Julia errs on the side of allowing you to do too many things! There are very few things the language says really won't let you do.
Julia has some packages to address this now.
https://github.com/timholy/Revise.jl
I don’t have much insight on the scientific computing landscape in general, but here’s one notable data point: I worked on the CMS experiment of LHC (Large Hadron Collider) for a while, which is one of the highest profile experiments in experimental physics. The majority of CMS code is C++, which you can check for yourself at https://github.com/cms-sw/cmssw (yes, much/most? of the code is open source). What I worked on specifically was prototyped in Python, then ported to C++ and plugged into the massive data processing pipeline where performance is critical due to the sheer amount of data. So I probably wouldn’t put C++ in parentheses.
Not sure about your exact use case and this is not part of Julia which I have ever used myself but the answer might be here:
https://github.com/JuliaLang/PackageCompiler.jl
There is a presentation from a recent JuliaCon by Kristoffer Carlson on the topic too, I believe.
https://m.youtube.com/watch?v=d7avhSuK2NA
I also like pipe syntax and I've found there is nice support for it in Julia. There are some nice packages to improve it over base [1].
Have you checked queryverse [2]?
[1] https://github.com/jkrumbiegel/Chain.jl
Julia has plenty of plotting solutions that are better for stats than matplotlib:
https://github.com/JuliaPlots/AlgebraOfGraphics.jl
https://github.com/JuliaPlots/StatsPlots.jl
https://github.com/queryverse/VegaLite.jl
https://github.com/GenieFramework/Genie.jl
So can Julia:
https://github.com/plotly/Dash.jl
> For a new R user it seems so much simpler:
> 1. run "library(dplyr)" 2. Google "how to XYZ in dplyr" 3. ??? 4. Profit
I beg to differ here. There’s much to be said for using data.table and base R instead of the tidyverse.
This article is worth a read in my view: https://github.com/matloff/TidyverseSkeptic
Well you could look at the source for org-mode, which does what Jupyter does but in Emacs, and using plain-text files.
https://github.com/bzg/org-mode
If NLP primitives are all that's keeping you from testing the waters, have a look at https://github.com/chengchingwen/Transformers.jl.
I worked with R and Python during the last 3 years but learning and dabbling with Julia since 0.6. Since the availability of [PyCall.jl] and [RCall.jl], the transition to Julia can already be easier for Python/R users.
I agree that most of the time data wrangling is super confortable in R due to the syntax flexibility exploited by the big packages (tidyverse/data.table/etc). At the same time, Julia and R share a bigger heritage from Lisp influence that with Python, because R is also a Lisp-ish language (see [Advanced R, Metaprogramming]). My main grip from the R ecosystem is not that most of the perfomance sensitive packages are written in C/C++/Fortran but are written so deeply interconnect with the R environment that porting them to Julia that provide also an easy and good interface to C/C++/Fortran (and more see [Julia Interop] repo) seems impossible for some of them.
I also think that Julia reach to broader scientific programming public than R, where it overlaps with Python sometimes but provides the Matlab/Octave public with an better alternative. I don't expected to see all the habits from those communities merge into Julia ecosystem. On the other side, I think that Julia bigger reach will avoid to fall into the "base" vs "tidyverse" vs "something else in-between" that R is now.
[PyCall.jl]: https://github.com/JuliaPy/PyCall.jl
[RCall.jl]: https://github.com/JuliaInterop/RCall.jl
[Julia Interop]: https://github.com/JuliaInterop
[Advanced R, Metaprogramming] by Hadley Wickham: https://adv-r.hadley.nz/metaprogramming.html