5 ms·

Interesting.. I thought Julia was on the rise ?

• dagw 6y ago
  It probably still is, but by all accounts it is rising a lot slower than many people had hoped for.
  • dunefox 6y ago
    Hopes are free. If you want it to rise quicker you have to use it and contribute. "Why would I use it if few people do?" is quite paradoxical.
    • michaericalribo 6y ago
      Definitely not paradoxical. Network effects of out-of-the-box tooling/features—I mean a robust, extensive set of libraries to accomplish basic and moderately complex statistical / ML tasks—is the table stakes here, and depends strongly on whether more than a “few people do” already.
• bsdubernerd 6y ago
  It is. But if your aim is to displace (never mind replace!) an old, established niche, it's a very steep uphill. Like the OP, I still use a ton of python. And I consider python to be a newcomer in the sci community, still gaining momentum with perhaps a bigger uptick in the recent years.
  • phkahler 6y ago
    >> But if your aim is to displace (never mind replace!) an old, established niche, it's a very steep uphill. If your goal is to beat someone else then you're playing the wrong game.
    • coldtea 6y ago
      This doesn't say much. First, as an analogy, since in most games, the goal is precisly to beat someone else, and there's nothing wrong with that (it's the very meaning of sports competition). Second, because for a programming language community and adoption and ecosystems matters, and you don't get all those without beating "someone else" or at least comming close to doing it. Either you magically double the number of devs/people doing data science, or you atract data scientists from Python and R (either attract existing users of Python, or get more new users into you rather than in Python).
  • snicker7 6y ago
    The goal is to create a great programming language to solve real problems.
    • michaericalribo 6y ago
      I already solve real problems in Python—why bother learning yet another language, and one our data engineers/backend folks don’t know? That larger context of implementation / development / deployment is a huge deciding factor for real-world problem solving, not how “great” a language is from a design perspective.
      • snicker7 6y ago
        It depends on the problem you have, "do excel-type business analysis" or "write a CRUD app" are things any language can do. Julia solves hard problems. Neuro-differential equations, energy grid optimization (Ivenia), database implementations (RelationalAI, see Jamie Brandon's talk on why Julia specifically is suitable for this), DSL implementations (Stan, &etc). Writing high-performance simulations (no, slow langs won't cut it, if you want tight loops you need low-level control such as cache-coherent memory layouts, vectorized instructions, &c).
        • coldtea 6y ago
          >(no, slow langs won't cut it, if you want tight loops you need low-level control such as cache-coherent memory layouts, vectorized instructions, &c). Yawn. You can have all those wrapped under a high level API, with much nicer implementations, with more support, more documentation, more eyeballs (due to more adoption) in a "slow" language. You can even have them run faster than Julia's and in more stable and mature implementations (like there's LAPACK).
          • Recurecur 6y ago
            > You can have all those wrapped under a high level API, with much nicer implementations, with more support, more documentation, more eyeballs (due to more adoption) in a "slow" language. You 'can' have those things, but 'should' you? Julia is well designed, so 'nicer' is not a given. Julia is also quite a high level language with excellent metaprogramming facilities. Otherwise, everything you listed is based on adoption level. Why use a "slow" language if you don't have to? Especially when the faster language is actually better designed...
• coldtea 6y ago
  Yes. For 10 years and probably 10 more before it gets anywhere near significant adoption...