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

31–40 of 291 posts

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

#31

The more I use Python the more I hate it. It’s genuinely a bad language, with a stellar ecosystem. Ironically, the most valuable parts of the ecosystem are often written in C (NumPy). It’d be interesting to see how much of the Python ecosystem is actually necessary to move PyTorch to a better language. I’m afraid we’re stuck with Python for the next 20 years. That makes me very, very sad.

Bad languages like Python, JavaScript, PHP are responsible for powering large part of tech revolution. Ability to write bad code easily is IMO large part of why they’re so popular. Low barrier to entry helps to build huge ecosystem.

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. But if a different language that sucked less existed we would, imho, be further along than we are.

I'm not annoyed Python exists. I'm annoyed that its inertia is so monumental it's inhibiting further progress. We're at a local maximum and the cost to take the next step is really really really high. That's not Python's fault mind you, just the way things work.

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

#32

The more I use Python the more I hate it. It’s genuinely a bad language, with a stellar ecosystem. Ironically, the most valuable parts of the ecosystem are often written in C (NumPy). It’d be interesting to see how much of the Python ecosystem is actually necessary to move PyTorch to a better language. I’m afraid we’re stuck with Python for the next 20 years. That makes me very, very sad.

What do you think the major drawbacks are? Speed would be the top of my list, but most projects to not need anything more than what python can currently pump out.

You can't dismiss the fact that hiring python is hard. You think you're getting a good programmer, because they know all the leetcode tricks, but that person turns out to be a dud.

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

#33
post #14
post #3

Java has a massive ecosystem yet we continue to see rapid replacement of backends in JavaScript (Node now Deno) and Golang. Each of those language ecosystems rapidly became both large (arguably too large) and robust. Rust has been eating C++ lunch. Same rapid rise of ecosystem story. Instead of forcing Python to be a language it isn't it might be more efficient and ultimately the "right choice" to invest the time in…

Wow I hadn't seen deno before, looks great. I dont like js/ts, but if you have to learn it for front end dev, it makes sense to use it at the back too. I'm not sure what advantage Julia has over Python. Yeah it has some typing and can be faster, but its too similar. Still single threaded.

As has been pointed out, Julia is not limited to a single thread. It's actually got a pretty good support for parallelism both at the thread and process level.

And no, Julia is not too similar to Python. Julia has multiple dispatch, Python does not.

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

#34

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

You must be in quite the functional bubble (I envy you for that, though)

Just Ruby...

I use Python plenty, just not in large enough doses that I have to actually make peace with it.

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

#35
post #14
post #3

Java has a massive ecosystem yet we continue to see rapid replacement of backends in JavaScript (Node now Deno) and Golang. Each of those language ecosystems rapidly became both large (arguably too large) and robust. Rust has been eating C++ lunch. Same rapid rise of ecosystem story. Instead of forcing Python to be a language it isn't it might be more efficient and ultimately the "right choice" to invest the time in…

Wow I hadn't seen deno before, looks great. I dont like js/ts, but if you have to learn it for front end dev, it makes sense to use it at the back too. I'm not sure what advantage Julia has over Python. Yeah it has some typing and can be faster, but its too similar. Still single threaded.

Julia is much, much faster than Python. For numeric code it's almost as fast as C++. They've used lots of cool tricks to become crazy fast on numeric workloads. It's also definitely got support for multithreading, clusters, etc...

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

#36
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…

no data types, no operator overloading, no extendability of new functions to existing objects, no C/Fortran interop, mediocre performance. Need I go on?

Also no (official) REPL.

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

#37
post #23
post #3

Java has a massive ecosystem yet we continue to see rapid replacement of backends in JavaScript (Node now Deno) and Golang. Each of those language ecosystems rapidly became both large (arguably too large) and robust. Rust has been eating C++ lunch. Same rapid rise of ecosystem story. Instead of forcing Python to be a language it isn't it might be more efficient and ultimately the "right choice" to invest the time in…

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 well rounded and fast.

So I admit my comment is less argument and more cheerleading. "Hey folks let's make this the case so us numerical people can have a slightly improved experience".

In the grand scheme of things this is as noble or ignoble as any.

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

#38
post #3

Java has a massive ecosystem yet we continue to see rapid replacement of backends in JavaScript (Node now Deno) and Golang. Each of those language ecosystems rapidly became both large (arguably too large) and robust. Rust has been eating C++ lunch. Same rapid rise of ecosystem story. Instead of forcing Python to be a language it isn't it might be more efficient and ultimately the "right choice" to invest the time in…

> it needs faster time to plot

Time to plot is much improved in 1.6 and should continue to improve in 1.7. It's definitely being addressed.

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

#39
post #36

Earlier quoted context omitted.

no data types, no operator overloading, no extendability of new functions to existing objects, no C/Fortran interop, mediocre performance. Need I go on?

Also no (official) REPL.

Actually Java has had a repl called Jshell since JDK 9.

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

#40

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

if you want tail calls in Julia, there is a 3 line macro that gives it to you.

Could you point to it? Thanks
Post reply on HN