Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How an MIT research project became the Julia programming language

news.mit.edu

Post reply on HN
Print view View original

131–140 of 142 posts

Re: How an MIT research project became the Julia programming language

#131

Post by Intralexical »

penteract wrote: post #94
eigenspace wrote: post #50

Earlier quoted context omitted.

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 ge…

> 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 t…

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.

Re: How an MIT research project became the Julia programming language

#132

Post by ModernMech »

postflopclarity wrote: post #92
eigenspace wrote: post #91

Earlier quoted context omitted.

Here's a somewhat recent discussion sparked by someone who was concerned having read the blogpost: https://discourse.julialang.org/t/julia-stability-vs-rust-fo... It got a little long and meandered a bit, but I think there's some good, nuanced discussion there.

in particular, https://discourse.julialang.org/t/julia-stability-vs-rust-fo... is a very visceral example of how bugs like these arise everywhere (including python) and are in no way unique or even exaggerated in Julia.

> in no way unique or even exaggerated in Julia

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.

Re: How an MIT research project became the Julia programming language

#133

Post by jakobnissen »

dunefox wrote: post #108
postflopclarity wrote: post #80

Earlier quoted context omitted.

nobody "demanded" anything. it's just the most productive way to write code these days. the same is true at the vast majority of software companies (that can afford the $$ on tokens) as well.

Wait, code of the programming language is now vibe coded?

No I don’t know how he gets that info. Most contributions to the language these days are AI assisted, but that’s a completely different matter. IMO if you can afford AI assistance, it would be irresponsible to not use it, given how good AIs are st bug finding and code review

Re: How an MIT research project became the Julia programming language

#134

Post by postflopclarity »

Intralexical wrote: post #129
postflopclarity wrote: post #126

Earlier quoted context omitted.

> 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 th…

I am not hostile to criticism.

> If anyone really believes the Python bugs are real, they should report it to Python

I have reported several bugs, both to Python and to Julia.

I'm not going to engage further in this thread, but if you want to continue discussion I'd be happy to chat somewhere else that's a little less clunky

Re: How an MIT research project became the Julia programming language

#135

Post by lalalanananana »

klaff wrote: post #116
lalalanananana wrote: post #113

Earlier quoted context omitted.

Strong avoid outside of academic use. It's been this way for more than a decade.

Is your ex named Julia?

Lul. No. Everytime one of these "look how amazing Julia pots comes up", myself and many others do what we can to protect other people from wasting their time or their money from using it due to our personal experiences with it professionally or as hobbyists.

Re: How an MIT research project became the Julia programming language

#136

Post by lalalanananana »

patagurbon wrote: post #118
lalalanananana wrote: post #114

Earlier quoted context omitted.

There are vc investments and other corporate sponsors which heavily dictate the language and it's ecosystem.

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 unadulte…

If you think this has no effect on core contributions or directionality for the language I have a crazy deal on a timeshare

Re: How an MIT research project became the Julia programming language

#137

Post by postflopclarity »

lalalanananana wrote: post #136
patagurbon wrote: post #118

Earlier quoted context omitted.

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 unadulte…

If you think this has no effect on core contributions or directionality for the language I have a crazy deal on a timeshare

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.

Re: How an MIT research project became the Julia programming language

#138

Post by postflopclarity »

Intralexical wrote: post #128
jakobnissen wrote: post #123

Earlier quoted context omitted.

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…

```

>>> x = [2*53, 2*53 + 2]

>>> statistics.covariance(x, x) 4.0

>>> statistics.variance(x) 2

```

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.

Re: How an MIT research project became the Julia programming language

#139

Post by lalalanananana »

postflopclarity wrote: post #137
lalalanananana wrote: post #136

Earlier quoted context omitted.

If you think this has no effect on core contributions or directionality for the language I have a crazy deal on a timeshare

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.

I have core contributions to the language too.

I think you misunderstood my sentiment. That's okay. In a few years you'll probably be where I am now. Setting a reminder for 2 years.

Re: How an MIT research project became the Julia programming language

#140

Post by cmontella »

fhn wrote: post #112
cmontella wrote: post #77

I did some Julia benchmarking over the weekend against a bunch of languages if anyone is interested. The workload is an EKF on an Apple M1, I'm trying to do as many as possible in parallel: https://raw.githubusercontent.com/mech-lang/mech/codex/taich... Compared against Taichi, Halide, Futhark, Rust', Lua, LuaJIT, Numpy and pure scalar Python. Julia holds up great it can run basically as fast as you'd like! (These ar…

I'd like to see how Mojo performs here

https://raw.githubusercontent.com/mech-lang/mech/codex/pypy-...

I added PyPy and Mojo.

PyPy performs valiantly compared to Cpython -- even better than LuaJIT. I'm sure someone skilled at writing it could do an even better job.

I measured 3 Mojo implementations. The first is a dynamic implementation, it performs like a typical dynamic language. Then when you use Mojo's SIMD intrinsics you can get compiled-tier performance in line with Futhark, Julia, Rust etc.

Then if you use their Max toolchain you can compile Mojo directly to Metal, with performance at the top of the stack (for the amount of money Qualcomm paid they'd better be there!).

The Rust / Mech version was rewritten to put it back on top, but the unchecked test is about equal. Basically if a toolchain can emit direct Metal code there's nothing preventing equal performance it seems, so the magic is in the compiler. Although there is some abstraction overhead depending on how you get there e.g. going wgpu->Metal has a penalty over going directly to Metal.

The big disclaimer again is that all of these measurements should be taken as lower bounds for one algorithm on one machine. I'm sure expert performance engineers could do better.

Post reply on HN