7 ms·

Julia and JuliaHub: Advancing Innovation and Growth

141 points by xgdgsc 2y ago

deleted 2y ago
[deleted]
pjmlp 2y ago
I love to see Julia growth, if nothing else by being another Dylan like take on Lisp ideas, with a JIT compiler in the box, and the community keeping the effort to overcome tooling issues despite critics.
- tajd 2y ago
  Yeah it's interesting to see how it's getting on! I wrote my PhD simulation code in it from the ground up as it had nice fundamental abstractions for parallizable code. Of course now it's just Python and Scala/Java but Julia was great for my purpose.
jakobnissen 2y ago
It would be much more useful to see metrics that aren't cumulative if we're interested in growth. Cumulative measurements, by definition, will never decrease, even if Julia were to fall in popularity.
- tpoacher 2y ago
  indeed; something like an h5-index would be interesting to see.
NeutralForest 2y ago
I like the language but I can't help but feel it missed the train and that the ergonomics improvements it offers are too small to switch over from Python.
- pjmlp 2y ago
  Depends on which train Julia folks want to board into.
  - NeutralForest 2y ago
    It felt to me like they wanted to be the language for ML/DL, which they haven't achieved. They clearly have been working more towards scientific stuff + ML, all the differential equations and math packages are a testament to that (as well as the pharma stuff with Puma). I'm not aware of what the vision is currently tbh
    - affinepplan 2y ago
      I think one really good use case is complex simulations.
      - deleted 2y ago
        [deleted]
    - mbauman 2y ago
      The key for me — as someone who has been around for a long time and is at JuliaHub — is that Julia excels most at problems that don't already have an efficient library implementation. If your work is well-served by existing libraries, great! There's no need to compete against something that's already working well. But that's frequently not the case for modeling, simulation, differential equations, and SciML.
      - catgary 2y ago
        The ODEs stuff in Julia is nice, but I think diffusers/JAX is a reasonable backbone to copy over whatever you need from there. I do think Julia is doing will in stats and has gotten some mindshare from R in that regard. But I think a reasonably compentent Python/JAX programmer can roll out whatever they need relatively easily (especially if you want to use the GPU). I do miss Tullio, though.
joshlk 2y ago
According to Stackoverflow trends, Julia’s popularity is decreasing and very small https://trends.stackoverflow.co/?tags=julia https://trends.stackoverflow.co/?tags=julia
- mjgant 2y ago
  Or thats the LLM/ChatGPT effect. Can see similar downtrends with other languages
- NeutralForest 2y ago
  Even languages like Python and Javascript who are huge show a decline after 2022 which suggests ChatGPT is probably responsible. It would be better to have some other measure imo.
  - joshlk 2y ago
    It measures the proportion of questions for that language out of all languages. So, if there is a general decline in Stackoverflow questions, it’s already accounted for in the metric
    - NeutralForest 2y ago
      There are too many confounding factors still.
    - deleted 2y ago
      [deleted]
- amval 2y ago
  That's mostly because Julia questions get answered on its Discourse or Slack. The sharp decline is due to an automatic cross-post bot that stopped working. No one bothered fixing it, in great part due to Discourse being the main place of discussion, as far as I know.
- eigenspace 2y ago
  Julia users don't go to Stack Overflow because we have better options.
jarbus 2y ago
I've used, and am still using, Julia for my PhD research. It's perfect for parallel/distributed computing, and the neural network primitives are more than enough for my purposes. Anything I write in pure julia runs really, really fast, and has great profiling tools to improve performance further. Julia also integrates with python, with stuff like PythonCall.jl. I've gotten everything to work so far, but it hasn't been smooth. The python code is always the major bottleneck though, so I try to avoid it. Overall, julia is a significantly better language in every single aspect except for ecosystem and the occassional environment issue, which you'll get with conda often anyways. It's really a shame that practically nobody actually cares about it compared to python. It supports multi-dimensional arrays as a first-class citizen, which means that each package doesn't have it's own array like torch, numpy, etc, and you don't have to constantly convert between the types.
- frakt0x90 2y ago
  I agree on all points. I have used Python for 15 years, Julia for 3 and reach for Julia most of the time for personal projects. I was really stoked when at work the only FOSS solver for our problem was in Julia so we wrote the rest in it for easy integration. The only thing I dread is having to look for a new package since the ecosystem can be quite fragmented.
- Bostonian 2y ago
  Your last sentence applies equally to Fortran. How would you compare Julia and Fortran?
  - realo 2y ago
    Julia uses LLVM for its jit architecture, if I recall correctly. That makes it a good candidate for running well on ARM platforms (think embedded data processing at the edge). Not sure how well fortran does on ARM.
    - pjmlp 2y ago
      Fortran does quite well on almost any major CPU since 1950's, including GPUs. Actually one of the reasons CUDA won the hearts of researchers over OpenCL, is that Khronos never cared for Fortran, and even C++ was late to the party. I attended one Khronos webminar where the panel was puzzled with a question from the audience regarding Fortran support roadmap. NVidia is sponsoring the work on the LLVM Fortran frontend, so same applies. https://flang.llvm.org/docs/ https://flang.llvm.org/docs/
tmvphil 2y ago
As someone working with it day to day, coming from around 18 years of mostly python, I wish I could say my experience has been great. I find myself constantly battling with the JIT and compilation and recompilation and waiting around all the time (sometimes 10 to 15 minutes for some large projects). Widespread macro usage makes stack traces much harder to read. Lack of formal interfaces means a lot of static checking is not practical. Pkg.jl is also not great, version compatibility is kind of tacked on and has odd behavior. Obviously there are real bright spots too, with speed, multiple dispatch, a relatively flourishing ecosystem, but overall I wouldn't pick it up for something new if given the choice. I'd use Jax or C++ extensions for performance and settle on python for high level, despite its obvious warts.
- catgary 2y ago
  Yeah, Jax with Equinox, jaxtyping, and leaning hard on python’s static typing modules + typeguard lets you pretend that you have a nice little language embedded in python. I swore off Julia a few years ago.
- nsajko 2y ago
  > Pkg.jl is also not great, version compatibility is kind of tacked on and has odd behavior. Huh? I think Pkg is very good as far as package managers go, exceptionally so. What specifically is your issue with it?
6gvONxR4sf7o 2y ago
I do scientific computing and a lisp was one of my first languages, so i feel like i ought to be the target audience, but it just never quite catches me. It’s almost statically compilable which has almost gotten me to pick it up a few times, but apparently it still can’t compile a lot of the most important ecosystem packages yet. The metaprogramming has almost gotten me to pick it up a few times, but apparently there aren’t mature static anti-footgun tools, even to the degree of mypy’s pseudo-static analysis, so I wouldn’t really want to use those in prod or even complex toy stuff. It’s so damned interesting though. I hope it gets some of this eventually.
kayson 2y ago
I'm curious how people feel about the JIT compilation time vs runtime tradeoff these days. Any good recent benchmarks?
- affinepplan 2y ago
  Chapel folk did a really nice benchmark last year including Julia, where it landed pretty much right on the Pareto frontier of code size vs performance I know that's not exactly answering your question, but you might be interested https://chapel-lang.org/ChapelCon/2024/chamberlain-clbg.pdf https://chapel-lang.org/ChapelCon/2024/chamberlain-clbg.pdf
  - bradcray 2y ago
    The ~10-minute video for this talk is here, if anyone's interested in the narrative behind the slides: https://www.youtube.com/watch?v=U8KM8wv32js https://www.youtube.com/watch?v=U8KM8wv32js
  - adgjlsfhk1 2y ago
    Also if you exclude Julia's compile time (which may or may not be reasonable depending on what you're trying to measure), Julia would gain a lot in speed since almost all of these benchmarks are in the 0.5s to 10s range.
toolslive 2y ago
We do statistical modeling in Python in our company. When a statistician asked for R, I said "no, but you can have Julia". He's quite happy with it, and we're planning to move some stuff over.
cbruns 2y ago
I am a MATLAB and Python user who has flirted with julia as a replacement. I don't love the business model of JuliaHub, which feels very similar to Mathworks in that all the cool toolboxes are gated behind a 'contact sales' or high priced license. The free 20 hours of cloud usage is a non-starter. Also it seems that by default, all JuliaHub usage is default cloud-based? on-prem and airgapped (something I need) is implied to be $$$. Open sourcing and maintaining some components of things like JuliaSim or JuliaSim Control might expand adoption of Julia for people like me. I will never be able to convince my company to pay for JuliaHub if their pricing is similar to Mathworks.
- adgjlsfhk1 2y ago
  I don't think this is really a good comparison. Matlab is a $150 for a personal license for the language itself ($1000/year for commercial), and if you want any packages, all the packages are extra on top of that. Julia is fully open source, and has a strong open source package ecosystem (I think we're up to 10k packages by now). Juliahub provides some enterprise systems like JuliaSim, but the language itself is totally free.
Kalanos 2y ago
With some serious repositioning, I think there is still an opportunity for Julia to displace Python tools like polars/pandas/numpy, airflow, and pytorch -- with a unified ecosystem that makes it easy to transition to GPU and lead a differentiable programming revolution. They have the brain power to do it. The future of Python's main open source data science ecosystem, numfocus, does not seem bright. Despite performance improvements, Python will always be a glue language. Python succeeds because the language and its tools are *EASY TO USE*. It has nothing to do with computer science sophistication or academic prowess - it humbly gets the job done and responds to feedback. In comparison to mojo/max/modular, the julia community doesn't seem to be concerned with capturing share from python or picking off its use cases. That's the real problem. There is room for more than one winner here. However, have the people that wanted to give julia a shot already done so? I hope not because there is so much richness to their community under the hood.
- catgary 2y ago
  Julia has really lost the differentiable programming mindshare to JAX. I’ve spent weeks or months getting tricky gradients to work in Julia, only to have everything “just work” in JAX. The quality of the autograd is night and day, and goes down to the basic design decisions of the respective “languages” (in the sense that JAX jit compiles a subset of Python) and their intermediate representations. Fundamentally, when you keep a tight, purely functional core representation of your language (e.g. jaxpr’s) and decompose your autograd into two steps (forward mode and a compiler-level transpose operation) you get a system that is substantially easier to guarantee correct gradients, is much more composable, and even makes it easier to define custom gradients. Unfortunately, Julia didn’t actually have any proper PLT or compilers people involved in the outset. This is the original sin I see as someone with an interest in autograd. I’m sure someone more focused on type theory has a more cogent criticism of their design decisions in that domain and would identify a different “original sin”. In the end, I think they’ve made a nice MatLab alternative but there’s a hard upper bound on what they can reach.
  - affinepplan 2y ago
    > Julia didn’t actually have any proper PLT or compilers people involved in the outset. while I don't disagree that currently JAX outshines Julia's autodiff options in many ways, I think comments like this are 1. false 2. rude and 3. unnecessary to make your point
culebron21 2y ago
My experience with Julia was good, and the language is convenient, however two major factors made me not use it after test projects: 1. Very scarce packages ecosystem. Like there's dataframes.jl file with poor mans implementation of Pandas. 2. Recompiling everything every time. It meant that a Julia program in some script would take ~40 seconds compiling with dataframes & some other important packages. I think if a language is to replace Python in science, it would need to either be very fast (recompilation on every run breaks this, and running Julia in a notebook/shell is interesting, but outside of pure scientific code, it should be easier to re-run it), or it should offer ergonomics. Pandas has very rough corners, especially when you need grouping with nontrivial operations, or grouped window functions. Joins aren't easy either. Any system that makes this more ergonomic, could bite a bit off Python. But I don't see such.
- xgdgsc 2y ago
  Using https://julialang.github.io/PrecompileTools.jl/stable/ https://julialang.github.io/PrecompileTools.jl/stable/ to avoid recompiling everytime is pretty convenient now. And there will be https://jbytecode.github.io/juliac/ https://jbytecode.github.io/juliac/ to build small binaries. I had some good experiences with https://github.com/sl-solution/InMemoryDatasets.jl https://github.com/sl-solution/InMemoryDatasets.jl and DuckDB.jl when DF.jl wasn' t performing well.
- nsajko 2y ago
  > Recompiling everything every time. > recompilation on every run breaks this Your comment is exceedingly misleading. Whether and when Julia code gets compiled is up to the user.
- dizk12 2y ago
  I think the Tidier.jl has made data in julia quite nice. TidierData leverages Dataframes.jl on the backend but with tidyverse syntax, and TidierDB.jl recreates python's ibis and Rs dbplyr. TidierDB (DuckDB is the main backend, but supports 11 other DB backends) also enables grouped window functions quite smoothly as well as joins and non equijoins. https://github.com/TidierOrg/TidierDB.jl https://github.com/TidierOrg/TidierDB.jl https://github.com/TidierOrg/TidierData.jl https://github.com/TidierOrg/TidierData.jl of note i am biased as a tidier contributor and author of tidierdb.jl but hopefully you might be willing to give it a try.
ofrzeta 2y ago
Somehow Julia is lacking the "killer app" like Ruby has with Rails.

141 points by xgdgsc 2y ago

deleted 2y ago

[deleted]

I love to see Julia growth, if nothing else by being another Dylan like take on Lisp ideas, with a JIT compiler in the box, and the community keeping the effort to overcome tooling issues despite critics.

tajd 2y ago
Yeah it's interesting to see how it's getting on! I wrote my PhD simulation code in it from the ground up as it had nice fundamental abstractions for parallizable code. Of course now it's just Python and Scala/Java but Julia was great for my purpose.

jakobnissen 2y ago

It would be much more useful to see metrics that aren't cumulative if we're interested in growth. Cumulative measurements, by definition, will never decrease, even if Julia were to fall in popularity.

tpoacher 2y ago
indeed; something like an h5-index would be interesting to see.

NeutralForest 2y ago

I like the language but I can't help but feel it missed the train and that the ergonomics improvements it offers are too small to switch over from Python.

pjmlp 2y ago
Depends on which train Julia folks want to board into.
- NeutralForest 2y ago
  It felt to me like they wanted to be the language for ML/DL, which they haven't achieved. They clearly have been working more towards scientific stuff + ML, all the differential equations and math packages are a testament to that (as well as the pharma stuff with Puma). I'm not aware of what the vision is currently tbh
  - affinepplan 2y ago
    I think one really good use case is complex simulations.
    - deleted 2y ago
      [deleted]
  - mbauman 2y ago
    The key for me — as someone who has been around for a long time and is at JuliaHub — is that Julia excels most at problems that don't already have an efficient library implementation. If your work is well-served by existing libraries, great! There's no need to compete against something that's already working well. But that's frequently not the case for modeling, simulation, differential equations, and SciML.
    - catgary 2y ago
      The ODEs stuff in Julia is nice, but I think diffusers/JAX is a reasonable backbone to copy over whatever you need from there. I do think Julia is doing will in stats and has gotten some mindshare from R in that regard. But I think a reasonably compentent Python/JAX programmer can roll out whatever they need relatively easily (especially if you want to use the GPU). I do miss Tullio, though.

joshlk 2y ago

According to Stackoverflow trends, Julia’s popularity is decreasing and very small https://trends.stackoverflow.co/?tags=julia https://trends.stackoverflow.co/?tags=julia

mjgant 2y ago
Or thats the LLM/ChatGPT effect. Can see similar downtrends with other languages
NeutralForest 2y ago
Even languages like Python and Javascript who are huge show a decline after 2022 which suggests ChatGPT is probably responsible. It would be better to have some other measure imo.
- joshlk 2y ago
  It measures the proportion of questions for that language out of all languages. So, if there is a general decline in Stackoverflow questions, it’s already accounted for in the metric
  - NeutralForest 2y ago
    There are too many confounding factors still.
  - deleted 2y ago
    [deleted]
amval 2y ago
That's mostly because Julia questions get answered on its Discourse or Slack. The sharp decline is due to an automatic cross-post bot that stopped working. No one bothered fixing it, in great part due to Discourse being the main place of discussion, as far as I know.
eigenspace 2y ago
Julia users don't go to Stack Overflow because we have better options.

jarbus 2y ago

I've used, and am still using, Julia for my PhD research. It's perfect for parallel/distributed computing, and the neural network primitives are more than enough for my purposes. Anything I write in pure julia runs really, really fast, and has great profiling tools to improve performance further. Julia also integrates with python, with stuff like PythonCall.jl. I've gotten everything to work so far, but it hasn't been smooth. The python code is always the major bottleneck though, so I try to avoid it. Overall, julia is a significantly better language in every single aspect except for ecosystem and the occassional environment issue, which you'll get with conda often anyways. It's really a shame that practically nobody actually cares about it compared to python. It supports multi-dimensional arrays as a first-class citizen, which means that each package doesn't have it's own array like torch, numpy, etc, and you don't have to constantly convert between the types.

frakt0x90 2y ago
I agree on all points. I have used Python for 15 years, Julia for 3 and reach for Julia most of the time for personal projects. I was really stoked when at work the only FOSS solver for our problem was in Julia so we wrote the rest in it for easy integration. The only thing I dread is having to look for a new package since the ecosystem can be quite fragmented.
Bostonian 2y ago
Your last sentence applies equally to Fortran. How would you compare Julia and Fortran?
- realo 2y ago
  Julia uses LLVM for its jit architecture, if I recall correctly. That makes it a good candidate for running well on ARM platforms (think embedded data processing at the edge). Not sure how well fortran does on ARM.
  - pjmlp 2y ago
    Fortran does quite well on almost any major CPU since 1950's, including GPUs. Actually one of the reasons CUDA won the hearts of researchers over OpenCL, is that Khronos never cared for Fortran, and even C++ was late to the party. I attended one Khronos webminar where the panel was puzzled with a question from the audience regarding Fortran support roadmap. NVidia is sponsoring the work on the LLVM Fortran frontend, so same applies. https://flang.llvm.org/docs/ https://flang.llvm.org/docs/

tmvphil 2y ago

As someone working with it day to day, coming from around 18 years of mostly python, I wish I could say my experience has been great. I find myself constantly battling with the JIT and compilation and recompilation and waiting around all the time (sometimes 10 to 15 minutes for some large projects). Widespread macro usage makes stack traces much harder to read. Lack of formal interfaces means a lot of static checking is not practical. Pkg.jl is also not great, version compatibility is kind of tacked on and has odd behavior. Obviously there are real bright spots too, with speed, multiple dispatch, a relatively flourishing ecosystem, but overall I wouldn't pick it up for something new if given the choice. I'd use Jax or C++ extensions for performance and settle on python for high level, despite its obvious warts.

catgary 2y ago
Yeah, Jax with Equinox, jaxtyping, and leaning hard on python’s static typing modules + typeguard lets you pretend that you have a nice little language embedded in python. I swore off Julia a few years ago.
nsajko 2y ago
> Pkg.jl is also not great, version compatibility is kind of tacked on and has odd behavior. Huh? I think Pkg is very good as far as package managers go, exceptionally so. What specifically is your issue with it?

6gvONxR4sf7o 2y ago

I do scientific computing and a lisp was one of my first languages, so i feel like i ought to be the target audience, but it just never quite catches me. It’s almost statically compilable which has almost gotten me to pick it up a few times, but apparently it still can’t compile a lot of the most important ecosystem packages yet. The metaprogramming has almost gotten me to pick it up a few times, but apparently there aren’t mature static anti-footgun tools, even to the degree of mypy’s pseudo-static analysis, so I wouldn’t really want to use those in prod or even complex toy stuff. It’s so damned interesting though. I hope it gets some of this eventually.

kayson 2y ago

I'm curious how people feel about the JIT compilation time vs runtime tradeoff these days. Any good recent benchmarks?

affinepplan 2y ago
Chapel folk did a really nice benchmark last year including Julia, where it landed pretty much right on the Pareto frontier of code size vs performance I know that's not exactly answering your question, but you might be interested https://chapel-lang.org/ChapelCon/2024/chamberlain-clbg.pdf https://chapel-lang.org/ChapelCon/2024/chamberlain-clbg.pdf
- bradcray 2y ago
  The ~10-minute video for this talk is here, if anyone's interested in the narrative behind the slides: https://www.youtube.com/watch?v=U8KM8wv32js https://www.youtube.com/watch?v=U8KM8wv32js
- adgjlsfhk1 2y ago
  Also if you exclude Julia's compile time (which may or may not be reasonable depending on what you're trying to measure), Julia would gain a lot in speed since almost all of these benchmarks are in the 0.5s to 10s range.

toolslive 2y ago

We do statistical modeling in Python in our company. When a statistician asked for R, I said "no, but you can have Julia". He's quite happy with it, and we're planning to move some stuff over.

cbruns 2y ago

I am a MATLAB and Python user who has flirted with julia as a replacement. I don't love the business model of JuliaHub, which feels very similar to Mathworks in that all the cool toolboxes are gated behind a 'contact sales' or high priced license. The free 20 hours of cloud usage is a non-starter. Also it seems that by default, all JuliaHub usage is default cloud-based? on-prem and airgapped (something I need) is implied to be $$$. Open sourcing and maintaining some components of things like JuliaSim or JuliaSim Control might expand adoption of Julia for people like me. I will never be able to convince my company to pay for JuliaHub if their pricing is similar to Mathworks.

adgjlsfhk1 2y ago
I don't think this is really a good comparison. Matlab is a $150 for a personal license for the language itself ($1000/year for commercial), and if you want any packages, all the packages are extra on top of that. Julia is fully open source, and has a strong open source package ecosystem (I think we're up to 10k packages by now). Juliahub provides some enterprise systems like JuliaSim, but the language itself is totally free.

Kalanos 2y ago

With some serious repositioning, I think there is still an opportunity for Julia to displace Python tools like polars/pandas/numpy, airflow, and pytorch -- with a unified ecosystem that makes it easy to transition to GPU and lead a differentiable programming revolution. They have the brain power to do it. The future of Python's main open source data science ecosystem, numfocus, does not seem bright. Despite performance improvements, Python will always be a glue language. Python succeeds because the language and its tools are *EASY TO USE*. It has nothing to do with computer science sophistication or academic prowess - it humbly gets the job done and responds to feedback. In comparison to mojo/max/modular, the julia community doesn't seem to be concerned with capturing share from python or picking off its use cases. That's the real problem. There is room for more than one winner here. However, have the people that wanted to give julia a shot already done so? I hope not because there is so much richness to their community under the hood.

catgary 2y ago
Julia has really lost the differentiable programming mindshare to JAX. I’ve spent weeks or months getting tricky gradients to work in Julia, only to have everything “just work” in JAX. The quality of the autograd is night and day, and goes down to the basic design decisions of the respective “languages” (in the sense that JAX jit compiles a subset of Python) and their intermediate representations. Fundamentally, when you keep a tight, purely functional core representation of your language (e.g. jaxpr’s) and decompose your autograd into two steps (forward mode and a compiler-level transpose operation) you get a system that is substantially easier to guarantee correct gradients, is much more composable, and even makes it easier to define custom gradients. Unfortunately, Julia didn’t actually have any proper PLT or compilers people involved in the outset. This is the original sin I see as someone with an interest in autograd. I’m sure someone more focused on type theory has a more cogent criticism of their design decisions in that domain and would identify a different “original sin”. In the end, I think they’ve made a nice MatLab alternative but there’s a hard upper bound on what they can reach.
- affinepplan 2y ago
  > Julia didn’t actually have any proper PLT or compilers people involved in the outset. while I don't disagree that currently JAX outshines Julia's autodiff options in many ways, I think comments like this are 1. false 2. rude and 3. unnecessary to make your point

culebron21 2y ago

My experience with Julia was good, and the language is convenient, however two major factors made me not use it after test projects: 1. Very scarce packages ecosystem. Like there's dataframes.jl file with poor mans implementation of Pandas. 2. Recompiling everything every time. It meant that a Julia program in some script would take ~40 seconds compiling with dataframes & some other important packages. I think if a language is to replace Python in science, it would need to either be very fast (recompilation on every run breaks this, and running Julia in a notebook/shell is interesting, but outside of pure scientific code, it should be easier to re-run it), or it should offer ergonomics. Pandas has very rough corners, especially when you need grouping with nontrivial operations, or grouped window functions. Joins aren't easy either. Any system that makes this more ergonomic, could bite a bit off Python. But I don't see such.

xgdgsc 2y ago
Using https://julialang.github.io/PrecompileTools.jl/stable/ https://julialang.github.io/PrecompileTools.jl/stable/ to avoid recompiling everytime is pretty convenient now. And there will be https://jbytecode.github.io/juliac/ https://jbytecode.github.io/juliac/ to build small binaries. I had some good experiences with https://github.com/sl-solution/InMemoryDatasets.jl https://github.com/sl-solution/InMemoryDatasets.jl and DuckDB.jl when DF.jl wasn' t performing well.
nsajko 2y ago
> Recompiling everything every time. > recompilation on every run breaks this Your comment is exceedingly misleading. Whether and when Julia code gets compiled is up to the user.
dizk12 2y ago
I think the Tidier.jl has made data in julia quite nice. TidierData leverages Dataframes.jl on the backend but with tidyverse syntax, and TidierDB.jl recreates python's ibis and Rs dbplyr. TidierDB (DuckDB is the main backend, but supports 11 other DB backends) also enables grouped window functions quite smoothly as well as joins and non equijoins. https://github.com/TidierOrg/TidierDB.jl https://github.com/TidierOrg/TidierDB.jl https://github.com/TidierOrg/TidierData.jl https://github.com/TidierOrg/TidierData.jl of note i am biased as a tidier contributor and author of tidierdb.jl but hopefully you might be willing to give it a try.

ofrzeta 2y ago

Somehow Julia is lacking the "killer app" like Ruby has with Rails.