Hacker News Reader

Comment by quixoticelixer- | Hacker News Reader

One thing that does annoy me about Julia is how much they focus on performance. I do appreciate the speed but the reason why I use Julia isn't because it's fast, it's because its (in my opinion) a nicer language than R or Python/Numpy and I would like to see more effort go into that.

View on HN

I do agree, but one thing I’ll say is that the performance is important because it means that you essentially need to call C code for performance. Having ll the code in a project and dependencies be in one language has some really nice advantages!

Of course we do call things like C or Python whenever there’s a good implementation of something we want, and because of that we have some excellent FFI capabilities.

But yeah, all that said, I’d use Julia even if it was slow. It’s an amazing, powerful and fun language that has taught me a lot and made me enjoy programming.

My experience has been completely the opposite. Julia has been frustrating to work with. Most of the time I’m just waiting for precompilation of the packages.

It’s unbelievable that the Julia core devs still haven’t addressed it. It is not fun by any means. Not even tolerable.

Try to use the REPL more instead of re-running your program from scratch. I just do `include("blah.jl")` then re-run my testcase.

Ah, the statefulness foot-gun. It'll solve all your problems... if your problem is having feet!

Ok, that's a little mean, there's nothing quite as convenient and simple as a REPL or notebook for ad-hoc caching, but sometimes you need the opposite and the language really needs to support that.

That's my least favorite thing about R - it just looooves to save state unless you configure it otherwise. This is also why I've had trouble adopting Julia in the past - I've adopted the habit of constantly resetting my workspace or working from scripts to avoid exactly this issue, so my habits are somewhat Julia-hostile.

I'm giving it another go though, since it seems like it could be really useful for algorithm-adjacent research.

I often chain unix tools, domain-specific binary executables and python scripts in shell. Julia feels very slow for this type of workflow. A few years ago there were discussions about whether Julia could replace Python. No way just due to Julia's long startup time.

Ditto.

I can't wait for Julia to murder Python but before it can do that it needs to push all delays out of the interactive parts (to include both REPL and cold launch) and into the package management parts, where people will tolerate delays. Anaconda decided to stick a full SAT solver into the package management and it's every bit the shitshow that you'd expect, frequently taking 30 minutes to solve and failing to converge, but people tolerate it because it's in the package management.

I have been using anaconda much less often due to its long resolving time... That said, I fully agree with you that Julia should cache precompiled binaries. Lacking this key functionality is a misstep from the very beginning.

It's a bit annoying but you should only have to precompile once and it doesn't take that long

Then they should have the package manager do it. Or the package maintainer.

The current release candidate for 1.6 does exactly that. In parallel.

Sweet!

That's not true though. It's everytime I want to do anything with Julia, I need to wait upto a minute or two. Gadfly takes ages to pre-compile.

Closed your terminal session? You're outta luck. Wait 2 mins please. Launch a notebook and want to start working on something? Wait 40 seconds. Wanna check something quick in Julia REPL session? Wait 7 seconds. Let me run this Julia script, wait 55 seconds.

I feel like the entire community should stop doing what they're doing and fix this issue. I am afraid, it is difficult to fix otherwise it would have been fixed by now.

This is also roughly my experience (though I haven’t tried 1.6 yet) and it really a shame - I much prefer Julia’s syntax to R’s (my primary language) and would love to switch for statistics work.

The problem is perhaps that I largely do fairly simple statistics and plotting, with scripts that in R usually take seconds rather than minutes to run, and the disadvantages of the requirement to compile the code overcomes the compiled speed advantage.

I have the same use case as you describe and it's not unreasonable to conclude that right now Julia simply does not offer anything that R does not. It seems most Julia users are more in fields like numerical computing or scientific simulations and such, where it does offer clear advantages. But if you just want to run some of the statistical tests you learn in undergrad or want to explore some data R is just a better choice right now.

You can speed this up using a custom system image, but the usability of it kinda sucks.

https://julialang.github.io/PackageCompiler.jl/dev/examples/...

That's what pushed me away in 2015. Someone said it was fixed in... 2018 I think, but I tried and it wasn't. It still isn't? Ouch.

If it comes to pushing binaries into the package manager, that's what it comes to, but waiting for a minute for the graphing library to load just isn't OK in this day and age.

I just tried it, and it took 13 seconds to load and plot some random numbers. It could be better but it’s an acceptable trade off for my usage. Not as good as Python in this regard, but much better than Matlab.

Is 13 seconds a build cache hit or miss?

It’s a precompilation hit, but it requires some compilation every time. Thinking about Julia like you might think about incremental C++ builds isn’t exactly right. A somewhat useful analogy though is that Julia is kind of like C++ template code. This is why it is so flexible, but also why compilation isn’t very cacheable. This is also why it is tricky (but possible) to do ahead of time Julia builds.

It's approximately halved in Julia v1.6 BTW. It's not perfect but continually getting better.

I work with julia every day and really don't spend much time waiting for things like compilation or precompilation.

> It’s unbelievable that the Julia core devs still haven’t addressed it. It is not fun by any means. Not even tolerable.

While I never really thought this was a big deal, the Julia devs certainly do, and I'm a little upset on their behalf that you'd say this. An amazing amount of developer time and effort has been going into reducing loading times and compiler latency lately. The currently release, 1.5.2 is leagues faster at package loading than the previous version and the upcoming 1.6 release candidate is even faster.

They recently implemented multi-threaded precomilation and have been going on a method invalidation crusade doing largely thankless work to deal with exactly this sort of whining.

I applaud Julia developers for their work. They just haven't focused on the UX of using Julia on a daily basis. I have been forced to use Julia as a maintainer (not author) and I feel totally exhausted, defeated and uninspired after working on Julia code.

Just being honest and voicing my opinions. If it hurts the people that worked on it for years, I am sorry.

Have you asked on https://discourse.julialang.org/ already? Maybe, hopefully, you can find help there to feel less exhausted.

-- It's not an opinion when you e.g. say that precompilation has not been addressed when it is being worked on (with much cost, I'd suppose). Same for haven't focused on the UX [snip]. In case you aren't on the julialang discourse I really encourage you to register and ask.

Thanks, I haven’t reached out but mostly seek help on SO.

SO is fine. On discourse (besides asking questions like on SO) there is also space to e.g. discuss why one feels exhausted, defeated and uninspired after working with Julia. This shouldn't be! And there is certainly a way to "fix it" :)

I am not sure faster compilation is the way to go. Cutting 30 sec to 15 helps little and the acceleration of compilation can't catch up with the growth of packages in the long run. Also, multi-threaded precompilation sounds a bad idea on managed clusters where resource usage should be controlled. I wonder how much Julia devs have done on caching precompiled binaries. That, though non-trivial to implement properly, is the ultimate solution to slow compilation.

We recently acquired new hardware and plan to look into it. Invalidations can get in the way, but there are some things that can be done.

The manual says “Large modules can take several seconds to load because executing all of the statements in a module often involves compiling a large amount of code. Julia creates precompiled caches of the module to reduce this time.”

https://docs.julialang.org/en/v1/manual/modules/#Module-init...

This sounds great in theory, but in practice julia-1.5.2 still takes 10 sec to start when I use a medium-sized package including its dependencies (16 compiled files in total). If julia is loading cached files, I would expect something below 1 sec.

You can manually precompile a system image with libraries you find yourself using often, like Plots.jl. The usability of it stinks, but... you can do it, and it speeds common things up.

https://julialang.github.io/PackageCompiler.jl/dev/examples/...

Its usability is being integrated into the package manager so that it automatically gives warnings and triggers when you need to redo the sysimage. Not in v1.6, but there's been a lot of discussions for doing it shortly after. That is something I'm excited for.

Thanks for the tip. This does look promising.

Just to clarify, those precompiled caches are (currently) not of binaries. At the very least, LLVM still needs to generate code after loading, and often everything up to inference still needs to be run as well.

Julia 1.6 involved a lot of work reducing invalidations, where old methods are invalidated by new definitions and thus forced to recompile. This has the obvious benefit of reducing the total amount of compilation needed, but the secondary benefit of making compiling to binaries more profitable; it's less likely that work will be wasted when someone loads another package.

I don't think it's fair to say that it has not been addressed.

See this recent blog post for instance: https://julialang.org/blog/2020/08/invalidations/

I’ve been a software engineer for many years. A lot of what I and my colleagues do is glue, sew and plumb things together.

I’ve never had to write a crazy algorithm. Nor have I had to do any graph traversal. Or anything that impacts performance.

For data analysis, pandas and numpy are plenty powerful. At no time in my career have I said “ditch all this because it’s too slow”. Perhaps others have, but I’m perfectly fine with Python. It’s a beautiful language with ability to hack into basically any part of the language. Batteries, flint, tent and a campsite included.

I sort of agree, although there are certainly quite a few Julia users who do use it for performance. On the other hand I much prefer Julia to Python/Numpy/Pandas regardless of speed.

somebody has to make the stuff you guys glue together.

Totally. And they can use C/C++/Rust which is what most do when performance really matters.

I don't see Julia as a general purpose langauge. I don't see high performance network stack written in Julia ever.

I see Julia as an academic scripting language that happens to be fast *

* Debatable.

really? I would think the number of people who would need to use a high performance number crunching for their business logic is much higher than the number of people who need a high peroformance network stack. The network is usually pretty slow, and almost always the bottleneck is not any code that hasn't already been integrated into the OS kernel. For 99% of people, the OS network stack is fine.

That's why Julia was created though. There is a lot of scientific code that needs to be fast and is written in C or Fortran, but those languages are mediocre in terms of scientific programming.

"Ever" could be a very long time, and lots of things can happen.

For example it might be possible to AoT compile parts of the code (as long as the types are fully defined) to export as a standalone library, and if that happens it would be beneficial to write the number crunching libraries for glue languages in Julia. I mean, there are already those (like DiffEq to Python and R), but if it's a binary that could have just as easily come from C it would be even better. And there are already works along this path, including for wasm deployment.

The multithreading in Julia is very fast and easy to use, and I'm sure it will become robust and safer as well as the language gets older, which can very well allow for an Akka style framework that allow for large software with both high reliability (thanks to stuff like supervision trees) and structured code (since like Julia's ecosystem design favors small libraries composing with each other, the future of large Julia codebases could become the composition of many small high level but fast actors).

There is also lots of interests in work-arounds on the garbage collector, like improved support to immutable structures (like 1.5 improvements on structs with references to mutable structures). It's possible that you might be able to more reliably write parts of the code that do not allocate (or allocate in predictable ways), so you'll be even handle those realtime code loops.

Sure this is very speculative, but look at Python today compared to when it had Julia's age. It took 8 years since Julia became public to get to this point (2 years since it got the first stable release, 1 year since it got it's multithreading model), it will surely be different when it has triple that age.

CORRECTION: I am mistaken. See https://docs.python.org/3/library/ctypes.html

Python is a pretty poor glue language, in my experience.

Calling C APIs from Python is not pleasant. This is how one might import the libm "error function" from Julia:

    const libm = "/lib64/libm.so.6"
    erf(x) = @ccall libm.erf(x::Float64)::Float64

Python requires writing/compiling a separate dll written in C (see [^1]). Python extensions are (reasonably) fast, sure. But they are not pleasant at all to write.

[^1]: https://docs.python.org/3/extending/building.html

Python has a perfectly useful CFFI. There's no need to write an extension module.

> Calling C APIs from Python is not pleasant. [...] Python requires writing/compiling a separate dll written in C (see [^1]).

No, it doesn't, see [0] and [1].

[0]: https://docs.python.org/3/library/ctypes.html

[1]: https://cffi.readthedocs.io/en/latest/

Pybind11 is a dream to work with and there are python packages that implement hot reloading for C++ into a live python session aswell as autogeneration tools for it.

I write crazy algorithms all the time, but I guess I have a more research oriented role. Ultimately someone has to write the crazy stuff you want to glue together, and the more productive those people are the sooner you can have those libraries available. As a user of this code I think there is a be benefit to you being able to read the source behind the algorithms without wading through esoteric FORTRAN, C, and/or CUDA.

This the problem with anecdotal data. In the past I have spent years mostly developing and implementing new algorithms, where appropriate using graph representations. I've also spent months at a stretch on low level performance tuning.

I don't find python beautiful; it's a functional glue language and I don't hate it. It has an ok REPL and some quirky design choices. It has a decent C interop which makes it practical. What makes it useful for data analysis is the large number of packages and staggering number of person-years that have been put into them. The greater python community is great. The language is ok. Together that's pretty useful.

What specifically would you like to see effort spent on? As you say, it's already a nicer language.

Reply on news.ycombinator.com