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
    3
    ·
    4 months ago

    @maegul

    In a real way it feels like there’s a “hump” with language adoption. Some languages clear it, some don’t, and I don’t think we have a good feel as an industry for what makes a language “successful” in this regard.

    Some things obviously help, other things obviously hurt, but mostly what succeeds or doesn’t seems to be a matter of luck intersecting with need.

    @programming

  • Juan Luis@social.juanlu.space
    link
    fedilink
    arrow-up
    3
    ·
    4 months ago

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

      • maegul@hachyderm.ioOP
        link
        fedilink
        arrow-up
        1
        ·
        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
          link
          fedilink
          arrow-up
          1
          ·
          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
            link
            fedilink
            arrow-up
            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.

          • maegul@hachyderm.ioOP
            link
            fedilink
            arrow-up
            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!!

    • maegul@hachyderm.ioOP
      link
      fedilink
      arrow-up
      1
      ·
      4 months ago

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

  • Murat@fosstodon.org
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    4 months ago

    @maegul @programming I had already switched to Python to solve the “Matlab problem”. I’ve been Julia-adjacent, looked at it with an open mind but it doesn’t make sense to switch to it when I can do almost everything I need in Python. A little diss here, just when we arrived at a free, available solution for widely available sci/biz programming envrionment (Python) Julia peeled off some whose code becomes unusable for most consumers of code.

  • EpicBear@genomic.social
    cake
    link
    fedilink
    arrow-up
    2
    ·
    4 months ago

    @maegul @programming Perhaps this is all kind of like evolution: something that evolves to be sufficient doesn’t necessarily need to further evolve to some pinnacle (however that may be defined it its context). R and Python are imperfect in so many ways, but sadly it gets the job done for most folks. I think people who explore Julia are simply not content for one reason or the other with R and Python (perhaps also Matlab), but they likely have gotten a lot of work done with R & Python.