Top all-time · #4246
Hamidreza Soleimani
Personal blog · hamidreza-s.github.io · on HN as hamidreza-sprogrammingsystems
Hamidreza Soleimani's personal blog at hamidreza-s.github.io covers programming and systems. Since 2015, 18 different Hacker News readers have linked it 19 times, most often “Erlang Garbage Collection Details and Why They Matter”. No feed was found, so read it on the site itself.
Too few sampled comments (13) to say how often HN recommends it.?
Why HN links it
HN readers link these posts as in-depth explanations of Erlang and BEAM internals, mainly garbage collection, memory layout, and preemptive scheduling. They are cited when explaining how Erlang processes handle data and CPU time.
Summarised by Claude from a sample of 13 HN comments that link here. Each comment is marked recommending, critical or neutral (citing without judging); how this works.
Hamidreza Soleimani's Blog - Just about what I know
Most-linked posts?
- Erlang Garbage Collection Details and Why They Matter10 people · 11 mentions · first linked 2015-09-15
- Erlang Scheduler Details and Why They Matter8 people · 8 mentions · first linked 2016-02-09
What Hacker News says?
It's true that when Erlang was first made, machines were single-core, so parallel execution was not possible on one machine. However, the "no shared memory" process model made transitioning to true parallelism much simpler. The ability to run one scheduler per core was added around 2005 I think. See https://hamidreza-s.github.io/erlang/scheduling/real-time/pr... Also: > Erlang achieves concurrency by interleaving th…
Comment linking /erlang/scheduling/real-time/preemptive/migration/2016/02/09/erlang-scheduler-details.html
on “Ask HN: Go-to web stack today?”Submitted Erlang Scheduler Details and Why They Matter as a story · 188 points
HN discussionThis unfortunately breaks down with (bad acting) NIFs. Thankfully you can mark 'em as the dirty evil little things that they are (with negligible overhead): ERL_NIF_DIRTY_JOB_CPU_BOUND. [1] I implore anyone interested in Erlang or its surrounding languages, to read its source code. [2] More specifically, the BEAM. I'll warn you that it's very 80's hackeresque, but in a good way. Incredibly pragmatic. The way they ac…
Comment linking /erlang/scheduling/real-time/preemptive/migration/2016/02/09/erlang-scheduler-details.html
on “Why Erlang Matters”Submitted Erlang Scheduler Details (2016) as a story · 151 points
HN discussionI don't know how the Erlang GC works so I can't really comment on that If you're interested, here are a few helpful blogposts on the subject: - This is a pretty short and readable post, though it's a bit old (2008): "Garbage Collection in Erlang" [0] - A more detailed (and recent -- 2015) blogpost: "Erlang Garbage Collection Details and Why It Matters" [1]. - And this is the most up-to-date description, from April 2…
Comment linking /erlang%20garbage%20collection%20memory%20layout%20soft%20realtime/2015/08/24/erlang-garbage-collection-details-and-why-it-matters.html
on “Notes on Distributed Systems for Young Bloods (2013)”Submitted Erlang Garbage Collection Details and Why They Matter as a story · 115 points
HN discussionThe BEAM is a preemptive VM. That means that no one long running process can hog resources. The BEAM was built on a principal of responsiveness since it was originally designed for telephonics. Here's an in depth article on preemption in the BEAM that I shared with a friend this morning https://hamidreza-s.github.io/erlang/scheduling/real-time/pr...
Comment linking /erlang/scheduling/real-time/preemptive/migration/2016/02/09/erlang-scheduler-details.html
on “A Brief History of the BEAM Compiler”Submitted Erlang Garbage Collection Details and Why It Matters (2015) as a story · 114 points
HN discussionnot exactly, but you can have a look at how GC works in BEAM[1][2]. [1]: https://www.erlang-solutions.com/blog/erlang-19-0-garbage-co... [2]: https://hamidreza-s.github.io/erlang%20garbage%20collection%...
Comment linking /erlang%20garbage%20collection%20memory%20layout%20soft%20realtime/2015/08/24/erlang-garbage-collection-details-and-why-it-matters.html
on “Dismissing Python Garbage Collection at Instagram”Submitted Erlang Garbage Collection Details and Why It Matters as a story · 66 points
HN discussionI really like this blog post on Erlang's garbage collection and memory structure. https://hamidreza-s.github.io/erlang%20garbage%20collection%...
Comment linking /erlang%20garbage%20collection%20memory%20layout%20soft%20realtime/2015/08/24/erlang-garbage-collection-details-and-why-it-matters.html
on “What Erlang Taught Me About Distributed Systems”Submitted Erlang Scheduler Details and Why It Matters (2016) as a story · 1 points
HN discussionI don't believe everything is shared like this. Anything smaller than 64 bytes is copied around to different process stacks. https://hamidreza-s.github.io/erlang%20garbage%20collection%... Is a great post
Comment linking /erlang%20garbage%20collection%20memory%20layout%20soft%20realtime/2015/08/24/erlang-garbage-collection-details-and-why-it-matters.html
on “What Erlang Taught Me About Distributed Systems”I wouldn't say you are doing anything wrong (or, at least I couldn't say that for certain without knowing more about your problem domain :) ). However, I also don't think you have to worry about the message payloads being too large. In Erlang, normally objects are copied between processes. However, for large objects (>64 bytes) they are put in a shared heap, and only the pointers are copied between processes[0]. [0]…
Comment linking /erlang%20garbage%20collection%20memory%20layout%20soft%20realtime/2015/08/24/erlang-garbage-collection-details-and-why-it-matters.html
on “Message Passing and the Actor Model”Briefly, the tradeoff that Erlang and its independent process heaps model make is that garbage collection (and execution in general) occurs per-process. In practical terms, this means you have lots of little garbage collections and much fewer "large" (think "full OS process heap") collections. This provides value in a few ways: - conceptually: it is very simple. i.e., the garbage collection of one process is not log…
Comment linking /erlang%20garbage%20collection%20memory%20layout%20soft%20realtime/2015/08/24/erlang-garbage-collection-details-and-why-it-matters.html
on “Erlang/OTP 27 Highlights”(has been a while since I touched Erlang, so: grain of salt) There are several tricks that BEAM employs to work around these problems: - BEAM has dedicated threads to I/O, and system calls will happen on those dedicated threads. So, the green thread aka processes wil not be affected - (almost [1]) every call that happens "outside erlang" (that is it calls some code implemented in C inside the VM such as regexps etc.…
Comment linking /erlang/scheduling/real-time/preemptive/migration/2016/02/09/erlang-scheduler-details.html
on “The BEAM Has Spoiled Me”It would be really cool to have the sort of Erlang-style processes in python -- where each process is a green process, so don't pay the cost of OS handling stuff, but at the same time you run multiple interpreters so that you still get the benefit of multiple cores [1]. Implementation-wise, this could be made simpler than removing the GIL, if we just fully give up on the concept of shared memory. (This is above my p…
Comment linking /erlang/scheduling/real-time/preemptive/migration/2016/02/09/erlang-scheduler-details.html
on “Die Threads: Python async code [video]”This is another article with more details: https://hamidreza-s.github.io/erlang%20garbage%20collection%...
Comment linking /erlang%20garbage%20collection%20memory%20layout%20soft%20realtime/2015/08/24/erlang-garbage-collection-details-and-why-it-matters.html
on “Erlang/OTP: Garbage Collector”I believe large objects are on a shared heap. Source: https://hamidreza-s.github.io/erlang%20garbage%20collection%...
Comment linking /erlang%20garbage%20collection%20memory%20layout%20soft%20realtime/2015/08/24/erlang-garbage-collection-details-and-why-it-matters.html
on a deleted thread
