161–170 of 193 posts
Earlier quoted context omitted.
In the case of Erlang, how would immutable data help? The code all run in single thread execution path in each process; there's no need for lock anyway. Each process can't access data of another process.
Immutable data (along with per process heaps) makes the garbage collection very simple.
Earlier quoted context omitted.
I've always thought that Erlang would be more successful if it had a better deployment story, along the lines of Go or Rust: e.g. if you had the option of baking an Erlang runtime into a static binary. As it stands, software like ejabberd and rabbitmq are pretty ugly in OS package form (because distro maintainers think such packages need to rely on a common, usually very old, Erlang runtime, instead of allowing them…
please, more sources and links? i would love to package up an entire elixir app as an rpm to a rhel7 target that has no internet connection. so the package/binary needs to have everything including erlang. i am not afraid of compiling from source. is the answer distillery or something else entirely?
Earlier quoted context omitted.
I think you make the Erlang definition look unnecessarily awful. fac(0) -> 1; fac(N) -> N * fac(N-1). Or is there a particular advantage to write it using guards?
having a semantically significant distinction between ; and . is unnecessarily awful. That kind of crap is one of the reasons Elixir has so much support.
I would also like to point out that Erlang has also very good support and has seen adoption in some very critical systems as opposed to CRUD web applications which is the main domain of Elixir. Most of Ericsson’s products use Erlang to a certain degree, there are a lot of banking systems and aviation systems which make use of Erlang as well, quite a few Internet companies use it to great success, and many more.
And by the way, the semantic meaning of “;” and “.” is an awful lot similar to their use in the English language, you are blowing it out of proportions. This is a trivial thing which you learn after a 10 minutes introduction to Erlang. For me, personally, if one has a problem understanding the meaning of “;” and “.” or learning a new syntax for that matter, I can easily conclude that I probably should not give that person any decision power in designing systems.
Earlier quoted context omitted.
Well, it's a skin on the rocket that will make it big. While they generally say that Elixir runs on top of the Erlang VM there happens to be a big fat Erlang/OTP layer in-between which Elixir and its libraries make full use of. This is just smart of course but not mentioning doesn't paint the whole picture.
I'd say Elixir is the skin, like you say: without it, all your rocket pieces are out in the open and not particularly aerodynamic, and they'll start breaking off and you won't be going to space today. There are other skins, though, like LFE and Erlang itself. The Erlang VM is the engine. You can make a beautiful, sleek, aerodynamic rocket, but it ain't going anywhere unless you literally light a fire under its butt.…
Earlier quoted context omitted.
My point was not that everything which is written in Elixir can be written in Erlang but mostly that using a reference to a system that sustains a large amount of traffic which is implemented in Elixir and runs on top of the Erlang virtual machine as an argument for how incredible Elixir is, is naive at best, as Elixir is just a layer on top of many Erlang libraries and also the Erlang virtual machine. Yes, syntax ca…
Thanks for your reply! All points you make are incredibly valid, but I still have some pushback: But where would you stop? If Elixir makes it easier to write fast, concurrent for many people than Erlang, that totally can be discussed. The way you separate developer satisfaction/well-designed syntax from the VM it runs on top of is a separation I dispute. Obviously these comparisons will never be 100% valid, but I thi…
You misunderstand me. I did not say that Elixir is not different from Erlang, what I said already two times and this is the third time is that you cannot send me to some case study about how code deployed on the Erlang virtual machine performs well at high traffic and imply that the performance seen is a quality of Elixir, because it is not. Can we agree on this? That is the one and only point that I was trying to make, and if you read carefully and want to understand I think I have expressed that thought in a quite clear way. It is also a very factual truth, not a subjective matter, when we discuss syntax preference we do not discuss throughput because throughput is not a quality of the syntax. Even less so in the case of Elixir which runs on top of the Erlang virtual machine. Performance could be discussed as a function of syntax if, for instance, Elixir compiled to virtual machine instructions for the Erlang virtual machine and then had its own layer of optimizations etc. and then there would be some inherent quality of the Elixir syntax which makes those optimizations easier. But the fact of the matter is that Elixir compiles to Erlang which is then compiled to instructions for the virtual machine. Yes, Elixir it’s just syntax, I suggest you read its source code and not take my word for it. There is nothing incredible that Elixir has invented, it just looks like Ruby which made it easier to read by ex-Ruby programmers, that’s all.
Yes, of course I am biased to have a problem towards Elixir programmers making extraordinary claims when they lack cultural knowledge and brag about things that have not been invented by Elixir in any way but are qualities of a system which they very much enjoy criticizing in ignorance. I have even heard Elixir programmers talking about a so-called Elixir virtual machine which I find amazing and tells me a lot about their community and culture.
How to make sure I don't read your post: > Our site has been optimized for use with newer browsers. We also require that your browser has JavaScript enabled. > It looks as if your browser has JavaScript disabled. > This site has information about enabling JavaScript, if that's something you want to do. Really? I am just trying read a few paragraphs of text on a fairly static-looking site.
However what I'm wondering is...there's other vendors and Ericson isn't powering the entire network. What software stacks are used by other vendors? I'm assuming it's mostly C-ish stuff with some ASM sprinkles like in Cisco IOS?
> Your Erlang program should just run N times faster on an N core processor But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever. If your program has sequential or less parallel phases or needs to communicate then…
That's true, but when I read that sentence I place the emphasis on should . I see it as aspirational. A better way to phrase this would perhaps would be to say that perfectly preemptive scheduler should be able to keep all cores hot. Blocking of one Erlang process should not halt the program's progress. As Erlang requires message passing overhead by design, it will never see perfectly linear scaling behaviour. Still,…
That's Erlang's main weakness. For parallel code, structurally shared data is immensely useful for processes running in the same address space. With Erlang, you have to give that up.
OTOH, not having this possibility makes distributing processes to other nodes a lot simpler.
Earlier quoted context omitted.
That's true, but when I read that sentence I place the emphasis on should . I see it as aspirational. A better way to phrase this would perhaps would be to say that perfectly preemptive scheduler should be able to keep all cores hot. Blocking of one Erlang process should not halt the program's progress. As Erlang requires message passing overhead by design, it will never see perfectly linear scaling behaviour. Still,…
> As Erlang requires message passing overhead by design That's Erlang's main weakness. For parallel code, structurally shared data is immensely useful for processes running in the same address space. With Erlang, you have to give that up. OTOH, not having this possibility makes distributing processes to other nodes a lot simpler.
Earlier quoted context omitted.
The prescheduler caps the execution window for anything that would block. If one piece of the system would take a long time to finish, it doesn't interfere with the other parts of the system completing their work on schedule. That one blocking piece will finish more slowly, but ever other moving part in the system will keep responding as expected.
>If one piece of the system would take a long time to finish, it doesn't interfere with the other parts of the system completing their work on schedule. That one blocking piece will finish more slowly, but ever other moving part in the system will keep responding as expected. That's how it works in pretty much any language that supports message passing. I used to do MPI programming in C. Nothing you said is not true…