Julia solves the 2 language problem, however it creates the 1.5 language problem | Hacker News Reader

Julia solves the 2 language problem, however it creates the 1.5 language problem

youtube.com

41 pointsnpalli19 comments

I like the Julia language. I've used Julia for some of my published academic papers. It represents an important step towards solving the two-language problem. But it does not solve the two-language problem.

Until Julia provides first-class support for AoT compilation of (small) binaries and libraries, I don't see it being a competitive single-language option for large-scale projects. And yes I'm aware of PackageCompiler.jl and StaticCompiler.jl (and even GPUCompiler.jl!) They do not provide first-class support for AoT compilation. There's a massive difference between the user experience of compiling a binary with those packages [1] as compared with, e.g., compiling a Mojo binary [2].

I would love to see Julia improve and become more widespread, but I see a strong possibility of it being disrupted by another language unless it improves on this front.

[1] https://julialang.github.io/PackageCompiler.jl/dev/apps.html

[2] https://docs.modular.com/mojo/manual/get-started/hello-world...

I dont understand the binary distribution requirement. For me julia is replacing python applications, and i distribute those as packages via poetry build and pypi.

AoT compiled binaries and libraries are fundamental building blocks for distributing software and running it quickly without latency.

Julia itself calls AoT binaries, for example when calling Linear Algebra functions [1].

Chris Rackauckas's team had to leverage AoT compilation (i.e. system images) to reduce TTFX on DifferentialEquations.jl [2].

PyTorch and Tensorflow run without TTFX because they use AoT compiled binaries. What's more, most end users don't have to compile anything on their computer--they can simply download the binaries and libraries.

For small scripts, yes you can simply distribute the package and have the user recompile on the fly. But imagine if your operating system had to recompile every time you turned the computer off. Or if an autonomous vehicle had to recompile an unseen patch of code while in motion.

[1] https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/#Stand...

[2] https://sciml.ai/news/2022/09/21/compile_time/

> Chris Rackauckas's team had to leverage AoT compilation (i.e. system images) to reduce TTFX on DifferentialEquations.jl [2].

In 2022 with Julia v1.8. See the edit from September. With Julia v1.10 it's mostly there without system image building since v1.9 added AoT compilation of packages during precompilation time and then v1.10 did a major improvement to that system. So as you said, AoT is required, though Julia now includes AoT as part of its package build system. I tend to not build system images anymore because of that, though there are a few more steps to get it to fully AoT (i.e. some load time reductions).

Interesting that you mention about binary size and AoT compilation. I just saw a video from Jeff Bezanson - What's the deal with Julia binary sizes? Might of some interest. Large reduction in binary sizes from back in the day.

https://youtu.be/kNslvU3WD4M?si=0gN_2auQAnwSnQlW

Nice! This is a positive trend. Great to see some additional options for compiling Julia code.

Fully agree. The biggest bummer when it comes to Julia for me is that proper compilation is just an afterthought. And it seems like compilation of portable binaries will remain a second class citizen inside the Julia project?

Julia with a proper `Julia -compile` flag that results in a proper binary of reasonable size would catapult Julia from "kinda nice, but limited" into "one of my favourite languages" territory.

Jax has turned out to be what I expected Julia to be. Write textbook-like numerical code and get good performance because the compiler is smart.

Maybe Julia is so focused on performance that the user experience suffers. Jax (on CPU for non-ML) feels like 80% performance for 20% work, while Julia would be 100% for 100%.

Jax is great, however you are still in the python ecosystem right? So, as you requirements grow, inevitably you will be at a point where 10% of your app goes through 'regular' python and if you don't "drop to C" - making this a two language problem - you will find your app in now 10x slower than an equivalent fast language. It is unbelievable how slow regular python (not using NumPy etc..) is.

I'm a researcher, so my applications are fairly small in terms of "business logic". Virtually all compute is spent in numerical procedures, not in the Python glue code. I am not writing a server backend ;-)

Any thoughts on Mojo?

From what I hear, it is also trying to solve the multi-language problem.

I have been asking myself the same question. Have not heard from it for a while and did not check myself lately. After the initial release some months ago I decided to wait on it and see if someone else comes up with a non-business usecase, but no luck so far.

Only hype no substance .... Yet

https://youtu.be/G98-34MBlaM?si=Lkbh26Az1Kv73eEa

Mojo is a superset of python, but, when I remember correctly, they are introducing C++ like move semantics to achieve "C like performance".

While formally this solves the "2 language problem" (and by design creates the same 1.5 language problem discussed in this talk, but only worse), I don't think it is a good trade off between performance and usability.

> Mojo is a superset of Python

Have you fired it up and tried to use it? I have not seen a single programmer who has used it and still called it a "superset of Python". It's definitely not a superset of Python, that's marketing which IMO will backfire when people actually try the thing. It can call Python (and its syntax for calling Python is actually quite similar to Julia's PyCall.jl), but it's not supersetting it into a larger language. If you want an explicit simple moniker to describe it, it's a whitespace sensitive Rust with a PyCall package built in. Its actions and memory management is very similar to Rust in how explicit it is, and its type system is clearly based on it.

That's not a bad thing perse, Rust is a very good language. However, because Rust is a good language, you have to ask why scientists have not flocked to it in droves and instead have stayed on R/Python/Julia. All of those languages are not surprisingly dynamic. There's a rather strong contingent of folks who believe in the superiority of static languages over dynamic languages and tend to be very vocal about how if they somehow got everyone to see the light then they will be validated in how right they are. Mojo is now an attempt to sell a static programming language as a superset of a popular dynamic one, where its actual actions and memory managements have nothing to do with the dynamic one but are instead pulled from a popular static language.

Will that actually work? I'm a bit skeptical that the reason the majority of programmers are using dynamic programming languages is because they are too stupid and need to be tricked into using a static programming language. I'd instead take it at face value that scientists and engineers are using something that they have found to be the most useful and productive, and today that's a lot of Python/R/Julia. Thus I would instead bet on a dynamic language which has features to force some static behavior, i.e. Julia learning from Typescript and adding similar features with compile-time enforcement, rather than assuming everyone will wake up one way and think C++ or Rust style programming is what every scientist should be doing. That's not to say Julia is perfect today, but I think it has the right bones to move into the direction that the future needs to, which is a dynamic base with optional static features with clear guarantees.

It feels like Julia would have side-stepped a lot of grumbling if it hadn't made its central pitch 'performance'. From time-to-plot to type instability and GC issues, lots of reasonable performance gripes have been amplified because we were sold that everything would be 'blazingly fast'.

On the other hand, performance really was, and remains, one of the main reasons to message from Python to Julia. Absent performance, why would a Pythonista migrate to Julia?

I would still think that multiple dispatch is a better way to build libraries than OOP, but indeed I agree that wouldn't be enough for something as drastic as changing language.

A lot of the design decisions seem to prioritize expressiveness over performance, with the type system and multiple dispatch etc. If they wanted a performant python, they wouldn't have made those choices. So clearly they think Julia is good in other ways, but it didn't make the marketing pitch, which tended to be just 'performant python'.

Now Mojo's going to come along and probably fill that niche, which might at the very least force Julia's community to focus a bit more on its other advantages.

Reply on news.ycombinator.com