[HN Gopher] A brief introduction to BEAM
___________________________________________________________________
A brief introduction to BEAM
Author : codeadict
Score : 99 points
Date : 2020-10-20 14:25 UTC (1 days ago)
(HTM) web link (blog.erlang.org)
(TXT) w3m dump (blog.erlang.org)
| hinkley wrote:
| I've heard that errors in native code called via FFI in BEAM code
| is the primary place where the runtime can behave
| uncharacteristically. I haven't seen anyone in the community
| describe it this way but it has the feel of undefined behavior to
| it.
|
| There's apparently some heightened interest in Rust for these
| purposes because its guarantees offer some additional robustness
| here.
|
| But having JIT for the BEAM changes the calculus of whether it's
| worth maintaining your code in two languages for a speed
| improvement that comes with additional liabilities. It will be
| interesting to see what libraries and tools become pure as the
| JIT covers more territory.
| rozap wrote:
| It's super exciting, but the JIT in its current form doesn't
| offer the kind of speedup that something like FFI into Rust or
| C provides. Also there are lots of great libraries in the
| Rust/C ecosystems that sometimes you need. Fortunately FFI is
| not hard, and with the relatively recent addition of dirty
| schedulers and with the Rustler library, it doesn't block the
| schedulers and it is safe, which were the two biggest issues.
| toast0 wrote:
| When you call into native code, you're explicitly opening the
| door to letting whatever happen happen. It's not undefined,
| it's a clearly defined escape hatch to do whatever. There's
| rules to follow, but it's the honor system, BEAM doesn't care
| if you do or not, but you'll have to live with the decisions
| you make.
| adenozine wrote:
| I wish there was a python implementation that ran on BEAM.
| ch4s3 wrote:
| Luerl is probably the closest thing in terms of semantics, but
| Elixir might feel right in terms of Syntax. Actually running
| Python on the BEAM would probably be pretty challenging based
| on what I've read about the GraalVM python efforts.
| blixtsnabb wrote:
| There is efene (https://efene.org) which claims to embrace the
| ZEN of python.
| josefrichter wrote:
| go for elixir. the differences compared to python are
| minuscule.
| macintux wrote:
| Here's a reasonably exhaustive list of languages that do:
|
| https://gist.github.com/macintux/6349828#alternative-languag...
| rdtsc wrote:
| The JIT in OTP 24 mentioned at the top was discussed in
| https://news.ycombinator.com/item?id=24441841
|
| I am looking forward to more blog posts about it.
|
| A few interesting snippets from the PR comments from it:
|
| ---
|
| [...] number of Estones as computed by the estone benchmark suite
| becomes about 50% larger, meaning about 50% more work can be done
| during the same time period. Individual benchmarks within the
| estone benchmark suite vary from a 170% increase (pattern
| matching) to no change at all (huge messages)
|
| [...] If we run the JSON benchmarks found in the Poison or Jason,
| BeamAsm achieves anything from 30% to 130% increase (average at
| about 70%) in the number of iterations per second for all
| Erlang/Elixir implementations.
|
| ---
| dnautics wrote:
| well, this is pretty timely. I have been peeking at some of the
| opcodes in the BEAM and some of this stuff I had gotten wrong;
| since there isn't AFAICT easy-to-find documentation on how this
| works. Does anyone know of other resources along these lines?
| RobertKerans wrote:
| https://github.com/happi/theBeamBook
| hkgumbs wrote:
| I'd highly recommend "The Beam Book" by Erik Stenman:
| https://blog.stenmans.org/theBeamBook/
|
| A few years ago, I spent my free time building a Haskell BEAM
| codegen library, and that was by far the best resource I found.
| I noted some other projects that helped me understand things
| here: https://github.com/kofigumbs/codec-beam#acknowledgements
| dnautics wrote:
| I'm familiar with the beam book but iirc it's incomplete, in
| particular in terms of what OP speaks of :|
| phoe-krk wrote:
| In the exception example, there is a line saying:
| {'try',{y,0},{f,13}}.
|
| Why is the symbol `try` quoted here? Does it need to, if its name
| is all lowercase?
| rdtsc wrote:
| Because 'try' is also a keyword in Erlang. The other symbols
| like that without the quotes are atoms
| (http://erlang.org/doc/reference_manual/data_types.html#atom).
|
| So to have an atom named after a keyword we'd have to add
| single quotes around it.
| phoe-krk wrote:
| Yes, got it - thank you for the response.
___________________________________________________________________
(page generated 2020-10-21 23:00 UTC)