TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

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

265 点作者 thetwentyone超过 3 年前

14 条评论

xbpx超过 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.<p>Rust has been eating C++ lunch. Same rapid rise of ecosystem story.<p>Instead of forcing Python to be a language it isn&#x27;t it might be more efficient and ultimately the &quot;right choice&quot; to invest the time in Julia.<p>Julia is great for numerical computing, it needs faster time to plot and more hands in the ecosystem. The former will be solved and the latter seems inevitable to me. Pitch in!
评论 #29355467 未加载
评论 #29355997 未加载
评论 #29356234 未加载
评论 #29356370 未加载
评论 #29355566 未加载
评论 #29355407 未加载
评论 #29355437 未加载
评论 #29359120 未加载
评论 #29356133 未加载
FridgeSeal超过 3 年前
This seems so silly to me.<p>It’s PyTorch-if they said “the next version of PyTorch will be in Julia, the ecosystem would shift accordingly.<p>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”
评论 #29356432 未加载
评论 #29356584 未加载
评论 #29356697 未加载
jszymborski超过 3 年前
I&#x27;ve been thinking a lot about trying to use functional dialect of Python like Coconut[0] and Hy[1] w&#x2F; JAX so I can write functional DL code.<p>Glad to see functorch[3] as PyTorch is the library I have the most experience with.<p>[0] <a href="http:&#x2F;&#x2F;coconut-lang.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;coconut-lang.org&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;docs.hylang.org&#x2F;en&#x2F;alpha&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.hylang.org&#x2F;en&#x2F;alpha&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;jax" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;jax</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;pytorch&#x2F;functorch" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pytorch&#x2F;functorch</a>
评论 #29413070 未加载
评论 #29364926 未加载
pilooch超过 3 年前
Loving pytorch but the reasoning remains strange to my ears: Python at all cost, not Julia, because of the ecosystem, well OK.<p>But all bullet points are about things that are easily done right now with libtorch (pytorch underlying C++ core code), and the hassle is... Python.<p>Well rational conclusion would be, just do everything in C++, and bind to Python. Make C++ first citizen here, since in all cases it&#x27;ll be needed for performance, forever.
评论 #29359947 未加载
评论 #29359416 未加载
forrestthewoods超过 3 年前
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).<p>It’d be interesting to see how much of the Python ecosystem is actually necessary to move PyTorch to a better language.<p>I’m afraid we’re stuck with Python for the next 20 years. That makes me very, very sad.
评论 #29355434 未加载
评论 #29356108 未加载
评论 #29355370 未加载
评论 #29355749 未加载
评论 #29355346 未加载
评论 #29355448 未加载
评论 #29355278 未加载
评论 #29356146 未加载
geofft超过 3 年前
&gt; <i>Julia says:</i><p>&gt; <i>A language must compile to efficient code, and we will add restrictions to the language (type stability) to make sure this is possible.</i><p>&gt; <i>A language must allow post facto extensibility (multiple dispatch), and we will organize the ecosystem around JIT compilation to make this possible.</i><p>&gt; <i>The combination of these two features gives you a system that has dynamic language level flexibility (because you have extensibility) but static language level performance (because you have efficient code)</i><p>Given those constraints, the first language that comes to mind is Java. Why is Java basically not a player in the scientific-computing game?
评论 #29356904 未加载
评论 #29355474 未加载
评论 #29355902 未加载
评论 #29355689 未加载
评论 #29355452 未加载
评论 #29356235 未加载
评论 #29355801 未加载
评论 #29357830 未加载
stabbles超过 3 年前
What stage of Julia denial is this?
评论 #29355372 未加载
评论 #29355670 未加载
评论 #29357335 未加载
opus111超过 3 年前
Why do people keep claiming that Julia&#x27;s ecosystem is limited? Julia can use all of Python&#x27;s libraries. They all work great. No need to reimplement in Julia, just use PyCall and your favorite Python code.
streamofdigits超过 3 年前
It feels a risky proposition at this juncture to go short python. The arguments against&#x2F;for have been rehashed a million times, the redeeming features of julia have been articulated very cogently...<p>What has not been accounted for is that the huge community &#x2F; network effect of the python ecosystem is very far from exhausting itself. If anything, it is just starting as the exponential growth has mostly been the last few years (tautology, he he)<p>A major investment to eliminate python technical debt would make more sense if things were stagnant and the re-engineering would open up entirely new domains.
cookieater超过 3 年前
I&#x27;ve used Julia for quite a few years now. It&#x27;s biggest flaws in my opinion are basically cultural and not technological. It&#x27;s been adopted mostly by serious domain experts rather then typical software engineers and more &#x27;normal&#x27; people. I don&#x27;t know say junior or senior scientists. This has lead to amazing results but also has it&#x27;s own detriments.<p>Some portions of the ecosystem are rock solid, especially the parts where JuliaComputing makes money from consulting(not all but some). Other parts are beds of sand&#x2F;permanent research projects. The median experience is usually someone points you to a package and it doesn&#x27;t really do what you hoped it would so you end up adapting it and rolling your own solution to a problem. Maybe you try to make a PR and it gets rejected because of &quot;not invented here&quot;&#x2F;academia mindsets, either way you made a fix and your code works for you.<p>What makes this barrier hard to overcome for adoption is: trust, and blind spots. People who aren&#x27;t experts in a casual work area (maybe computer vision) realize they can&#x27;t use a tool to do something `basic` and run away to easier ecosystems(R&#x2F;Python). People who are experts in other areas, check credentials of packages see that an ivy league lead researcher made it and assumes it&#x27;s great and usable for a general audience. So you&#x27;ll get a lot of &quot;there&#x27;s a package for that&quot; but when you go to use it you might find the package is barren for common and anticipatable use cases in industry (or even hobbies).<p>This makes Julia best positioned as a research tool, or as a teaching tool. Unfortunately - where Julia actually shines is as a practical tool for accomplishing tasks very quickly and cleanly. So there&#x27;s this uncomfortable mismatch between what Julia could be and what it&#x27;s being used for today. (yes Julia can do both not arguing against it). The focus on getting headlines far outsurpasses stable useful stuff. Infact, very often after a paper gets published using Julia, a packages syntax will completely change - so no one really benefits except for the person who made the package.<p>Interestingly, 1 person(with some help of course) fleshed out the majority of the ecosystems need for interchange format support(JSON), database connections, etc. It&#x27;s not like that person is jobless spending all their days doing it - it was a manageable task for a single smart person to kick off and work hard to accomplish. Why? Because Julia is amazing for quickly developing world class software. That is also kind of its detriment right now.<p>Because its so easy to create these amazing packages you&#x27;ll find that a lot of packages have become deprecated or are undocumented. Some researcher just needed a 1 off really quickly to graduate, maybe the base language(or other parts of the ecosystem) changed many times since its release. Furthermore, if you try to revitalize one of these packages you&#x27;ll sometimes find a rats nest of brilliance. The code is written very intelligently, but unpacking the design decisions to maintain world class performance can be prickly at best.<p>One of Julia&#x27;s strengths is it&#x27;s easy&#x2F;clean to write fast enough code. One of its downsides is, this attracts people who focus on shaving nanoseconds from a runtime (sometimes needlessly) at the expense of (sometimes) intense code complexity. Performance is important, but, stable and correct features&#x2F;capabilities mean more to the average person. After-all, this is why people use, pay for, hire for: Matlab, Python and R in the first place - right?<p>Most people don&#x27;t want to have to figure out which ANOVA package they should use. Or find out in a bad way some weird bug in one of them and be forced to switch. Meanwhile in R: aov(...).<p>Do I blame Torch for not using Julia? No. Should they consider using it? Yes, absolutely. Does Julia&#x27;s cultural issue need attention before risking Python(or anything else) reinventing a flavor of Julia that&#x27;s more widely used for stability reasons alone - in my opinion, yes (see numba, pyjion, etc). Still love the language, because technologically it&#x27;s sound, but there are blemishes. I&#x27;d chalk it up to growing pains.
评论 #29361161 未加载
71a54xd超过 3 年前
I was surprised when browsing PaperSpace.com (a gpu host for ML training) that Fast.AI is now considered a &quot;legacy&quot; software? I&#x27;ve built a few small classifiers &#x2F; ML projects but not really enough to really branch out of an intermediate tutorial.<p>With how quickly these frameworks change it&#x27;s overwhelming to keep pace! Anyone have advice for solid frameworks that can reasonably leverage GPU&#x27;s without too much heavy lifting?
评论 #29356360 未加载
评论 #29356151 未加载
adsharma超过 3 年前
I&#x27;m surprised that no one brought up using a subset of python with an emphasis on static typing, efficiency and transpilation can give you both the ecosystem and the efficiency.
评论 #29371641 未加载
adenozine超过 3 年前
Neither language have proper tail call elimination, which, is absolutely insane to me.<p>Yall really just write procedural code for everything?
评论 #29355316 未加载
评论 #29356408 未加载
评论 #29355378 未加载
评论 #29355387 未加载
评论 #29356216 未加载
评论 #29356296 未加载
评论 #29355469 未加载
评论 #29355891 未加载
评论 #29355338 未加载
评论 #29357231 未加载
nothrowaways超过 3 年前
Why not go? Go beats Julia in parts where python is not good at. Is it because fb vs Google?
评论 #29360520 未加载
评论 #29360803 未加载
评论 #29361007 未加载