6 ms·

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

41 points by npalli 3y ago

ubj 3y ago
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 https://julialang.github.io/PackageCompiler.jl/dev/apps.html [2] https://docs.modular.com/mojo/manual/get-started/hello-world.html#build-an-executable-binary https://docs.modular.com/mojo/manual/get-started/hello-world...
- banku_brougham 3y ago
  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.
  - ubj 3y ago
    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/#Standard-functions https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/#Stand... [2] https://sciml.ai/news/2022/09/21/compile_time/ https://sciml.ai/news/2022/09/21/compile_time/
    - ChrisRackauckas 3y ago
      > 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).
- npalli 3y ago
  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 https://youtu.be/kNslvU3WD4M?si=0gN_2auQAnwSnQlW
  - ubj 3y ago
    Nice! This is a positive trend. Great to see some additional options for compiling Julia code.
- Herbstluft 3y ago
  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.
cl3misch 3y ago
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%.
- npalli 3y ago
  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.
  - cl3misch 3y ago
    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 ;-)
- signaru 3y ago
  Any thoughts on Mojo? From what I hear, it is also trying to solve the multi-language problem.
  - cl3misch 3y ago
    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.
  - arbitrandomuser 3y ago
    Only hype no substance .... Yet https://youtu.be/G98-34MBlaM?si=Lkbh26Az1Kv73eEa https://youtu.be/G98-34MBlaM?si=Lkbh26Az1Kv73eEa
baazaa 3y ago
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'.
- jakobnissen 3y ago
  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?
  - kdwikzncba 3y ago
    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.
  - baazaa 3y ago
    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.

41 points by npalli 3y ago

ubj 3y ago

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 https://julialang.github.io/PackageCompiler.jl/dev/apps.html [2] https://docs.modular.com/mojo/manual/get-started/hello-world.html#build-an-executable-binary https://docs.modular.com/mojo/manual/get-started/hello-world...

banku_brougham 3y ago
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.
- ubj 3y ago
  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/#Standard-functions https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/#Stand... [2] https://sciml.ai/news/2022/09/21/compile_time/ https://sciml.ai/news/2022/09/21/compile_time/
  - ChrisRackauckas 3y ago
    > 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).
npalli 3y ago
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 https://youtu.be/kNslvU3WD4M?si=0gN_2auQAnwSnQlW
- ubj 3y ago
  Nice! This is a positive trend. Great to see some additional options for compiling Julia code.
Herbstluft 3y ago
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.

cl3misch 3y ago

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%.

npalli 3y ago
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.
- cl3misch 3y ago
  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 ;-)
signaru 3y ago
Any thoughts on Mojo? From what I hear, it is also trying to solve the multi-language problem.
- cl3misch 3y ago
  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.
- arbitrandomuser 3y ago
  Only hype no substance .... Yet https://youtu.be/G98-34MBlaM?si=Lkbh26Az1Kv73eEa https://youtu.be/G98-34MBlaM?si=Lkbh26Az1Kv73eEa

baazaa 3y ago

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'.

jakobnissen 3y ago
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?
- kdwikzncba 3y ago
  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.
- baazaa 3y ago
  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.