Live data from Hacker News

PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

dev-discuss.pytorch.org

151–160 of 291 posts

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#151

Earlier quoted context omitted.

I would claim the tech revolution happened despite those terrible languages rather than because of them. The languages are popular because of inertia, not because they're good. Python is popular because of the ML revolution. If ML didn't take off neither would Python's popularity. Is ML successful because of Python or despite Python? Well, the world is probably further along with Python than if it merely didn't exist…

As someone who uses Python since 2004, you got it backwards. Python was popular before because it's very nice language. People wanted to use it for science to, so they wrote very good scientific libraries for it. R was very popular for non-neural-network ML some years ago, yet it wasn't picked up for NN, because R kind of sucks for general programming. As the joke goes, the best part of R is that is a language writte…

The runtime of R is it’s biggest downfall. Its single threaded nature kills it. I say this having used future::promise in a Plumber API to get some semblance of concurrency.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#152
post #15

> Julia says: > A language must compile to efficient code, and we will add restrictions to the language (type stability) to make sure this is possible. > A language must allow post facto extensibility (multiple dispatch), and we will organize the ecosystem around JIT compilation to make this possible. > The combination of these two features gives you a system that has dynamic language level flexibility (because you h…

one day OCaml will win ;-;

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#153

Neither language have proper tail call elimination, which, is absolutely insane to me. Yall really just write procedural code for everything?

I've never seen recursive looping over a thing get turned into efficient SIMD code in any language. Starting with loops has no good reason to be better able to achieve that but for practical compilers it makes a huge difference. Julia code might also uses a lot of in place operations which would be hard for a compiler to infer as safe.

> I've never seen recursive looping over a thing get turned into efficient SIMD code in any language. Starting with loops has no good reason to be better able to achieve that but for practical compilers it makes a huge difference.

Well, for example at the very least in Common Lisp you'll have much more joy with higher-order functions than with loops. The simple reason for that is the existence of compiler macros (http://clhs.lisp.se/Body/03_bba.htm) which can replace function compositions with arbitrary code. And it's much easier to figure out what the function composition does than to write a loop vectorizer.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#154
post #150
post #86

Earlier quoted context omitted.

Tail calls and while loops are essentially equivalent, so why care whether a language prefers one or the other?

They're not "essentially equivalent". A while loop can't begin in one module and end in another. A tail call sequence can. Loops are not modular.

Just to be clear, are you suggesting mutual recursion across modules?

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#155
post #130
post #46

Earlier quoted context omitted.

Another point that is often lost is how mathematical Julia code can look, especially for matrix functions. Yeh this is superficial, but so are 200 dollar sneakers and they do just fine. Honestly there is a real pleasure writing code that looks like it could be on the blackboard. The numpy / numba world in Python just feels... not great.

I actually consider that a negative. Mathematical notation is fine when you're dealing with limited space on a blackboard, but if you're programming please name your name variables and take the time to model your domain explicitly.

I don't understand - what is wrong with condensing the python representation `sum_of_lambda_for_each_psi` to `Σλ∀φ`? It seems that 4 symbols is much quicker and easier to read than a slew of snake case stuff.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#156
post #37
post #23

Earlier quoted context omitted.

I don't know, x being a potential replacement for y doesn't say all that much. You could have been writing Java or C++ for the past 25 years and got loads of stuff done, solved problems, shipped software, made money etc. Languages are fun to think about but you don't always need to be concerned with every vocal minority of programmers that like to talk about how their language is better than yours. Sometimes that rep…

I wholeheartedly agree. X instead of reasonably-similar-Y isn't convincing in and of itself. I'm not even convinced Julia will be the dominant numerical programming language. That said I'd like it if it develops a robust and large ecosystem because I personally like coding in it. It has built-in matrix ops, parallel ops, dynamic dispatch etc that are really nice to work with in the numerical space. Like Matlab but we…

** like Matlab - but free and open source ** Perhaps an important aspect that allows it to be relevant

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#157
post #128

Earlier quoted context omitted.

Or I read it as "We want to make life as easy for our userbase as possible, so we will put more work on ourselves to make our users lives easier" which is an attitude I very much appreciate.

In the long run I think moving to Julia would make a lot of sense. I have used MATLAB, R, Python and Julia extensively for doing all sorts of data related things during the last 20 years. Julia is incredibly easy to work with, very elegant and really efficient. R and Python have always felt clumsy in some ways, and hard to write really performant code, even if you are more proficient in Python! As a seasoned Lisper a…

Flux dev here. There's Transformers.jl which has prebuilt transformers built on top of Flux. While the package does change, we have been more careful about ensuring we don't break code all that often.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#158
post #113

Earlier quoted context omitted.

100% this. I love that in python I can handle most all problems reasonably well. I don't need perfect, I need a good, versatile language that I know how to code. Even if Julia is better in some things, the switching cost of learning the language, libraries, nuances, the massively fewer online resources, just is not there.

I've been using C++ and Python since the early 2000s. Julia these days is my go to free time language to hack together stuff in, partially because I've been impressed with what comes out of that ecosystem despite the smaller community. I think this is at least a testament with how composable things are relative to C++ or python. I love many things about Julia, but there are definitely growing pains for the language a…

The way I see Julia now is how I saw python ~12 years ago

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#159
post #147

Earlier quoted context omitted.

Julia is generally in the same ballpark as Numba (depending on the application they should be within 2%). The difference is that Julia is a full language, while Numba breaks if you try to use it with anything else.

Yeah, Numba usually delivers on its performance promises when used right, but can be such a huge hassle oftentimes as to make it not really worth it.

Yes, Numba is just barely less awful than managing a C build process.

Julia is a much better solution to the two language problem, here's hoping it can overcome the ecosystem inertia.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#160

Earlier quoted context omitted.

Python is the middle manager of languages. It sucks at everything, but always knows a guy.

And there's 1 guy he knows that's a 10x developer and always willing to take one for the team. I'll leave it to HN to figure out what that means :P

Call native libraries?
Post reply on HN