5 ms·

I like Erlang and Elixir quite a bit. However, I do think a bit of caution is warranted. With languages like Java, Ruby or Python, you can probably do an ok job

by davidw 6y ago

I like Erlang and Elixir quite a bit. However, I do think a bit of caution is warranted. With languages like Java, Ruby or Python, you can probably do an ok job at any particular task. Maybe not a great job, but good enough to get something up and running. I think BEAM has some sweet spots where it really is the best, but they're not huge spaces, and it's good to be wary of people jumping into BEAM without solid reasons why. In terms of what it's good at, we very successfully employed Erlang as the command and control language for some semi-embedded system medical devices. The runtime is predictable in terms of performance and memory, and fast enough for a lot of things. Where it wasn't, it's easy enough to talk to C. All the fault-tolerant bits are nice for a system like that where you want it to take note of a failure and restart the subsystem that failed. Lots of good logging, introspection and diagnostic tools exist.

dudul 6y ago
For what tasks is the BEAM not "good enough to get something up and running"? AFAIK, any modernish language is good enough to get something up and running regardless of the task.
- bcrosby95 6y ago
  In my experience the difficulty of using BEAM is directly related to how well your problem fits into the actor+deep copy model of the environment. For certain problems BEAM will be a terrible solution because you're going to spend a lot of time working around this. I also think this is what makes it easily the best choice for other problems that fit this model well. In the middle you will probably have a large number of problems that it's ok-ish at. But not really sure on what the distribution is here.
  - acoard 6y ago
    >For certain problems Can you give an examples? Respectfully, you were asked for tasks and instead gave a description of the category. I can only think of real-time, or real performance limited software (example: rocket guidance software, aviation, etc). With these every modicum of performance per millisecond matters; but these constraints only apply in a few (relatively) small fields of software development.
    - toast0 6y ago
      I'm an Erlang enthusiast, but find myself writing C for (small) things where I need to interface with struct heavy library calls, and nobody else has built up an BEAMy interface. I could build it, but it would take about the same work to just build my project in C. Of course, maybe there's a generalized BEAM to C call library I'm not aware of? (I didn't think to search for one until now) Also, honestly, it's a little easier to have a C daemon than an erlang daemon. Just call daemon() before the service loop vs setting up an app file. Of course, you have to build hotload yourself from dlopen and friends, and you lose out on a lot of features.
      - dnautics 6y ago
        Probably the best you're going to get for a generalized c call library is rustler or zigler (I maintain zigler)
        toast0 6y ago
        Yeah, so those look like nicer ways to call C than writing a NIF, but they don't look like point to a C include and get the constants and a way to call the functions in the include (and use the types in the include. If I'm reading correctly. I'm looking for the equivalent of Perl's h2xs, or something like that. (which incidentally, maybe I should be writing these things in perl ;)
        dnautics 6y ago
        challenge accepted: https://github.com/ityonemo/zigler/issues/240 https://github.com/ityonemo/zigler/issues/240
      - rkangel 6y ago
        Two ideas that might help: Elixir releases are built in and easy to use. You don't have to write an app file directly for instance. I usually use ports for C interface (rather than NIFs). I have a little boilerplate C and Elixir that I recycle to do the ground work and then it's just your specific implementation detail.
- davidw 6y ago
  There are things where the Ruby/Java version will be faster to use, more polished, or simply exist in the first place. I mean, yes, you can probably kinda sorta get something working with BEAM languages, but I'd occasionally hit something where Ruby had a gem, and Erlang didn't have much.
- dragonwriter 6y ago
  > AFAIK, any modernish language is good enough to get something up and running regardless of the task. A lot of languages that have more limited existing use have more gaps in their ecosystems. That means that to get something going quickly, you run into cases where you spend a lot more time building (or validating and tweaking existing but relatively rough) support infrastructure that you would just grab a well-tested, established library for in a language with a richer community and ecosystem. This is an area where the top tier ecosystems (Python, .NET, JVM) really shine over even second-tier popular ones like Ruby, and where both of those tower over things like BEAM, which has the additional problem that it has a fairly high impedance for incorporating C libraries, where many other platforms (some also with stronger ecosystems of their own) also more easily consume C libraries. This extends both to broad application domains (e.g., scientific libraries) and to things like probability of having an idiomatic, language specific, well-supported client for a new service you want to tie in and incorporate.
- monadic3 6y ago
  I've been porting code across platforms and most languages cannot embed themselves into arbitrary runtimes, for technical or political reasons. Had to go with rust rather than higher level languages. If you're running a server—sure, BEAM me up.
strokirk 6y ago
What logging tools are you using? We have a couple of Elixir stack and their logging functionality leaves much to be desired at the moment, compared to the Python standard logging library. I'd like to improve it but haven't found much guidance so far.
- hwatkins 6y ago
  I agree with that, we had to replace the whole logging module that Phoenix gives you out of the box to provide for logging messages to one line, JSON format, logging both to stdout and file. This is an area that would be easy to improve. Also distributed tracing is not easy to get working or at least the libraries I've found.
devoutsalsa 6y ago
I've worked in Elixir every day for the past 5 years. Things I like using it for: - long running services - doing anything w/ concurrency - setting up cron-like processes that run every so often - actor model anything - stateful services - web development using Phoenix & Ecto - parsing - encoding/decoding Things I don't like are primarily related to it being a small enough community. That means libraries for third party services aren't always the best, and using it in the enterprise means that the smaller talent pool is less attractive when the company's priority is to use proven/boring tech for which you can hire tons of developers. I also don't think Elixir has a clear value proposition when you're writing small, single purpose functions for a serverless architecture (even though I really like writing it), or when you're company decides to go all in on Kafka for communication between micro services. Just my two cents.
- davidw 6y ago
  I think those are all pretty good fits. The single unix process that BEAM uses is more conducive to some kinds of systems than some of the hackier-feeling solutions for the Rails ecosystem to tie different pieces together.
- zumu 6y ago
  > or when you're company decides to go all in on Kafka for communication between micro services. What's the issue with Kafka and Elixir?
  - pselbert 6y ago
    There isn't an issue with Kafka and Elixir, it's the inherent complication around using Kafka when a lighter weight solution (Rabbit, PG) would work perfectly fine.
  - deleted 6y ago
    [deleted]
- toolz 6y ago
  I hear the 3rd party library complaint a lot, but as someone who has been writing elixir professionally for about as long as you have I just haven't seen that. Speaking of kafka, the clients aren't as far along as the official clients, but the same can be said for almost all languages. Being able to utilize erlang libraries means there are a ton of heavily production tested libraries you can easily drop into an elixir project.

by davidw 6y ago

dudul 6y ago

For what tasks is the BEAM not "good enough to get something up and running"? AFAIK, any modernish language is good enough to get something up and running regardless of the task.

bcrosby95 6y ago
In my experience the difficulty of using BEAM is directly related to how well your problem fits into the actor+deep copy model of the environment. For certain problems BEAM will be a terrible solution because you're going to spend a lot of time working around this. I also think this is what makes it easily the best choice for other problems that fit this model well. In the middle you will probably have a large number of problems that it's ok-ish at. But not really sure on what the distribution is here.
- acoard 6y ago
  >For certain problems Can you give an examples? Respectfully, you were asked for tasks and instead gave a description of the category. I can only think of real-time, or real performance limited software (example: rocket guidance software, aviation, etc). With these every modicum of performance per millisecond matters; but these constraints only apply in a few (relatively) small fields of software development.
  - toast0 6y ago
    I'm an Erlang enthusiast, but find myself writing C for (small) things where I need to interface with struct heavy library calls, and nobody else has built up an BEAMy interface. I could build it, but it would take about the same work to just build my project in C. Of course, maybe there's a generalized BEAM to C call library I'm not aware of? (I didn't think to search for one until now) Also, honestly, it's a little easier to have a C daemon than an erlang daemon. Just call daemon() before the service loop vs setting up an app file. Of course, you have to build hotload yourself from dlopen and friends, and you lose out on a lot of features.
    - dnautics 6y ago
      Probably the best you're going to get for a generalized c call library is rustler or zigler (I maintain zigler)
      - toast0 6y ago
        Yeah, so those look like nicer ways to call C than writing a NIF, but they don't look like point to a C include and get the constants and a way to call the functions in the include (and use the types in the include. If I'm reading correctly. I'm looking for the equivalent of Perl's h2xs, or something like that. (which incidentally, maybe I should be writing these things in perl ;)
        dnautics 6y ago
        challenge accepted: https://github.com/ityonemo/zigler/issues/240 https://github.com/ityonemo/zigler/issues/240
    - rkangel 6y ago
      Two ideas that might help: Elixir releases are built in and easy to use. You don't have to write an app file directly for instance. I usually use ports for C interface (rather than NIFs). I have a little boilerplate C and Elixir that I recycle to do the ground work and then it's just your specific implementation detail.
davidw 6y ago
There are things where the Ruby/Java version will be faster to use, more polished, or simply exist in the first place. I mean, yes, you can probably kinda sorta get something working with BEAM languages, but I'd occasionally hit something where Ruby had a gem, and Erlang didn't have much.
dragonwriter 6y ago
> AFAIK, any modernish language is good enough to get something up and running regardless of the task. A lot of languages that have more limited existing use have more gaps in their ecosystems. That means that to get something going quickly, you run into cases where you spend a lot more time building (or validating and tweaking existing but relatively rough) support infrastructure that you would just grab a well-tested, established library for in a language with a richer community and ecosystem. This is an area where the top tier ecosystems (Python, .NET, JVM) really shine over even second-tier popular ones like Ruby, and where both of those tower over things like BEAM, which has the additional problem that it has a fairly high impedance for incorporating C libraries, where many other platforms (some also with stronger ecosystems of their own) also more easily consume C libraries. This extends both to broad application domains (e.g., scientific libraries) and to things like probability of having an idiomatic, language specific, well-supported client for a new service you want to tie in and incorporate.
monadic3 6y ago
I've been porting code across platforms and most languages cannot embed themselves into arbitrary runtimes, for technical or political reasons. Had to go with rust rather than higher level languages. If you're running a server—sure, BEAM me up.

strokirk 6y ago

What logging tools are you using? We have a couple of Elixir stack and their logging functionality leaves much to be desired at the moment, compared to the Python standard logging library. I'd like to improve it but haven't found much guidance so far.

hwatkins 6y ago
I agree with that, we had to replace the whole logging module that Phoenix gives you out of the box to provide for logging messages to one line, JSON format, logging both to stdout and file. This is an area that would be easy to improve. Also distributed tracing is not easy to get working or at least the libraries I've found.

devoutsalsa 6y ago

I've worked in Elixir every day for the past 5 years. Things I like using it for: - long running services - doing anything w/ concurrency - setting up cron-like processes that run every so often - actor model anything - stateful services - web development using Phoenix & Ecto - parsing - encoding/decoding Things I don't like are primarily related to it being a small enough community. That means libraries for third party services aren't always the best, and using it in the enterprise means that the smaller talent pool is less attractive when the company's priority is to use proven/boring tech for which you can hire tons of developers. I also don't think Elixir has a clear value proposition when you're writing small, single purpose functions for a serverless architecture (even though I really like writing it), or when you're company decides to go all in on Kafka for communication between micro services. Just my two cents.

davidw 6y ago
I think those are all pretty good fits. The single unix process that BEAM uses is more conducive to some kinds of systems than some of the hackier-feeling solutions for the Rails ecosystem to tie different pieces together.
zumu 6y ago
> or when you're company decides to go all in on Kafka for communication between micro services. What's the issue with Kafka and Elixir?
- pselbert 6y ago
  There isn't an issue with Kafka and Elixir, it's the inherent complication around using Kafka when a lighter weight solution (Rabbit, PG) would work perfectly fine.
- deleted 6y ago
  [deleted]
toolz 6y ago
I hear the 3rd party library complaint a lot, but as someone who has been writing elixir professionally for about as long as you have I just haven't seen that. Speaking of kafka, the clients aren't as far along as the official clients, but the same can be said for almost all languages. Being able to utilize erlang libraries means there are a ton of heavily production tested libraries you can easily drop into an elixir project.