I'm curious, does anyone use Julia for Operations Research/Optimization/Supply Chain/Logistics? I am trying to learn more about the use of the language in that space. Thx.
Yes! This is a beautiful use-case, thanks to JuMP.
How an MIT research project became the Julia programming language
121–130 of 142 posts
Re: How an MIT research project became the Julia programming language
#122Earlier quoted context omitted.
I don’t know if experience has just damaged my brain or what, but I really like matlab’s syntax for what it is. Nice for writing 100 line experiments or using in the REPL. Sort of like the Python of linear algebra, haha. It also has a nice feature where you start getting headaches to let you know you’ve tried to extend it past its comfort zone. Julia seems to sit in this area between Matlab and Fortran where I can’t…
Julia might just be the closest thing at the moment to Matlab without being a Matlab clone. I think you're overestimating the learning curve. It has a REPL, with tab completion and ? for high-quality help (without resorting to a browser or llm).
Just to be fully pedantic, Octave is the closest thing to being Matlab without being Matlab (and actually I use Octave). :)
Re: How an MIT research project became the Julia programming language
#123Earlier quoted context omitted.
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…
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.
Re: How an MIT research project became the Julia programming language
#124Earlier 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.
Re: How an MIT research project became the Julia programming language
#125Earlier quoted context omitted.
Julia might just be the closest thing at the moment to Matlab without being a Matlab clone. I think you're overestimating the learning curve. It has a REPL, with tab completion and ? for high-quality help (without resorting to a browser or llm).
Just to be fully pedantic, Octave is the closest thing to being Matlab without being Matlab (and actually I use Octave). :)
[deleted]
Re: How an MIT research project became the Julia programming language
#126Earlier quoted context omitted.
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…
> 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.
Re: How an MIT research project became the Julia programming language
#127Earlier quoted context omitted.
It kinda feels like Julia competes for the people who write the libraries for R and Matlab. Writing fast and elegant ODE solvers, etc in Julia seems to be easier than the others and they've attracted a lot of academics for that reason.
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…
One thing that I find extremely annoying when I occasionally read Julia code is the pervasive usage of Unicode. I explicitly forbid agents to use any anything other than ASCII for that reason.
Re: How an MIT research project became the Julia programming language
#128Earlier quoted context omitted.
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…
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
2. random.choices(['a','b','c'], cum_weights=[5,2,7], k=10000)
Non-monotone cum_weights makes 'b' unselectable.
3. statistics.fmean([1,2,3], weights=[-1,1,1])
“Mean” of three values in [1,3] returns 4 — outside the convex hull.
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.
5. urlparse('http://example.com/?').geturl()
Trailing ? (empty query) and # (empty fragment) silently stripped
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.
Re: How an MIT research project became the Julia programming language
#129Earlier quoted context omitted.
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…
> 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.
Re: How an MIT research project became the Julia programming language
#130I 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…
Nice. Suggestion: Add PyPy too.