Crowdsourcing product mentions, applying sentiment analysis, and scoring to rank products. Used to build the Start learning Elixir recommendation website. I’ve used this forum to source product mentions and recommendations for learning Elixir.
@mkunikow posted a link to this article earlier, it has some flattering comments about Elixir
Elixir appeals largely to those with Ruby or Erlang backgrounds. Its creator, José Valim, was a Rails Core developer, so it’s no surprise his creation draws much of its inspiration from Ruby. Because of its esoteric syntax, Erlang has been one of the least approachable programming languages. Yet it sits atop an incredible piece of technology. It’s the same technology which handles most of the phone calls in the world with 99.9999999% uptime. That is 32 milliseconds of downtime a year. The creators of WhatsApp scaled to hundreds of millions of users with only a few developers in part thanks to its robustness. Elixir brings this technology to the broader public.
Thanks to the Phoenix framework, Elixir will attract a lot of Rails developers. It feels like the next generation of Rails in a functional flavored Ruby. It does things with ease that Ruby has been hacked into doing: long-running processes, multi-core processing, and WebSockets, among others. I think we’ll see Elixir use grow for both monolithic-style minimum viable products and for apps that require high user concurrency like chat, messaging, and audio/video calls. The platform can also see interesting uses in Internet of Things and machine-to-machine applications because of its ability to handle large numbers of connections.[/quote]
What’s the added value of GenServer in this example? If read caching is what you’re looking for, I think ETS would be a much better idea. Using GenServers to represent objects makes your application complicated and brittle. For instance, since you’re using casts, in a high load situation the message queues can keep growing until the VM runs out of memory.
This is a great summary. I think it could be improved even further by mentioning one important aspect - naming things.
In particular the naming conventions around packages that build on top of other packages, e.g. ecto extensions, some reusable plugs, etc. It’s tempting to put your library under the Ecto.Whatever namespace, but that’s a bad idea. The Ecto namespace is already owned by the Ecto package itself and it’s easy to see what problems it might cause if it decides to add a module called Ecto.Whatever itself. It’s usually a much better idea to make the main namespace WhateverEcto or EctoWhatever - something unique to the new package.