At present, in what aspects is Julia still relatively weak compared to other mainstream programming languages?

[WuSiren]

At present, in what aspects is Julia still relatively weak compared to other mainstream programming languages? Or to put it another way, what aspects should Julia strengthen in the future? --A Julian with a surge of love for Julia suddenly wants to perceive its strength in all aspects at the macro level.

[johnh]

i will give my opinion here. I do not have an answer. To have a long life a language needs a ‘killer app’. I believe for Python that was interfacing to AI models. Julia is finding its killer app or apps now with scientific machine learning.

Now why are companies not rushing to code everything in Julia? I believe the answer here is ‘good enough for jazz’. If you already ue Python/Matlab yada yada and it is adequate to do your tasks then Julia is not on your radar.
Sorry to say but I have met this in two companies I worked for.

[mbauman]

Everyone will have a different answer — there’s not one definitive answer.

One place to look for a wider view is in the community surveys: https://julialang.org/assets/2023-julia-user-developer-survey.pdf#page=8

(As an aside, we ask that folks talk about the language as an “it” and not as a “her”).

[goerz]

I find the single aspect where Julia still lacks behind other languages is in dev-tools, especially linters.

I’d desperately want to see a fast, standalone, and reliable command-line linter. Something that integrates well into vim via ALE. Basically, the equivalent of flake8/pylint/ruff for Python. LSP sounds like a good idea in principle, but it’s extremely slow and extremely unreliable. I sometimes open up VSCode to go through my code base, and 90% of the warnings are false positives, or otherwise useless. It’s also a complete black box, with no way to understand why it thinks a particular line has a particular problem, or being able to configure which linting rules I might want to ignore.

A better debugger would be nice, too. Infiltrator is great, but it’s not a debugger, and Debugger works fine for stepping into a simple function, but it doesn’t work very well for the real use case of a debugger: Understanding control flow. My number one way to get into an unfamiliar code base is to step through integration tests with a debugger to see which routines actually get called. Try this with something like Documenter, which has a pretty idiosynchratic and complicated control flow, with it’s notion of “processing pipelines”. With Julia’s multiple dispatch, a proper debugger is even more important, as it’s almost impossible to reason about code just by looking at it. You can’t really know what method is going to be called in a particular line. Of course, Julia has excellent print-based debugging, including printing @which for a particular line deep inside some code, but a good debugger would be so much easier. The main problem with the existing debugger is that it’s slow or tends to hang. Or maybe I just haven’t figured out how to switch between compiled mode and interpreted code well enough.

Also, the ability to reason about code is probably the biggest long-term worry I have with a large Julia code base. But that’s really just saying that multiple dispatch is a double-edged sword. On the one hand, it’s amazingly expressive, efficient, and allows different packages to integrate with each other. On the other hand, you basically have no guarantees about any particular variable that might be passed into a function, or about the return value of any function you call in your code. Someone could always come in and define a new, potentially buggy, method. This is basically the whole discussion about traits and formal interfaces. In the meantime, I’ve gone with explicit interface tests in my own code, which are probably a good enough solution. It does require a lot of discipline, though.

[RoyiAvital]

For me:

1. Development Environment
   The Julia Extension in VS Code is still not there compared to the Python integration in VS Code.
   I miss the ability to work in Interactive Window Mode which is the perfect “notebook” as I can do in Python. Working in cells, rendering MarkDown (MathJaX) included) while still having a code only file is done brilliantly in VS Code for Python.
   Also the debugger experience is not as smooth and reliable as in Python in VS Code.
2. Export of Code in a Binary Form
   Julia is relatively new. Hence when one works on established project the best way to use Julia in by integrating Julia “modules” in the code. The most used API for this use case is a dynamic library with C function exported. The main effort to produce production quality libraries like that is StaticCompiler.jl. Yet it is a community driven project which is still not up to production (Though it is close and the effort is amazing, they achieved so much).
3. Plotting Experience
   For me, whenever I use Julia for small analysis the thing I miss the most is MATLAB’s figure() element. I couldn’t replicate something similar in Julia. The closest are PlotlyJS.jl and Bokeh.jl yet they are not battle proven (Many issues, mainly under Windows). Makie is also stepping there. I guess this one might be no more a deficit in the near future.

[Benny]

To comment on that complaint survey’s top entry, there are many situations where you need or want something fleeting or small, not a full runtime that remains active long-term. JIT compilation latency especially hurts here, but it’s oversimplistic to say that’s the same issue, hence separate entries in the survey. This is my understanding of the current options for compiling for the command-line:

• PackageCompiler.jl has been around a while, and one of its features is runtime-bundled executables.
• More recently, a package can independently cache machine code for calls it specifies, especially with the help of PrecompileTools.jl, so you can specify an environment in the julia --project=<path> command in which import X loads a specific cache, similar to Python with venv. Package precompilation is typically used for standard-issue calls though; it’s unusual to duplicate packages just to cache different main functions for command-line workflows when PackageCompiler already serves the purpose with a self-contained solution. Moreover, only package source code is distributed (for now) and precompiled on the destination machine, so only PackageCompiler allows distribution of executables, which requires additional avoidance of destination-specific compilation, e.g. using the artifacts system instead of installing binary dependencies in build.jl.
• With many significant limitations, StaticCompiler.jl compiles a Julia function call signature to a bare-minimum executable, no runtime necesssary and no ties to package environments (though you should otherwise document it somewhere for reproducibility). This is closest in principle to what people are hoping for, but many features can’t be easily replaced when the runtime is omitted, especially since the language wasn’t designed for it.

Aside, this feels like one of those open-ended threads that should have a time limit.

[DoktorMike]

As a Machine learning guy I would say large neural networks are hard to do competitively in Julia compared to Jax or pytorch. These frameworks have a subset of instructions they support and care about which are specifically optimized. As such they are not as general as Julias frameworks, e.g., flux et. al. are. But from a practitioners point of view you just notice the speed drop.

Plenty of skilled and smart people are working on this though. But it probably won’t have as high a priority as scientific ML for example where Julia is in fact in the lead I would say.

[jar1]

• A way to specify and validate the interface of a function in code. Julia only has a little (AbstractArray, etc). Other languages do this with traits, type classes, dynamic contracts, protocols.

• A way to handle expected failures, like an http request failure. Julia throws an exception which breaks normal control flow, which would be fine for an unexpected failure, but network request failures are a normal part of doing business. Other languages return a Result{T,E} = OK{T} | Err{E} that you can handle as a normal value.

• All of “What's bad about Julia?” are still active except for, imho, compile time latency (which has dramatically improved recently) and “You can’t extend existing types with data” (which is actually a good thing).

[adienes]

@jar1

A way to handle expected failures, like an http request failure

is this one really a language limitation? seems like more of an ecosystem / adoption problem for the attempts at this in various packages like Results.jl

[stevengj]

Added a topic timer, since this sort of thread otherwise invariably runs in circles for weeks, often degenerating into an ensemble of unrelated gripes. See also: Time limits for unfocused discourse threads?

[Tetrakai]

I’d say interactively manipulating and exploring a dataset requires far more effort/verbosity than in R. But I am still “new” (only trying it since last November) so could be I am still not used to it.

Please let me know if you disagree.

[mkitti]

There is the whole Tidier.jl ecosystem which I think tries to address the R approach directly.

[ANN] (Belatedly) Announcing Tidier.jl

With the 1-year anniversary of Tidier.jl coming up soon, I wanted to put together an official (if slightly belated) package announcement describing Tidier.jl to invite you to give it a try. Tidier.jl originally began as a package intended for working with DataFrames based on the R dplyr and tidyr packages as part of the R tidyverse ecosystem. That portion of Tidier.jl has since been split off into its own package (TiderData.jl), with Tidier.jl focused much more broadly on implementing the entir…

Also see GitHub - JuliaData/DataFramesMeta.jl: Metaprogramming tools for DataFrames

[jar1]

I don’t think so (I don’t even use the packages that @mkitti linked), with only rare exceptions (rare enough that I can’t think of them right now). If you give some examples we can see.

[Tetrakai]

I’m not really a tidyverse fan. It was too slow (so I needed to rewrite anything to scale even a bit) but moreso was the dependency hell.

When/if I come up across another example I’ll ask about it.

Edit:

To be clear I am referring to the R tidyverse. I haven’t tried the tidier package yet, but so far I am a heavy user of Julia dataframes.

[Dan]

Steve Ballmer: Developers

[kdpsingh]

I’ve been an R user for a decade before switching to Julia. Agree that R as a language and ecosystem has a lot to offer.

The main idea for Tidier.jl is to capture the syntax of tidyverse at the speed of Julia.

The Julia language in my experience is flexible and expressive enough to do just about anything you can do in R. So while I agree that aspects of the Julia ecosystem are less mature, the core language is really fun, and it’s the reason I’ve continued to work on Tidier.jl.

The biggest thing lacking is the Python ML/LLM functionality. I love the direction of PromptingTools.jl and Transformers.jl but am happy to rely on PythonCall when needed. At its worst, Julia is a very fast and expressive glue language.

[juliohm]

I no longer join open ended threads like this, but I will make an exception this time given that people often forget the most crucial aspect:

Julia needs more package maintainers, i.e., people willing to improve packages that they use with their own hands. We will never solve other technical aspects in reasonable time if end-users don’t join ongoing efforts to improve usability and fix small bugs. I must say that our end-user-to-maintainer ratio is terrible.

I suggest that we include a question or two in our next community survey about contributorship:

1. How many issues did you open in your favorite package?
2. How many PRs did you submit to any package this year?
3. How many tutorials you’ve written to help other users?

Add a scale from 0 to 5 (or more), and my guess is that 90% of the people taking the survey will choose 0 or 1 contributions. We are super weak on that regard.

[PetrKryslUCSD]

@juliohm

We are super weak on that regard.

Data?

[juliohm]

@PetrKryslUCSD

Data?

Perform a simple search on JuliaHub or elsewhere, using a tool such as GitHub.jl or similar. Search for unique package authors that are actively maintaining their packages. Compare this number with the Julia user base and you will get a ratio.