Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jax vs. Julia (Vs PyTorch)

kidger.site

Post reply on HN
Print view View original

101–110 of 111 posts

Re: Jax vs. Julia (Vs PyTorch)

#101

Post by rg111 »

patrick451 wrote: post #58

> It’s pretty common to see posts on the Julia Discourse saying “XYZ library doesn’t work”, followed by a reply from one of the library maintainers stating something like “This is an upstream bug in the new version a.b.c of the ABC library, which XYZ depends upon. We’ll get a fix pushed ASAP.” And > First of all, it’s not in the Flux documentation. Instead it’s in the documentation for a separate component library –…

> People love to rave about how the julia ecosystem is made up of tons of tiny composable libraries instead of large monolithic libraries like scipy. To me, that sounds like a major headache

Absolutely agree.

First and foremost, I need to get my work done. I do not want to learn all those libraries.

The API design, its quality, philosophy (or lack thereof) of framework will be different across all the frameworks.

And I am not sure I want too many libraries in my codebase.

It is a whole different level of technical debt.

Re: Jax vs. Julia (Vs PyTorch)

#102

Post by eggy »

aaplok wrote: post #16
machinekob wrote: post #5

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.

I agree, and from my math/APL bubble, let me have my succinct symbols. I invoke the famous Iverson 1979 Turing Award Lecture, "Notation as a Tool for Thought" [1]. If you are in ML and do math to some degree, learn the symbols; it's more than just about succinctness.

[1] https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.p...

Re: Jax vs. Julia (Vs PyTorch)

#103

Post by socialdemocrat »

snicker7 wrote: post #90
socialdemocrat wrote: post #78

Earlier quoted context omitted.

I use export for my public functions. What is wrong with that? How exactly does Python signal what is public? Nothing but conventions like underscore, which btw Julia developers use as well. If I really really don't want somebody to use a function, I might underscore it but generally I don't see the point.

The underscore naming convention is far from ubiquitous in either the Python or Julia communities. The more practical indicator of a function being "public" is whether or not it appears in the published API documentation. Unlike Julia, Python projects are more likely to have complete documentation (or even documentation at all). So there is a better understanding of what "public" means in Python. Without docs, it's a…

I agree documentation is a problem with Julia, but I dislike the lack of nuance when people discuss this. There is no doubt in my mind that the core Julia libraries are far better documented than the Python equivalents.

Just do something simple like looking up help on `print` in the REPL on Python and Julia. The Python documentation is very primitive compared to what you get in Julia.

Julia has a better standard documentation system than Python and have in the standard library started a better convention for how to document things which means that as this spreads out to other third party libraries, Julia has the potential to be better documented than Python.

What you see today is immaturity rather than signs of an inherently bad system.

Re: Jax vs. Julia (Vs PyTorch)

#104

Post by belval »

doliveira wrote: post #100
belval wrote: post #47

Earlier quoted context omitted.

The programming language is already in English, implying that using greek letters to map to math concepts is easier to understand for non-native is disingenuous.

It's really not. There are just a few programming language-specific keywords that you have to memorize, unlike infinite possible combinations of English words for parameters. edit: as an example, when programming for Brazilian businesses, we generally just use a mix and match of Portuguese and English like getFinanciamento. "Get" is a technical concept while "Financiamento" is a business concept and it often doesn't…

I am not debating the merits of writing your business logic in whatever language that you want.

Flux, the Julia framework that we are discussing, is in English. Its classes, function names, optimizers, everything is in English. Keeping parameters as Greek letters and arguing that it's easier to understand is insanity.

Re: Jax vs. Julia (Vs PyTorch)

#105

Post by doliveira »

belval wrote: post #104
doliveira wrote: post #100

Earlier quoted context omitted.

It's really not. There are just a few programming language-specific keywords that you have to memorize, unlike infinite possible combinations of English words for parameters. edit: as an example, when programming for Brazilian businesses, we generally just use a mix and match of Portuguese and English like getFinanciamento. "Get" is a technical concept while "Financiamento" is a business concept and it often doesn't…

I am not debating the merits of writing your business logic in whatever language that you want. Flux, the Julia framework that we are discussing, is in English. Its classes, function names, optimizers, everything is in English. Keeping parameters as Greek letters and arguing that it's easier to understand is insanity.

I am replying to a comment in which you were talking in general terms. Maybe it's insanity because typing Greek symbols in most general-purposes IDEs is hard, querying it in search engines can be tough, etc. Not because it's mixed with English names.

Classes are a programming concept, they do map to the programming domain. Even optimizers and functions probably do map to a named mathematical concept, not to a Greek letter. But prameters probably map to a specific symbol in an equation.

In Mathematica, for instance, we use Greek letters and it allows you to just type an equation in the proper visual form. So much easier to map it when you're working with the actual domain-native names and formats.

Re: Jax vs. Julia (Vs PyTorch)

#106

Post by bmc7505 »

SemanticStrengh wrote: post #6

The most next gen autodiff library probably is https://github.com/breandan/kotlingrad because of its features, ergonomy and type safety

Author here. You are very kind, but Kotlin∇ is definitely a work-in-progress and its claimed contributions are more modest in nature. It is true that Kotlin∇ was one of the first AD frameworks to introduce shape-safe tensor arithmetic, however we were not the only ones to realize the importance of this concept, which has since been adopted by more powerful type systems (e.g., Dex and Hasktorch). Right now, our efforts have mostly migrated from gradient-based machine learning in continuous spaces to generalized differentiation over finite fields (details forthcoming in our ARRAY'22 presentation), which allows us to take derivatives in discrete spaces such as bounded-width regular and context free languages. Our findings indicate that generalized AD has practical applications to robust-parsing, error-correcting codes, type inference and program synthesis.

Re: Jax vs. Julia (Vs PyTorch)

#107

Post by DNF2 »

blindseer wrote: post #40

Another massive frustration for me is that Julia has no formal way to say "here are public functions and these are private" but does have a completely orthogonal way of saying "these are functions that will populate your global namespace if you use `using`", i.e. `export variable_name`, and people absolutely confuse the hell out of these. I don't think there's even agreement in the Julia community if you should use `…

You list some reasonable criticisms, but how is 'immutable structs are more performant' a valid criticism? That's just because compilers can do more optimizations with immutables. Unless you want immutables to be intentionally hobbled, what exactly do you expect the Julia devs to do about it?

Re: Jax vs. Julia (Vs PyTorch)

#108

Post by otagekki »

dunefox wrote: post #99
127 wrote: post #36

Earlier quoted context omitted.

Google Translate is one click away. I can easily translate both Japanese and Chinese comments and variable names to get the gist of it. Using single hieroglyphs for it makes the entire endeavor impossible.

So, you are fine with google translating variable names but you absolutely cannot interpret symbols? Wow.

Still better to google translate the meaning of 学习率 than do the same on eta...

Re: Jax vs. Julia (Vs PyTorch)

#109

Post by dunefox »

otagekki wrote: post #108
dunefox wrote: post #99

Earlier quoted context omitted.

So, you are fine with google translating variable names but you absolutely cannot interpret symbols? Wow.

Still better to google translate the meaning of 学习率 than do the same on eta...

That's ridiculous.

Re: Jax vs. Julia (Vs PyTorch)

#110

Post by catelm »

dklend122 wrote: post #91

There are several repeating (valid) critiques. There is also a sense that things won't get better. I don't think that's necessarily the case. I can't give timelines, but I'll list the themes and point to the very active work going on in those areas: 1. Static analysis/ it's hard to write large codebases of correct Julia code. That's being addressed on several fronts: a. Work on both traits/interfaces and sound static…

Do you have a link to some information regarding the work on traits/interfaces and static typing, please?
Post reply on HN