ihuk

(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 a while it was 12-16 cores. Not sure what the limit is these days.

Again, I am not arguing Java over Erlang. There is no lack of great examples of large successful project running on Erlang. For me and my team Erlang was just too much hassle for not much gain. Your milage may vary.

[1]https://github.com/erlang-lager/lager

Exactly my point. It scales about as well as any other language so why not use a language that's nicer to work with?

Agreed. Couple of clarifications/observations.

(1) there are situations like this:

    if
    DeductCreditInRatingGroup ->
      log("deducting credit...");
    end;

unfortunately you cannot write it this way. You have to write it as:

    if
    DeductCreditInRatingGroup ->
      log("deducting credit...");
    true -> ok
    end;

Not a huge deal but it's annoying.

(2) Let it crash attitude is something I never understood. It's just not something you can do most of the time. If subscriber consumed 2MB and you let it crash in the middle of rating function you just "lost" 2MB. With couple of million subscribers on LTE that turns into very expensive error handling very fast.

(3) We actually ended up using hackney.

(4) We were not doing anything compute heavy. I think our application was well architected and we had no problem fitting it into OTP "framework". Comparing CPU and memory usage to our Java implementation, Java is more performant.

edit: fixed code formatting.

No; as I understand it Elixir's only advantage is, arguably, better syntax. I don't mind Erlang's syntax that much.

We were handling, in peek hours, over 100k requests per second spread over 3 servers.

Funny you should mention scalability as something that somehow justifies Erlang's other shortcomings. I don't think scalability is something Erlang/OTP does out of the bag. One thing we learned the hard way is that Erlang does not do overload well at all. Erlang mailboxes are unbounded and it can get very messy very fast. I always found that design choice odd given Erlang's origins in telecommunications.

Now this is not to say you can't do massively scalable systems in Erlang, it's just that there's no silver bullet when it comes to scalability.

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 at you `inets/httpc`.

But the really big problem was the whole ecosystem. Build process was needlessly complicated. Surprisingly enough multicore support was not great. Performance was not that great. It seemed like a lot of libraries were abandoned after 2013. I could go on.

We ended up rewriting the whole thing in Java and, so far, it worked out great. And after Java 8, Java the language is not so bad. I still have somewhat found memories of Erlang but I don't miss it.

I will not comment on (1) and (2) but (3) is wrong. I don't think that's even a 737 MAX on the picture.

737 was originally designed to be low to the ground to make it easier for ground crew to "bulk" load i.e. just throw stuff into the cargo area. The reason why 737 could be so low to the ground was that they were using turbojet[1] engines. Turbojet engines are very slim compared to new turbofan engines used on later 737 generations. When they moved to turbofan engines which have bigger diameter they needed to move them higher up from the ground. So they moved the engines in front of the wings. To gain even more ground clearance they moved accessory gearbox and fuel pump from underneath the engine to the side. That's why engine appears flat on the bottom. Obviously the engine is still round because the fan is round but the lip is flattened. All this allowed Boing to fit more efficient and quieter engines to 737 without extending landing gear. The shape itself does not generate much aerodynamical lift if any.

On the 737 MAX they actually extended the landing gear and it does not feature "flattened" engine shape any more.

[1] https://en.wikipedia.org/wiki/Pratt_%26_Whitney_JT8D

If you have HP-48/49 you can get an HP-41 emulator from http://www.hrastprogrammer.com/emulators.htm. You can do synthetic programming on it.

So being barely able to write C is now Hacker News-worthy?