4 ms·

The things that stick out to me as unwieldy in Julia: * Not embracing functional style idioms. There's no TCO so writing recursive algorithms from old FP paper

The things that stick out to me as unwieldy in Julia: * Not embracing functional style idioms. There's no TCO so writing recursive algorithms from old FP papers is hard. Not an issue per se, just gripe. * Not having explicit interfaces. I'm sure there's some advanced Julia-fu that I could do to introspect my way to knowing what methods I need, but the very concept of them not being explicit irks me. Again, not an issue per se, but it annoys me. * There's a complete and total disregard to any notion of a smaller Julia or a Julia more suited for general purpose. Julia seems ripe to benefit from a Ruby&mruby sorta situation, but alas. We need this gigantic blob of dependencies and toolchains and compilers and this and that, to operate this programming language. I don't get it. For the last time, it's not an issue per se, and the language has achieved incredible engagement in many demanding niches, so what do I know anyhow?

tines 5y ago
There's no TCO in many languages, even proudly functional ones like Clojure, so that doesn't seem to be as make-or-break as you and I would have expected. (Clojure does have recur though, but it doesn't help for mutual recursion.)
- sitkack 5y ago
  Clojure has no TCO so it can interop with Java. It is the last language I would bring up as evidence. https://clojure.org/about/functional_programming https://clojure.org/about/functional_programming
  - tines 5y ago
    I don't think it matters why; the fact is that it's a popular "functional" language that doesn't support (full) TCO.
  - thayne 5y ago
    fwiw, scala has some limited TCO, and it also runs on the JVM
    - e12e 5y ago
      Kotlin has explicit tail-calls via tailrec: https://kotlinlang.org/docs/functions.html#tail-recursive-functions https://kotlinlang.org/docs/functions.html#tail-recursive-fu...
      - tines 5y ago
        Looks like the equivalent of Clojure's `recur`. Unfortunately doesn't work for mutually recursive routines.
coldtea 5y ago
>There's no TCO so writing recursive algorithms from old FP papers is hard. Why write "recursive algorithms from old FP papers"? As an exercize, or is there a business need?
- neolog 5y ago
  Inherently recursive algorithms are clearer when written in recursive style.
amkkma 5y ago
>There's a complete and total disregard to any notion of a smaller Julia or a Julia more suited for general purpose That's false. General purpose Julia is a stated goal of the core team, it's just that numerical domination is higher priority. Also, small binary static compilation with tree shaking is further along than you think
- dnautics 5y ago
  yeah, if anything that's what I dislike about julia, I wish it didn't claim to be a GP programming language, and instead worked more on figuring out how to glue it to languages that aren't C. For context, I have basically stopped using julia (not for any taste-related reason except I started doing jobs that were more suited for elixir and haven't had to do numerical computation since), and elixir doesn't claim to be a GP-PL and it's perfectly fine and doing quite well.
  - oscardssmith 5y ago
    Is there anything you think that prevents Julia from being general purpose? The main one I run into is that the garbage collector needs work, but fundamentally I don't think there's much that keeps Julia from being good as a general purpose language.
    - dnautics 5y ago
      "JIT" (ELAOT) compilation and tail latencies. Python is a GP pl (not a very good one, IMO, but it is one). For a long time for some distros Linux CLI and even GUI tools were in python. Can you imagine such an ecosystem in Julia? I can't, nor would I want Julia to make the sacrifices it would need to make to fulfill such a role. There are so many things that python is "mediocre, but good enough" at, that Julia is quite frankly terrible at, because of the (good for what it does) choices that Julia made. I wouldn't write a quick CLI using Julia (versus a long-running or test runner CLI - I have done this professionally [0]). I wouldn't write a web server that is expected to take a load (a personal website is probably fine, though probably still quite painful). I wouldn't write Anything embedded. [0] Wrote a containerized storage block device performance measurement tool. Julia was useful to generate and track statistical distributions of random reads and writes with very clear and concise code. I also think Julia's concurrency story is not that great. But I'm biased against every PL since I have spent a ton of time in erlang/elixir-land which currently has the only (high level) concurrency story that makes any sense IMO. I liked when Julia's concurrency was done per-process (still lives on in Distributed.jl, iirc). I get that this has performance implications, especially around spawning and expensive communications, even with MPI, but I kind of wanted some sort of non-locality of data to be acknowledged, and maybe I would have preferred the new threading concurrency to work with the Distributed.jl abstraction. I think it would have been even more awesome if Julia GPU treated computation against gpu arrays in the same fashion as a distributed job... But as of the last time I used julia (it's been a while) that wasn't the case.

tines 5y ago

There's no TCO in many languages, even proudly functional ones like Clojure, so that doesn't seem to be as make-or-break as you and I would have expected. (Clojure does have recur though, but it doesn't help for mutual recursion.)

sitkack 5y ago
Clojure has no TCO so it can interop with Java. It is the last language I would bring up as evidence. https://clojure.org/about/functional_programming https://clojure.org/about/functional_programming
- tines 5y ago
  I don't think it matters why; the fact is that it's a popular "functional" language that doesn't support (full) TCO.
- thayne 5y ago
  fwiw, scala has some limited TCO, and it also runs on the JVM
  - e12e 5y ago
    Kotlin has explicit tail-calls via tailrec: https://kotlinlang.org/docs/functions.html#tail-recursive-functions https://kotlinlang.org/docs/functions.html#tail-recursive-fu...
    - tines 5y ago
      Looks like the equivalent of Clojure's `recur`. Unfortunately doesn't work for mutually recursive routines.

coldtea 5y ago

>There's no TCO so writing recursive algorithms from old FP papers is hard. Why write "recursive algorithms from old FP papers"? As an exercize, or is there a business need?

neolog 5y ago
Inherently recursive algorithms are clearer when written in recursive style.

amkkma 5y ago

>There's a complete and total disregard to any notion of a smaller Julia or a Julia more suited for general purpose That's false. General purpose Julia is a stated goal of the core team, it's just that numerical domination is higher priority. Also, small binary static compilation with tree shaking is further along than you think

dnautics 5y ago
yeah, if anything that's what I dislike about julia, I wish it didn't claim to be a GP programming language, and instead worked more on figuring out how to glue it to languages that aren't C. For context, I have basically stopped using julia (not for any taste-related reason except I started doing jobs that were more suited for elixir and haven't had to do numerical computation since), and elixir doesn't claim to be a GP-PL and it's perfectly fine and doing quite well.
- oscardssmith 5y ago
  Is there anything you think that prevents Julia from being general purpose? The main one I run into is that the garbage collector needs work, but fundamentally I don't think there's much that keeps Julia from being good as a general purpose language.
  - dnautics 5y ago
    "JIT" (ELAOT) compilation and tail latencies. Python is a GP pl (not a very good one, IMO, but it is one). For a long time for some distros Linux CLI and even GUI tools were in python. Can you imagine such an ecosystem in Julia? I can't, nor would I want Julia to make the sacrifices it would need to make to fulfill such a role. There are so many things that python is "mediocre, but good enough" at, that Julia is quite frankly terrible at, because of the (good for what it does) choices that Julia made. I wouldn't write a quick CLI using Julia (versus a long-running or test runner CLI - I have done this professionally [0]). I wouldn't write a web server that is expected to take a load (a personal website is probably fine, though probably still quite painful). I wouldn't write Anything embedded. [0] Wrote a containerized storage block device performance measurement tool. Julia was useful to generate and track statistical distributions of random reads and writes with very clear and concise code. I also think Julia's concurrency story is not that great. But I'm biased against every PL since I have spent a ton of time in erlang/elixir-land which currently has the only (high level) concurrency story that makes any sense IMO. I liked when Julia's concurrency was done per-process (still lives on in Distributed.jl, iirc). I get that this has performance implications, especially around spawning and expensive communications, even with MPI, but I kind of wanted some sort of non-locality of data to be acknowledged, and maybe I would have preferred the new threading concurrency to work with the Distributed.jl abstraction. I think it would have been even more awesome if Julia GPU treated computation against gpu arrays in the same fashion as a distributed job... But as of the last time I used julia (it's been a while) that wasn't the case.