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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Correctness and composability bugs in the Julia ecosystem

699 点作者 benjojo12大约 3 年前

47 条评论

KenoFischer大约 3 年前
So this one is a tough one for me, because Yuri has certainly spent significant time with Julia and I think he&#x27;s a very competent programmer, so his criticism is certainly to be taken seriously and I&#x27;m sad to hear he ended up with a sour opinion.<p>There&#x27;s a lot of different issues mentioned in the post, so I&#x27;m not really sure what angle to best go at it from, but let me give it a shot anyway. I think there&#x27;s a couple of different threads of complaints here. There&#x27;s certainly one category of issues that are &quot;just bugs&quot; (I&#x27;m thinking of things like the HTTP, JSON, etc. issues mentioned). I guess the claim is that this happens more in Julia than in other systems. I don&#x27;t really know how to judge this. Not that I think that the julia ecosystem has few bugs, just that in my experience, I basically see 2-3 critical issues whenever I try a new piece of software independent of what language it&#x27;s written in.<p>I think the other thread is &quot;It&#x27;s hard to know what&#x27;s expected to work&quot;. I think that&#x27;s a fair criticism and I agree with Yuri that there&#x27;s some fundamental design decisions that are contributing here. Basically, Julia tries very hard to make composability work, even if the authors of the packages that you&#x27;re composing don&#x27;t know anything about each other. That&#x27;s a critical feature that makes Julia as powerful as it is, but of course you can easily end up with situations where one or the other package is making implicit assumptions that are not documented (because the author didn&#x27;t think the assumptions were important in the context of their own package) and you end up with correctness issues. This one is a bit of a tricky design problem. Certainly adding more language support for interfaces and verification thereof could be helpful, but not all implicit assumptions are easily capturable in interfaces. Perhaps there needs to be more explicit documentation around what combinations of packages are &quot;supported&quot;. Usually the best way to tell right now is to see what downstream tests are done on CI and if there are any integration tests for the two packages. If there are, they&#x27;re probably supposed to work together.<p>To be honest, I&#x27;m a bit pained by the list of issues in the blog post. I think the bugs linked here will get fixed relatively quickly by the broader community (posts like this tend to have that effect), but as I said I do agree with Yuri that we should be thinking about some more fundamental improvements to the language to help out. Unfortunately, I can&#x27;t really say that that is high priority at the moment. The way that most Julia development has worked for the two-ish years is that there are a number of &quot;flagship&quot; applications that are really pushing the boundary of what Julia can do, but at the same time also need a disproportionate amount of attention. I think it&#x27;s overall a good development, because these applications are justifying many people&#x27;s full time attention on improving Julia, but at the same time, the issues that these applications face (e.g. - &quot;LLVM is too slow&quot;, better observability tooling, GC latency issues) are quite different from the issues that your average open source julia developer encounters. Pre 1.0 (i.e. in 2018) there was a good 1-2 year period where all we did was think through and overhaul the generic interfaces in the language. I think we could use another one of those efforts now, but at least that this precise moment, I don&#x27;t think we have the bandwidth for it. Hopefully in the future, once things settle down a bit, we&#x27;ll be able to do that, which would presumably be what becomes Julia 2.0.<p>Lastly, some nitpicking on the HN editorialization of the title. Only of the issues linked (<a href="https:&#x2F;&#x2F;github.com&#x2F;JuliaLang&#x2F;julia&#x2F;issues&#x2F;41096" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;JuliaLang&#x2F;julia&#x2F;issues&#x2F;41096</a>) is actually a bug in the <i>language</i> - the rest are various ecosystem issues. Now, I don&#x27;t want to disclaim responsibility there, because a lot of those packages are also co-maintained by core julia developers and we certainly feel responsibility to make those work well, but if you&#x27;re gonna call my baby ugly, at least point at the right baby ;)
评论 #31401814 未加载
评论 #31400647 未加载
评论 #31401490 未加载
评论 #31408519 未加载
评论 #31400518 未加载
ChrisRackauckas大约 3 年前
Everything has correctness issues somewhere. Julia ships an entire patched version of LLVM to fix correctness bugs in numerical methods. It has its own implementations of things like software-side FMA because the FMA implementation of Windows is incorrect: <a href="https:&#x2F;&#x2F;github.com&#x2F;JuliaLang&#x2F;julia&#x2F;pull&#x2F;43530" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;JuliaLang&#x2F;julia&#x2F;pull&#x2F;43530</a> . Core Julia devs are now the maintainers of things like libuv because of how much had to be fixed there. So from those three points, that clearly points out tons of cases where Python, R, etc. code is all incorrect where Julia isn&#x27;t.<p>I think what&#x27;s interesting about Julia is that because the code is all Julia, it&#x27;s really easy to dig in there and find potential bugs. The standard library functions can be accessed with @edit sum(1:5) and there you go, hack away. The easier it is to look at the code, the easier it is to find issues with it. This is why Julia has such a higher developer to user ratio. That has its pros and cons of course. It democratizes the development process, but it means that people who don&#x27;t have a ton of development experience (plus Fortran or C knowledge) are not excluded from contributing. Is that good or bad? Personally I believe it&#x27;s good in the long run, but can have its bumps.<p>As an aside, the author highlights &quot;for i in 1:length(A)&quot;. I agree, code should never do that. It should be `eachindex(A)`. In general things should use iterators which are designed for arbitrary indexing based on iterators. This is true in any language, though you&#x27;ll always have some newcomers write code (and documentation) with this. Even experienced people who don&#x27;t tend to use arrays beyond Array tend to do this. It&#x27;s an interesting issue because coding style issues perpetuate themselves: explicitly using 1-base wasn&#x27;t an issue before GPUs and OffsetArrays, but then loop code like that trains the next generation, and so more people use it. In the end the people who really know to handle these cases are the people who tend to use these cases, just like how people who write in styles that are ARM-safe tend to be people who use ARM. Someone should just run a bot that opens a PR for every occurrence of this (especially in Base), as that would then change the source that everyone learns from and completely flip the style.
评论 #31401925 未加载
评论 #31400434 未加载
评论 #31397787 未加载
评论 #31399713 未加载
评论 #31398685 未加载
评论 #31399954 未加载
评论 #31400373 未加载
评论 #31400643 未加载
评论 #31400227 未加载
评论 #31398705 未加载
评论 #31398588 未加载
ninjin大约 3 年前
I am a long-time member of the Julia community and had a discussion with the author about these issues a long time ago – but did not give feedback on the post. Let me first state that Yuri is a great person and was a valuable member of the community. He pushed the boundaries of the language and produced some very nice packages in his time. His concerns are genuine and should be respected and discussed in that context.<p>Also, let me say that encountering these kinds of bugs is not something I have had experience with. <i>But</i>, I tend to be very conservative with my usage of libraries and fancy composition.<p>If I had more experience with programming language theory and implementation, perhaps I would have a better name to describe the source of the issues described. My attempt is to call it “type anarchy”. The way I see it, there is not a clear way to assign responsibility for correctness. In the case of the array used in the post, is it the fault of the implementer of the `sum` function (without a type signature, as it should be) or implementer of the data structure? I am honestly not sure. But as Julia breaks news ground with its type system and multiple dispatch, this could very much be an open question.
QuackingTheQ大约 3 年前
I&#x27;ve spent a lot of time developing large computational codebases in Julia, and I think the most insidious of these issues is a product of no formal way of enforcing interfaces. Using one of the common packages to build a trait system and add some sort of guarantee that all the right methods are implemented for a given trait simplifies maintenance dramatically.<p>This doesn&#x27;t catch mathematical bugs, but those crop up everywhere. Instead, knowing what the interfaces must be specified so you can trust your implementation is crucial, and being able to know when it is invalidated is invaluable.<p>I&#x27;ve had a few awful bugs involving some of the larger projects in this language, but a proper interface&#x2F;trait system would simplify things exponentially. There are some coding style things that need to be changed to address this, like using `eachindex` instead of `1:length(A)` for array iteration as the example in the article points out. However, these should be one-off lessons to learn, and a good code linter should be able to catch potential errors like this.<p>Between a good code linter (or some static analysis, I&#x27;m pulling for JET.jl) and a formal interface spec, I really think most of Julia&#x27;s development-side issues could be quelled.
评论 #31398362 未加载
评论 #31398032 未加载
one-more-minute大约 3 年前
It might be useful to separate the issues that are &quot;just&quot; bugs from the problems that come with Julia&#x27;s unusual level of composability. I have no idea if Julia has more bog-standard, local bugs – things like data structure problems or compiler faults – than other languages of comparable maturity and resources, but clearly the OP has bumped into several, which is frustrating.<p>The composition bugs – as in offsetarrays or AD – are a bit of a special case. In most languages package A will only work with package B if it&#x27;s specifically designed to, and the combination will be explicitly developed and tested. That A and B <i>can</i> work together by default in Julia is really cool, but it also means that as you add new types and packages, you have a quadratically growing set of untested edges.<p>The canonical solution is strict interfaces. But Julia is laissez faire about those too (with some good reasons). Together this means that if A doesn&#x27;t work with B as expected, it&#x27;s not always easy even to assign fault, and both might be reluctant to effectively special-case the other. Program transformations (autodiff) compound this problem, because the default is that you promise to support the universe, and it&#x27;s not easy to opt out of the weird cases.<p>I think it&#x27;s absolutely right to celebrate Julia&#x27;s approach to composition. I also hope new research (in Julia or elsewhere) will help us figure out how to tame it a bit.
评论 #31398332 未加载
评论 #31398142 未加载
Sukera大约 3 年前
Most of these seem to be about packages in the ecosystem (which, after clicking through all links, actually almost all got fixed in a very timely manner, sometimes already in a newer version of the packages than the author was using), not about the language itself. Other than that, the message of this seems to be &quot;newer software has bugs&quot;, which yes is a thing..?<p>For example, the majority of issues referenced are specific to a single package, StatsBase.jl - which apparently was written before OffsetArrays.jl was a thing and thus is known to be incompatible:<p>&gt; Yes, lots of JuliaStats packages have been written before offset axes existed. Feel free to make a PR adding checks.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;JuliaStats&#x2F;StatsBase.jl&#x2F;issues&#x2F;646#issuecomment-766756335" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;JuliaStats&#x2F;StatsBase.jl&#x2F;issues&#x2F;646#issuec...</a><p>EDIT: Since this comment seems to gain some traction - title is editorialized, original is &quot;Why I no longer recommend Julia&quot;.
评论 #31400024 未加载
jbezanson大约 3 年前
I&#x27;m not sure what to make of this. Yuri is great and I&#x27;ll certainly miss having him in the Julia community. Yes, of course there are bugs. We work on fixing them all the time. If there are just too many for you, or we are too slow at fixing them for you, then OK I understand you might walk away.<p>With these kinds of posts (and the reactions to them) lots of issues tend to get conflated. For example there are issues with OffsetArrays because some people write code assuming indexes start at 1. Starting at 0 wouldn&#x27;t fix that. A static type system wouldn&#x27;t fix that; most static type systems don&#x27;t check array bounds. Are we supposed to un-register the OffsetArrays package? Should we disallow overloading indexing? Personally I have told people not to use `@inbounds` many times. We could remove it, but those who want the last drop of performance would not be too happy. The only path I see is to fix the bugs.<p>&gt; They accept the existence of individual isolated issues, but not the pattern that those issues imply.<p>I admit, I do not see the pattern allegedly formed by these issues. Of course, static types do remove a whole category of issues, but &quot;switch to static types&quot; is not really a practical request. There are other things you can do, like testing, but we do a LOT of testing. I really do not mean to downplay Yuri&#x27;s experience here, I am just not sure what to take away other than that we should work even harder on bugs and quality.
评论 #31402722 未加载
xt00大约 3 年前
If you look at the history of lots of packages in matlab they fixed tons of bugs that sound similar to this stuff over the years. It requires consistent hard work by a core group of people who understand the issues to get everything right. I have no idea who maintains Julia and these packages but the author of the article mentions this as language problems — aren’t these just bugs? Like if gcc was incorrectly multiplying some constant by the wrong value, that doesn’t sound like a bug with C but a bug with gcc right?
评论 #31399808 未加载
评论 #31397726 未加载
cs702大约 3 年前
A more appropriate title for the OP would have been:<p>&quot;A new language that makes it easy to write and use <i>generic algorithms</i> on a growing number of <i>custom types developed by others</i> is bound to experience growing pains as difficult-to-foresee correctness bugs have to be discovered and fixed over time.&quot;<p>In my humble opinion, this kind of <i>universal composability</i>, which Julia makes easy via multiple dispatch and naming conventions, is the underlying root cause of all the correctness bugs that have surfaced as the language has evolved. But the bugs are being fixed, one at a time, and ultimately the result should be both beautiful and powerful. We will be all be thankful for it!
评论 #31398940 未加载
评论 #31400367 未加载
p33p大约 3 年前
Viral frequents HN so I will be curious to see if he engages this directly in a productive manor.<p>There are many great qualities of Julia, and I&#x27;ve wanted to love it and use it in production. However, coming from the tooling and correctness of Rust leaves me thinking something is just missing in Julia. One of the links in the post references &quot;cowboy&quot; culture. While I don&#x27;t think this is the correct nomenclature, there is a sense with looking at the package ecosystem and even Julia itself that makes me think of the pressure in academia to publish constantly. I&#x27;m not sure what to make of that, and it&#x27;s simply a feeling.
评论 #31400976 未加载
评论 #31402591 未加载
rpmuller大约 3 年前
I&#x27;ve been a part of many language communities, and that the Julia team is the very best in terms of the professionalism of the language and the key modules.<p>Maybe the best response to this is to view it as a call to action for us Julia fanboys&#x2F;girls to stop cheering and fix some bugs ;-).
评论 #31398856 未加载
cwp大约 3 年前
I wonder how much of this is just that Julia is more composable than most people are used to, and the community hasn&#x27;t yet developed the patterns and culture that are needed to avoid these kinds of problems.<p>I&#x27;m thinking, for example, of the way that Smalltalkers often create parameters with type-evocative names, such as &quot;aString&quot;. Or Objective-C with two-letter prefixes to work around lack of namespaces. Or even the Java &quot;EntityAdaptorFactoryFactory&quot; design aesthetic. (Some of you will shudder, and I&#x27;m with you, but it did solve real problems that the Java world was facing.)<p>Julia is still a pretty young language, and it&#x27;s probably only recently that the ecosystem has gotten big enough to hit these problems.<p>Edit: come to think of it, one of the issues that the Java folks were dealing with was lack of composability. :-&#x2F;
freemint大约 3 年前
As a huge fan of Julia i got to fully agree. Although i would probably not &quot;no longer recommend Julia&quot; but &quot;give huge caveats when mentioning Julia&quot;. Organisations (that includes those who maintain programming language) have values Bryan Cantrill has an excellent talk on this <a href="https:&#x2F;&#x2F;youtu.be&#x2F;2wZ1pCpJUIM" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;2wZ1pCpJUIM</a> and i got to agree with the author that correctness (especially correctness under arbitary composability) is not a value that Julia teaches and instills in its users. Some Julia users care about this, some core maintainers do to (as the Pkg3 demonstrates). However there are many invocations (SafeTestSets vs Test) and stumbling blocks. I am aware of no efforts to do formal verification on Julia code. There are no good ways to move certain Run-Time to compile errors. Correctness is not a value of the Julia language. Here is the good thing though, as Bryan demonstrates in his talk, you can hire for values.
dmos62大约 3 年前
In extreme composability, it might be hard to determine where the origin of a bug is. Worse yet, when libraries start adhering and relying on the brokenness of other libraries, fixing the once minor bug isn&#x27;t enough anymore. How do you address technical debt in such situations?<p>In my mind Julia broke new ground in terms of what happens when you create an environment where such compasibility is possible. Author&#x27;s finishing thought is apt:<p>&gt; Ten years ago, Julia was introduced to the world with inspiring and ambitious set of goals. I still believe that they can, one day, be achieved—but not without revisiting and revising the patterns that brought the project to the state it is in today.
hprotagonist大约 3 年前
Ouch. That sounds all the more damning for the authors studious care to calmly describe instead of angrily rant.<p>I’ve spent too much time in research working on codebases that feel like quicksand — you never know what changing something might do!— to want to worry about that for stdlib or major package ecosystems, too.
pankgeorg大约 3 年前
I feel this post is a bit unfair and quite outdated (seems like it&#x27;s written 9-12 months ago), and I interpret his issue as a prioritization issue, not a language one. If your priorities mandate a more mature ecosystem, you should use one. The Julia ecosystem is much smaller - both in terms of people and development invested, than Python, Java or JavaScript, and still overperforms in many aspects of computing. If those aspects, where Julia is first-of-class, are not your priorities, and your fault tolerance is very low, maybe another tool is better for you.<p>Also, as every ecosystem, the Julia Ecosystem will naturally see some packages come and go. JSON3 is the third approach to reading JSON (and it&#x27;s terrific). HTTP.jl is the reference HTTP implementation - Julia hasn&#x27;t had it&#x27;s `requests.py` moment. Web frameworks have also been immature, python has had `Django`, `pyramid`, `flask` and so many others before `FastAPI` (along with new language features) came and dominated. Some people need to put effort in attempts that will naturally hit a dead end before we have a super polished and neat FastAPI.jl, and the same goes for everything.<p>Also, <a href="https:&#x2F;&#x2F;github.com&#x2F;JuliaLang&#x2F;julia&#x2F;issues&#x2F;41096" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;JuliaLang&#x2F;julia&#x2F;issues&#x2F;41096</a> is referenced with a wrong name that involves the issue&#x27;s author&#x27;s misunderstanding, can you update please and, if possible, add a note about the edit?
catchclose8919大约 3 年前
Only thing &quot;interesting&quot; to me there would be the <i>automatic differentiation bugs</i> ...but is there any argument as to them being the fault of the language, instead of just poor engineering from the library developers&#x27; part?<p>I mean, one can&#x27;t expect all algorithms to work correctly with all datatypes just because the compiler allows that code to run ...<i>you write tests and guarantee numerical stability for a small subset of types you can actually do it for, and then it&#x27;s the code&#x27;s consumers&#x27; job to ensure it work with types it&#x27;s not documented to work and such, no?</i> ...Julia is quite a dynamic language, JITed or what not, its semantics are closer to Python and Lisp than to Rust or Haskell ...maybe don&#x27;t expect guarantees that aren&#x27;t there and just code more defensively when making libraries others depends on?<p>Probably the Python + C(++) ecosystems works better bc their devs know they are working in loose, dynamic and weekly typed shoot-your-foot-off type languages and just take action and code defensively and test things properly, whereas Julia devs expect the language to give them guarantees that aren&#x27;t there.
评论 #31397289 未加载
isaacimagine大约 3 年前
So it seems Julia&#x27;s multiple dispatch (dynamic dispatch for any function based on argument types) has a flaw: namely, if the types used do not match assumptions present in the implementation of the function (e.g. arrays start at 1), the results may be silently incorrect. Julia&#x27;s multiple dispatch is really cool, but I&#x27;m not sure how this issue can be prevented in practice (without a lot of added verbosity). It&#x27;d be a pity to have to restrict yourself to a small set of types you know work with the functions you&#x27;re using, because multiple dispatch is one of Julia&#x27;s killer features.
randyzwitch大约 3 年前
Not specific to specific examples in the article, I think some of the things people perceive as &quot;bugs&quot; other people see as features or an opportunity to correct past mistakes.<p>I can remember an example where I suggested automatic treatment of missing values in a stats library, and the library maintainer disagreed. Meaning, my lobbying for Julia to do what R&#x2F;Python did was seen as &quot;Yes, but that&#x27;s wrong and we shouldn&#x27;t promote that sort of treatment&quot;. As a business user, I didn&#x27;t care that it was theoretically wrong, the maintainer as an academic did.<p>That ends up becoming open-source prerogative. I could do it wrong &quot;on my own time&quot; in my own code...doesn&#x27;t make either a bug, but a different choice based on perspective.
Sporktacular大约 3 年前
This is a pity. It seems like a great language and I&#x27;d be keen to dive in more, but it seems fair to expect a math&#x2F;numerical analysis-oriented language to be especially dependable wrt correctness.<p>I remember a claim made by Mathworks about MATLAB and wondering if it wasn&#x27;t far fetched, but if true I appreciate it: &quot;A team of MathWorks engineers continuously verifies quality by running millions of tests on the MATLAB code base every day.&quot; <a href="https:&#x2F;&#x2F;www.mathworks.com&#x2F;products&#x2F;matlab&#x2F;why-matlab.html#reason7" rel="nofollow">https:&#x2F;&#x2F;www.mathworks.com&#x2F;products&#x2F;matlab&#x2F;why-matlab.html#re...</a>
评论 #31399481 未加载
ble大约 3 年前
This article contains no instances of the word &quot;test&quot;, which seems surprising but entirely in keeping with the author&#x27;s observations.<p>&gt; Julia has no formal notion of interfaces, generic functions tend to leave their semantics unspecified in edge cases, and the nature of many common implicit interfaces has not been made precise (for example, there is no agreement in the Julia community on what a number is).<p>&gt; The Julia community is full of capable and talented people who are generous with their time, work, and expertise. But systemic problems like this can rarely be solved from the bottom up, and my sense is that the project leadership does not agree that there is a serious correctness problem. They accept the existence of individual isolated issues, but not the pattern that those issues imply.<p>It sounds like the cultural standard for writing libraries is, &quot;works good enough for users like me&quot; which should be good if you are using things the same way as the authors. Writing good tests for numerics is hard and grueling; testing numerics or numerics-like code is not nearly as fun or productive-feeling as using numerics to get shit done, so it all makes sense to me.
NeutralForest大约 3 年前
I mean this looks like good potential targets to improve the language moving forward, it&#x27;s healthy to not be in awe of your tools and push to make them better. I don&#x27;t see this as &quot;bad&quot; honestly.
评论 #31397223 未加载
评论 #31397279 未加载
nohat大约 3 年前
The power of allowing everyone to make foundational types and functions that work together is indeed dangerous. I&#x27;m not sure you are better off in the even more dangerous waters of c&#x2F;c++&#x2F;fortran, except that they are older and more established with many times the man-hours sunk into them. Is there a good way to control the interaction of these many different libraries with losing the generality and composability of Julia?<p>I will say that as a matter of language design 1 based indexing is perfectly fine, 0 based indexing is perfectly fine. Choose your own indexing is a hilarious foot gun, so no surprise it went off sometimes. Fortunately using it seems to be quite rare.
评论 #31402475 未加载
dekhn大约 3 年前
Wait, are those examples real?<p>I remember complaining about 1-bsaed indexing only to be told &quot;julia is great! we have offsetindex&quot;. If it&#x27;s a source of bugs, that ... greatly reduces my future interest in adopting the language.
评论 #31398419 未加载
评论 #31399570 未加载
评论 #31397222 未加载
评论 #31398280 未加载
评论 #31397246 未加载
评论 #31397353 未加载
RcouF1uZ4gsC大约 3 年前
&gt; If you pass it an array with an unusual index range, it will access out-of-bounds memory: the array access was annotated with @inbounds, which removed the bounds check.<p>It think making indexes configurable is a huge mistake. Even if they are not ideal for the situation, having a single way to do indexes makes a huge source of confusion and potential bugs just go away. And this is orthogonal to whether you pick 0 or 1 as your starting point, as long as the whole language embraces that.<p>For example with C&#x2F;C++&#x2F;Rust, you know it is zero based indexing. Even if it is not perfectly ideal for your formulas, the mental math of translating to zero based is with not constantly having to worry about if a library is one based or zero based and what happens if you compose them.
评论 #31398472 未加载
评论 #31397334 未加载
评论 #31397858 未加载
评论 #31402905 未加载
jrochkind1大约 3 年前
&gt; Given Julia’s extreme generality it is not obvious to me that the correctness problems can be solved. Julia has no formal notion of interfaces, generic functions tend to leave their semantics unspecified in edge cases, and the nature of many common implicit interfaces has not been made precise (for example, there is no agreement in the Julia community on what a number is).<p>Does all that apply to Python? I think so? Yet apparently similar problems don&#x27;t exist in python, and even one of the examples in OP had the reporter moving to python to have no problems getting the same thing to work that was problematic in Julia.<p>In a language intended for math, I do understand the desire to have something with more formal properties suited for guarantees and such. But Python seems to be doing just fine in that domain without those features, so, I&#x27;m not sure what we should conclude here.
评论 #31403306 未加载
sharikous大约 3 年前
My opinion is that Julia was too ambitious from day one. Reimplementing the whole scientific computing stack AND a new modern language with an innovative type system and introspection AND perfecting tooling is just too big an effort.<p>The priority for correctness has been drowned out by too much other issues and we are here with a 10 years old language with a very perfectionist and ambitious mindset that is still a raw fruit in basically everything. It&#x27;s not some rough edges it&#x27;s just too many edges, most of them rough.<p>I cannot help thinking that if the same amount of people focused on a much smaller goal we could have something much more usable today. As it is now I know Julia won&#x27;t be production ready for at least 10 years. And that&#x27;s in the lucky case that it doesn&#x27;t become irrelevant in the meantime.
评论 #31402648 未加载
j7ake大约 3 年前
In terms of saving human time I have found R to be fastest (in human time) for iterative prototyping, exploring, and visualising data<p>R still has the best statistical package ecosystem, although python is catching up.
teddyh大约 3 年前
Actual title: “Why I no longer recommend Julia”.
评论 #31397998 未加载
cleandreams大约 3 年前
Unfortunately this is not a feature but a bug, and the worst kind, a bug at the language design level:<p>Basically, Julia tries very hard to make composability work, even if the authors of the packages that you&#x27;re composing don&#x27;t know anything about each other. That&#x27;s a critical feature that makes Julia as powerful as it is, but of course you can easily end up with situations where one or the other package is making implicit assumptions that are not documented (because the author didn&#x27;t think the assumptions were important in the context of their own package) and you end up with correctness issues.
评论 #31407859 未加载
cbkeller大约 3 年前
This seems hard to evaluate without a quantitative comparison to the abundance of bugs in the package ecosystems of other languages at the same age. So, for instance, how many correctness bugs existed (or, alternatively, had been found and fixed) in the Python ecosystem when Python was ten years old? The author makes a subjective claim, but from the few other languages they mention it seems they are comparing primarily to older and more stable ecosystems.
blindseer大约 3 年前
Correctness in Julia feels like it&#x27;ll never happen, because interfaces seem like they&#x27;ll never happen.<p>Correctness guarantees &#x2F; interfaces and slow startup are both my biggest pain points in Julia.<p>I often think what would happen if every Julia dev just dropped the language and used Rust instead. A scientific ecosystem in Rust would be amazing.
评论 #31402692 未加载
ModernMech大约 3 年前
&gt; OffsetArrays in particular proved to be a strong source of correctness bugs. The package provides an array type that leverages Julia’s flexible custom indices feature to create arrays whose indices don’t have to start at zero or one.<p>I always thought this sounded like a bad idea. I remember one time I was working with a C++ guy on a Matlab project, and he handed me some Matlab code with 0 based indexing assumed. I said &quot;Did you even run this code?&quot;, and he assured me he had. But of course he had not, because if he did it would have complained about the 0-based indices. But the point is that it <i>did</i> complain when I ran it, and I was able to match it to my code. I imagine in Julia he would have used 0-based indices, and I would have used 1-based, and our programs would have silently failed.
评论 #31400974 未加载
asdfman123大约 3 年前
&gt; In my experience, Julia and its packages have the highest rate of serious correctness bugs of any programming system I’ve used, and I started programming with Visual Basic 6 in the mid-2000s.<p>Oh God, is this what qualifies you as &quot;old&quot; now
评论 #31415187 未加载
评论 #31403465 未加载
snicker7大约 3 年前
A lot of these issues can be fixed. Adding robust type constraints (e.g. traits) and accompanying &quot;static analysis&quot; tooling would help a lot. Julia can learn a lot from ML-family languages (e.g. OCaml, Haskell) in that regard. And there are efforts in the Julia community to add these features via third-party libraries. However, I don&#x27;t see things improving unless such features are baked into the language and used more ubiquitously in open source modules.
IshKebab大约 3 年前
I tried Julia but the compilation time for interactive use was just too insane.<p>I ended up paying £125 for MATLAB. Nothing else really remotely compares to MATLAB&#x27;s plotting facilities.
评论 #31399680 未加载
评论 #31402690 未加载
评论 #31399435 未加载
garrison大约 3 年前
Similar correctness issues are a big part of the reason that, several years ago, I submitted a series of pull requests to Julia so that its entire test suite would run without memory errors under Valgrind, save for a few that either (i) we understood and wrote suppressions for, or (ii) we did not understand and had open issues for. Unfortunately, no one ever integrated Valgrind into the CI system, so the test suite no longer fully runs under it, last time I checked. (The test suite took nearly a day to run under Valgrind on a fast desktop machine when it worked, so is infeasible for every pull request, but could be done periodically, e.g. once every few days.)<p>Even a revived effort on getting core Julia tests to pass under Valgrind would not do much to help catch correctness bugs due to composing different packages in the ecosystem. For that, running in testing with `--check-bounds=yes` is probably a better solution, and much quicker to execute as well. (see e.g. <a href="https:&#x2F;&#x2F;github.com&#x2F;JuliaArrays&#x2F;OffsetArrays.jl&#x2F;issues&#x2F;282" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;JuliaArrays&#x2F;OffsetArrays.jl&#x2F;issues&#x2F;282</a>)
patrec大约 3 年前
I tend to be a a bit wary of dynamic languages with sophisticated, performant implementations of complex abstractions, especially if they have somewhat niche appeal. In my experience this is a combination that makes for running into a lot of implementation bugs. For example, I&#x27;ve run into many more nasty compiler bugs with lisps (and julia at least qualifies as an almost-lisp) than with more simple-minded dynamic languages like python or erlang[1] or fairly sophisticated but niche statically typed languages.<p>I think watching Julia over the next few years will be quite interesting: it&#x27;s the only dynamically typed language that has both sophisticated abstractions and a sophisticated implementation[1] that has enough pull to have a chance to become entrenched in certain domains. I wonder to what extent they will be able to get this problem under control.<p>[1] BEAM, unlike cpython, is actually a marvel of engineering and making very deliberate trade-offs. But it&#x27;s not very complex.<p>[2] Javascript is of course the one pervasive dynamically typed programming language that has sophisticated implementations, but of mostly ill-conceived constructs.
fgh大约 3 年前
It would be interesting to know which language the author currently uses.
评论 #31397265 未加载
评论 #31397239 未加载
ur-whale大约 3 年前
The examples provided feel more like bugs in various libraries than an actual problem intrinsic to Julia the language.
评论 #31397272 未加载
评论 #31397275 未加载
评论 #31397225 未加载
cancandan大约 3 年前
I wonder why not much is done to bring high performance scientific computing to common lisp. There are some interesting projects I was able to find like <a href="https:&#x2F;&#x2F;github.com&#x2F;clasp-developers&#x2F;clasp" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;clasp-developers&#x2F;clasp</a> and <a href="https:&#x2F;&#x2F;github.com&#x2F;marcoheisig&#x2F;Petalisp" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;marcoheisig&#x2F;Petalisp</a> and <a href="https:&#x2F;&#x2F;github.com&#x2F;takagi&#x2F;avm" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;takagi&#x2F;avm</a>. But I guess it would be good to have a coordinated effort in this area.
uwuemu大约 3 年前
A devastating article for Julia. I was thinking about trying Julia out... but not after reading this.
chubot大约 3 年前
Oof, accessing out of bounds memory is pretty surprising to me for a dynamic language ... But I guess it&#x27;s not surprising if your goal is to compile to fast native code (e.g. omit bounds checks).<p>I don&#x27;t know that much about how Julia works, but I feel like once you go there, you need to have very high test coverage, and also run your tests in a mode that catches all bound errors at runtime. (they don&#x27;t have this?)<p>Basically it&#x27;s negligent not to use ASAN&#x2F;Valgrind with C&#x2F;C++ these days. You can shake dozens or hundreds of bugs out of any real codebase that doesn&#x27;t use them, guaranteed.<p>Similarly if people are just writing &quot;fast&quot; Julia code without good tests (which I&#x27;m not sure about but this article seems to imply), then I&#x27;d say that&#x27;s similarly negligent.<p>-----<p>I&#x27;ve also learned the hard way that composability and correctness are very difficult aspects of language design. There is an interesting tradeoff here between code reuse with multiple dispatch &#x2F; implicit interfaces and correctness. I would say they are solving O(M x N) problems, but that is very difficult, similar how the design of the C++ STL is very difficult and doesn&#x27;t compose in certain ways.<p>(copy of lobste.rs comment)
评论 #31400487 未加载
vasili111大约 3 年前
Does the Python have similar issues?
hzhou321大约 3 年前
Think about programing layers: A-&gt;B-&gt;C-&gt;D-&gt;...-&gt;Compiler-&gt;binary-&gt;output, where A is the end programmer, and B, C, D are the libraries and modules. I think what the article describes is not much different from issues in any complicated software systems, as quite a few comments also pointed out. However, when the language become more expressive and compiler become more clever, more of the issues will be rooted from the the compiler-&gt;binary link. I think this is inevitable with the current model of how software works, which I can simplify as: A -&gt; [super compiler] -&gt; output<p>The middle part is the concatenation of all the middle links and handles the complexity necessary to translate from language to output. As we trying to make A less complex, the middle [super compiler] will get more complex, and more buggy because of the complexity.<p>I believe the fundamental issue with this model is the lack of feedback. A feedback on output, and A makes change (in A) until output get correct. With the big complex and opaque middle, for one, we can&#x27;t get full feedback on output -- that is the correctness issue. The more complex the middle gets, the less coverage the testing can achieve. For two, even with clear feedback -- a bug -- A cannot easily fix it. The logic from A to output is no longer understandable.<p>I believe the solution is to abandon the pursuit of magic solution of A -&gt; [super compiler] -&gt; output but to focus on how to get feedback from every link in A-&gt;B-&gt;C-&gt;D-&gt;...-&gt;compiler-&gt;binary-&gt;output<p>For one this give A a path to approach and handle complexity. A can choose to check on B or C or ... directly on output, depending on A&#x27;s understanding and experience. For the least, A can point fingers correctly.<p>For two, this provides a path to evolve the design. The initial design on which handles which or how much complexity is no longer crucial. Each link, from A, to B, to C, ... to compiler can adjust and shift the complexity up and down, and eventually settle down to a system that fits the problem and team.<p>I believe this is how natural language works. Initially A tells B to &quot;get an apple&quot; and they directly feedback on the end result of what apple B gets to A and may alter layer of A by expanding into more details until it gets the right result. Then, some of the details will be handled by B and A can feed back on B&#x27;s intermediate response for behavior. As the world gets more complex, the complexity at the layer A stays finite but we added middle layers. Usually, A only need feedback on its immediate link (B) and the final output, but B needs to be able to feedback on its next immediate link, and if A is capable, A may choose to cut-out the one of his middle man.
jahewson大约 3 年前
When Julia was first released, I tried it out and decided I&#x27;d write a syntax highlighter for it, so I asked for a grammar. There wasn&#x27;t one. I was told to refer to the parser source code, which was written in a custom dialect of LISP. That was a red flag for me and I never returned.
adolph大约 3 年前
Oftentimes people describe languages as &quot;Turing complete&quot; but how often do they talk about languages being &quot;Gödel incomplete?&quot; Another way of stating maybe is &quot;Are what some call flaws what others call features?&quot;<p><a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;7284&#x2F;what-is-turing-complete" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;7284&#x2F;what-is-turing-comp...</a><p><a href="https:&#x2F;&#x2F;plato.stanford.edu&#x2F;entries&#x2F;goedel-incompleteness&#x2F;" rel="nofollow">https:&#x2F;&#x2F;plato.stanford.edu&#x2F;entries&#x2F;goedel-incompleteness&#x2F;</a>
评论 #31397599 未加载