3 ms·

> Cross-vendor GPU support: A single codebase runs on AMD, NVIDIA, and CPU via KernelAbstractions.jl This is why I wish Julia were the language for ML and sci

by zamalek 8mo ago

> Cross-vendor GPU support: A single codebase runs on AMD, NVIDIA, and CPU via KernelAbstractions.jl This is why I wish Julia were the language for ML and sci comp in general, but Python is sucking all of the air out of the room.

jampekka 8mo ago
Maybe because Python can reasonably used to make actual applications instead of just notebooks or REPL sessions.
- yellowapple 8mo ago
  What's stopping Julia from being reasonably usable to make actual applications? It's been awhile since I've touched it, but I ain't seeing a whole lot in the way of obstacles there — just less inertia.
  - zamalek 8mo ago
    It's actually better suited IMO, being a compiled language. I'm not sure how anyone could consider the current train wreck of getting python code just to run "actual applications." uv is great and all, but many of these "actual applications" don't use it.
  - fc417fc802 8mo ago
    Presumably inertia and ecosystem size (but that's a follow on of inertia). When Julia came out Python already had traction for ~most things. Keep in mind that it went with 1 based indexes to make the switch easy for Matlab types. I'm not sure if that was a good or bad move for the long term. I'm sure it got some people to move who otherwise wouldn't have but conversely there are also people like me who rejected it outright as a result (after suffering at the hands of 1 based indexing in Matlab I will never touch those again if I have any say in the matter). I've considered switching to it a few times since seeing that they added variable indexes but Python works well enough. Honestly if I were going to the trouble of switching I'd much rather use Common Lisp or R5RS. The nearest miss for me is probably Chicken, where you can seamlessly inline C code but (fatally) not C++ templates. If I ever encounter "Chicken, except Rust" I will probably switch to that for most things.
    - seertaak 8mo ago
      That's part of the answer, but there's a bit more to it IMO. The syntax is a bit weird; python, swift, rust, and zig feel more parsimonious. I absolutely love multimethods, but I think the language would have been better served by non-symmetric multimethods (rather than the symmetric multimethods which are used). The reason is that symmetric multimethods require a PHD-level compiler implementation. That, in turn, means a developer can't easily picture what the compiler is doing in any given situation. By contrast, had the language designers used asymmetric multimethods (where argument position affects type checking), compilation becomes trivial -- in particular, easily allowing separate compilation. You already know how: it's the draw shapes trick i.e., double-dispatch. So in this case, it's trivial to keep what compiler is "doing" in your head. (Of course, the compiler is free to use clever tricks, such as dispatch tables, to speed things up.) The aforementioned interacts sensitively with JIT compilation, with the net outcome that it's reportedly difficult to predict the performance of a snippet of Julia code.
      - seertaak 8mo ago
        Just to clarify the above: 1. I use the term "performance" slightly vaguely. It's comprised of two distinct things: the time it takes to compile the code, and the execution time. The issue is the compilation time: there are certain cases where it's exponential in the number of types which could unify with the callsite's type params. 2. IIRC, Julia compiler has heuristics to ensure things don't explode for common cases. If I'm not mistaken, not only do compile times explode, but certain (very common) things don't even typecheck. There's an excellent video about it by the designer of the language, Jeff Bezanson -- https://www.youtube.com/watch?v=TPuJsgyu87U https://www.youtube.com/watch?v=TPuJsgyu87U . Note: Julia experts, please correct me if this has been fixed. 3. The difficulty in intuiting which combinations of types will unify at a given callsite isn't theoretical; there are reports of libraries which unexpectedly fail to work together. I want to qualify this statement: Julia is light years ahead of any language lacking multimethods when it comes to library composability. But my guess is that those problems would be reduced with non-symmetric multimethods. 4. The non-symmetric multimethod system I'm "proposing" isn't my idea. They are referred to variously as encapsulated or parasitic multimethods. See http://lucacardelli.name/Papers/Binary.pdf http://lucacardelli.name/Papers/Binary.pdf I have huge respect for Jeff Bezanson, for the record!
  - mathisfun123 8mo ago
    https://yuri.is/not-julia/ https://yuri.is/not-julia/ > My conclusion after using Julia for many years is that there are too many correctness and composability bugs throughout the ecosystem to justify using it in just about any context where correctness matters.
  - zem 8mo ago
    I was excited about julia as an application development language when it first came out, but the language and ecosystem seem to be targeting long-running processes. there was just a ton of latency in build time and startup time for things like scripts and applications, so I moved on.
- pjmlp 8mo ago
  https://juliahub.com/case-studies https://juliahub.com/case-studies Most "Python" applications are actually bindings to C, C++ and Fortran code doing the real work.
  - SJC_Hacker 8mo ago
    And it ... works? Use C, C++ or Fortran for the heavy lifting, and Python for UI/business logic/non-high perf stuff for rapid app development.
    - seertaak 8mo ago
      > And it ... works? It gets the job done, but the existence of Cython, Numba, Pythran, PyPy and many, many, others are indication that this isn't a global optimum.
mathisfun123 8mo ago
i hope you realize this is purely because julia uses LLVM and LLVM has backends for those targets (noticeably absent are GPUs which do not have LLVM backends). any other language which uses LLVM could do the same exact same thing (and would be hampered in the exact same way).
- majoe 8mo ago
  Probably true, but one unique thing about Julia is, that exposes almost all stages of the compilation to the user. From typed IR to native code generation you can customise the compilation in many ways. Together with the power of LISP's metaprogramming features, that's a really fine basis for powerful and performamt DSLs and code transformations. All those GPU targets are powered by libraries, that are not part of Julia itself (GPUCompiler.jl). The same goes for automatic differentiation. That's remarkable in my opinion. So you're right, that many programming languages could do it, but it's no wonder, that other languages are lacking in this regard compared to Julia.

by zamalek 8mo ago

jampekka 8mo ago

Maybe because Python can reasonably used to make actual applications instead of just notebooks or REPL sessions.

yellowapple 8mo ago
What's stopping Julia from being reasonably usable to make actual applications? It's been awhile since I've touched it, but I ain't seeing a whole lot in the way of obstacles there — just less inertia.
- zamalek 8mo ago
  It's actually better suited IMO, being a compiled language. I'm not sure how anyone could consider the current train wreck of getting python code just to run "actual applications." uv is great and all, but many of these "actual applications" don't use it.
- fc417fc802 8mo ago
  Presumably inertia and ecosystem size (but that's a follow on of inertia). When Julia came out Python already had traction for ~most things. Keep in mind that it went with 1 based indexes to make the switch easy for Matlab types. I'm not sure if that was a good or bad move for the long term. I'm sure it got some people to move who otherwise wouldn't have but conversely there are also people like me who rejected it outright as a result (after suffering at the hands of 1 based indexing in Matlab I will never touch those again if I have any say in the matter). I've considered switching to it a few times since seeing that they added variable indexes but Python works well enough. Honestly if I were going to the trouble of switching I'd much rather use Common Lisp or R5RS. The nearest miss for me is probably Chicken, where you can seamlessly inline C code but (fatally) not C++ templates. If I ever encounter "Chicken, except Rust" I will probably switch to that for most things.
  - seertaak 8mo ago
    That's part of the answer, but there's a bit more to it IMO. The syntax is a bit weird; python, swift, rust, and zig feel more parsimonious. I absolutely love multimethods, but I think the language would have been better served by non-symmetric multimethods (rather than the symmetric multimethods which are used). The reason is that symmetric multimethods require a PHD-level compiler implementation. That, in turn, means a developer can't easily picture what the compiler is doing in any given situation. By contrast, had the language designers used asymmetric multimethods (where argument position affects type checking), compilation becomes trivial -- in particular, easily allowing separate compilation. You already know how: it's the draw shapes trick i.e., double-dispatch. So in this case, it's trivial to keep what compiler is "doing" in your head. (Of course, the compiler is free to use clever tricks, such as dispatch tables, to speed things up.) The aforementioned interacts sensitively with JIT compilation, with the net outcome that it's reportedly difficult to predict the performance of a snippet of Julia code.
    - seertaak 8mo ago
      Just to clarify the above: 1. I use the term "performance" slightly vaguely. It's comprised of two distinct things: the time it takes to compile the code, and the execution time. The issue is the compilation time: there are certain cases where it's exponential in the number of types which could unify with the callsite's type params. 2. IIRC, Julia compiler has heuristics to ensure things don't explode for common cases. If I'm not mistaken, not only do compile times explode, but certain (very common) things don't even typecheck. There's an excellent video about it by the designer of the language, Jeff Bezanson -- https://www.youtube.com/watch?v=TPuJsgyu87U https://www.youtube.com/watch?v=TPuJsgyu87U . Note: Julia experts, please correct me if this has been fixed. 3. The difficulty in intuiting which combinations of types will unify at a given callsite isn't theoretical; there are reports of libraries which unexpectedly fail to work together. I want to qualify this statement: Julia is light years ahead of any language lacking multimethods when it comes to library composability. But my guess is that those problems would be reduced with non-symmetric multimethods. 4. The non-symmetric multimethod system I'm "proposing" isn't my idea. They are referred to variously as encapsulated or parasitic multimethods. See http://lucacardelli.name/Papers/Binary.pdf http://lucacardelli.name/Papers/Binary.pdf I have huge respect for Jeff Bezanson, for the record!
- mathisfun123 8mo ago
  https://yuri.is/not-julia/ https://yuri.is/not-julia/ > My conclusion after using Julia for many years is that there are too many correctness and composability bugs throughout the ecosystem to justify using it in just about any context where correctness matters.
- zem 8mo ago
  I was excited about julia as an application development language when it first came out, but the language and ecosystem seem to be targeting long-running processes. there was just a ton of latency in build time and startup time for things like scripts and applications, so I moved on.
pjmlp 8mo ago
https://juliahub.com/case-studies https://juliahub.com/case-studies Most "Python" applications are actually bindings to C, C++ and Fortran code doing the real work.
- SJC_Hacker 8mo ago
  And it ... works? Use C, C++ or Fortran for the heavy lifting, and Python for UI/business logic/non-high perf stuff for rapid app development.
  - seertaak 8mo ago
    > And it ... works? It gets the job done, but the existence of Cython, Numba, Pythran, PyPy and many, many, others are indication that this isn't a global optimum.

mathisfun123 8mo ago

i hope you realize this is purely because julia uses LLVM and LLVM has backends for those targets (noticeably absent are GPUs which do not have LLVM backends). any other language which uses LLVM could do the same exact same thing (and would be hampered in the exact same way).

majoe 8mo ago
Probably true, but one unique thing about Julia is, that exposes almost all stages of the compilation to the user. From typed IR to native code generation you can customise the compilation in many ways. Together with the power of LISP's metaprogramming features, that's a really fine basis for powerful and performamt DSLs and code transformations. All those GPU targets are powered by libraries, that are not part of Julia itself (GPUCompiler.jl). The same goes for automatic differentiation. That's remarkable in my opinion. So you're right, that many programming languages could do it, but it's no wonder, that other languages are lacking in this regard compared to Julia.