Elixir Blog Posts

blog-posts
wiki
stickies

#407

I’ve shared 2 short posts on my first Nerves project on the nerves Slack channel and @ConnorRigby reminded me that it could be shared here as well. So here we go:


:vulcan_salute:


#408

Being one of Erlang’s most amazing features, hot code reloading is sometimes compared to replacing the wheels on a driving car…

Nice way to put it :lol:


#409

This is pretty cool. The rate limiter & circuit breaker use cases is something I didn’t think about before.


#410

Not to take away from this library which looks pretty reasonable on its own, but I don’t think you actually want to do either of those things. In a large enough cluster different servers may have different views of the external service. You don’t want to blow circuits for otherwise healthy nodes just because one unhealthy node says that their circuit is blown. Along with those reasons I would be very hesitant to add that much complexity into the critical path of the request. Rate limiting is much better done by leveraging Little’s Law and increasing or decreasing the number of outbound “connections” dynamically.

Another minor quibble with the post but this statement is inaccurate and I think potentially misleading:

Conflict-resolution is the central feature of CRDTs. In fact, CRDTs are guaranteed to converge globally , meaning that the data will (eventually) be the same at every replica.

CRDTs don’t actually guarantee this. This is a guarantee that the replication protocol has to provide. Even if you assume that there’s a replication protocol underneath your CRDT that manages this correctly it’s only a valid statement if you add the sentence, “as long as there are no network partitions”. The cold hard reality of “eventually consistent systems” (meaning inconsistent systems) is that “eventually” is only theoretical. There’s always a likelihood that your system never converges. Not stating this explicitly has the potential to grossly mislead people.


#411

Introducing GenBrowser

http://crowdhailer.me/2018-11-04/introducing-genbrowser/

Elixir (and erlang) are built on processes, which makes concurrency and distribution simpler. What if the processes model extended beyond the server, to the clients of a web application?

GenBrowser enables browsers to send and receive messages like an Elixir process. This simplifies communication and allows the actor model to be applied to reasoning about the whole client-server system.


#412

Hi @keathley, I thought the word “eventually” was enough to cover network partitions, but I’ve adjusted the wording to make it more explicit. I’ve also added some text about anti-entropy algorithms for completeness.

No comment on whether it’s actually a good idea to build some of these things, the goal of this blog post is mostly to get people thinking about different ways they might be able to use the library. Feel free to post in the comments on the blog post itself though.


#413

#414

I read Erlang/Elixir between the lines, Alan Kay’s OOP:


reminds me of: Joe Armstrong interviews Alan Kay


#415

We’ve just published a guide on how to use Planga in your Elixir/Phoenix-application:


#416

#417

#418

Hmm that article states that Cachex is only a local cache but it supports distributed caching as well:
https://hexdocs.pm/cachex/distributed-caches.html
It’s not super featureful, like I don’t know if it’s pluggable, but it supports cross BEAM node cache storage via sharding, so Nebulex is more capable if you have an external store.

I wonder how they benchmark, I’d love to see both tested with their full feature sets. ^.^


#419

Hmm that article states that Cachex is only a local cache but it supports distributed caching as well

Yeah, good catch, apparently since v3.1 supports distributed features. But overall, the main argument is not only about if the cache is distributed or not. The existing libraries are particular cache implementations, not a caching framework which is what Nebulex aims to be, be able to craft different caching topologies and patterns using different cache stores. But all these things are covered in the blog post.

It’s not super featureful, like I don’t know if it’s pluggable, but it supports cross BEAM node cache storage via sharding, so Nebulex is more capable if you have an external store

Well, I’m not sure what you meant, but Nebulex supports distributed caching by means of its distributed build-in adapter (among others) which implementing sharding (under-the-hood). Therefore, it is not necessary an external store, it is optional, and that’s the point, Nebulex doesn’t depend on an external store or any other particular cache implementation. The idea is that you can setup the adapters you need and deploy the topologies you require for your specific use case. For example, a multilevel topology where the L1 is the local cache using the built-in local adapter or even Cachex (in the roadmap there is an adapter for cachex), the L2 could be a distributed cache (using the built-in adapter), the L3 could be an external store like Redis, and so on and so forth.

I wonder how they benchmark, I’d love to see both tested with their full feature sets

Yeah, both Nebulex built-in adapters and Caches have benchmarks, you can run those benchmarks on each project and compare. But again, that’s not the point, it doesn’t matter which one is faster. The purpose of Nebulex is not to be faster than Cachex or any other cache, actually they complement each other, Cachex is a amazing cache library, and you can use it with Nebulex as well. The idea of Nebulex is to provide a caching framework you can play with, craft your own caches using the implementations you want, etc.


#420

Yep, that’s what I went on to say, Cachex’s version is not super featureful so if someone needed more detailed setup like pluggable implementations or so then Nebulex is better to use. :slight_smile:

Precisely, that’s what I was summarizing, that Nebulex is better to use especially in such scenarios. I am curious if it can handle transactional support though, I didn’t see it mentioned in the post. Like with Cachex you can access and store cached entries in bulk so no worry about out of sync issues (though it has issues doing that distributed, transactions are basically disabled then unless very specifically used).

I was actually just thinking that I wonder if Cachex could switch to using Nebulex as a backend for its distributed cache. ^.^


#421

I am curious if it can handle transactional support though, I didn’t see it mentioned in the post

Yes, Nebulex supports transactions as well (Erlang :global library is used under-the-hood). You can find more detailed info in the Nebulex Repo. Anyways I will write more about transactions, this is a very tricky feature and controversial topic that worth to be explained better :slight_smile:

I was actually just thinking that I wonder if Cachex could switch to using Nebulex as a backend for its distributed cache. ^.^

I think it might be possible, but the other option is to use Cachex from Nebulex, and that’s where the Cachex adapter comes in. But use Nebulex from Cachex sounds also interesting.

Thanks for your thoughts :slight_smile: !!!


#422

Plataformatec’s recap of their year with Elixir:

Thank you José and everyone at Plataformatec for everything you do with Elixir :purple_heart:


#423

Elixir and Erlang Ecosystem? https://link.medium.com/74U1RILJFS


Alvise Susmel's blog on Elixir
#424

Best practices for integrating with third party libraries
https://www.jackmarchant.com/articles/integrating-third-party-libraries-in-elixir


#425

Counting Real-Time Trades

In the Real-time Market-Data Updates with Elixir article, we have seen how to build a Coinbase WebSocket client and receive real-time trades. A reader asked how many trades we receive per second. In general, the rate of trades depends on the product and the time of day.
In this article we start to see how to aggregate these trades in real-time, using the GenServer behaviour. We’ll build an aggregation process that groups and count the trades.


#426

Friends, I am now at least in this respect a rare breed: an Elixir programmer who has never written Ruby.

I was never a professional Erlang programmer. I cut my teeth on Python and began working in Python, but Erlang was the language I learned after that and the one that I looked for excuses to write in (in addition to Nim, which would come a little later, but which I would also be able to finagle into production at MakeSpace).

So here was my impression of Elixir for the first several years of my passing acquaintance with it: it’s Erlang with Ruby syntax. I had never ended up writing any Ruby, and I was already happy with Erlang and its syntax. So I had a fairly simplistic understanding of the Elixir language and the roots of its popularity and it didn’t seem that there was anything of value to me.

https://blog.zdsmith.com/posts/sketches-of-elixir.html