Did #julialang end up kinda stalling or at least plateau-ing lower than hoped?
I know it’s got its community and dedicated users and has continued development.
But without being in that space, and speculating now at a distance, it seems it might be an interesting case study in a tech/lang that just didn’t have landing spot it could arrive at in time as the tech-world & “data science” reshuffled while julia tried to grow … ?
Can a language ever solve a “two language” problem?
@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 @maegul @astrojuanlu @programming
Interesting. But seems to be limited to arrays. And I’m wondering what the benefit is over regular Numpy. In my tests I did not find Numpy to be slower than any other Blas or Lapack implementation (if type stable and immutable).
Do you have any comparisons?
In any case, I don’t think it would work for solving ODEs unless I’d implement the RHS in a JIT compiled function.
I used to love Python, but now it looks like a collection of add-ons/hacks to fix the issues I have.