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

111–120 of 291 posts

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

#111

Post by antisthenes »

queuebert wrote: post #107
Mehdi2277 wrote: post #106

Earlier quoted context omitted.

Language choices are less about language to me and more about ecosystem of libraries. Python has generally been very strong in the ml/data science realm. I know Julia is catching up but am unsure just how much it covers. Example of python libraries I would consider needed as part of the data ecosystem, numpy, pytorch/tf, batch and stream processing frameworks like spark/flink/beam, workflow orchestration like kubeflo…

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

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

#112

Post by patagurbon »

AstroDogCatcher wrote: post #91
fantod wrote: post #36

Earlier quoted context omitted.

Also no (official) REPL.

The Julia crowd really need to hang less value on the REPL - people writing serious production code don't use one, and scientists using Python have moved on to notebooks. At this point, having Julia be so focused on the REPL is a weird affectation.

Julia has great notebook support, the Ju in Jupyter stands for Julia after all. There's also the fantastic Pluto.jl for reactive notebooks.

And the VSCode extension isn't quite IDE level, but that's just a matter of resources.

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

#113

Post by fault1 »

driscoll42 wrote: post #102
6gvONxR4sf7o wrote: post #72

Earlier quoted context omitted.

Python’s strength isn’t being the best at anything. Its strength is being top 2/5/whatever in a ton of things. Moving to julia for this just trades some pain points for others.

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 and I can see why it may be a hard sale to people used to modern python or C++, both of which have improved since Julia came out. However, Julia has it's own goals that might make certain communities veer towards it. It'll be interesting to see if it gets more adoption in industry.

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

#114

Post by forrestthewoods »

faizshah wrote: post #77
forrestthewoods wrote: post #4

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.

I have had the opposite experience with python, the more I use it and learn the standard library and ecosystem the more I love it. What exactly makes you think its a bad language? For me I think the packaging ecosystem is bad, we need one package management tool like poetry built in. We need a built in typing system like typescript. Lastly we need to remove the GIL. I’m pretty sure all of these are currently being ad…

I'd be moderately happy with Python if it had full static typing, improved error handling, fixed packaging, fixed deployment, and removed the GIL.

I like to think that containers only exist because deploying a Python application is so %^#(&*# complicated that the easiest way to do is to deploy an entire runtime image. It's an absolute nightmare and travesty. So bad. So very very bad. https://xkcd.com/1987/

I'm not optimistic on TypeScript for Python. That'd be great if such a thing existed! I'm not optimistic on packaging or deployment. There is recent progress on GIL removal which is exciting! There is hope, but I'm proceeding with very cautious optimism.

Comprehensions are kinda great, but also hideous and backwards. Rust iterators are a significant improvement imho. The fact that no recent languages have chosen to copy Python's syntax for comprehensions is telling!

Oh, and I think the standard library API design is pretty poor. Filesystem has caused me immense pain and suffering. Runtime errors are the worst.

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

#115

Post by _tom_ »

FridgeSeal wrote: post #92

This seems so silly to me. It’s PyTorch-if they said “the next version of PyTorch will be in Julia, the ecosystem would shift accordingly. They’re practically saying “this language has every feature we need and want, most of them already existing, but we’re going to continue re-inventing them in this objectively less suitable language because we clearly wish to make life harder for ourselves”

By "the ecosystem" they mean the python ecosystem, not the PyTorch ecosystem.

PyTorch is a small part of the python ecosystem. The python ecosystem is not going to change at all if PyTorch moves to Julia.

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

#116

Post by nicoburns »

xbpx wrote: post #43
KptMarchewa wrote: post #17

Earlier quoted context omitted.

>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.

It’s not really bifurcated. Hardly anyone is using demo.

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

#117

Post by oefrha »

xbpx wrote: post #43
KptMarchewa wrote: post #17

Earlier quoted context omitted.

>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.

One has to be in a pretty tiny bubble to believe there’s rapid replacement of Java backends with Deno, of all things.

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

#118

Post by longqzh »

Mikeb85 wrote: post #35
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.

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...

For numeric code, comparing to pure python makes no sense, since people use numpy+numba to do that. Is julia much much faster than numba? I don't think so :)

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

#119

Post by dnautics »

fault1 wrote: post #105
driscoll42 wrote: post #100

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.

agreed, and this always been the driving philosophy of pytorch, and perhaps why it kind of won so much brainshare against tensorflow despite _long_ odds when torch was ported from lua. Soumith Chintala had a keynote talk in juliacon where he focused on these points; https://www.youtube.com/watch?v=6V6jk_OdH-w

were those odds really long? TensorFlow is a beastly mess; and there were some very serious breaking issues between minor version revisions, it was so bad that I used to work at a company where we joked "this company only exists because people can't install tensorflow". We also used to joke that in order to install TensorFlow, step 1: install the JVM.

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

#120

Post by rg111 »

driscoll42 wrote: post #100
FridgeSeal wrote: post #92

This seems so silly to me. It’s PyTorch-if they said “the next version of PyTorch will be in Julia, the ecosystem would shift accordingly. They’re practically saying “this language has every feature we need and want, most of them already existing, but we’re going to continue re-inventing them in this objectively less suitable language because we clearly wish to make life harder for ourselves”

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.

Exactly.

PyTorch is not only easy, but is a joy to work with.

Among researchers, TensorFlow is rapidly losing ground to PyTorch, and, I think, will keep losing ground until it becomes a niche and only used by Googlers and some others.

https://horace.io/pytorch-vs-tensorflow/

Post reply on HN