9 ms·

Elixir and Phoenix can do it all

187 points by mike1o1 3y ago

yewenjie 3y ago
Love Elixir and Phoenix, but the last time I checked (granted, two years ago), the major lack was learning material for people who weren't coming from Ruby experience.
- lawik 3y ago
  I have found learning materials to be plentiful. I came from Python which I guess looks sikilar enough to Ruby. But of course what paths you hit can vary wildly.
- givemeethekeys 3y ago
  The Elixir and Phoenix books by Pragmatic Programmers are very good. Beyond that, a little bit of practice and getting used to the docs is all I've needed (so far).
- mattferderer 3y ago
  It's been well over 2 years since I tried it out & I thought the Elixir docs were really awesome when I did it. They had great walk throughs to getting started. I also did Rob Conery's Elixir tutorial which was fun - https://robconery.com/course/take-off-with-elixir/#/ https://robconery.com/course/take-off-with-elixir/#/ Absolutely loved the way he did this one as a story but it also didn't feel like I was sitting there forever waiting for him to get to the lesson either. Looks like it's out dated though.
- ydnaclementine 3y ago
  I agree with this sentiment of lack of learning materials. I've been through the Liveview for elixir 2.5 times, and the programming pheonix book when it came out, and the they cover the simpler things of elixir. But they don't cover some of the benefits listed in the article (background jobs, service wide state, etc) with solid examples. But maybe I'm not thinking about it the right way because I am coming from a rails or whatever perspective. I've been brainstorming writing my own book that covers elixir pheonix crud, auth, background jobs, live view, (+ more?) using a twitter-clone example, which feels sufficiently complex. Basically writing a book that I wish existed.
- abrookewood 3y ago
  Pragmatic Studio have some really good courses on both Elixir & Phoenix and some are free: https://online.pragmaticstudio.com/ https://online.pragmaticstudio.com/
crummy 3y ago
I hear so much good stuff about Elixir and Phoenix (often from fly.io blogs) but I've always dismissed it for the lack of type support. Is there a TypeScript equivalent on the horizon? Or is it not so much of an issue?
- satvikpendem 3y ago
  The Gleam language is the alternative, it also runs on BEAM. It's also supported by Fly.io as is this article. It was also recently discussed [1]. [0] https://gleam.run/ https://gleam.run/ [1] https://news.ycombinator.com/item?id=38031342 https://news.ycombinator.com/item?id=38031342
- winter_blue 3y ago
  I second this question. Static typing is super critical for large projects.
  - lawik 3y ago
    I hear this a lot. I get that it is helpful. But I know people run large projects without it in Elixir and seem to do fine. Discord and remote.com seem likely to be fairly massive. Last I spoke to Remote they did 70 releases a day and no type static typing. I know from Elm that it does change how things feel. I could see an upside. But coming from a dynamic life I can't quite grok considering it a requirement.
    - sodapopcan 3y ago
      Not to mention the AXD301 :)
    - gloryjulio 3y ago
      > fairly massive It really depends on your definition of your massive. Discord seems to have a few hundreds to a thousand employees in total. I am from a typical tech company. So I could estimate that their total engineers count is probably just a couple of hundreds, which is about our director/senior director's team size. In our definition of massive, we could have even hundreds of ppl to touch the same portion of the code base frequently. We regularly have to deal with code which are about 10 years old and it's a moving target. You have to deliver quickly with migration requirement in mind. Also we frequently collaborate with the other teams and you have to be able to understand others' code quickly. Typing is critical as you don't have time to deal with the constant stream of the new projects to dig deeper in to the objects. And you really want to have some understanding of the code in the first glance. We also want to offload lots of the things to compiler and ide as much as possible. It doesn't have to be full on static typing like Java, type annotation in python/ruby already helped a lot
shijie 3y ago
We’re experiencing this at my place of work. Our backend stack is Python, and coming from an Elixir/Phoenix background, adding a durable queue to our infrastructure should be trivial but because of the nature of Python, it is all but impossible to run the queue in the same codebase and application server. Elixir and the BEAM make it so easy and pleasant to run extremely complicated infrastructure in the same codebase and in the same application context. Hard problems made easy. I miss it.
- lionkor 3y ago
  FYI "all but impossible" usually means the opposite of what you think it means - "all but" meaning "everything except". Seen this usage a lot and it bothers me, because both usages are common and theyre the exact opposites. If I didn't have context clues, it'd be difficult to know which one you mean. Edit: not native but I've always understood it as the first def here https://idioms.thefreedictionary.com/all+but https://idioms.thefreedictionary.com/all+but
  - pakitan 3y ago
    It's an idiom and means "nearly impossible". There is no other usage.
  - shijie 3y ago
    In this context I meant “all but” == “everything except” i.e it is almost impossible. Are you saying it means the opposite of how I used it? I’m not certain what you mean.
  - TJSomething 3y ago
    I'm not sure how it makes sense to claim that an action is "everything except impossible." This is more in the classic sense of "the battle was all but lost" for a battle was practically but not actually lost. You could implement a queue in a Python server, but it would be technically awful to do.
  - yodon 3y ago
    100% of the usage I've encountered as a native speaker is "all but impossible" = "almost impossible". This stems from "all but" = "almost"[0] [0]https://www.merriam-webster.com/dictionary/all%20but https://www.merriam-webster.com/dictionary/all%20but
cschmatzler 3y ago
This post is missing one huge point: its tooling is bad. Like, real bad. The language server will regularly crash, does not support code actions _at all_, messes up formatting regularly by ignoring the configuration. Then credo, the popular linter, will tell you that your imports are not alphabetically ordered but there’s no fix mode, meaning you’ll go back to order them yourself. I love the language, am using it during my day job right now, and have published multiple libraries, but the development experience can be infuriating.
- michalg 3y ago
  Regarding credo - try https://github.com/adobe/elixir-styler https://github.com/adobe/elixir-styler
- loloquwowndueo 3y ago
  Works fine for me under vim with elixir_ls and mix format.
- aeturnum 3y ago
  I also develop Elixir professionally and I find the tooling to be excellent. I've seen some transient language server crashes[1] - but I wouldn't call it common? I personally dislike Credo, but it's very customizable, and you can simply remove the "alias order" readability check[2]. [1] https://elixirforum.com/t/elixir-ls-error-undefinedfunctionerror-function-sslverifyfun-mixfile-project-0-is-undefined-module-sslverifyfun-mixfile-is-not-available/55790 https://elixirforum.com/t/elixir-ls-error-undefinedfunctione... [2] https://hexdocs.pm/credo/Credo.Check.Readability.AliasOrder.html https://hexdocs.pm/credo/Credo.Check.Readability.AliasOrder....
- sbrother 3y ago
  I find the tooling excellent. `mix` just works, and `alchemist` mode in emacs provides everything I could imagine needing. I've never heard of credo, but adding a call to `elixir-format` on save solves any linting needs I've had.
- jswny 3y ago
  I’ve been writing Elixir for years and I can’t even think of the last time I had a language server crash… Plus, these days there are many alternate LSP implementations besides Elixir LS: https://github.com/lexical-lsp/lexical https://github.com/lexical-lsp/lexical https://github.com/elixir-tools/next-ls https://github.com/elixir-tools/next-ls
SteveMorin 3y ago
Elixir/Erlang is great and excited for types. A project that would help webassembly run natively on the beam with an actor model interface. Have a proposal here: https://docs.google.com/document/d/1adXQGiDoqyJ37r8XWYthFFZf4vLHdRLHTdDYU7ksTRE/edit https://docs.google.com/document/d/1adXQGiDoqyJ37r8XWYthFFZf...
mrdoops 3y ago
This is a great resource to map "what library/thing should I use for x situation" which can sometimes be daunting to someone new to an ecosystem. The "niche" label cast at Elixir and its ecosystem hasn't been relevant for years; it can do what you need it to and with massive reduction in complexity. If or when you do need to write your own library: you'll find that straightforward as well.
banashark 3y ago
In a lot of these BEAM threads I see certain features listed as "part of the benefits", but when I look to see who is using them in production, most of the advice is "don't use that, use an established service to do that". This is usually things around either ETS/mnesia for state storage or doing hot-releases, both of which I find most people in the community recommend _against_. A few examples: - Server-wide state - Persistable data - Background Jobs Having worked in a heavy Erlang codebase and enjoyed some of the features of it, but realized some of the shortcomings where when reliability is a primary concern (medical/healthcare), a lot of the advice changes. Though I haven't written any F# in a while, I was always curious to see how F# + https://learn.microsoft.com/en-us/dotnet/orleans/overview https://learn.microsoft.com/en-us/dotnet/orleans/overview (virtual actors) would feel comparatively.
- toast0 3y ago
  I dunno, the blogging community of Erlangers seems to have a different opinion of hot-loading and mnesia scalability than I developed working at WhatsApp. Specifically, hot loading allows for tremendous agility in rolling out code: for better and worse. There's sharp edges, but it's worth it IMHO (of course, it should be noted that AFAIK, hot loading is either unused or very rarely used at WhatsApp now. I believe they now use fairly conventional rollouts where new instances are started with the new code, load balancers shift the load and old instances are shut down eventually... back in my day, we didn't have load balancers or easy access to spare machines to rotate through, etc) Mnesia has lots of sharp edges too, but if you are willing to learn them as you grow, and maybe do a bit of work here and there, disc_copies and ram_copies tables scale pretty good (afaik, we only used disc_only_copies for the schema table, and that's a small table, so it works; I don't think that table type works well with large tables). And having data and application colocated makes a lot of things pretty nice. IMHO, if you are doing the volume of data and accesses we were doing with any other database, you'd need in house engineering on the database as well, so I don't see it as a strong negative that it's needed for mnesia. If you have a smaller need, maybe it works out of the box. IMHO, mnesia works best with stable nodes and stable network though: the original use case was for two nodes in the same chassis, and the farther you stray from that, the more work you may have to do. But we had replication setup between Reston, VA and Dallas, TX and it worked fine as long as the backbone between the two wasn't being extra flakey. Again, I think post-acquisition, mnesia was phased out, but FB doesn't value stability of nodes or networks.
ahallock 3y ago
The main issue with Phoenix on the front-end is all the great component libraries target React. Developing accessible, battle-tested components (even a simple dropdown is much more involved than you think) is extremely hard and can drain a lot of development time. I've seen a few blogs about using React alongside LiveView--even sharing state--but I think we need something official.
- impulser_ 3y ago
  It actually not that hard at all with LiveView. LiveView gives you a bunch of helper functions to make it easy to build components with JS https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.html https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm... It might be hard if you never used JS before but it not as hard as you think once you build a component. Also Phoenix comes with common components like modals.
  - sb8244 3y ago
    I did heavy LiveView development for a while. The library problem definitely exists. It's very rare to find what you want already implemented, so you have to rebuild it yourself. It takes a lot of time. What I ended up doing was loading react components using LiveView hooks and syncing state using pushed events. Saved me a ton of time because libraries were all there, and worked seamlessly alongside my LiveView app.
    - impulser_ 3y ago
      There are component libaries for LiveView. https://github.com/petalframework/petal_components https://github.com/petalframework/petal_components https://github.com/coingaming/moon https://github.com/coingaming/moon I personally wouldn't use React for components in LiveView, you are just adding more complexity to your application for no reason. It really not that hard to build components using JS and LiveView. In the end you get less complex components than what you would get with react.
      - 3y ago
nologic01 3y ago
Honest question, if its so great an ecosystem why is it not adopted more? I can cite some easily available public stats: Scholar, which is compared to numpy, has like 0.001% of its popularity. (While there are rumors people buy likes on github I doubt this is something affecting the numpy project). Maybe the reason believers in elixir/erlang are more passionate is precisely because there is no obvious reason there isn't major adoption? My best guess is that the missing ingredient are major corporate interests that directly or indirectly are promoting the technology. E.g the usual big tech suspects seem to be absent. For better or worse, they are the ones dangling lucrative jobs prospects etc. But if its a technology delivering the goods people would gravitate to it sooner or later. Would be interested if more informed people can add their insights
- dartos 3y ago
  Elixir is hard to write (well) and hard to hire for because it lacks the network effect. The ruby community it aimed at initially already moved to go and JavaScript by the time phoenix became production ready. Erlang is an arcane, hard to understand language which many of the base packages of the elixir ecosystem uses. I think that’s why it’s not as popular as it should be. It’s great though. My go to stack is phoenix nowadays.
- jswny 3y ago
  Comparing Scholar or any other Elixir ML component is bizarre. Elixir has been around for many years and its ML ecosystem has only existed for the last few. Obviously Python, the most used ML ecosystem in the world, is going to be way more popular than Elixir. ML isn’t even close to the primary use case of Elixir either. This is just a bizarre comparison. Also, Scholar would be equivalent to Sklearn, not Numpy. Nx would be the Numpy equivalent. Scholar has literally only existed for 2 years.
hbcondo714 3y ago
I recently deployed a Phoenix LiveView app[1] on a shared-cpu-2x 512MB fly machine[2]. Configuration and deployment was non-trivial with their CLI. I ran `fly launch`[3] which auto-detected the project's codebase as a Phoenix app which then auto-generated a Dockerfile with support for rust NIF built using rustler so I didn't have to do anything extra to support the project's rust dependency. Overall, it was a convenient experience and wanted to share. [1] https://github.com/hbcondo/last10k_liveview https://github.com/hbcondo/last10k_liveview [2] https://fly.io/docs/about/pricing/#apps-v2-and-machines https://fly.io/docs/about/pricing/#apps-v2-and-machines [3] https://fly.io/docs/elixir/getting-started/existing/ https://fly.io/docs/elixir/getting-started/existing/
tracerbulletx 3y ago
Elixir/BEAM seems like an ideal solution to many common problems. Why has it not caught on more yet? Can anyone who uses it give a devils advocate position or is everyone just lagging behind on something thats going to get more and more common?
- AlchemistCamp 3y ago
  A lot of devs really don’t want to learn anything but the very most popular languages. A lot of managers don’t even understand that what language they use makes a difference in terms of their product or their productivity—they optimize for whatever stack they can most easily the hire the cheapest devs for. That leads to the market responding much more slowly to newer options, even when they have clear advantages. Smaller startups and indie hackers don’t have the same switching costs though, so you’ll see more of them making a bet on a less popular technology they believe has a productivity edge for their use case.
- arcanemachiner 3y ago
  I'm pretty new to the community, but I think there is something of a first-mover advantage which Python, PHP, JS, etc. have which Elixir does not: The former languages all have mature solutions to a lot of problems (in terms of packages available, not language capabilities) which Elixir has not had time to catch up to yet. Plus since these solutions already exist, there is less incentive to switch things over to the newcomer when you already have something that is working.
- davidw 3y ago
  BEAM is pretty cool, but some of what that article is talking about, the fact that you can do everything under the same roof... it's nicer than, say, Rails, but it's not like 100 times better either.
p2hari 3y ago
I would like some community feedback on this. I have been attempting to try Elixir and Phoenix and did with some small projects. However, when it comes to db, that is where I found it challenging. Ecto supports SqL and Absinthe provides graphql. However, if I want to roll out some of my own with Surreal, edgeDb and Mongodb, Neo4j or something else. I am forced to eject out ecto. I am fine with that, but how do we support other Dbs easily as Ecto or Absinthe. Are there any libraries I am missing? Has anyone tried with other options. I saw somebody mentioned mnesia. It can be an abstraction maybe .
- sb8244 3y ago
  Mongo appears to have a decent driver for it. I'd lean to that if i were looking for an alternative to SQL. You shouldn't have any issues integrating it into Absinthe, because it doesn't have any ecto bindings out of the box. (There's a helper library, but even that is fairly small.) I have heard of people using mnesia, but it's not really that common. I'd personally avoid it unless I had a good reason not to.
TinaCarriere 3y ago
[dead]

187 points by mike1o1 3y ago

Love Elixir and Phoenix, but the last time I checked (granted, two years ago), the major lack was learning material for people who weren't coming from Ruby experience.

lawik 3y ago
I have found learning materials to be plentiful. I came from Python which I guess looks sikilar enough to Ruby. But of course what paths you hit can vary wildly.
givemeethekeys 3y ago
The Elixir and Phoenix books by Pragmatic Programmers are very good. Beyond that, a little bit of practice and getting used to the docs is all I've needed (so far).
mattferderer 3y ago
It's been well over 2 years since I tried it out & I thought the Elixir docs were really awesome when I did it. They had great walk throughs to getting started. I also did Rob Conery's Elixir tutorial which was fun - https://robconery.com/course/take-off-with-elixir/#/ https://robconery.com/course/take-off-with-elixir/#/ Absolutely loved the way he did this one as a story but it also didn't feel like I was sitting there forever waiting for him to get to the lesson either. Looks like it's out dated though.
ydnaclementine 3y ago
I agree with this sentiment of lack of learning materials. I've been through the Liveview for elixir 2.5 times, and the programming pheonix book when it came out, and the they cover the simpler things of elixir. But they don't cover some of the benefits listed in the article (background jobs, service wide state, etc) with solid examples. But maybe I'm not thinking about it the right way because I am coming from a rails or whatever perspective. I've been brainstorming writing my own book that covers elixir pheonix crud, auth, background jobs, live view, (+ more?) using a twitter-clone example, which feels sufficiently complex. Basically writing a book that I wish existed.
abrookewood 3y ago
Pragmatic Studio have some really good courses on both Elixir & Phoenix and some are free: https://online.pragmaticstudio.com/ https://online.pragmaticstudio.com/

crummy 3y ago

I hear so much good stuff about Elixir and Phoenix (often from fly.io blogs) but I've always dismissed it for the lack of type support. Is there a TypeScript equivalent on the horizon? Or is it not so much of an issue?

satvikpendem 3y ago
The Gleam language is the alternative, it also runs on BEAM. It's also supported by Fly.io as is this article. It was also recently discussed [1]. [0] https://gleam.run/ https://gleam.run/ [1] https://news.ycombinator.com/item?id=38031342 https://news.ycombinator.com/item?id=38031342
winter_blue 3y ago
I second this question. Static typing is super critical for large projects.
- lawik 3y ago
  I hear this a lot. I get that it is helpful. But I know people run large projects without it in Elixir and seem to do fine. Discord and remote.com seem likely to be fairly massive. Last I spoke to Remote they did 70 releases a day and no type static typing. I know from Elm that it does change how things feel. I could see an upside. But coming from a dynamic life I can't quite grok considering it a requirement.
  - sodapopcan 3y ago
    Not to mention the AXD301 :)
  - gloryjulio 3y ago
    > fairly massive It really depends on your definition of your massive. Discord seems to have a few hundreds to a thousand employees in total. I am from a typical tech company. So I could estimate that their total engineers count is probably just a couple of hundreds, which is about our director/senior director's team size. In our definition of massive, we could have even hundreds of ppl to touch the same portion of the code base frequently. We regularly have to deal with code which are about 10 years old and it's a moving target. You have to deliver quickly with migration requirement in mind. Also we frequently collaborate with the other teams and you have to be able to understand others' code quickly. Typing is critical as you don't have time to deal with the constant stream of the new projects to dig deeper in to the objects. And you really want to have some understanding of the code in the first glance. We also want to offload lots of the things to compiler and ide as much as possible. It doesn't have to be full on static typing like Java, type annotation in python/ruby already helped a lot

shijie 3y ago

We’re experiencing this at my place of work. Our backend stack is Python, and coming from an Elixir/Phoenix background, adding a durable queue to our infrastructure should be trivial but because of the nature of Python, it is all but impossible to run the queue in the same codebase and application server. Elixir and the BEAM make it so easy and pleasant to run extremely complicated infrastructure in the same codebase and in the same application context. Hard problems made easy. I miss it.

lionkor 3y ago
FYI "all but impossible" usually means the opposite of what you think it means - "all but" meaning "everything except". Seen this usage a lot and it bothers me, because both usages are common and theyre the exact opposites. If I didn't have context clues, it'd be difficult to know which one you mean. Edit: not native but I've always understood it as the first def here https://idioms.thefreedictionary.com/all+but https://idioms.thefreedictionary.com/all+but
- pakitan 3y ago
  It's an idiom and means "nearly impossible". There is no other usage.
- shijie 3y ago
  In this context I meant “all but” == “everything except” i.e it is almost impossible. Are you saying it means the opposite of how I used it? I’m not certain what you mean.
- TJSomething 3y ago
  I'm not sure how it makes sense to claim that an action is "everything except impossible." This is more in the classic sense of "the battle was all but lost" for a battle was practically but not actually lost. You could implement a queue in a Python server, but it would be technically awful to do.
- yodon 3y ago
  100% of the usage I've encountered as a native speaker is "all but impossible" = "almost impossible". This stems from "all but" = "almost"[0] [0]https://www.merriam-webster.com/dictionary/all%20but https://www.merriam-webster.com/dictionary/all%20but

cschmatzler 3y ago

This post is missing one huge point: its tooling is bad. Like, real bad. The language server will regularly crash, does not support code actions _at all_, messes up formatting regularly by ignoring the configuration. Then credo, the popular linter, will tell you that your imports are not alphabetically ordered but there’s no fix mode, meaning you’ll go back to order them yourself. I love the language, am using it during my day job right now, and have published multiple libraries, but the development experience can be infuriating.

michalg 3y ago
Regarding credo - try https://github.com/adobe/elixir-styler https://github.com/adobe/elixir-styler
loloquwowndueo 3y ago
Works fine for me under vim with elixir_ls and mix format.
aeturnum 3y ago
I also develop Elixir professionally and I find the tooling to be excellent. I've seen some transient language server crashes[1] - but I wouldn't call it common? I personally dislike Credo, but it's very customizable, and you can simply remove the "alias order" readability check[2]. [1] https://elixirforum.com/t/elixir-ls-error-undefinedfunctionerror-function-sslverifyfun-mixfile-project-0-is-undefined-module-sslverifyfun-mixfile-is-not-available/55790 https://elixirforum.com/t/elixir-ls-error-undefinedfunctione... [2] https://hexdocs.pm/credo/Credo.Check.Readability.AliasOrder.html https://hexdocs.pm/credo/Credo.Check.Readability.AliasOrder....
sbrother 3y ago
I find the tooling excellent. `mix` just works, and `alchemist` mode in emacs provides everything I could imagine needing. I've never heard of credo, but adding a call to `elixir-format` on save solves any linting needs I've had.
jswny 3y ago
I’ve been writing Elixir for years and I can’t even think of the last time I had a language server crash… Plus, these days there are many alternate LSP implementations besides Elixir LS: https://github.com/lexical-lsp/lexical https://github.com/lexical-lsp/lexical https://github.com/elixir-tools/next-ls https://github.com/elixir-tools/next-ls

SteveMorin 3y ago

Elixir/Erlang is great and excited for types. A project that would help webassembly run natively on the beam with an actor model interface. Have a proposal here: https://docs.google.com/document/d/1adXQGiDoqyJ37r8XWYthFFZf4vLHdRLHTdDYU7ksTRE/edit https://docs.google.com/document/d/1adXQGiDoqyJ37r8XWYthFFZf...

mrdoops 3y ago

This is a great resource to map "what library/thing should I use for x situation" which can sometimes be daunting to someone new to an ecosystem. The "niche" label cast at Elixir and its ecosystem hasn't been relevant for years; it can do what you need it to and with massive reduction in complexity. If or when you do need to write your own library: you'll find that straightforward as well.

banashark 3y ago

In a lot of these BEAM threads I see certain features listed as "part of the benefits", but when I look to see who is using them in production, most of the advice is "don't use that, use an established service to do that". This is usually things around either ETS/mnesia for state storage or doing hot-releases, both of which I find most people in the community recommend _against_. A few examples: - Server-wide state - Persistable data - Background Jobs Having worked in a heavy Erlang codebase and enjoyed some of the features of it, but realized some of the shortcomings where when reliability is a primary concern (medical/healthcare), a lot of the advice changes. Though I haven't written any F# in a while, I was always curious to see how F# + https://learn.microsoft.com/en-us/dotnet/orleans/overview https://learn.microsoft.com/en-us/dotnet/orleans/overview (virtual actors) would feel comparatively.

toast0 3y ago
I dunno, the blogging community of Erlangers seems to have a different opinion of hot-loading and mnesia scalability than I developed working at WhatsApp. Specifically, hot loading allows for tremendous agility in rolling out code: for better and worse. There's sharp edges, but it's worth it IMHO (of course, it should be noted that AFAIK, hot loading is either unused or very rarely used at WhatsApp now. I believe they now use fairly conventional rollouts where new instances are started with the new code, load balancers shift the load and old instances are shut down eventually... back in my day, we didn't have load balancers or easy access to spare machines to rotate through, etc) Mnesia has lots of sharp edges too, but if you are willing to learn them as you grow, and maybe do a bit of work here and there, disc_copies and ram_copies tables scale pretty good (afaik, we only used disc_only_copies for the schema table, and that's a small table, so it works; I don't think that table type works well with large tables). And having data and application colocated makes a lot of things pretty nice. IMHO, if you are doing the volume of data and accesses we were doing with any other database, you'd need in house engineering on the database as well, so I don't see it as a strong negative that it's needed for mnesia. If you have a smaller need, maybe it works out of the box. IMHO, mnesia works best with stable nodes and stable network though: the original use case was for two nodes in the same chassis, and the farther you stray from that, the more work you may have to do. But we had replication setup between Reston, VA and Dallas, TX and it worked fine as long as the backbone between the two wasn't being extra flakey. Again, I think post-acquisition, mnesia was phased out, but FB doesn't value stability of nodes or networks.

ahallock 3y ago

The main issue with Phoenix on the front-end is all the great component libraries target React. Developing accessible, battle-tested components (even a simple dropdown is much more involved than you think) is extremely hard and can drain a lot of development time. I've seen a few blogs about using React alongside LiveView--even sharing state--but I think we need something official.

impulser_ 3y ago
It actually not that hard at all with LiveView. LiveView gives you a bunch of helper functions to make it easy to build components with JS https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.html https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm... It might be hard if you never used JS before but it not as hard as you think once you build a component. Also Phoenix comes with common components like modals.
- sb8244 3y ago
  I did heavy LiveView development for a while. The library problem definitely exists. It's very rare to find what you want already implemented, so you have to rebuild it yourself. It takes a lot of time. What I ended up doing was loading react components using LiveView hooks and syncing state using pushed events. Saved me a ton of time because libraries were all there, and worked seamlessly alongside my LiveView app.
  - impulser_ 3y ago
    There are component libaries for LiveView. https://github.com/petalframework/petal_components https://github.com/petalframework/petal_components https://github.com/coingaming/moon https://github.com/coingaming/moon I personally wouldn't use React for components in LiveView, you are just adding more complexity to your application for no reason. It really not that hard to build components using JS and LiveView. In the end you get less complex components than what you would get with react.
    - 3y ago

nologic01 3y ago

Honest question, if its so great an ecosystem why is it not adopted more? I can cite some easily available public stats: Scholar, which is compared to numpy, has like 0.001% of its popularity. (While there are rumors people buy likes on github I doubt this is something affecting the numpy project). Maybe the reason believers in elixir/erlang are more passionate is precisely because there is no obvious reason there isn't major adoption? My best guess is that the missing ingredient are major corporate interests that directly or indirectly are promoting the technology. E.g the usual big tech suspects seem to be absent. For better or worse, they are the ones dangling lucrative jobs prospects etc. But if its a technology delivering the goods people would gravitate to it sooner or later. Would be interested if more informed people can add their insights

dartos 3y ago
Elixir is hard to write (well) and hard to hire for because it lacks the network effect. The ruby community it aimed at initially already moved to go and JavaScript by the time phoenix became production ready. Erlang is an arcane, hard to understand language which many of the base packages of the elixir ecosystem uses. I think that’s why it’s not as popular as it should be. It’s great though. My go to stack is phoenix nowadays.
jswny 3y ago
Comparing Scholar or any other Elixir ML component is bizarre. Elixir has been around for many years and its ML ecosystem has only existed for the last few. Obviously Python, the most used ML ecosystem in the world, is going to be way more popular than Elixir. ML isn’t even close to the primary use case of Elixir either. This is just a bizarre comparison. Also, Scholar would be equivalent to Sklearn, not Numpy. Nx would be the Numpy equivalent. Scholar has literally only existed for 2 years.

hbcondo714 3y ago

I recently deployed a Phoenix LiveView app[1] on a shared-cpu-2x 512MB fly machine[2]. Configuration and deployment was non-trivial with their CLI. I ran `fly launch`[3] which auto-detected the project's codebase as a Phoenix app which then auto-generated a Dockerfile with support for rust NIF built using rustler so I didn't have to do anything extra to support the project's rust dependency. Overall, it was a convenient experience and wanted to share. [1] https://github.com/hbcondo/last10k_liveview https://github.com/hbcondo/last10k_liveview [2] https://fly.io/docs/about/pricing/#apps-v2-and-machines https://fly.io/docs/about/pricing/#apps-v2-and-machines [3] https://fly.io/docs/elixir/getting-started/existing/ https://fly.io/docs/elixir/getting-started/existing/

tracerbulletx 3y ago

Elixir/BEAM seems like an ideal solution to many common problems. Why has it not caught on more yet? Can anyone who uses it give a devils advocate position or is everyone just lagging behind on something thats going to get more and more common?

AlchemistCamp 3y ago
A lot of devs really don’t want to learn anything but the very most popular languages. A lot of managers don’t even understand that what language they use makes a difference in terms of their product or their productivity—they optimize for whatever stack they can most easily the hire the cheapest devs for. That leads to the market responding much more slowly to newer options, even when they have clear advantages. Smaller startups and indie hackers don’t have the same switching costs though, so you’ll see more of them making a bet on a less popular technology they believe has a productivity edge for their use case.
arcanemachiner 3y ago
I'm pretty new to the community, but I think there is something of a first-mover advantage which Python, PHP, JS, etc. have which Elixir does not: The former languages all have mature solutions to a lot of problems (in terms of packages available, not language capabilities) which Elixir has not had time to catch up to yet. Plus since these solutions already exist, there is less incentive to switch things over to the newcomer when you already have something that is working.
davidw 3y ago
BEAM is pretty cool, but some of what that article is talking about, the fact that you can do everything under the same roof... it's nicer than, say, Rails, but it's not like 100 times better either.

p2hari 3y ago

I would like some community feedback on this. I have been attempting to try Elixir and Phoenix and did with some small projects. However, when it comes to db, that is where I found it challenging. Ecto supports SqL and Absinthe provides graphql. However, if I want to roll out some of my own with Surreal, edgeDb and Mongodb, Neo4j or something else. I am forced to eject out ecto. I am fine with that, but how do we support other Dbs easily as Ecto or Absinthe. Are there any libraries I am missing? Has anyone tried with other options. I saw somebody mentioned mnesia. It can be an abstraction maybe .

sb8244 3y ago
Mongo appears to have a decent driver for it. I'd lean to that if i were looking for an alternative to SQL. You shouldn't have any issues integrating it into Absinthe, because it doesn't have any ecto bindings out of the box. (There's a helper library, but even that is fairly small.) I have heard of people using mnesia, but it's not really that common. I'd personally avoid it unless I had a good reason not to.

TinaCarriere 3y ago

[dead]