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

81–90 of 291 posts

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

#81

Post by fault1 »

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

I would say the almost every version of Julia 1.x has better in terms of code startup.

as in 1.7 > 1.6 > 1.5 > 1.4 > 1.3 > etc...

it's especially goten way better since julia 1.5, so really mostly in the last few years.

In julia 1.8, what's interesting to me is that the julia runtime will be separated from the llvm codegen; https://github.com/JuliaLang/julia/pull/41936

the immediate effect is to allow small static binaries without a huge runtime (namely the LLVM ORC), but the side effect is probably that the interpreter will also get better in cases where you don't want JIT.

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

#82

Post by jstx1 »

71a54xd wrote: post #74

I was surprised when browsing PaperSpace.com (a gpu host for ML training) that Fast.AI is now considered a "legacy" software? I've built a few small classifiers / ML projects but not really enough to really branch out of an intermediate tutorial. With how quickly these frameworks change it's overwhelming to keep pace! Anyone have advice for solid frameworks that can reasonably leverage GPU's without too much heavy li…

Keras is integrated into TensorFlow and it's as solid and easy as it gets if you need a high level API for deep learning. If you need to write your own modules PyTorch is probably a better choice.

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

#83

Post by ummonk »

freemint wrote: post #13
adenozine wrote: post #5

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

I've never seen recursive looping over a thing get turned into efficient SIMD code in any language. Starting with loops has no good reason to be better able to achieve that but for practical compilers it makes a huge difference. Julia code might also uses a lot of in place operations which would be hard for a compiler to infer as safe.

And functional paradigms have a way to express looping over a thing that's much better than recursion: filter / map / reduce.

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

#84

Post by jreese »

dnautics wrote: post #52
jreese wrote: post #47

Earlier quoted context omitted.

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

> Why are you hiring for language skills rather than problem solving aptitude and conceptual fundamentals? All I'm saying is that signal to noise for the common tests you give for 'problem solving aptitude and conceptual fundamentals', is much lower when you are hiring for a python position. You think you're hiring for those things, but you're actually hiring for leetcode-optimizers. I mean, I'm not trying to do hire…

> when you are hiring for a python position

If you instead hire for "engineering" positions, without caring about what languages the candidate knows, you can interview for their ability to solve practical programming exercises [1] in whatever language they are most familiar/comfortable with. Maybe this only works at FAANG-level hiring, but in these contexts, top tier candidates can get things done in any language, and that's really what matters, no? But more to your point, I've generally found candidates that pick Python (or Ruby/Perl/etc) can actually accomplish more–and therefore prove their capabilities–in the space of an interview simply because they're picking a more expressive language. Bad candidates will prove they are bad candidates no matter what language they choose.

1: Eg, reading/manipulating files, merging/filtering/sorting data, generating and processing multi-dimensional data structures, etc.

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

#85

Post by yakubin »

doliveira wrote: post #7
adenozine wrote: post #5

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)

Actually, I've recently watched a talk by Guy Steele where he makes a case for tail call elimination being essential for object orientation: https://www.youtube.com/watch?v=0hlBkQ5DjaY>. He demonstrates how tail call elimination enables better separation of concerns, allowing you to write code where objects don't need to "peek" into one another.

Another non-functional application of tail call elimination is finite state machines. Writing them as functions calling the next state in tail call position is very elegant, legible and efficient.

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

#86

Post by creata »

adenozine wrote: post #5

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

Tail calls and while loops are essentially equivalent, so why care whether a language prefers one or the other?

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

#87

Post by fault1 »

edgyquant wrote: post #44
stabbles wrote: post #2

What stage of Julia denial is this?

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.

Personally, I think when you write Julia in shorthand form, it looks nothing like ruby or basic.

for example, check out parts of the stdlib: https://github.com/JuliaLang/julia/blob/master/base/operator...

but in the end, julia really is a lisp: https://www.youtube.com/watch?v=dK3zRXhrFZY

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

#88

Post by AstroDogCatcher »

jstx1 wrote: post #62
edgyquant wrote: post #48

Earlier quoted context omitted.

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

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

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

#89

Post by de6u99er »

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…

I think Python is great for exploration and method development, while I would prefer something more efficient like Julia for production systems. On the other hand, Julia requires compilation while Python allows open-heart surgery on the production system (for the masochists among us).

I personally don't like Python that much because every library does things differently and sometimes it feels like learning a completely new (sub) language. E.g. NumPy DataFrames allow to do the same thing in multiple ways (e.g. adding an index column, or removing a column). Often when I need to look up how to do a particular thing I end up finding many solutions that simply don't function with the version I am working with. Sometimes looking even into old code of mine doesn't work any more and requires either me using an older library of relearning how to do things.

That being said, a friend of mine has been quite fond of Julia lately. Which put Julia on the top of my list of programming languages to do a deep dive.

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

#90

Post by yakubin »

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…

Julia is designed with interactive use and REPL in mind. Java is designed with enterprise software written by large teams and IDEs in mind. The first one, among other things, leads to valuing terseness. The seconds leads to valuing verbosity. I wouldn't want to deal with the usual Java boilerplate in an interactive session.
Post reply on HN