9 ms·

>including being one of the few dynamic languages with a working concurrency model... Elixir is worth a look. It's a pretty productive little language with a

>including being one of the few dynamic languages with a working concurrency model... Elixir is worth a look. It's a pretty productive little language with a great concurrency model.

tombert 7y ago
For that matter, Erlang has been around for like almost 30 years and has had multicore support since 2007, and has always been dynamic.
- zzzcpan 7y ago
  In fact Elixir and Erlang are the only reasonably known dynamic languages that differentiate on concurrency. The rest either do higher order event loop concurrency, which is ok, but not a differentiator, or do worse, shared memory multithreading (threads, coroutines with synchronous channels, mutexes, etc.)
  - tombert 7y ago
    I don't really know what "differentiate" means, but Clojure has support for CSP-channel style with core.async, shared-memory with transactions using atoms/refs, and actor-ish style with the agents.
    - cstrahan 7y ago
      > I don't really know what "differentiate" means [...] Probably “set themselves apart from others”.
- davidw 7y ago
  Erlang is great, and I miss working with it, but I'd never want to write much in the way of 'quick scripts' with it. Something like Ruby feels much more productive for that.
  - tombert 7y ago
    Heh, escript isn't so bad once you get used to it. Clojure would be a great language for small-ish scripts if it weren't the dog-slow startup times, and has excellent concurrency support. I hear that GraalVM might fix that but I sadly haven't had a chance to play with that yet.
    - jdminhbg 7y ago
      GraalVM does in fact fix that. There's a (new-ish) project called babashka that lets you do some basic scripting for example: https://github.com/borkdude/babashka https://github.com/borkdude/babashka
    - didibus 7y ago
      Ya, GraalVM fixes it. But it requires a compile step, so it's not as nice for scripts. My favourite for scripting right now is Joker: https://github.com/candid82/joker https://github.com/candid82/joker Joker is a Clojure dialect which is interpreted, thus it starts super fast (but runs slower, but fast enough for scripts). Its design is to be batteries included for all things scripting. So it's just a self contained executable with everything you need for scripting. It's implemented in Go. I use it wherever I would have used bash or powershell prior. There is also Babashka: https://github.com/borkdude/babashka https://github.com/borkdude/babashka which is a similar idea, it's an interpreted dialect of Clojure with fast start times designed for scripting. The difference with Joker is that it is newer and more experimental, and it is implemented in JVM Clojure, compiled with GraalVM and has no Windows support for now. Anyways, I really recommend the use of Joker. Its awesome for scripting. I just put its binary in all my bin folders and script with it. It's great.
    - cutler 7y ago
      Even if GraalVM fixes startup times aren't JVM languages just too long-winded for scripting? Perl, Python and Ruby dominate the scripting world for a reason - standard libraries for file, dir and pathname manipulation written in a concise language. Scripting is a style of coding, not just a means to an end. It is here that dynamic languages excel. Clojure is the leanest of the JVMs but doesn't it still rely on Java for file, dir and pathname manipulation?
- lliamander 7y ago
  Oh certainly. I've done production work with Erlang, and it's great for building systems. I also love the Prolog syntax (I've also since done some side projects in Prolog for great fun). Why I suggested Elixir is because it has all the strengths of Erlang but is also a better scripting language, and would compete better with Raku on a more equal footing in that respect.
7thaccount 7y ago
When someone says they want to work in Perl6/Raku, they likely have vastly different problems than someone using Erlang/Elixer. There is overlap of course (both general purpose), but I can't imagine using Erlang for scripting, while Raku is first class here.
- weff_ 7y ago
  I'm trying to understand, what kind of scripting requires first-class concurrency that isn't fulfilled by say Python?
  - Grinnz 7y ago
    I am not that familiar with Python, but the GIL has long prevented any real in-process concurrency. Perl has concurrency but it's complex, heavy, and poorly supported. Raku's approach to this is built to avoid all these problems (like Elixir).
    - weff_ 7y ago
      I agree the GIL is a problem but it's only an issue for CPU-bound problems. Is there really an important amount of CPU-bound work that is written in a scripting language? If it's CPU-bound, wouldn't you want to use something lower level?
      - karmakaze 7y ago
        It's not just CPU bound problems, handling multiple overlapping i/o operations is more trouble than it ought to be.
        weff_ 7y ago
        Can you expand a bit on that? I'm not familiar with the issue you're describing.
      - Grinnz 7y ago
        Indeed and as a Perl developer I make use of XS/external libraries, cooperative multitasking (event loops/promises), and forking to cover these use cases. It doesn't preclude wanting the additional option to take advantage of threads in a useful way, since they do exist.

>including being one of the few dynamic languages with a working concurrency model... Elixir is worth a look. It's a pretty productive little language with a great concurrency model.

tombert 7y ago

For that matter, Erlang has been around for like almost 30 years and has had multicore support since 2007, and has always been dynamic.

zzzcpan 7y ago
In fact Elixir and Erlang are the only reasonably known dynamic languages that differentiate on concurrency. The rest either do higher order event loop concurrency, which is ok, but not a differentiator, or do worse, shared memory multithreading (threads, coroutines with synchronous channels, mutexes, etc.)
- tombert 7y ago
  I don't really know what "differentiate" means, but Clojure has support for CSP-channel style with core.async, shared-memory with transactions using atoms/refs, and actor-ish style with the agents.
  - cstrahan 7y ago
    > I don't really know what "differentiate" means [...] Probably “set themselves apart from others”.
davidw 7y ago
Erlang is great, and I miss working with it, but I'd never want to write much in the way of 'quick scripts' with it. Something like Ruby feels much more productive for that.
- tombert 7y ago
  Heh, escript isn't so bad once you get used to it. Clojure would be a great language for small-ish scripts if it weren't the dog-slow startup times, and has excellent concurrency support. I hear that GraalVM might fix that but I sadly haven't had a chance to play with that yet.
  - jdminhbg 7y ago
    GraalVM does in fact fix that. There's a (new-ish) project called babashka that lets you do some basic scripting for example: https://github.com/borkdude/babashka https://github.com/borkdude/babashka
  - didibus 7y ago
    Ya, GraalVM fixes it. But it requires a compile step, so it's not as nice for scripts. My favourite for scripting right now is Joker: https://github.com/candid82/joker https://github.com/candid82/joker Joker is a Clojure dialect which is interpreted, thus it starts super fast (but runs slower, but fast enough for scripts). Its design is to be batteries included for all things scripting. So it's just a self contained executable with everything you need for scripting. It's implemented in Go. I use it wherever I would have used bash or powershell prior. There is also Babashka: https://github.com/borkdude/babashka https://github.com/borkdude/babashka which is a similar idea, it's an interpreted dialect of Clojure with fast start times designed for scripting. The difference with Joker is that it is newer and more experimental, and it is implemented in JVM Clojure, compiled with GraalVM and has no Windows support for now. Anyways, I really recommend the use of Joker. Its awesome for scripting. I just put its binary in all my bin folders and script with it. It's great.
  - cutler 7y ago
    Even if GraalVM fixes startup times aren't JVM languages just too long-winded for scripting? Perl, Python and Ruby dominate the scripting world for a reason - standard libraries for file, dir and pathname manipulation written in a concise language. Scripting is a style of coding, not just a means to an end. It is here that dynamic languages excel. Clojure is the leanest of the JVMs but doesn't it still rely on Java for file, dir and pathname manipulation?
lliamander 7y ago
Oh certainly. I've done production work with Erlang, and it's great for building systems. I also love the Prolog syntax (I've also since done some side projects in Prolog for great fun). Why I suggested Elixir is because it has all the strengths of Erlang but is also a better scripting language, and would compete better with Raku on a more equal footing in that respect.

7thaccount 7y ago

When someone says they want to work in Perl6/Raku, they likely have vastly different problems than someone using Erlang/Elixer. There is overlap of course (both general purpose), but I can't imagine using Erlang for scripting, while Raku is first class here.

weff_ 7y ago
I'm trying to understand, what kind of scripting requires first-class concurrency that isn't fulfilled by say Python?
- Grinnz 7y ago
  I am not that familiar with Python, but the GIL has long prevented any real in-process concurrency. Perl has concurrency but it's complex, heavy, and poorly supported. Raku's approach to this is built to avoid all these problems (like Elixir).
  - weff_ 7y ago
    I agree the GIL is a problem but it's only an issue for CPU-bound problems. Is there really an important amount of CPU-bound work that is written in a scripting language? If it's CPU-bound, wouldn't you want to use something lower level?
    - karmakaze 7y ago
      It's not just CPU bound problems, handling multiple overlapping i/o operations is more trouble than it ought to be.
      - weff_ 7y ago
        Can you expand a bit on that? I'm not familiar with the issue you're describing.
    - Grinnz 7y ago
      Indeed and as a Perl developer I make use of XS/external libraries, cooperative multitasking (event loops/promises), and forking to cover these use cases. It doesn't preclude wanting the additional option to take advantage of threads in a useful way, since they do exist.