Hacker News Reader

Comment by banashark | Hacker News Reader

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 (virtual actors) would feel comparatively.

View on HN

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.

Are they still using Erlang at Whatsapp?

I should think so. I certainly haven't heard differently, and I'd expect some sort of engineering blog about rewriting an chat system evolved from ejabberd in C++ for a second time.

I think it's more that it's not recommended within the web development community which, of course, was Elixir's initial "purpose". As a web developer who has worked with a lot of web developers, I think this is pretty sound advice. However, I do wish there was more multi-node literature out there for web developers as I'm very interested in it myself. I'm talking running different OTP applications on different nodes. Almost every blog post I've found on the topic doesn't go much farther than `iex --sname foo@localhost --cookie monster`. Hopefully more in depth stuff will start to show up.

Yeah, like anything, the BEAM world can get a bit hypey.

From the first slide in the linked article, I would almost never use Erlang to store data. I'm always going to reach for Postgres there unless I've got some very specific use case.

I do think having most everything else "under the same roof" is nice for a smaller company that doesn't want to run a whole bunch of different services, though. Having an internal cron thing, and an internal job thing are probably fine for a lot of people getting something off the ground and easier to deal with than having something external to deal with. I think in particular this is often nice when trying to replicate the production environment on both a staging and local development system. If the infrastructure is complicated, that's harder to do. It's nice to be running substantially similar systems everywhere.

I'm not 100% sold that it's that big a win compared to having more libraries and such available with, say, Rails or PHP or Python or something. But it's definitely nice to have.

What did you do with Erlang and healthcare?

Reply on news.ycombinator.com