Hacker News Reader

Comment by th0ma5 | Hacker News Reader

I feel the biggest misleading statements around Julia is that for true speed you can somehow ignore the lower abstractions, or that there is some kind of free lunch, but always what you gain in performance you'll spend in development time. Julia has some neat tricks, but they are not generally and universally applicable at least not like other languages. I dunno. These arguments against Julia are many, but I'm still appalled they have so many handy wavy misleading statements in just their introductory text, I don't think it be less than a decade before they recover.

View on HN

There are different levels of performance to target though - a _basic_ (no SIMD, parallelization, etc) `for` loop can easily be as fast as an C++ version. More performance can be had from both languages, of course. In my experience, the Julia versions offer easier mechanisms to take the code from _basic_ fast to _advanced_ fast. For many, _basic_ fast is fast enough. And when it matters, you can go a bit deeper.

A good example: there was recently a thread on the Julia discourse comparing Julia and Mojo. Julia used no external libraries (compared to 7 with Mojo) implemented a simpler, faster, and cleaner version of the Mojo code that was used to showcase how fast Mojo was: https://discourse.julialang.org/t/julia-mojo-mandelbrot-benc.... Then further still, folks were able to optimize for even more speed with various abstractions that let Julia take more advantage of the hardware.

That's the promise I think Julia makes and delivers on - you can write incredibly "fast" code simply and cleanly. Yes, you can have a higher standard of "fast" which requires a bit more advanced knowledge but I'd argue that Julia still offers the cleanest/simplest way to take advantage of those micro-optimizaitons.

The speed ups exist in other languages like data.table in R, Polars / Jax / NumPy in Python for example.

And exactly that is one of the things Julia was designed for, you don't need two languages to get the performance. This allows to have even more flexibility, you can write allocation free, copy free, SIMD code from top to bottom, because it is a single language. That is not possible on other languages, because you have the high-low level language/library distinction. And if you do (JAX?), then you have made what Julia already is, a runtime compiled language, but with its own set of problems.

How do you define "abstraction" then, I don't see how that is beneficial to obfuscate at which level things are happening.

For abstractions think: automated memory management, rich class/object libraries, idiomatic libraries, compilers that recognize and vectorize common usage patterns, runtime error handling, dynamic typing, etc.

That's not obfuscation, its faster code development, easier to read code, simpler maintainability.

Everything at a higher level than stack, manual heap, processor instruction, registers, explicit addressing and modes, direct I/O, and networking primitives level.

To have all that help, but still be able to drop down to the lowest level, in one consistent toolset is really nice for development and reliable sharing.

(Only a Julia fan at a distance! Not had the pleasure.)

I guess this sounds nice but I wouldn't want to be told that I should just learn assembler, or that if I know assembler that I'd have to put up with whatever high level memory management scheme that I'd have to work around, etc...

I don't think that's right. Well, you're right that some enthusiasts of Julia are too quick to say "fast as C, easy as Python" without appending an asterisk to that statement. You can't get really fast performance without paying any attention to the hardware.

Performance is on a spectrum, and usually a tradeoff against readability and conciseness. I think it IS true that Julia excels in that it gives, by far, the best expressibility/performance tradeoff.

Also, often, you really can get "free lunch" - there are many times where if you just do the obvious thing, Julia and its backend LLVM can optimise it to extremely efficient code. For a simple example, just summing an array with a for loop, for example.

To me, that's the big hand wavy thing is that that thing where if you just do the straightforward obvious thing it's fast, most real world problems aren't straightforward and obvious and therefore turn into something more complex. And now you've got a big can of worms because it was quick in the unspecial case. But now you have no real easy way to get to your special case working correctly without learning more and spending more time just like any other language or switching to a lower level.

> But now you have no real easy way to get to your special case working correctly without learning more and spending more time just like any other language

That's a big hand wavy thing right there: "spending more time" is not a binary, and "just like any other language" ignores the massive differences there are in how much time you have to spend, what resources are available to you from the language, and how easy the ecosystem makes it.

At every level of abstraction there is a lot of learning in that context, but now you demand it across all levels simultaneously.

My experience is a first implementation / novice programmer will write Julia code of a similar speed to python. But then an intermediate Julia programmer can adapt that same code to be of order C / Fortran performance, without stopping the novice programmer from being able to work on the code base. So it's this ability to iteratively improve and collaborate across very different skill sets that's really important.

This is quite a different situation to traditional scientific computing.

> My experience is a first implementation / novice programmer will write Julia code of a similar speed to python.

No because of JIT compilation he would write code faster than Python by default. Now to truly rival optimized C++ code one has to do the tricks mentioned in this post like optimizing memory access, SIMD and maximizing instruction parallelism.

The key point is you are better off by default and can do some ugly stuff in the critical parts of the code while still using the same language.

It really depends on what you end up doing. A lot of "python" code is really just thin wrappers around fairly optimized C routines (although there's inefficiencies from the wrapper, and the optimization barriers), so if you're doing something where the bulk of the work is happening inside those routines, beginner-written julia code will end up being roughly comparable to expert-written numpy code or whatever.

But yeah if you're writing a loop or something else where the majority of work is actually being done by python itself, then it's going to typically be much much slower than the equivalent julia code.

> beginner-written julia code will end up being roughly comparable to expert-written numpy code or whatever

This is not possible by definition, or is a misunderstanding of where and how performance occurs. If this is possible, then it is just as easy to perform worse if the beginner steps to either side of the happy path or if their problem doesn't fit the preconceived optimizations and is therefore no longer a "language" but some kind of "library". I think Julia should be seen as a library and not a language because a language is not comparable in this way that Julia likes to handwave away as magic.

Reply on news.ycombinator.com