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

131–140 of 291 posts

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

#131

Post by jolux »

forrestthewoods wrote: post #114
faizshah wrote: post #77

Earlier quoted context omitted.

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 op…

> I'm not optimistic on TypeScript for Python. That'd be great if such a thing existed

MyPy exists, Python officially supports type annotations.

I do think comprehensions are a weird feature for Python, particularly from the “one way to do it” perspective. And also because the language so strongly discourages FP patterns outside of comprehensions.

Overall I would say the language is a lot better than the ecosystem, and that it suffers a lot from having a bad packaging design. I’m not a fan, suffice it to say. It’s best if you can stick to the standard library.

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

#132

Post by creata »

Vetch wrote: post #124
creata wrote: 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?

It's like, why use one synonym and not the other? Sometimes it's because writing things in an immutable manner makes things clearer. Other code that can benefit are certain coroutines and generators.

> It's like, why use one synonym and not the other? Sometimes it's because writing things in an immutable manner makes things clearer.

That's true in many situations, but in this case the equivalence between the two is so straightforward that I can't see recursion gaining you any clarity. Perhaps you have a concrete example?

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

#133

Post by longemen3000 »

fault1 wrote: post #99
ummonk wrote: post #76

Earlier quoted context omitted.

Indeed, and static type analysis is the single biggest feature I'd like Julia to add first class support for.

i agree, this is without a doubt the number one thing that julia needs. nearly every dynamic language has trended towards this in the last 7-8 years. it's probably had the most profound effect in modern Javascript (typescript) and python. It's incredible how different production javascript and production python are compared to say, 2014 javascript or 2014 python. JET.jl is a interesting project to do some error analy…

JET.jl it's an interesting case indeed. Its being used retroactively in the Julia base code to look for any undesirable dynamic type situations

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

#134

Post by adgjlsfhk1 »

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.

IMO, the REPL is really nice for exploration. I would never write code in it, but it serves as a really good doc search tool and quick way to check things. It helps that the Julia REPL is more inspired by the Lispy ones than python/R.

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

#135

Post by searchableguy »

nicoburns wrote: post #116
xbpx wrote: post #43

Earlier quoted context omitted.

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.

I think Slack is using deno now.

https://api.slack.com/future/tools/cli

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

#136

Post by adgjlsfhk1 »

longqzh wrote: post #118
Mikeb85 wrote: post #35

Earlier quoted context omitted.

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 :)

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.

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

#138

Post by edgyquant »

AstroDogCatcher wrote: post #88
jstx1 wrote: post #62

Earlier quoted context omitted.

> People who are scientists write code that we would think is disgusting and don’t care that much about abstraction outside of mathematical functions. - plenty of scientists write good code; I think the "scientist can't code" meme is harmful. - most of the people that write PyTorch code aren't necessarily scientists - they're software developers (data scientists, ML engineers, research engineers, whatever title - but…

I'd flip that meme slightly; it is true that scientists write shitty code...but it turns out computer scientists do exactly the same, and with less humility.

The difference is programmers write shitty abstractions to abstract shitty code

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

#139

Post by edgyquant »

amelius wrote: post #78
edgyquant wrote: post #44

Earlier quoted context omitted.

I like what Julia is doing but I just dislike the syntax. It seems to resemble ruby, whose syntax I also think is ugly, which to me resembles a modern form of basic.

I know what you mean. I especially dislike the use of an "end" keyword everywhere without a corresponding "begin" keyword.

Yeah that’s exactly what I’m talking about

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

#140

Post by adgjlsfhk1 »

Mehdi2277 wrote: post #106
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”

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…

One of the really nice things with Julia is some of the ecosystem needs disappear. Python needs a lot of ecosystem because none of the packages work together, and the language is slow so you have to make sure you are doing as much work as possible outside the language itself. To answer your question more specifically:

Numpy -> Array + broadcasting (both in Julia Base)

pytoch/tf -> Flux.jl (package)

batch/stream processing -> you don't need it as much, but things like OnlineStats exist. Also Base has multithreaded and distributed computing. Spark in particular is one where it lets you use a cluster of 100 computers to be as fast as 1 computer running good code.

pyarrow -> Arrow.jl (there's also really good packages for JSON, CSV, HD5 and a bunch of others)

Let me know if you have any other questions. Always glad to answer!

Post reply on HN