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

71–80 of 291 posts

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

#71

Earlier quoted context omitted.

Real world code rarely uses recursion, and if it does it's the kind that doesn't allow tail call optimization.

I've been using FP strategies for around thirty years, so pardon me if I don't find confidence in your perspective.

Your case is covered by the "rarely" word in my comment.

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

#72
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…

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.

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

#73

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.

> 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 being almost completely irrelevant as a positive signal for hiring, though it may be useful as a filtering tool to reduce an overwhelming volume of applicants to a manageable one where high rates of both false negatives and false positives, but some slight advantage over just randomly discarding applicants, is tolerable.

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

#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 lifting?

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

#75

Earlier quoted context omitted.

I would say that those are not bad languages. People are just elitist and think if your language isn’t strictly typed, functional and gives first year CS students a headache it’s a bad language and “creates spaghetti code.” The only thing wrong with dynamic typing is it’s slower and is harder to debug, but people are able to be way more productive in these languages you call bad.

> The only thing wrong with dynamic typing is it’s slower and is harder to debug, but people are able to be way more productive in these languages you call bad. Not even close to "only thing". Dynamic language is a net loss of productivity once you reach a certain level of scale. Refactoring a codebase with millions of lines of code in a dynamic language is an absolute nightmare. Opinions vary at what level of scale…

It's not just Python, Julia is dynamically typed too.

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

#76
post #75

Earlier quoted context omitted.

> The only thing wrong with dynamic typing is it’s slower and is harder to debug, but people are able to be way more productive in these languages you call bad. Not even close to "only thing". Dynamic language is a net loss of productivity once you reach a certain level of scale. Refactoring a codebase with millions of lines of code in a dynamic language is an absolute nightmare. Opinions vary at what level of scale…

It's not just Python, Julia is dynamically typed too.

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

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

#77

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 addressed by the community.

I switch languages a lot and things like functools, itertools, dunder methods, list comprehensions, dict comprehensions are things I sorely miss especially in typescript. In particular list and dict comprehensions when used with care are a great deal easier to work with and reason about when transforming data.

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

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

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

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

#79
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…

[deleted]

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

#80

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.

Someone wanting to promote a new language could wrap Python as a growth hack.
Post reply on HN