7 ms·

LFE is really cool, but I think the biggest thing that LFE has going against it in terms of mainstream/industry adoption is that Elixir is _roughly_ a Lisp (pre

LFE is really cool, but I think the biggest thing that LFE has going against it in terms of mainstream/industry adoption is that Elixir is _roughly_ a Lisp (pretending it's not). LFE is competing against a language that has some _very_ well polished edges, and IMO it doesn't feel like LFE brings to much to the table for industry over the Lisp-y features that Elixir already has[0][1][2][3][4]. What I'd really like to see is a Mix LFE compiler[7] that lets you write LFE modules in a bigger Elixir project[5], plus a set of mix tasks like `mix lfe.repl` that integrates with the other BEAM components of your Mix projects. Long term I think it would be cool if the BEAM community comes together around the excellent tooling (mix, ExUnit, Iex) that the Elixir Team is bringing, I'd love to see other BEAM languages (LFE, Gleam[6]) with top notch integrations that let a mix project include them side by side. I think the BEAM is a really cool piece of technology, and many of these new BEAM languages offer pretty neat advantages, I'm excited to see the interop story grow over time [0] https://elixir-lang.org/getting-started/meta/macros.html https://elixir-lang.org/getting-started/meta/macros.html [1] https://elixir-lang.org/getting-started/comprehensions.html https://elixir-lang.org/getting-started/comprehensions.html [2] https://elixir-lang.org/getting-started/protocols.html https://elixir-lang.org/getting-started/protocols.html [3] https://elixir-lang.org/getting-started/basic-types.html#linked-lists https://elixir-lang.org/getting-started/basic-types.html#lin... [4] https://elixir-lang.org/getting-started/basic-types.html#anonymous-functions https://elixir-lang.org/getting-started/basic-types.html#ano... [5] This exists, but looks unmaintained https://hex.pm/packages/mix_lfe https://hex.pm/packages/mix_lfe [6] https://gleam.run/ https://gleam.run/ [7] https://hexdocs.pm/mix/1.10.2/Mix.Task.Compiler.html https://hexdocs.pm/mix/1.10.2/Mix.Task.Compiler.html

rkangel 6y ago
I completely agree. There's a higher abstraction level than the BEAM itself that it should be possible to integrate a new BEAM language at.
whynotwhynot 6y ago
I'd like to invite you to the Other Side Of The Force, Grant. http://www.petecorey.com/blog/2017/08/07/what-if-elixir-were-homoiconic/ http://www.petecorey.com/blog/2017/08/07/what-if-elixir-were... It's much more pretty over there. I haven't looked at Elixir but I have read a bit about Supervisors which I think are an excellent idea for fault tolerant systems. However, the phrase "self healing" is thrown around a lot in talks about Elixir, as if it's a magical feature of the language, without much explanation as to what it means to universally heal from faults (I think maybe they mean self healing strategies that the programmer authors and implements, not some AGI that rewrites the code on the fly to fix it, lol, but that's my gripe, mostly the hype around that... and "coding for the happy path" which is not really a rigorous statement either... maybe someone can tell me what is the happy path for an algorithm in my head without knowing the algorithm, because that somebody is me, and I don't really know my algorithms until I have thought through the not-so-happy path... I mostly code to explore what I need to specify rather than describe some specification I already have.) Maybe Elixir is not for me. Or maybe it is. I need to learn more, and go past the hype. For me, Lisp is an alien technology with great power that will never be matched, except by another Lisp. So it was great to find out about LFE! I even appreciate the separate var/fn namespaces, like nouns and verbs in natural language, e.g. fight the good fight, and I can see how it comes in handy, yet it's a new PL concept for me, so I'm still processing it.
- 67868018 6y ago
  > coding for the happy path It's not that complicated. A relatable example would be writing an API endpoint that receives data and then you do something with that data. 1. Write the endpoint so it works for the expected data. 2. You're done That's it. You don't need to worry about anyone sending you malformed payloads or fuzzing your API. You can ignore it. They cannot exploit anything, they cannot crash BEAM. It will keep working. Maybe they'll run you out of memory or CPU or bandwidth, but those are problems solved at other layers (unless you include rate limiting in your application). Ignore all errors you do not need to explicitly handle. That's the whole point. It's wonderful. Maybe you can do this in other languages with worker pools and supervisors, but it will be very expensive and high latency due to the cost of OS process forking and you're also wasting a lot of resource on context switches with that design anyway.
  - whynotwhynot 6y ago
    That is seems to be more about the underlying infra (BEAM) than the language. I thought it was something specific to Elixir. I thought they meant it at the level of program logic, which is why it seemed very confusing. I guess Lisp is about beauty and poetic justice and it shall remain in that realm. I'll look into Elixir. Seems to have a healthy and growing ecosystem.
    - dnautics 6y ago
      The underlying infra is not decouplable from the language. The beam is first and foremost designed to get stuff done easy and without error, not to be beautiful and poetic. Doesn't mean it can't be beautiful! And programming is fun because it feels like programming with training wheels on.
  - mercer 6y ago
    My 'A-ha' moment with Elixir was exactly your example. Both me and a friend were building an app that ingests cryptocurrency data and stores it in a database for later analysis. The important part was that we wanted data at regular intervals. I'm not much into all this but this is what was asked of us. He wrote the app in Python; I wrote it in Elixir. Turns out the API's of the various exchanges are (or were) atrocious. We'd get responses ranging from weird error codes to malformed data to timeouts. API's would randomly change. It was a mess. My app just chugged along, a process per request per api endpoint. When some of these endpoints 'misbehaved' the others just kept going. His app kept crashing, restart, and so one misbehaving endpoint would cause trouble for all the other ones. He had to add try...catch statements and fix the problems. I would just look at my logs, update the happy-path code, push it, and recompile() in the REPL. I also have a bunch of personal projects chugging along on my VPS. They actively handle requests a few times per hour at least, by me, and they're doing fine despite the fact that I was quick about it and only wrote the 'happy path'. There's crashes and errors all over the place, and yet when one part crashes the rest just keeps going. It's been a rare occasion where the entire supervision tree failed and the app gave up.

rkangel 6y ago

I completely agree. There's a higher abstraction level than the BEAM itself that it should be possible to integrate a new BEAM language at.

whynotwhynot 6y ago

I'd like to invite you to the Other Side Of The Force, Grant. http://www.petecorey.com/blog/2017/08/07/what-if-elixir-were-homoiconic/ http://www.petecorey.com/blog/2017/08/07/what-if-elixir-were... It's much more pretty over there. I haven't looked at Elixir but I have read a bit about Supervisors which I think are an excellent idea for fault tolerant systems. However, the phrase "self healing" is thrown around a lot in talks about Elixir, as if it's a magical feature of the language, without much explanation as to what it means to universally heal from faults (I think maybe they mean self healing strategies that the programmer authors and implements, not some AGI that rewrites the code on the fly to fix it, lol, but that's my gripe, mostly the hype around that... and "coding for the happy path" which is not really a rigorous statement either... maybe someone can tell me what is the happy path for an algorithm in my head without knowing the algorithm, because that somebody is me, and I don't really know my algorithms until I have thought through the not-so-happy path... I mostly code to explore what I need to specify rather than describe some specification I already have.) Maybe Elixir is not for me. Or maybe it is. I need to learn more, and go past the hype. For me, Lisp is an alien technology with great power that will never be matched, except by another Lisp. So it was great to find out about LFE! I even appreciate the separate var/fn namespaces, like nouns and verbs in natural language, e.g. fight the good fight, and I can see how it comes in handy, yet it's a new PL concept for me, so I'm still processing it.

67868018 6y ago
> coding for the happy path It's not that complicated. A relatable example would be writing an API endpoint that receives data and then you do something with that data. 1. Write the endpoint so it works for the expected data. 2. You're done That's it. You don't need to worry about anyone sending you malformed payloads or fuzzing your API. You can ignore it. They cannot exploit anything, they cannot crash BEAM. It will keep working. Maybe they'll run you out of memory or CPU or bandwidth, but those are problems solved at other layers (unless you include rate limiting in your application). Ignore all errors you do not need to explicitly handle. That's the whole point. It's wonderful. Maybe you can do this in other languages with worker pools and supervisors, but it will be very expensive and high latency due to the cost of OS process forking and you're also wasting a lot of resource on context switches with that design anyway.
- whynotwhynot 6y ago
  That is seems to be more about the underlying infra (BEAM) than the language. I thought it was something specific to Elixir. I thought they meant it at the level of program logic, which is why it seemed very confusing. I guess Lisp is about beauty and poetic justice and it shall remain in that realm. I'll look into Elixir. Seems to have a healthy and growing ecosystem.
  - dnautics 6y ago
    The underlying infra is not decouplable from the language. The beam is first and foremost designed to get stuff done easy and without error, not to be beautiful and poetic. Doesn't mean it can't be beautiful! And programming is fun because it feels like programming with training wheels on.
- mercer 6y ago
  My 'A-ha' moment with Elixir was exactly your example. Both me and a friend were building an app that ingests cryptocurrency data and stores it in a database for later analysis. The important part was that we wanted data at regular intervals. I'm not much into all this but this is what was asked of us. He wrote the app in Python; I wrote it in Elixir. Turns out the API's of the various exchanges are (or were) atrocious. We'd get responses ranging from weird error codes to malformed data to timeouts. API's would randomly change. It was a mess. My app just chugged along, a process per request per api endpoint. When some of these endpoints 'misbehaved' the others just kept going. His app kept crashing, restart, and so one misbehaving endpoint would cause trouble for all the other ones. He had to add try...catch statements and fix the problems. I would just look at my logs, update the happy-path code, push it, and recompile() in the REPL. I also have a bunch of personal projects chugging along on my VPS. They actively handle requests a few times per hour at least, by me, and they're doing fine despite the fact that I was quick about it and only wrote the 'happy path'. There's crashes and errors all over the place, and yet when one part crashes the rest just keeps going. It's been a rare occasion where the entire supervision tree failed and the app gave up.