Earlier quoted context omitted.
> 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, an…
PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
101–110 of 291 posts
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#102Java 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)
#103Earlier quoted context omitted.
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 bein…
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#104Java 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 don't know, x being a potential replacement for y doesn't say all that much. You could have been writing Java or C++ for the past 25 years and got loads of stuff done, solved problems, shipped software, made money etc. Languages are fun to think about but you don't always need to be concerned with every vocal minority of programmers that like to talk about how their language is better than yours. Sometimes that rep…
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#105This 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.
Soumith Chintala had a keynote talk in juliacon where he focused on these points; https://www.youtube.com/watch?v=6V6jk_OdH-w
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#106This 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”
Another issue is pytorch/tf in python are very dominant in research/projects. Often we clone relevant recent projects and try experimenting with them to see if they help. Swapping to Julia would hurt a ton in that area.
edit: Also while I'm fond of python I'd be very open to seeing another language win. There are language design choices I dislike in python, but I like enough of the language and ecosystem as been too strong to leave most other languages worth pondering. If Julia grows enough that my coworkers start asking for Julia support I'd be happy to explore it. My pet preferred language is crystal (ruby like readability + types + good performance) but ecosystem wise it's tiny.
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#107This 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…
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#108Earlier quoted context omitted.
Could you point to it? Thanks
Here is one: https://github.com/TakekazuKATO/TailRec.jl It works by inspecting the code and rewriting a function to turn tail calls into loops. The interesting bit is that it was very easy to write because of the strong macros in Julia.
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#109Earlier 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.
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#110The 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.