Live data from Hacker News

Which companies are using Erlang, and why?

erlang-solutions.com

161–170 of 204 posts

Re: Which companies are using Erlang, and why?

#161
post #29

Earlier quoted context omitted.

Erlang's advantage is being able to build a featureful, secure, scalable and performant enough communication backend in very little time and effort. This is a niche in which it can not be beaten.

Time/effort/security/performance, really? IIRC the reasons to consider Erlang is purely to do with building a fault tolerant highly distributed system.

I would say that at least the elixir ecosystem puts a very high priority on making sane security very easy, especially Phoenix and nerves

Re: Which companies are using Erlang, and why?

#162
post #15

I have never programmed Erlang but it feels like it is the currently only language that is some kind of secret weapon. It has similar aura than Lisp had before that with Erlang you can do stuff beyond "normal" languages.

Its strengths lie in its concurrency, simple message passing, distributed design, and robust VM.

The really interesting part is message passing and easy peasy baked in communication that allows to to send messages to other erlang nodes. So building applications that talk to each other over networks is just a normal function of the language and not a higher level dependency such as a library.

The concurrency is also pretty neat as erlang treats all threads of execution as an erlang process. So merging that with the distribution and simple message passing you can easily build stuff that scales without much external tooling.

It's almost an OS unto itself. There are two interesting IoT systems which use it to such length such as GRiSP which is erlang beam ported to bare metal using RTEMS and Nerves which runs beam directly on top of a Linux kernel making beam the serspace.

Re: Which companies are using Erlang, and why?

#163
post #49

Earlier quoted context omitted.

> ...in very little time and effort. You have a very naive view of large-scale distributed systems. For companies that truly need them, "time" and "effort" are never a consideration. Furthermore, the challenges facing these companies in battling project delays and cost overruns are the 100% organizational and political, not technical.

Where did I mention "large-scale distributed systems"? My entire intention was to say Erlang is easy to get off the ground with quickly. Most companies outside of the Silicon valley bubble are resource limited.

Let me unpack my way comment:

a) Erlang (as opposed to something else) is only useful for large distributed systems.

b) If your organization is at the scale where you need a large distributed system, then the problems in your project aren't related to code or to coding speed.

Re: Which companies are using Erlang, and why?

#164
post #97

Earlier quoted context omitted.

>Are you ready to do this for your Whatsapp? I don't need to thanks to the fact that a bunch of those patches are now part of Erlang.

Note how I said it was an incomplete list of patches only . There's also signinficant tuning and optimisation, both for the Erlang VM and FreeBSD. There also things like (quotes from Highscalability): "Mnesia: Using no transactions, but with remote replication ran into a backlog. Parallelized replication for each table to increase throughput." "When Rick is going through all the changes that he made to get to 2 milli…

Honestly, I'll worry about it when I get there.

Re: Which companies are using Erlang, and why?

#165
post #84

We developed Online Charging System in Erlang that served couple million subscribers for close to three years. I found the whole experience fairly terrible. Erlang is nice enough language and I don't mind the syntax but it's also kinda cumbersome and verbose at times. For example, adding `true -> ok` to every if statement gets old fast. Similarly, Erlang/OPT is a nice platform but some parts are fairly bad. Looking a…

I can't refute your personal experience, but 10 years of Erlang work left me longing for more. It sounds as if perhaps Erlang was not used optimally, or, alternatively, best practices may not have been followed. 10 years ago the ecosystem was horrendous, and is much better now. Granted, the build experience could be better but I didn't find it that bad. I find that people's experiences are relative to what they are a…

It's funny how "you're holding it wrong" is the go to response whenever somebody criticizes Erlang. Why is that?

Re: Which companies are using Erlang, and why?

#166
post #157

Earlier quoted context omitted.

1. Here I would do something like this: log("deducting credit...", DeductCreditInRatingGroup), ... log(Msg, true) -> do_the_logging(); log(Msg, false) -> ok. Nowadays though, you should really use the new logger introduced in Erlang 21. There you can do run-time filtering on many different parameters, or even write your own handlers. Using if-statements is usually considered an anti-pattern in Erlang, and I think ver…

(1) was not about logging. I was trying to illustrate a valid use case for `if` statement that requires `true` guard expression. We used lager[1] for logging. I understand that new logger was inspired or loosely based on lager. (2) I would argue that it's a rare case you don't care about errors. (4) Multicore support in Erlang was not always great and you would run into all kinds of problems after 2-4 cores. Than for…

Can't comment on your other issues (I'll say I have noticed the complete opposite in practice, where the same team working with Java vs Erlang led to far more reliable, performant systems in Erlang, but I obviously can't speak to your experience), but for (2) -

You always care about exceptions/errors. The thing is, most you won't predict/can't handle. Those you do predict, and know how to handle, you should, because they're not really errors/exceptions at that point; they're just edge cases.

The point of Erlang is not to make it so you just throw instead of addressing an edge case; it's to make it so you reason about how, if something you don't predict and don't know how to handle happens, you can get back into a known good state. It's actually phenomenal at doing that. I've had complicated user facing production systems work without noticeable issue for years (even while under active development) in Erlang. I've never seen that in any other language. Not to say it can't happen, I just haven't seen it, and the operational lift to achieve that was no different for us than just "make it work"; we were spending the same amount of time thinking about failure cases with the Erlang system as other languages. The difference was a better approach to handling the things we didn't think of.

Re: Which companies are using Erlang, and why?

#167
post #165

Earlier quoted context omitted.

I can't refute your personal experience, but 10 years of Erlang work left me longing for more. It sounds as if perhaps Erlang was not used optimally, or, alternatively, best practices may not have been followed. 10 years ago the ecosystem was horrendous, and is much better now. Granted, the build experience could be better but I didn't find it that bad. I find that people's experiences are relative to what they are a…

It's funny how "you're holding it wrong" is the go to response whenever somebody criticizes Erlang. Why is that?

Replace "Erlang" with any other language and the statement still holds true.

If you want the obvious explanation, it's because we all have different experiences, and no one tool will be the biggest win for all teams across all domains.

Re: Which companies are using Erlang, and why?

#168
post #49

Earlier quoted context omitted.

Where did I mention "large-scale distributed systems"? My entire intention was to say Erlang is easy to get off the ground with quickly. Most companies outside of the Silicon valley bubble are resource limited.

Let me unpack my way comment: a) Erlang (as opposed to something else) is only useful for large distributed systems. b) If your organization is at the scale where you need a large distributed system, then the problems in your project aren't related to code or to coding speed.

a) But it is not. Erlang is a very productive language and works great even for small projects.

b) Needing a large distributed system is a requirement that one can get to from lots of situations. You are making way too large of a generalization.

Re: Which companies are using Erlang, and why?

#169

Earlier quoted context omitted.

My main interest in Erlang is mnesia. A relational/object hybrid data model that is suitable for telecommunications applications. A DBMS query language, Query List Comprehension (QLC) as an add-on library. Persistence. Tables can be coherently kept on disc and in the main memory. Replication. Tables can be replicated at several nodes. Atomic transactions. A series of table manipulation operations can be grouped into…

Yeah mnesia is extremely clever and very fun to learn. Also being able to store basically any term without having to do conversions is very useful. I've found some practical aspects a bit painful though. It took me a while to figure out how to make backups, migrate schemas to different sets of nodes, that sort of thing. Also there are size limits on disk-based tables which are a bit limiting, and while you can use ta…

'I also don't like the way it deals with netsplits'

I actually prefer it. Too often systems out there don't tell you what they do in the event of a netsplit. They may have marketing copy somewhere that tells you what they try to do, but then you see the Jepsen tests and realize that's a lie, or is naive, or whatever.

Mnesia makes no secrets about it. In the event of a partition it stays partitioned, operating as separate nodes. It's up to you to figure out what to do about that. You can grab a Raft implementation to perform leader election, with the tradeoffs that entails. You want it to self-heal and deconflict based on arbitrary logic, for an eventually consistent system? You can do that too. You want to pretend it doesn't happen, stick your fingers in your ears, "LALALALA" until it does and requires manual intervention? That's fine too! What it DOESN'T do is give you a false sense of security while handwaving away the decisions and implementation concerns that were made to determine CAP behavior, which I find pretty much every other distributed data store does.

It definitely has pain points in learning it, and it also has some very definite limitations, but as a baked in, minimally biased distributed store, it's a battery I really loved having included.

Re: Which companies are using Erlang, and why?

#170
post #157

Earlier quoted context omitted.

1. Here I would do something like this: log("deducting credit...", DeductCreditInRatingGroup), ... log(Msg, true) -> do_the_logging(); log(Msg, false) -> ok. Nowadays though, you should really use the new logger introduced in Erlang 21. There you can do run-time filtering on many different parameters, or even write your own handlers. Using if-statements is usually considered an anti-pattern in Erlang, and I think ver…

(1) was not about logging. I was trying to illustrate a valid use case for `if` statement that requires `true` guard expression. We used lager[1] for logging. I understand that new logger was inspired or loosely based on lager. (2) I would argue that it's a rare case you don't care about errors. (4) Multicore support in Erlang was not always great and you would run into all kinds of problems after 2-4 cores. Than for…

1. My point still stands, using if-statements is not common in Erlang exactly for the reason you mention.

2. In Erlang it usually only make sense to care about errors which you can actually handle in a sensible way. Everything else you usually "let crash" and let the supervisor tree deal with recovering. Defensive programming is another anti-pattern in Erlang in my opinion.

4. Not sure what you mean with "not great". With Erlang, if you have a completely parallelizable problem you should see close to linear scalability. If it drops of after that it's either because the problem is not parallelizable enough or because of your architecture.

Yeah, I'm not arguing Erlang over Java either. I'm just pointing out that blanket statements like this are usually because of architecture or design rather than shortcomings of the language itself.

Post reply on HN