I mean I see this as very likely. When the world runs on digital infrastructure then having a nearly infinite collection of hackers that will work for you 24/7 without question makes you very powerful indeed.
I really don't think people realize how our lax position on security is coming to bite us in the ass.
Do you think the criticism in the article "Why I no longer recommend Julia" about correctness is still valid? * there are too many correctness and composability bugs throughout the ecosystem to justify using it in just about any context where correctness matters *
I think that article has been discussed to death and there's not much value in resurrecting it on every single post that mentions Julia. ultimately if you think the language might be a fit for your use case, I'd recommend trying it out and see how you like it first-hand.
I'm one of today's lucky 10,000, so I'm glad it was linked here (and would happily read a defence of the language from one of those previous discussions, too).
When the criticisms relate to correctness bugs, I don't think 'try it out and see how you like it' is sufficient. I might love the syntax and the design and so on, but that doesn't tell me whether I'm going to run into serious bugs some time in the future.
That reads to me more like a long-winded example of a Julia user refusing to take correctness issues seriously, and instead using an LLM to self-soothe by deflecting onto other projects:
> I think there’s also a mindset split, some people just like to have things more strict and avoid bugs by having their compiler proof everything, and others like more freedom and are fine with occasional mishaps.
> Just for the fun of it, I put claude on Python, and it also found some eye watering correctness issues (to be fair, I haven’t taken the time to verify and judge them, but it seems like that’s a similar situation for the Julia version)
I say "self-soothe" because if the intention were to better understand the correctness situation, presumably one would at least want to evaluate the output before declaring it "eye watering". And then even if the output was real, it would be better to report it to the affected Python projects instead of using it as an excuse to downplay problems in Julia.
But most of the supposed "bugs" seem like totally fine/reasonable behaviors to me, often for clearly nonsensical inputs. Seriously, `np.array([1, 'two', 3.0])`? That's not a bug, the behavior is clearly documented on numpy.org, but really no matter what Python does with that, it's not comparable to issues like `prod([Int8(100), Int8(100)]) != prod((Int8(100), Int8(100)))` from that post about Julia. Which again the linked Discourse post downplays as "freedom and occasional mishaps".
You can not be serious in suggesting these aren’t straight up Python correctness bugs. Exactly the same kind that Yuri brought up as damning evidence of Julia unseriousness, but for Python with easily 25x the user base.
Most (all?) aren't bugs by any stretch of the imagination, no. Let's go over the first 5.
1. random.choices(['a','b','c'], weights=[-1,5,1], k=10000)
Negative weight on 'a' silently shifts
Python docs say, "Weights are assumed to be non-negative and finite." Garbage in, garbage out.
2. random.choices(['a','b','c'], cum_weights=[5,2,7], k=10000)
Non-monotone cum_weights makes 'b' unselectable.
...Those weights aren't cumulative, which the docs say they should be. Again, garbage in, garbage out.
3. statistics.fmean([1,2,3], weights=[-1,1,1])
“Mean” of three values in [1,3] returns 4 — outside the convex hull.
This is just straight-up mathematically correct behavior. It preserves linearity. It fits the commonly accepted definition of weighted mean as `(w1*x1+w2*x2...)/(w1+w2...)`.
The LLM fabricated a fake/idiosyncratic definition of weighted mean in order to claim it's a bug, because it was instructed to come up with bugs.
4. json.dumps({1: 'a', '1': 'b'})
Produces invalid JSON with duplicate keys; round-trip silently drops one entry.
Again, documented behavior/GIGO. Docs say, "loads(dumps(x)) != x if x has non-string keys."
This is literally just what geturl() is supposed to do. It's the whole point. Docs say "empty parameters, queries, and fragment identifiers will be removed". The LLM is claiming that geturl()'s primary intended purpose is a bug.
So all of these "eye watering correctness issues" so far seem to be either (1) straight-up correct, or (2) doing things Python explicitly tell you not to do. Same deal with the Numpy "bugs", AFAICT, as I touched on in my previous comment.
In fact, I would venture that we all know those Python bugs are fake, but (unfortunately) the Julia ones aren't. Because the Julia bugs mentioned by Yuri were reported to the Julia bug tracker, and eventually fixed. Whereas if you really thought these are real bugs in Python, then (IMO) you should be reporting them to the Python tracker, not getting mad at me for doubting them.
Moreover, even if they were real bugs in Python (which they aren't), bugs existing in Python still wouldn't change the situation for Julia. The Discourse user who posted it still admitted that they didn't even take the time to verify them.
Surely you must realize how bad it makes Julia look, when its users fling LLM slop to attack Python in response to Julia's issues being brought up? A constructive project should instead talk about what's been done and planned to improve Julia's situation, not tell lies to drag Python down. I liked Julia when I tried it! The JIT plus multiple dispatch is so unique. But this so isn't the way.
python has plenty of bugs like these too. is this example also "LLM slop" ? I think it's frankly delusional to somehow believe that these issues are unique to Julia.
> But most of the supposed "bugs" seem like totally fine/reasonable behaviors to me
exactly. and the same is true for many of the bugs that have been presented as indictments of Julia. but when the same is said of those, the community is called "defensive." so it's a lose-lose.
There is no equivalence here. The Julia bugs were real. They were reported, accepted, and fixed. The Python bugs you linked to are fake LLM slop, see my other comment right above/below this one. [0] If anyone really believes the Python bugs are real, they should report it to Python, not use it to deflect from Julia's issues.
What's been presented as an indictment of Julia (in Yuri's own post and after) is the fact that members of the Julia community have vocally downplayed problems and played the victim when quality concerns have been raised, as I think you're doing. Do you want to convince everybody you've "won" "a lose-lose"? Or do you want to write correct programs?
I like Julia, the language and the tech. I really hope this hostile attitude towards criticism and growth fades eventually, because I'd like to be able to use and trust it at some point.
I wouldn't say this is true really. Julia does have some unique properties which cause these issues other languages just sidestep. The dynamic dispatch system is really magical when it works, but it's the source of much of the consternation you see here in this thread, and the reason it persists despite individual bugs being fixed. The problem is the "bugs" in this case aren't really as such; they're not wrong code, they are violations of silent contracts.
The whole magic of dynamic dispatch is you write Library A and Type B, and they "just work" together without having to know about one another. This is of course very powerful and so people have been very enthusiastic when wielding it.
But with great power comes great responsibility; when using libraries and types that weren't meant to work together, one of those types might violate a silent contract in the library. This would be fine if the error could be caught at compile time, but it happens in the form of numerical correctness issues, so they don't even present as actual errors.
The most obvious example of this is where Julia allows for arbitrary arrays and two things expecting different bases come into contact. This is something that's just not possible in other languages, so they're not exposed to this class of bugs.
So maybe you can harden and make explicit some of these contracts, or put up warning signs, or add some lints, and thus "fix bugs"; but they keep coming back because the dynamic dispatch system assures it due to the combinatorial explosion of interactions it incurs. I'm very interested in how Julia will solve this issue going forward.
I strongly recommend listening to others experiences and not forwarding some conversion metric for the languages share holders. Maybe there's a lot of wisdom in smart people being vocal enough to say "yea no" about it. It's not like it's one person...
I don't have any financial interest in Julia so I'm a bit confused about the reference to "share holders." I'm just a user.
I'm sure there are lots of smart people who found that the language didn't suit their needs. there are also lots of smart people who love using Julia. both things can be true at the same time.
There are no language share holders, and note that this account was created an hour ago just to post vague nonspecific gripes about Julia.
There are some real issues in the ecosystem. Specifically there is a high proportion of “gradware” because much like other scientific languages there is a high proportion of graduate students doing their projects and then moving on.
The language also encourages relying on packages which can break. But juliaup makes this easy enough to solve by downgrading.
They dictate what their employees are paid to work on, there are no VC investments in The Julia Programming Language
It’s true that MIT and a few other organizations have more influence than others simply because they employ more developers with time/scope to work on the language. Just like every programming language.
But this becomes less true all the time. And most of the direction that is “paid for” is an unadulterated good: JuliaC ahead of time compilation has been requested for over a decade and has made enormous progress.
I have submitted plenty of core contributions, none of which were directed or paid for by VC. the language contributions come from those sufficiently motivated to contribute. if you want to change the direction, you need to do some work.
Programming languages have bugs. These things happen, and this tired article blows them totally out of proportion.
Some languages are less permissive, and have a culture of searching harder for corner cases and dealing with them than others, that is true. I would expect to find less cases like this in Rust, but more cases like this in Python.
Julia is an extremely flexible and permissive language, which means that generic code needs to be written carefully and contracts between interfaces need to be thought through.
When you combine funky package types like OffsetArrays with functions from a package where the authors didn't think about OffsetArrays, bad things can happen. Those things were then reported and the community has learned a lot about how to deal with those sorts of things.
I'm sure an AI agent can crawl through and find a new big list of weird bugs in julia, but that's true even of a language like Rust.
> Some languages are less permissive, and have a culture of searching harder for corner cases and dealing with them than others, that is true. I would expect to find less cases like this in Rust, but more cases like this in Python.
My expectation is that when I think I've found a bug in the programming language implementation I'm using, it's actually me that's mistaken (or at least that language lawyers consider me to be mistaken). Hearing about someone who has encountered multiple bugs (in regular use, rather than running a fuzzer or being directly involved in implementing the language) makes me very wary.
Yeah, this is crazy. It's literally a cliché for most programming languages that it's never the compiler's fault. Granted a lot of the Julia bugs seem to be in the standard/core libraries, but still. Even if the bugs are overstated, this cavalier attitude towards correctness in a numerical language is super disconcerting to me.
Corner cases like `prod([Int8(100), Int8(100)]) != prod((Int8(100), Int8(100)))`? Both returned integers, but the left was 10000 while the right was 16. [0]
Which, apparently, sat in the standard library for almost four years after it was introduced before it was fixed. [1]
Even if there was some merit to your argument, I would still find the attitude disqualifying. While it may be technically true that all programming languages have bugs, software and software communities for numerical computing should take responsibility and treat those bugs seriously, not downplay them by pointing to the fact that other software probably has bugs too.
FWIW I don't have a horse in this race. I've used both before, and I currently make money using neither. I liked Julia. I find that article concerning. And I find the attempts by Julia users to discredit that article in this thread, without addressing its substance, even more concerning and disappointing.
Well, bugs can be fixed. But ideally not by a culture that dismisses them as inevitable or unimportant.
For the monthly price of Spotify, one could rent a VPS and host Navidrome on it. In case you already have spare capacity, then it might be (almost) free.
I always followed trial and error until I reached my target and I had the feeling that my results were much better than if I were randomly clicking buttons. That is, some memory always remained. Or the menu is well thought out and has some consistency.
Trump himself understands little of everything he does. He cannot be bothered to read simple texts, but he prefers images. His attention span is very short. So he is somewhat like a toddler. But in the end of course he does sign decisions and orders, even though he might have not read them fully. Someone else writes those documents he signs.
Public administration in Europe has already started moving away from the american hyperscalers. This is of course happening at the usual speed which is characteristic of all public administration.
reply