Jax vs. Julia (Vs PyTorch)
kidger.site
Jax vs. Julia (Vs PyTorch)
1–10 of 111 posts
Re: Jax vs. Julia (Vs PyTorch)
#2Re: Jax vs. Julia (Vs PyTorch)
#3""" Even in the major well-known well-respected Julia packages – I’ll avoid naming names – the source code has very obvious cases of unused local variables, dead code branches that can never be reached, etc. """ Please name names. that way we can fix stuff. Other than that, great post!
Re: Jax vs. Julia (Vs PyTorch)
#4""" Even in the major well-known well-respected Julia packages – I’ll avoid naming names – the source code has very obvious cases of unused local variables, dead code branches that can never be reached, etc. """ Please name names. that way we can fix stuff. Other than that, great post!
I think the author is pushing for better code quality tooling in Julia instead of having people manually fix these problems.
Re: Jax vs. Julia (Vs PyTorch)
#5But for us mortal who cross multiple domains its just getting extremely frustrating to read full math based notation without any extra info about notation in package/functions etc. so debugging multiple sub-packages is just getting too time consuming as you have to learn both person style of writing code, whole scientific notation and get domain knowledge before you can even touch the code.
Re: Jax vs. Julia (Vs PyTorch)
#6Re: Jax vs. Julia (Vs PyTorch)
#7Item #2, again another Zygote bug.
Item #3, which package? That sounds like an hyperbole, an extrapolation from a small sample, and "I'll avoid naming names" is a lazy excuse that would hide this. It is similarly easy to point to poorly written (or poorly documented) JAX code or Python code as well, so that doesn't prove that "Julia is lacklustre and JAX shines". Also, as an academician, I strongly disagree that learning_rate=... is better than η=..., but that's a matter of convention & taste, with no bearing on the correctness or performance of the package/language. It's bikeshedding. I agree that errors are usually not "instructable" in Julia ML packages (which needs to be improved), so monkey typing is less likely to succeed.
Item #4 is such a nitpicker. Sure, Julia may not have a special syntax for that particular fringe array slicing like Numpy does and you'll instead need to make a function call, but matrix/tensor code in Numpy is usually filled with calls to zips and cats with explicit indices, whereas in Julia, no explicit indexing needs to be done usually. Also, one can nitpick similarly in the opposite direction: Julia has many language features lacking from JAX or Python, why not talk about those as well?
I'm not a huge fan of Julia either (mainly because of it's garbage collected nature), but this is such a low-effort criticism of it.
Re: Jax vs. Julia (Vs PyTorch)
#8I strongly agree with readability in my opinion its cause Academia people live in "bubbles" and they assume everyone knew what a domain specific terms and greek letters means so its easier to read some omega then for example learning_rate or lr. But for us mortal who cross multiple domains its just getting extremely frustrating to read full math based notation without any extra info about notation in package/function…
Re: Jax vs. Julia (Vs PyTorch)
#9I strongly agree with readability in my opinion its cause Academia people live in "bubbles" and they assume everyone knew what a domain specific terms and greek letters means so its easier to read some omega then for example learning_rate or lr. But for us mortal who cross multiple domains its just getting extremely frustrating to read full math based notation without any extra info about notation in package/function…
And if you ever do want to edit the code, you have to know the name of every non-ASCII symbol the codebase uses if you want to type out those same symbols without copying and pasting them. If you're not familiar with the material, entering a character like ξ can be a real challenge, and is actually more keystrokes than just typing "xi".
Re: Jax vs. Julia (Vs PyTorch)
#10Earlier quoted context omitted.
And if you ever do want to edit the code, you have to know the name of every non-ASCII symbol the codebase uses if you want to type out those same symbols without copying and pasting them. If you're not familiar with the material, entering a character like ξ can be a real challenge, and is actually more keystrokes than just typing "xi".
Difference is 1 keystroke: you type \xi. Why is that a "real challenge"?