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

    • maegul@hachyderm.ioOP
      2·
      4 months ago

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

      • Hrefna (DHC)@hachyderm.io
        3·
        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

        • maegul@hachyderm.ioOP
          1·
          4 months ago

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

          • Hrefna (DHC)@hachyderm.io
            1·
            4 months ago

            @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

        • maegul@hachyderm.ioOP
          1·
          4 months ago

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