131–140 of 204 posts
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…
Earlier quoted context omitted.
You can absolutely do anything you can do in Erlang in another language. Some tasks will be easier, or harder, however. In my mind, Erlang excels in a few ways: Less often remarked, binary parsing in Erlang is rather nice. Parsing out an IPv4 packet looks like this: > = Payload, OptsSize = (IHL - 5) * 4, > = IPRest, And then you've got everything. As long as formats are reasonably documented, it's easy to parse them.…
To be fair though many Erlang programmers also avoid hot loading code. For the rest, nice summary.
Fairly blind question: does Erlang|Elixir and BEAM make any sense in a pseudo-embedded, edge compute or IoT environment with constrained resources (CPU and memory), or even ARM architecture? Aside from the developer-side things, if AMQP were to the centralized communications hub (e.g. RabbitMQ) does using Nerves on devices make any performance benefit - meaning BEAM and app(s) there? The intent would be pre-process d…
Fairly blind question: does Erlang|Elixir and BEAM make any sense in a pseudo-embedded, edge compute or IoT environment with constrained resources (CPU and memory), or even ARM architecture? Aside from the developer-side things, if AMQP were to the centralized communications hub (e.g. RabbitMQ) does using Nerves on devices make any performance benefit - meaning BEAM and app(s) there? The intent would be pre-process d…
Typically not suited for embedded.
(Assuming you mean embedded as in severely limited in resouces, and not "modern embedded" where you have lots and lots of unused system resources. If you mean the latter then anything goes.)
Earlier quoted context omitted.
Not to refute your experience, but "adding true -> ok to every if statement" sounds like an anti-pattern. A couple of notes to elaborate: 1. If-statementes should rarely be used in Erlang because case is preferred 2. If you're returning ok everywhere, you could also just let it crash by doing something akin to true = function(). Always go for let it crash first, unless you really know you can handle the error sensibl…
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 d…
log("deducting credit...", DeductCreditInRatingGroup),
...
log(Msg, true) -> do_the_logging();
log(Msg, false) -> ok.
2. Sounds like one of the rare cases where you care about the error and can also handle it. In the use case you mentioned, I would buffer the data outside of the loop that produces it and wrap the loop in a try-catch statement. That way, you don't loose the data if one iteration crashes.
4. Erlang usually ends up being good at latency and concurrency (scalability over cores), together with a smaller and easier to read code base. I'm curious about your case, and what would have made Java a better fit. If you share a lot of global objects, Java might be faster for some things (at the cost of concurrency usually). Erlang has tools for that as well though (e.g. ETS and recently persistent_term).
Earlier quoted context omitted.
To be fair though many Erlang programmers also avoid hot loading code. For the rest, nice summary.
It’s rare in production, but fantastic in development. Often I don’t even restart my Elixir app when switching between git branches, because the hot reload is enough.
Earlier quoted context omitted.
why so many negative votes? Isn't C++ a far more battle-tested language than Erlang? Hasn't C++ a far bigger community than Erlang? To all whose concern is Memory Management, learn about C++11 (and newer standards): smart pointers and heavy use of RAII pattern work shamefully good
Yes, it is battle-tested, and the testing result was the big failure: memory-related issues and vulnerabilities alone caused billions of dollars of damage, and on their way to cause more. It is generally not a good idea at all to use C++ in network-facing applications.
Earlier quoted context omitted.
why so many negative votes? Isn't C++ a far more battle-tested language than Erlang? Hasn't C++ a far bigger community than Erlang? To all whose concern is Memory Management, learn about C++11 (and newer standards): smart pointers and heavy use of RAII pattern work shamefully good
Because subjective opinions on programming languages (C++ good, Erlang less good) are really boring without some reasoning as to why.
Earlier quoted context omitted.
Interesting, do you think Elixir would be better in your case? Also what was the amount of requests per second? Looks like you didn't really need Erlang's scalability.
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 Erl…
Earlier quoted context omitted.
> But please downvote away :) I don't think you're getting downvoted because you're not praising a piece of technology; you're getting downvoted because your tone seems rude, arrogant, and like you're on a witch-hunt rather than an honest inquiry. While tech fan-clubs do exist on HN, in my experience they respond quite constructively to reasoned criticism--if it's not phrased in an unkind way.
I'm not for or against Erlang. While honestly attempting to learn something new today, I became frustrated with how devoid of content most of the comments in this thread are. "I'm {senior title}, and {tech name} is great" is as far as most of the comments go. That's just extremely mediocre.