4 ms·

Neither of those is arguably very expressive as a language though. It's the runtime and the built-in libraries around it (OTP) that holds the power.

by hopia 7y ago

pdimitar 7y ago
What do you mean by "expressive"?
- hopia 7y ago
  Able to abstract concisely at a high level, provides decent facilities for modeling business logic in a succinct yet correct manner etc. Elixir and Erlang both lack a type system and maintain a focus on keeping the language constructs simple rather than providing various high level abstractions some other more expressive languages have.
  - pdimitar 7y ago
    I mean sure, you are right, but is there a language that is expressive by your criteria? You seem to be describing DSLs -- that can be done by all LISPs and some others -- and not programming languages per se. Elixir has very powerful macros by the way, they are compile-time and not the runtime `method_missing` stuff that Ruby does, so they are basically code generation that you don't get to see but get all the benefits from. With those macros you can go quite far creating business DSLs with Elixir (and a bunch more language, in the interest if full honesty). That's why many people qualify Elixir as "LISP-y". The lack of static typing is indeed something that is poking my eyes as well, but so far I have been managing. The extra cognitive load due to it -- plus the need to utilise the strong but dynamic typing system -- is definitely there though, cannot deny that.
    - hopia 7y ago
      I'm aware, I'm running Elixir in production, including custom macros. That said, even the macro system pales in comparison with say, Haskell, in terms of expressiveness. Haskell has such a depth of constructs and allows highly sophisticated (& safe) abstractions that you often don't feel like you'd even need a separate DSL or an embedded DSL. If anything, writing Elixir macros feels a lot like writing Typescript AST transformers to me.
      - pdimitar 7y ago
        That they are indeed. And yeah, I am aware others have more powerful macro systems. OCaml is also pretty amazing at similar workloads. Doesn't seem that we disagree on anything. You seem dissatisfied with the maturity of certain areas and that's okay.
- smabie 7y ago
  static typing (especially HKT), macros, or laziness? The BEAM is amazing, but Erlang is kind of meh. Also the BEAM is very slow so you end up writing C to get any real work done. I haven't used Elixer, but I suspect it suffers from the same problems. When the JVM finally supports preemptive multi-tasking, Erlang and the BEAM will become completely unnecessary.
  - pdimitar 7y ago
    As mentioned in a reply to your sibling comment, the lack of static typing is definitely a minus. Not denying it. Full laziness I found quite overrated while trying to write several very small business services in Haskell. Even in Elixir when you can utilise laziness in limited areas (in the I/O processing stdlibs, but there are almost no data structures for it) it's a proven fact [with benchmarks] that unless your data is at least a list with 500+ elements then laziness introduces both performance penalty and complexity. Not bashing the idea but it's not so universally good as several groups of rather religious programmers seem to make it. Right tool for the right job and all. ;) Macros is Elixir are quite powerful and very different from stuff like it's done in Ruby. They are basically compile-time code generators, utilised with crushing success in Phoenix (web framework), Absinthe (GraphQL) and Ecto (DB data mapper library). Friendly programmer advice: don't underestimate Elixir macros. Many people stayed with Elixir mostly because of them. --- > When the JVM finally supports preemptive multi-tasking, Erlang and the BEAM will become completely unnecessary. 1. Maybe, but I was hearing about preemptive multi-tasking on the JVM when I gave up on Java and that was around 2009. Believe me when I tell you, I really want at least 4-5 other runtimes to gain the capabilities of the BEAM. But alas, they still don't. Only Rust 3rd party runtime devs seem to be truly trying to push the envelope. Everybody else is like "yeah, we're gonna get it done by 2050, no worries". Sorry if that comes across as a bit cynical and dismissive, but I do read history. 2. The preemptive multi-tasking of the BEAM is indeed a huge selling point but not the only one. The actor model -- basically green threads with message inboxes -- are historically being proven more and more as a much more successful parallel computing model compared to... pretty much anything else. Really good Golang devs can kinda-sorta-partially emulate that with channels and mutexes/semaphores but it's obviously manual and error-prone. Rust's `actix` devs also agree and if you look at Techempower's benchmarks that try to emulate real web apps, you'll notice that `actix-web` is on top. Kinda funny when you think about how many people here in HN keep saying the actor model is only a good idea on paper and would never perform well in practice. Additionally, if you keep an eye on the whole ecosystem (as much as that is actually even possible) you'd notice that almost everyone, JS included, is begrudgingly moving to immutable data and lock-less synchronisation. A lot of tech is starting to come to grips with the reality of us humans being flawed and not as bright as we'd like -- me included. I paid my dues with manually crafting mutex and condition variables workflows in C for years, then translating that to Java, then Go, etc. And I can confidently say: it doesn't work sustainably well. You can make a few simple pieces with it but for long-term projects, just go with immutability and lock-less sync. --- I guess my point is, Erlang/Elixir are still quite strong and don't have much serious competition in their niche (where they are doing well). Lastly, I agree that the BEAM in general isn't the fastest thing to run code on. Absolutely. In practice however -- and I mean importing a few million lines of CSV/XML a day -- I found that if you invest just a little more effort, Elixir will stay out of your way and your code will be mostly I/O bound. I mean yeah, Elixir isn't as fast as C++ or Rust. But I already used it for several pretty different projects and it has been performing absolutely excellently. I am looking forward to learn Rust's `actix-web` though. I feel it could be a better fit for some more dramatically more computationally demanding web projects.

Neither of those is arguably very expressive as a language though. It's the runtime and the built-in libraries around it (OTP) that holds the power.

by hopia 7y ago

Neither of those is arguably very expressive as a language though. It's the runtime and the built-in libraries around it (OTP) that holds the power.

pdimitar 7y ago

What do you mean by "expressive"?

hopia 7y ago
Able to abstract concisely at a high level, provides decent facilities for modeling business logic in a succinct yet correct manner etc. Elixir and Erlang both lack a type system and maintain a focus on keeping the language constructs simple rather than providing various high level abstractions some other more expressive languages have.
- pdimitar 7y ago
  I mean sure, you are right, but is there a language that is expressive by your criteria? You seem to be describing DSLs -- that can be done by all LISPs and some others -- and not programming languages per se. Elixir has very powerful macros by the way, they are compile-time and not the runtime `method_missing` stuff that Ruby does, so they are basically code generation that you don't get to see but get all the benefits from. With those macros you can go quite far creating business DSLs with Elixir (and a bunch more language, in the interest if full honesty). That's why many people qualify Elixir as "LISP-y". The lack of static typing is indeed something that is poking my eyes as well, but so far I have been managing. The extra cognitive load due to it -- plus the need to utilise the strong but dynamic typing system -- is definitely there though, cannot deny that.
  - hopia 7y ago
    I'm aware, I'm running Elixir in production, including custom macros. That said, even the macro system pales in comparison with say, Haskell, in terms of expressiveness. Haskell has such a depth of constructs and allows highly sophisticated (& safe) abstractions that you often don't feel like you'd even need a separate DSL or an embedded DSL. If anything, writing Elixir macros feels a lot like writing Typescript AST transformers to me.
    - pdimitar 7y ago
      That they are indeed. And yeah, I am aware others have more powerful macro systems. OCaml is also pretty amazing at similar workloads. Doesn't seem that we disagree on anything. You seem dissatisfied with the maturity of certain areas and that's okay.
smabie 7y ago
static typing (especially HKT), macros, or laziness? The BEAM is amazing, but Erlang is kind of meh. Also the BEAM is very slow so you end up writing C to get any real work done. I haven't used Elixer, but I suspect it suffers from the same problems. When the JVM finally supports preemptive multi-tasking, Erlang and the BEAM will become completely unnecessary.
- pdimitar 7y ago
  As mentioned in a reply to your sibling comment, the lack of static typing is definitely a minus. Not denying it. Full laziness I found quite overrated while trying to write several very small business services in Haskell. Even in Elixir when you can utilise laziness in limited areas (in the I/O processing stdlibs, but there are almost no data structures for it) it's a proven fact [with benchmarks] that unless your data is at least a list with 500+ elements then laziness introduces both performance penalty and complexity. Not bashing the idea but it's not so universally good as several groups of rather religious programmers seem to make it. Right tool for the right job and all. ;) Macros is Elixir are quite powerful and very different from stuff like it's done in Ruby. They are basically compile-time code generators, utilised with crushing success in Phoenix (web framework), Absinthe (GraphQL) and Ecto (DB data mapper library). Friendly programmer advice: don't underestimate Elixir macros. Many people stayed with Elixir mostly because of them. --- > When the JVM finally supports preemptive multi-tasking, Erlang and the BEAM will become completely unnecessary. 1. Maybe, but I was hearing about preemptive multi-tasking on the JVM when I gave up on Java and that was around 2009. Believe me when I tell you, I really want at least 4-5 other runtimes to gain the capabilities of the BEAM. But alas, they still don't. Only Rust 3rd party runtime devs seem to be truly trying to push the envelope. Everybody else is like "yeah, we're gonna get it done by 2050, no worries". Sorry if that comes across as a bit cynical and dismissive, but I do read history. 2. The preemptive multi-tasking of the BEAM is indeed a huge selling point but not the only one. The actor model -- basically green threads with message inboxes -- are historically being proven more and more as a much more successful parallel computing model compared to... pretty much anything else. Really good Golang devs can kinda-sorta-partially emulate that with channels and mutexes/semaphores but it's obviously manual and error-prone. Rust's `actix` devs also agree and if you look at Techempower's benchmarks that try to emulate real web apps, you'll notice that `actix-web` is on top. Kinda funny when you think about how many people here in HN keep saying the actor model is only a good idea on paper and would never perform well in practice. Additionally, if you keep an eye on the whole ecosystem (as much as that is actually even possible) you'd notice that almost everyone, JS included, is begrudgingly moving to immutable data and lock-less synchronisation. A lot of tech is starting to come to grips with the reality of us humans being flawed and not as bright as we'd like -- me included. I paid my dues with manually crafting mutex and condition variables workflows in C for years, then translating that to Java, then Go, etc. And I can confidently say: it doesn't work sustainably well. You can make a few simple pieces with it but for long-term projects, just go with immutability and lock-less sync. --- I guess my point is, Erlang/Elixir are still quite strong and don't have much serious competition in their niche (where they are doing well). Lastly, I agree that the BEAM in general isn't the fastest thing to run code on. Absolutely. In practice however -- and I mean importing a few million lines of CSV/XML a day -- I found that if you invest just a little more effort, Elixir will stay out of your way and your code will be mostly I/O bound. I mean yeah, Elixir isn't as fast as C++ or Rust. But I already used it for several pretty different projects and it has been performing absolutely excellently. I am looking forward to learn Rust's `actix-web` though. I feel it could be a better fit for some more dramatically more computationally demanding web projects.