Hacker News Board Hacker News, browsed like a classic message board
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

Post reply on HN
Print view View original

41–50 of 291 posts

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

#41

Post by [deleted] »

forrestthewoods wrote: post #31
justapassenger wrote: post #10

Earlier quoted context omitted.

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…

[deleted]

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

#42

Post by edgyquant »

zz865 wrote: post #14
xbpx wrote: 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.

I do like JS quite a bit, I was a hater until a few years ago when I had to start working with it more than a snippet here and there, but I still prefer python on the backend. I think JS makes a lot of sense for frontend with the way everything is async.

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

#43

Post by xbpx »

KptMarchewa wrote: post #17
xbpx wrote: 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…

>rapid replacement of backends in JavaScript Really? I thought that was a ~2017 thing.

Ha it's still going strong. Now bifurcated between node+next and the rise of Deno.

It won't stop either because the road between between JS client dev and JS server dev is so smooth. Path of least resistance type thing.

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

#45

Post by edgyquant »

geofft wrote: 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…

The main reason is that a lot of scientific computing depends on ancient libraries written in Fortran or C, and a lot of newer libraries depend on GPUs for their matrix operations so need to be able to make calls to C/C++ modules that run directly to the GPU. This probably isn’t impossible for Java but that was never meant to be it’s niche, it doesn’t compile to machine instructions and prefers portability.

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

#46

Post by xbpx »

RemoteControlr wrote: post #33
zz865 wrote: post #14

Earlier quoted context omitted.

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.

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.

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

#47

Post by jreese »

dnautics wrote: post #32
noitpmeder wrote: post #9

Earlier quoted context omitted.

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.

Isn't that true for any language? Why are you hiring for language skills rather than problem solving aptitude and conceptual fundamentals?

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

#48

Post by edgyquant »

iddan wrote: post #25
geofft wrote: 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…

Because people in that game value simplicity of use over anything else (performance, safety, maintenance) and Python is a top performer in that KPI while Java is not very good at this (though it is getting better but still)

This is a big part of it. People who are scientists write code that we would think is disgusting and don’t care that much about abstraction outside of mathematical functions. There’s a lot to learn with Java. I helped classmates in my intro to programming class when I went to college, because I already knew how to code, and I have no idea why they picked that language as an introduction language. After weeks people were still struggling because on top of the ideas like loops/variables/control flow now they are having to learn classes.

Python was written with people like scientists in mind. Professionals write fast C libraries and then people who know just enough to get by use python to glue it all together.

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

#49

Post by edgyquant »

dnautics wrote: post #32
noitpmeder wrote: post #9

Earlier quoted context omitted.

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.

Can you elaborate? If someone can pump out leet code I would assume they would be a half decent programmer and it would just take some time for them to be as productive as you wanted. Then again I’m mostly self taught and never done leet code and I still manage to be a good programmer according to those I’ve worked with

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

#50

Post by Mikeb85 »

ur-whale wrote: post #26
zz865 wrote: post #14

Earlier quoted context omitted.

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.

> I'm not sure what advantage Julia While I'm really not a fan of 1-based indexing, Julia's multiple dispatch is not something easy to match in Python. [EDIT]: one thing that's still not solved in Julia is code startup time. Many people will sell you some sort of workflow that works around the problem, but it's the same old tired arguments people would use to defend traditional compiled languages, and I'm not buying.…

> [EDIT]: one thing that's still not solved in Julia is code startup time.

> Many people will sell you some sort of workflow that works around the problem, but it's the same old tired arguments people would use to defend traditional compiled languages, and I'm not buying.

I mean, Julia has a REPL so you can basically edit code as the process runs, which definitely makes startup time less of an issue. The fact Julia can produce such fast code is also pretty nice.

Starting a new process every time you want to run a snippet of code isn't getting the best out of a dynamic language...

Post reply on HN