[HN Gopher] Why I program in Erlang (2012)
___________________________________________________________________
Why I program in Erlang (2012)
Author : ianbutler
Score : 146 points
Date : 2022-11-01 19:17 UTC (3 hours ago)
(HTM) web link (www.evanmiller.org)
(TXT) w3m dump (www.evanmiller.org)
| [deleted]
| ok_dad wrote:
| I am surprised this isn't here already, I've used it twice
| already to (re)learn Erlang over a few years, and now that I'm
| reminded about it I'm going to read it again (I should pay this
| time!):
|
| https://learnyousomeerlang.com/
| Kurtose wrote:
| Great writer & engineer. Worth a re-read every couple of years
| before heading back to your blub codebase.
| latenightcoding wrote:
| >> Erlang does not use a contiguous chunk of memory to represent
| a sequence of bytes. Instead, it something called an "I/O list"
| -- a nested list of non-contiguous chunks of memory.
|
| is this cpu cache-friendly ?
| mamp wrote:
| Elixir has a vector library Nx that's designed for these use
| cases.
| crabmusket wrote:
| > almost certainly will never win any medals for speed ... The
| language is slow, awkward, and ugly
|
| I suspect the answer is probably moot.
|
| But I also think that the answer would depend on what the bytes
| are being used for, how large the chunks are, etc. CPU cache
| utilisation is influenced by many factors, and can't be deduced
| from examining the data structure _alone_.
| stonemetal12 wrote:
| Probably isn't too bad. chunks probably fill a cache line. Then
| it is just a question of whether or not beam inserts prefetches
| for the next chunk, and or the CPU prefetch realizes we are
| chasing this set of pointers.
|
| Note: I am more familiar with C++, so C++ digression here.
|
| C++ has std::deque that is a similar non-contiguous chunked
| container, comparing it to std::vector(the contiguous
| container) it is really close for things vector is good at, and
| better than it at things vector is bad at like random insert
| and removal.
|
| https://baptiste-wicht.com/posts/2012/12/cpp-benchmark-vecto...
| toast0 wrote:
| Definitely maybe. If your I/O list is a list of integers (the
| traditional Erlang string type), probably not.
|
| If your I/O list is a bunch of binaries you got from here and
| there and you don't need to inspect them, just pass them along
| to another destination, then maybe yes. When BEAM writes an I/O
| list to an FD, it's going to use scatter/gather I/O and at no
| time does BEAM need to form a contiguous chunk of memory with
| all the data; what the OS does with that is up to the OS
| though.
| asabil wrote:
| An `iolist()` or `iodata()` structure is mainly designed for
| I/O.
|
| The idea is rather simple but powerful.
|
| Let's say you want to send `"Hello " + name`, where `name` is a
| string, over the network. Traditionally, in C, you would
| allocate a buffer that is large enough and copy the "Hello "
| literal into it and then copy the `name` string before calling
| `write(fd, buffer, length)`.
|
| If you wanted to avoid allocating the buffer and doing the
| copy, you would make use of `writev(fd, iovec, count)`, and
| this is exactly what the `iolist()` structure allows for. The
| erlang runtime system (erts) makes use of efficient `writev`
| calls instead of having to allocate temporary buffers just to
| send data over the network (something Erlang is notoriously
| good at) when you make use of `iolists`.
| distortedsignal wrote:
| > ... [I]n my experience it is rarely necessary to refactor
| Erlang code in the same way the object-oriented code needs
| refactoring from time to time.
|
| That... depends. If you work with only highly disciplined people
| who want to do the right thing always, then yeah, I agree. But if
| you work with people who have deadlines or need to get stuff done
| _now_, you could see functions that take unnecessary arguments,
| or excessively large records, and those sorts of things are hard
| to work with.
|
| I think this person is an excellent engineer who loves to code
| and is really good at it, but hasn't worked with Erlang in a
| professional capacity. Which...
|
| > I have spent a large chunk of my free time programming in
| Erlang
|
| ding ding ding
| crabmusket wrote:
| Refactoring is (or should be) caused by changing requirements,
| not by the class becoming "too big". Changing requirements come
| from many places, but tend to be more common in line-of-
| business applications than free-time programming IME.
|
| That is to say: I agree with you, and I think there's some
| correlation between "software at the mercy of changing business
| requirements" and "software written in popular class-oriented
| languages".
| lgas wrote:
| The original definition of re-factoring was changing code to
| improve the quality without changing the behavior. Going by
| that definition anything you do in response to changing
| requirements is by definition, not re-factoring. I guess it's
| just come to mean "changing code" these days, but I think
| this is regression in terms of expressivity.
| andirk wrote:
| You forgot to add the tech debt contributed by people who
| either can't code well or don't care. Those two often go hand-
| in-hand
| rozap wrote:
| After programming in elixir/erlang for ~8 years (for fun and
| professionally), I have to agree. I've had to dig into the "why"
| of BEAM a number of times, and I can't remember ever being
| disappointed. The decisions that they make might be frustrating
| at the time ("why does passing a shared sub-binary through a
| process prevent it from being GC'd") but I always come away from
| the docs with the understanding of how the design decision was
| the right one in the context of the larger system, which is very
| pleasant. They just took a handful of requirements around
| concurrency and fault tolerance, and all decisions logically
| followed from those. BEAM is not good at everything, but it is
| good at the things it wants to be good at, which is refreshing.
| topaz0 wrote:
| Needs a (2012).
| lucasmullens wrote:
| I was going to say, I was surprised to see an article like this
| without at least some mention of Elixir.
| dang wrote:
| Need fulfilled. Thanks!
| _se wrote:
| See also: https://ferd.ca/the-zen-of-erlang.html (2016)
| jeffreygoesto wrote:
| This introduced me to Erlang, not much later I found myself
| watching all Joe Armstrong videos I could find and read his
| thesis [0]. It is so well written and unique in it's
| retrospective.
|
| [0] https://erlang.org/download/armstrong_thesis_2003.pdf
| mypetocean wrote:
| Do you have any favorite talks of his you can recommend?
| hinkley wrote:
| BEAM seems to be designed to be very comfortable on NUMA
| hardware, which as cpu scaling continues to grind to a halt is
| likely to become much more attractive.
| imachine1980_ wrote:
| Elixir wasn't there when the article was written, I'm not using
| it but read elixir code and look charming
| jolux wrote:
| Elixir is basically Erlang with a strong focus on developer
| experience. It carries through the legacy of careful design
| in my opinion.
| eschneider wrote:
| I'm writing some (mostly) embedded software with Elixir and
| it's...nice. Takes a bit of getting used to, but no huge
| downsides.
| myleftfoot wrote:
| brink wrote:
| As an engineer, you have a responsibility to care. Bad
| languages and bad design come with a whole host of issues, and
| are generally nightmares to maintain.
| myleftfoot wrote:
| Good comment, so true. I do care what I and my team
| programming in. I just don't do for the author of the
| article.
| dang wrote:
| Discussed at the time:
|
| _Why I Program in Erlang_ -
| https://news.ycombinator.com/item?id=4715823 - Oct 2012 (93
| comments)
| OkayPhysicist wrote:
| It's interesting reading the comments referencing the then-
| fledgling Elixir from back then. Definitely no indication it
| would end up being a ton of people's introduction to OTP and
| the BEAM.
___________________________________________________________________
(page generated 2022-11-01 23:00 UTC)