Live data from Hacker News

How an MIT research project became the Julia programming language

news.mit.edu

101–110 of 142 posts

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

#101

Earlier quoted context omitted.

I'm currently split between Python and Julia, having used R happily in the past for data analysis and Matlab for this and that in my EE program. For me, Julia crushes one niche that the rest of them are not good at: making the math look like the math. https://docs.sciml.ai/ModelingToolkit/stable/tutorials/nonli... If you've used something like SciPy or symbolic Matlab or Maxima or whatever, it always feels like I'm v…

Julia is fun, but is still mostly an academic language. Very few shops will use it in the private sector. Python is also more common as a prototype integration language, and rarely seen in industrial areas. If you are an EE that wants to remain employed... than make sure you have documented hours with C/C++, Verilog on Zynq, and ladder logic for Rockwell automation products. Best of luck =3

I'm an electrical engineer and I use Julia for all kinds of analyses that I might have earlier in my career done in a spreadsheet (Lotus 1-2-3 at first!), or later in python (when I had to choose between Numeric or NumArray).

I started using python for various engineering analysis problems around 2001 and I loved it for how fast (due to minimal boilerplate and automatic memory management) I could code up some thought relative to using C or Java. I could tackle problems in ways I just wouldn't have tried otherwise because I couldn't afford the longer time to write it in other languages. However, for problems which needed speed, of course it bogged down.

I started using Julia for ODE stuff in 2018 or 2019 and was thrilled with the speed and conciseness. As others have said, it looks much more like math and a lot of better design choices were made.

Python obviously has a much larger ecosystem and probably always will, and it will remain a safe choice, but you don't set yourself apart by doing the same thing as everyone else.

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

#102
post #53

Unfortunately Julia is now a vibe coded project where Claude has moved to the #1 spot for Jun-Aug 2026. Of course their sponsors demand it. So it is in the same place as Ruby: interesting but out of the question.

What's with all the throwaway snide comment accounts?

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

#103

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 * https://yuri.is/not-julia/

I do. It pairs nicely with this quote from the article: > “With Dyad 3.0, you can upload data and design documents and the system will design an entire aircraft for you,” Shah says

[deleted]

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

#104
post #98

Earlier quoted context omitted.

The abstraction does not require a lot of understanding/bodges to get performant code by amateurs: https://cuda.juliagpu.org/stable/tutorials/introduction/ But I agree the shared memory Distributed Computing part of Julia still needs a lot of work. Spawning binary image instances over ssh is too fragile. =3

> The abstraction does not require a lot of understanding/bodges to get performant code by amateurs I agree the change is simple, and didn’t question that; I questioned the “implicitly” in the claim > Julia is the first language I've seen in years that implicitly abstracts parallelism cleanly. (Aside: I think scala does this even nicer. There, adding `.par` can make code run multi-threaded. See https://docs.scala-lan…

If you read the tutorial, the broadcast iterators and GPU kernel are often implicit. As the CUDA array type hints means you don't need to explicitly define standard operations unless doing something custom.

I hope one day Julia does a cleaner version of Scala or Erlang/Elixir OTP languages. Clustering on OTP was certainly an area even seasoned gray beards tried to avoid. =3

https://youtu.be/lg-710Kk5CM?t=20

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

#105

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.

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".

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

#106

Earlier quoted context omitted.

Julia is fun, but is still mostly an academic language. Very few shops will use it in the private sector. Python is also more common as a prototype integration language, and rarely seen in industrial areas. If you are an EE that wants to remain employed... than make sure you have documented hours with C/C++, Verilog on Zynq, and ladder logic for Rockwell automation products. Best of luck =3

Oh, my friend, I’m in my 40s now and while I’ve never touched ladder logic (mostly on purpose), I can honestly say I’ve been writing C since the last century and C++ only a few years less. I remember, with pain in my heart, what C++ looked like before C++11, C++14, and C++17. C++03 had just come out when I started and lots of features even there weren’t really all that baked in the toolchains at them time :). Zynq is…

Analog Devices Pluto SDR has a fairly integrated tutorial program for zynq fpga.

https://www.analog.com/en/resources/evaluation-hardware-and-...

> I’ve never touched ladder logic

Depends what kind of work you do, as product development is different from factory journeyman. I don't see a chaotic market supporting many domestic product development projects for the next 2 years. =3

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

#107
post #39

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 * https://yuri.is/not-julia/

As someone who could be tempted by Julia but isn't involved in the community this was a very helpful read, thank you for sharing.

It really isn't very helpful, as many of the issues are either obsolete or exaggerated.

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

#108
post #53

Unfortunately Julia is now a vibe coded project where Claude has moved to the #1 spot for Jun-Aug 2026. Of course their sponsors demand it. So it is in the same place as Ruby: interesting but out of the question.

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?

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

#109

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 * https://yuri.is/not-julia/

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…

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.

[0] https://github.com/JuliaLang/julia/issues/39183

[1] https://github.com/JuliaLang/julia/blob/26f2333686ce90331548...

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

#110

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 * https://yuri.is/not-julia/

I do. It pairs nicely with this quote from the article: > “With Dyad 3.0, you can upload data and design documents and the system will design an entire aircraft for you,” Shah says

[deleted]
Post reply on HN