Live data from Hacker News

Jax vs. Julia (Vs PyTorch)

kidger.site

11–20 of 111 posts

Re: Jax vs. Julia (Vs PyTorch)

#11
post #9

Earlier 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"?

The challenge comes from a person like me, who doesn't know off the top of my head which Greek letter ξ is. So for each of these symbols I'd have to google them and learn it, or have some notepad where I can copy paste the needed symbol

Re: Jax vs. Julia (Vs PyTorch)

#12
post #9

Earlier quoted context omitted.

Difference is 1 keystroke: you type \xi. Why is that a "real challenge"?

The challenge comes from a person like me, who doesn't know off the top of my head which Greek letter ξ is. So for each of these symbols I'd have to google them and learn it, or have some notepad where I can copy paste the needed symbol

So you don't know the Greek alphabet, but write high-performance computing code involving non-trivial math? (Julia's main use case is HPC)

Re: Jax vs. Julia (Vs PyTorch)

#13
post #9

Earlier quoted context omitted.

Difference is 1 keystroke: you type \xi. Why is that a "real challenge"?

The challenge comes from a person like me, who doesn't know off the top of my head which Greek letter ξ is. So for each of these symbols I'd have to google them and learn it, or have some notepad where I can copy paste the needed symbol

You should probably take the time to learn the names of the Greek letters. There are only 24 of them and they're even related to the English ones. It's not a huge time investment, and it's probably worth it if you work in engineering.

Re: Jax vs. Julia (Vs PyTorch)

#14
post #7

In his item #1, he links to https://discourse.julialang.org/t/loaderror-when-using-inter... The issue is actually a Zygote bug, a Julia package for auto-differentiation, and is not directly related to Julia codebase (or Flux package) itself. Furthermore, the problematic code is working fine now, because DiffEqFlux has switched to Enzyme, which doesn't have that bug. He should first confirm whether the problem he is c…

I’ve been using Julia since 2017 and still do on a day to day basis, and I agree with the author in a lot of cases, even his subjective naming conventions gripes.

The author’s biggest criticism is that Julia doesn’t have tooling to make the developer experience better. There’s Revise, JuliFormatter, LanguageServer and Jet, but the development experience in Python is enviable. There’s like 3 different REPLs, at least two competing linters and auto formatters. It’s okay to admit that these are places Julia is lacking.

I think your kind of response to criticism about Julia is what gives the Julia community a bad name, in my opinion. What is wrong with saying these things suck and need improvements? Would you rather Julia not improve and stay the way it is right now forever? Surely I hope not.

Re: Jax vs. Julia (Vs PyTorch)

#15
post #10
post #9

Earlier quoted context omitted.

Difference is 1 keystroke: you type \xi. Why is that a "real challenge"?

What editors does this work in?

Juno, Jupyter support it out-of-the-box. With plug-ins: VS Code (unicode-latex), Atom (latex-completions), Emacs (which has TeX input), Vim (latex-unicoder), ...

Re: Jax vs. Julia (Vs PyTorch)

#16

I 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…

> Academia people live in "bubbles" and they assume everyone knew what a domain specific terms and greek letters

Naming things by their English name is not more universal than using Greek letters. It's just serving amother group of people who live in a different bubble.

Re: Jax vs. Julia (Vs PyTorch)

#17

I 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…

I understand both camps but I believe, these are superficial problems. It's like worrying about the comfort of seat in the operating room of a nuclear plant.

Re: Jax vs. Julia (Vs PyTorch)

#18
post #7

In his item #1, he links to https://discourse.julialang.org/t/loaderror-when-using-inter... The issue is actually a Zygote bug, a Julia package for auto-differentiation, and is not directly related to Julia codebase (or Flux package) itself. Furthermore, the problematic code is working fine now, because DiffEqFlux has switched to Enzyme, which doesn't have that bug. He should first confirm whether the problem he is c…

> but that's a matter of convention & taste, with no bearing on the correctness or performance of the package/language. It's bikeshedding.

I heartily disagree with that. Bikeshedding is about focussing on the trivial, and the symbols we choose in our codebases are hardly trivial, and indeed many of us regard naming things as one of the central problems in programming[1].

[1]:https://medium.com/hackernoon/naming-the-things-in-programmi...

Re: Jax vs. Julia (Vs PyTorch)

#19
post #7

In his item #1, he links to https://discourse.julialang.org/t/loaderror-when-using-inter... The issue is actually a Zygote bug, a Julia package for auto-differentiation, and is not directly related to Julia codebase (or Flux package) itself. Furthermore, the problematic code is working fine now, because DiffEqFlux has switched to Enzyme, which doesn't have that bug. He should first confirm whether the problem he is c…

I’ve been using Julia since 2017 and still do on a day to day basis, and I agree with the author in a lot of cases, even his subjective naming conventions gripes. The author’s biggest criticism is that Julia doesn’t have tooling to make the developer experience better. There’s Revise, JuliFormatter, LanguageServer and Jet, but the development experience in Python is enviable. There’s like 3 different REPLs, at least…

What exactly do you think I said about Julia's linters and auto-formatters?

Re: Jax vs. Julia (Vs PyTorch)

#20
post #16

I 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…

> Academia people live in "bubbles" and they assume everyone knew what a domain specific terms and greek letters Naming things by their English name is not more universal than using Greek letters. It's just serving amother group of people who live in a different bubble.

Yes and no, the example that the author gives is actually a very good one:

> Many Julia APIs look like Optimiser(η=...) rather than Optimiser(learning_rate=...). This is a pretty unreadable convention.

The learning rate is a well known name that basically every one will understand, on the other hand, "η" or eta, is not even used everywhere in the literature with some papers using alpha instead.

This just looks clever, it's a pretty bad parameter name.

Post reply on HN