this post was submitted on 15 Jul 2024
34 points (94.7% liked)
Programming
17424 readers
53 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
@maegul @programming Maybe nobody (save for the Julia developers) ever cared about the "two language problem". I see folks are just happy writing high performance tools in Rust with Python wrappers.
In any case, I'm happy that the Julia folks gave birth to things like DifferentialEquations.jl, truly a piece of art. Anything that helps scientists and engineers move away from MATLAB is welcome.
The MATLAB language may be pretty bad but IMO that's not what makes MATLAB good. Rather it's:
Every signal processing / maths function is available and well documented. I don't know how well Julia does on this but I know I wouldn't want to use Python for the kinds of things I used MATLAB for (medical imaging). You don't have to faff with pip to get a hilbert transform or whatever...
The plotting functionality is top notch. You can easily plot millions of points and it's fast and responsive. Loads of plotting options. I just haven't found anything that comes close. Every other option I've tried (a lot) only works for small datasets.
@FizzyOrange The problem with Python for signal processing and stuff like that is not pip (I know it's a meme by now, but it's really not that bad) but rather, the fact that some SciPy subpackages are barely maintained
@tschenkel @astrojuanlu @maegul @programming I completly agree with your second point.
@tschenkel @astrojuanlu @programming
I'd suppose part of the problem might be that there's a somewhat hidden 3rd category of user that "feels" whatever added complexity there is in a two-language lang like julialang and has no real need for performant "product" code.
And that lack of adoption amongst this cohort and your first enforces lang separation.
I may be off base with whether there's a usability trade off, but I'd bet there's at least the perception of one.
@maegul
Considering, it may be worth highlighting that tools like Jax exist as well (https://github.com/google/jax). These have even become an expected integration in some toolkits (e.g., numpyro)
It may not be the most elegant approach, but there's a lot of power in something that "mostly just works and then we can optimize narrowly once we find a problem"
It doesn't make a solution that solves this mess bad, but I do wonder about it being a narrow niche
@tschenkel @astrojuanlu @programming
@hrefna @tschenkel @astrojuanlu @programming
Yea ... it seems that things like this are part of Julia's problem ...
that for many the "two language problem" is actually the "two language solution" that's working just fine and as intended, or as you say, well enough to make an ecosystem jump seem too costly.
@tschenkel
Mostly its advantage as far as arrays go is its ability to push things out to an accelerator (GPU) without making code changes. Also its JIT functionality is a good bit faster than using pytorch's (at least anecdotally).
My experience with it is not at all related to ODEs (more things like MCMC) and I have no direct experience with its gradient functionality and only limited with its auto vectorization, so take my experience with a grain of salt.
@maegul @astrojuanlu @programming
@tschenkel @astrojuanlu @programming
I understood ... I was reaching for some shorthand (500 char limits FTW!)
There's probably a good amount of work that exists somewhere between your needs and "could be a spreadsheet", where caring about performance isn't an issue or hasn't surfaced yet, either practically or culturally (where the boundaries of what research *can* be done "tomorrow" are of importance)
BTW, cheers for all the info!!
@astrojuanlu @programming
> Maybe nobody (save for the Julia developers) ever cared about the "two language problem"
Yea, it’s what prompted my post. I saw in a rust forum push back on the two language thing but from the lower level side (where they were arguing about introducing lazier memory management facilities on the basis that you should just use swift/Python etc).
And re MATLAB … absolutely! This is not a diss against Julia at all.