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

221–230 of 291 posts

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

#221

Post by cookieater »

Vetch wrote: post #121
Der_Einzige wrote: post #56

Earlier quoted context omitted.

This is why I find it so annoying that CS programs seem to worship functional programming (at least MY program did!). No, I AM going to write procedural code, and it WILL be faster than your "high IQ" 1 line recursive solution. Also funny to see how little recursion gets used in CUDA/Pytorch/GPU programming - which is what we are seeing to be more and more important over time.

Functional programming is a lot more than just recursion and there's nothing about GPUs that precludes an immutable first array based language with functional programming as core. Google Research's Dex is an example.

Speaking of functional programming and GPU's - check out Futhark :D. Very on the fringe but very interesting.

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

#222

Post by tfehring »

chaxor wrote: post #158
fault1 wrote: post #113

Earlier quoted context omitted.

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

I agree, but it's probably closer to 20 years IMO, which makes sense given that Python has been around for 21 years longer. By 2009 Python was already in widespread use at Google/YouTube and (I think) Mozilla, plus startups like Reddit and Dropbox. Hell, Steve Huffman wrote "Lots of people have written web applications in Python, and there's plenty of code from which to learn" as one justification for Reddit's Python rewrite in 2005 [0]. No one is saying that about Julia today, it's seeing very little use in the private sector at this point.

[0] http://web.archive.org/web/20051230163903/http://reddit.com/...

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

#223

Post by sigzero »

oefrha wrote: post #117
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.

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

That was my first thought in reading the "JavaScript backend" thing.

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

#224

Post by cookieater »

freemint wrote: post #196
laichzeit0 wrote: post #148

Earlier quoted context omitted.

Let’s not ignore the giant elephant in the room: 1-based indexing. I don’t particularly care since I use R and Python but Java, C, C/C++, C# all used 0-based indexing. It’s truly a bizarre choice Julia made there.

You can turn any 1 based array into a 0 based array using a wrapper type that just gets inlined away. Also have a look at https://github.com/giordano/StarWarsArrays.jl

Mose Giordano hit the nail on the head with this one. Who cares about 1 vs 0 based indices? If anything its a silly and minor design decision.

I worry about someones ability to solve real problems in any language if they can't get their head around an +1/-1 when indexing into an array.

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

#225

Post by pm90 »

joconde wrote: post #183
mbeex wrote: post #179

Earlier quoted context omitted.

Indeed it is (slight improvements not excluded). I would love to be able to write things like M T A (w/o the HTML rubbish seen here - flavour of the same problem) for two matrices directly as code (can Julia do that?). Instead, I've been forced to learn row and column precedence in OpenGL, DirectX, Numpy, and whatever, paying attention to it in endless constructs. Even after 25 years in the business, it's still a pai…

What about everything that isn't yet represented by widely-adopted mathematical notation? I'd hate to have to learn which Greek letters correspond to which operations every time I dive into a new codebase. The advantage of English words is that everyone knows them. Edit for details: `Σλ∀φ` is a chore to read for me. These letters only make sense if I've absorbed the author's notation beforehand, like in a math proof.…

This is a valid question. Others have provided a much better answer, the thing I want to add is that being able to express computation in software the same way as in research papers makes the code much easier to read and reason about. This language was invented a long time ago to express computations concisely, and today you will see a lot of math built on top of these abstractions (since they’ve been around for sooo long).

So the ability to express computation in standard mathematical notation rather than having to invent pseudo symbols to do it makes it much easier to read for people who already have that training. And for people who don’t… it does require pre-reading to understand how these symbols are used but you have the benefit for hundreds of years of math literature and community to look it up!

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

#226

Post by pm90 »

tfehring wrote: post #220
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.

Does keeping as much of the codebase as possible in Python (or keeping the fast parts in C++) actually make things easier for the userbase, or do they just care about having a first-class interface in Python regardless of the implementation language?

Almost certainly the latter. Python excels in this because it’s really easy to learn, so non python libraries provide python functions that you can call which may not be implemented in pure python.

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

#227

Post by ChrisRackauckas »

nothrowaways wrote: post #202

Why not go? Go beats Julia in parts where python is not good at. Is it because fb vs Google?

>Go beats Julia in parts where python is not good at.

I have not seen good results from differential equation solvers in Go.

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

#228

Post by dragonwriter »

dnautics wrote: post #103
dragonwriter wrote: post #73

Earlier quoted context omitted.

> You can't dismiss the fact that hiring python is hard. I deny that hiring Python is hard beyond “hiring is hard”. > You think you're getting a good programmer, because they know all the leetcode tricks, Unless I want someone for a role that is very much like reproducing leetcode tricks, I don't think I would think someone is good for it because they are good at those. In fact, leetcode is mercilessly mocked as bein…

Do you have absolute control over the hiring of every person you work with? Not all of us do.

> Do you have absolute control over the hiring of every person you work with?

That's...a complete topic switch and irrelevant. The discussion I was responding to is about the challenges facing whoever does have control.

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

#229

Post by sgt101 »

xbpx wrote: post #46
RemoteControlr wrote: post #33

Earlier quoted context omitted.

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.

This is really useful when relating Julia code to a paper or providing it as part of a paper - there is very little lost in translation.

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

#230

Post by jkhdigital »

fault1 wrote: post #208
Tarq0n wrote: post #130

Earlier quoted context omitted.

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.

Completely disagreed. I was skeptical originally, because I wasn't used to seeing unicode symbols in code, but in certain types of mathematical code, it makes it /far/ clearer because your brain can link to the appropriate symbols in textbooks. To me, it's a matter of familiarity. clearly human brains can process large amount of symbols. Just look at some east asian languages. Historically, there has been an ASCII bi…

To your point, for personal projects in Elixir I’ve started using Japanese characters for function names because they can be so much more terse.
Post reply on HN