Erlang Garbage Collection Details and Why It Matters
hamidreza-s.github.io
hamidreza-s.github.io
There is recent config setting since 19.0 to move the message queue outside the main process heap. I have seen decent performance gains from that.
Sometimes for fun I like to describe a running Erlang VM as a modern os - processes have isolated heaps and can be gc-ed independently. Then think about programing in a language with a shared heap and it is a bit like putting that mission critical code to run on Windows 95. You wouldn't do that in 2017, but somehow we still do it at the language level.
Now Rust lets us have both speed and memory safety and it allows these guarantees to happen at compile time. I think that is one of the more exciting latest development in programming languages.
Though in this context---if we were to include more than that one dimension of the memory model---pony-lang seems like it might be the more Rust-like w/ compile time guarantees, but with a general programming model of intercommunicating asynchronous processes included.
Why, on a topic about (an amazing language that is) erlang would you talk about other languages. Especially when they are nothing like erlang.
http://learnyousomeerlang.com/content
A lot of languages "emphasize safety at the top of their feature lists". By a lot i mean A LOT. If you have to compare, Erlang is similar to Haskell. Rust is nothing like erlang.
Why bring syntax as the first thing? What does that have todo with memory safety.
> By a lot i mean A LOT.
You mentioned Haskell and Ada so far. Which I agree with. What are the other ones?
A 10min investigation would bring fruit to your curiosity. But wth..
Lisp, scheme, closure, modula and smalltalk are the ones that come to my mind now that offer ONLY safe data access (modula3 has "unsafe" keyword, but only when talking to outside code). Actually R, awk, bc, shell and such are also like that, but not really general purpose. Languages that are "memory safe" by default, but include "unsafe" memory access (that come to my mind now) are C#, F#, C++ and such (Rust goes into this "category").
All functional languages are, AFAIK, "memory safe" by default (well.. you could make a functional language that lets you go out of bounds, but that wouldn't be a "pure" functional language).
In fact, as far as i know, there are more programming languages that ARE "memory safe" then ones that are not. One could just go over the wikipedia list [0] and.. list them out.
[0] https://en.wikipedia.org/wiki/List_of_programming_languages
While somewhat on the topic of functional vs "Turing" languages, here's a couple of videos. https://www.youtube.com/watch?v=eis11j_iGMs https://www.youtube.com/watch?v=RPQD7-AOjMI
So.. the only thing that prompted you to talk about Rust is memory safety ?
EDIT:
> Why bring syntax as the first thing? What does that have todo with memory safety.
Because the question i asked was "Can i ask why do you mention rust ? By that i mean what prompted you to write about rust here and now." and your answer was (paraphrased) "they bout emphasize memory safety", as if that was the only defining factor of a programming language.
Ok if C++ is memory safe, what's a memory unsafe language then?
If concurrency units (threads, co-routines) share a heap they are not memory safe. In Rust they do but Rust provide compile time checks for make sure access is safe.
awk, bc not production level languages. I think you're being disingenuous there.
> the only thing that prompted you to talk about Rust is memory safety ?
Yes
> they bout emphasize memory safety", as if that was the only defining factor of a programming language.
If you know anything about both languages that's at the top of their features list, which I mentioned.
> I also mentioned FORTRAN.
Ah interesting. So initializing a variable in FORTRAN would put that in thread local / separate heap?
First of all, we are talking about programming languages here, not about how widely they are used in "production". I know that awk is used in one giant company to do an important thing (aka dealing with money). It wouldn't surprise me to find that bc is also used in "the industry".
On that note, the TIOBE index lists Java, C, C++ and C# as being the most widely used languages. Awk is number 33, just below Ada, Prolog and Erlang. Rust is not even on the list, a list where assembly of all things holds the 14'th place. (bc is in the same group as rust there)
Erlang is also used for plenty of "heavy" things, notably in the telecommunication and banking industries. Haskell is used by facebook for their spam filter. WhatsUp is written in erlang. https://www.youtube.com/watch?v=LnX3B9oaKzw
> If you know anything about both languages that's at the top of their features list, which I mentioned.
Not everything is about "features".
> If concurrency units (threads, co-routines) share a heap they are not memory safe.
If you want to talk about concurrency you should mention "Communicating sequential processes", where from Rust did take some wisdom, but Go (as a popular example) went full in. Functional programming (lamda calculus) also lends itself extremely well to "threading", intrinsically so.
I think that discussions are about learning things, clarifying things and such "nonsense". But this discussion seems to be all about "winning at any cost". So.. goodbye.
The very last statement was a passing commentary about something that seemed conceptually correlated to the commenter.
I'm really confused by the hyper-sensitivity. With the exception of Javascript conversation threads--- where they're overwhelmed by React vs. X---almost all other language focused threads on HN are full of people making comparison and contrast statements to different things.
If you just mentioned that Ada is great without a reason you might get downvoted or just asked to provide support for you statement. If you provide a reason or compare some of the features Ada has and how they might be better in some cases, I don't think you would be. Compared to other forums, I think HN is pretty good about that.
Con: a small performance cost. Pro: a far simpler system in every other aspect. Garbage Collection and ownership is much easier when you are making copies of data.
That entirely depends on the amount of data that needs to be copied (!)
In many cases, it pays off to actually use that intricate shared memory system when possible. Yes, you lose some predictability, but you gain a lot of performance.
If you are storing a lot of data, you either tend to keep it in ETS, which has its own storage engine (and you copy the small parts of data you work on in/out of the ETS system), or as binary data, which are tracked by an ARC-like system in its own arena/heap.
Of course, if you systematically abuse the system and ask it to copy several megabytes around all the time, your efficiency will suffer. But note that this is bad form: yes, it is faster locally internally inside a given node, but once you start running true distribution, you don't want to copy megabytes of data between nodes anyway.
Shared memory tend to imply a lot of locks, which can bring a lot of contention as well. It is far more complex than just a general rule which says "copying is always bad". And this was my main point, more or less. It is a mistake to see copying for all its bad behaviour, without ever wondering what it brings to the table as a result.
I even seem to recall there was a historical implementation of the Erlang VM which didn't copy the messages, or maybe it was a port to an alternate VM like JVM...