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?

@programming

  • Hrefna (DHC)@hachyderm.io
    link
    fedilink
    arrow-up
    0
    ·
    4 months ago

    @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

    • tschenkel@mathstodon.xyz
      link
      fedilink
      arrow-up
      0
      ·
      4 months ago

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