4 ms·

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

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
        >You 'can' have those things, but 'should' you? As opposed to what? Wait for Julia to catch up in 10 years? If so, yes, you absolutely should get those things from where they're already available. >Why use a "slow" language if you don't have to? Because that's where the action is, and who gets those niceties first. Julia hasn't even fixed their slow startup/load situation all these years...
- bsdubernerd 6y ago
  The vast majority of people look first for existing tools to solve the problem, then for ready-made libraries to solve the problem, then for libraries/code which is easily adaptable with the least effort. Don't delude yourself into thinking the actual language matters in most cases. Historically it never did. (I love julia, btw)

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
        >You 'can' have those things, but 'should' you? As opposed to what? Wait for Julia to catch up in 10 years? If so, yes, you absolutely should get those things from where they're already available. >Why use a "slow" language if you don't have to? Because that's where the action is, and who gets those niceties first. Julia hasn't even fixed their slow startup/load situation all these years...
bsdubernerd 6y ago
The vast majority of people look first for existing tools to solve the problem, then for ready-made libraries to solve the problem, then for libraries/code which is easily adaptable with the least effort. Don't delude yourself into thinking the actual language matters in most cases. Historically it never did. (I love julia, btw)