Can we beat Kafka if we build it in Elixir?
Yes.
As others have mentioned, Kafka as implemented is a very narrow, well-engineered tool. The only way to “beat” it would be to add value to their approach fundamentally.
As mentioned, ESB approaches bring scaleability issues. This is inherent to the immutable, distributed transaction log approach, event stores/sourcing, as well as more conventional rdbms as well (which rely heavily on transactional logs under the covers). And more recently, blockchain “dbs” are running into the same issues as well, being solved by fracturing through both hard forks and simply new blockchains. I say inherent because the DB and its configuration are separate data structures, which does not evolve and distribute easily.
IPFS looks very promising in it’s approach to this, but it is written in go and js. But this is precisely the scaleability issue that ibGib (src) addresses with it’s design, and it is written in Elixir (though isomorphic engines in other languages would be ultimately implemented just as IPFS is attempting).
ibGib incorporates a tree-shaking capability, which is similar to creating a stream projection in the event stream paradigm. The difference is that each record contains its own self-contained projection, so there is no single source of truth. This includes data, as well as any metadata, e.g. configuration. And the integrity is maintained via the merkle DAG (although as I’ve mentioned elsewhere it is both cyclic and acyclic).
There are other hard problems addressed in the design, largely related to growing identity and integrity beyond clusters. And this scaleability issue is only one of the multiple aspects that enable it to be the next architectural evolution for the distributed programming model.
Btw, I’m at 530+ bicycle miles for my path for ibGib now, currently in Muleshoe - almost out of Texas! 
, though David himself seems quite brilliant.