[HN Gopher] How I fell in love with Erlang
___________________________________________________________________
How I fell in love with Erlang
Author : asabil
Score : 354 points
Date : 2025-11-01 21:00 UTC (10 days ago)
(HTM) web link (boragonul.com)
(TXT) w3m dump (boragonul.com)
| az09mugen wrote:
| Unrelated to the topic, but I really like the feature `> cd ..`
| at the bottom of the article. It's simple and accessible even
| with a smartphone. I wonder if there is an easter egg inside.
| ramon156 wrote:
| I'd also love a `cd -` on the top left
| darkwater wrote:
| Because the homepage has this "interactive terminal" which is
| funny and nice (kudos for readline shortcut support) but also
| partially "broken", i.e. the blog post(s) and other links you
| see with "ls" are not clickable, at least on Firefox.
| Gleamball wrote:
| Great talk i love it and thanx for sharing.
| abrookewood wrote:
| Great article & I love the command line interface on the home
| page.
| vortegne wrote:
| Nice post, looking forward to more!
| jacquesm wrote:
| It's funny how HN goes through these Erlang cycles. It's a long
| standing tradition, starting off with 'Erlang Day':
| https://news.ycombinator.com/front?day=2009-03-11
|
| Erlang gets a lot of stuff right for scalable web based stuff,
| and even though there are many of its influences that have by now
| made it into other languages and eco systems it is still amazing
| to me that such a well thought out system is run with such
| incredible modesty. You'll never see the people behind Erlang be
| confrontational or evangelists, they just do what they're good at
| and it is up to you whether you adopt it or not. And that is an
| interesting thing: the people that are good at this are writing
| code, not evangelizing. If I had to reboot my career I'd pick
| this eco system over anything else, it has incredible staying
| power, handles backwards compatibility issues with grace and has
| a community that you can be proud of joining. Modest, competent,
| and with a complete lack of drama.
| marceldegraaf wrote:
| It's funny that you mention this, and it made me take some time
| to appreciate I've been working with Elixir full-time for
| almost 10 years now, and the entire experience has been so...
| stable.
|
| There's been little drama, the language is relatively stable,
| the community has always been there when you need them but
| aren't too pushy and flashy. It all feels mature and - in the
| best possible way - boring, and that is awesome.
| noosphr wrote:
| I've moved from Linux to OpenBSD for this reason.
|
| It's all so boring it's wonderful.
| christophilus wrote:
| I like OpenBSD, but I like Docker and Steam too much to
| daily-drive it.
| fridder wrote:
| FreeBSD can do OCI containers now!
| zwnow wrote:
| For me it took a tremendous amount of work to somewhat
| understand the OTP stuff though. Its one of those languages
| where I can never be confident about my implementations, and
| thankfully it has features to check whether you have stale
| processes or whatever. A language I am humbled by whenever I
| use it.
| giraffe_lady wrote:
| I love saying this but OTP is a really roughneck standard
| library. They just added shit to it as they needed it
| without apparently putting too much consideration into the
| organization, naming, or conventions.
|
| It makes it very powerful but very disorienting and
| experience gained with one part of it often does not really
| prepare you for other parts. Usually each specific tool was
| created by someone who used it immediately, so it's all
| reliable in its way. But there is a lot of redundancy and
| odd gaps.
|
| Elixir's almost extreme attention to naming, organization,
| and consistent convention is almost as far as you can get
| from this approach too. It's fun to have them in the same
| ecosystem and see that there are actually pros and cons to
| each approach.
| asa400 wrote:
| Thank you for this post and I'll add a note for people who
| are seeing this and are maybe discouraged about learning
| Erlang/OTP/Elixir.
|
| I generally agree with you that learning Erlang stuff can
| be daunting.
|
| I will say that many things worth doing are not easy!
| Erlang and the whole OTP way of thinking is tough to learn
| in part because it is genuinely different enough from
| everything else that is out there that one's odds of being
| familiar with its conceptual underpinnings are low.
|
| If you have trouble learning Erlang (and OTP specifically)
| it's not because you're dumb, it's because Erlang is
| different.
|
| Learning Erlang is not like learning any other dynamic
| language you've learned. Learning Erlang is closer to
| learning a bespoke operating system designed to build
| reliable low-latency long-running systems. It's a larger
| conceptual lift than going from one dynamic OOP language to
| another dynamic OOP language.
| simoncion wrote:
| It also took me quite a bit of time to understand OTP. In
| fact, I had to have a project that actually required what
| OTP offered to really _get_ it.
|
| Two things that definitely helped me understand were
| reading the somewhat-dated-but-still-useful material on the
| topic in Learn You Some Erlang, as well as reading through
| the "OTP Design Principles" section of the Erlang System
| Documentation.
| toast0 wrote:
| Here's a trick to confidence in a BEAM system. If you get
| good at hot loading, you significantly reduce the cost of
| deployment, and you don't need as much pre-push confidence.
| You can do things like "I think this works, and if it
| crashes, I'll revert or fix forward right away" that just
| aren't a good fit for a more common deployment pattern
| where you build the software, then build a container, then
| start new instances, then move traffic, etc.
|
| Of course, there are some changes that you need confidence
| in before you push, but for lots of things, a bit crashy as
| an intermediate step is acceptable.
|
| As for understanding the OTP stuff, I think you have to be
| willing to look at their code. Most of it fits into the 'as
| simple as possible' mold, although there's some places
| where the use case is complex and it shows in the code, or
| performance needs trumped simplicity.
|
| There's also a lot of implicitness for interaction between
| processes. That takes a bit of getting used to, but I try
| to just mentally model each process in isolation: what does
| it do when it receives a message, does that make sense,
| does it need to change; and not worry about the sender at
| that time. Typically, when every process is individually
| correct, the whole system is correct; of course, if that
| always worked, distributed systems would be very boring and
| they're not.
| bostik wrote:
| Erlang's hot reload is a two-edged blade. (Yes yes,
| everything is a tradeoff but this is on another level.)
|
| _Because_ it 's possible to do hot code reloading, and
| since you can attach a REPL session into a running BEAM
| process, running 24/7 production Erlang systems - rather
| counterintuitively - can encourage somewhat questionable
| practices. It's too easy to hot-patch a live system
| during firefighting and then forget to retrofit the fix
| to the source repo. I _know_ that one of the outages in
| the previous job was caused by missing retrofit patch,
| post deployment.
|
| The running joke is that there have been some Ericsson
| switches that could not be power cycled because their
| only correct state was the one running the network, after
| dozens of live hot patches over time had accumulated that
| had not been correctly committed to the repository.
| toast0 wrote:
| You certainly can forget to push fixes to the source
| repo. But if you do that enough times, it's not hard to
| build tools to help you detect it. You can get enough
| information out of loaded modules to figure out if they
| match what's supposed to be there.
|
| I had thought there was a way to get the currently loaded
| object code for a module, but code:get_object_code/1
| looks like it pulls from the filesystem. I would think in
| the situation where you a) don't know what's running, and
| b) have the OTP team on staff, you could most likely
| write a new module to at least dump the object code (or
| something similar), and then spend some time turning that
| back into source code. But it makes a nice story.
|
| [1] https://www.erlang.org/doc/apps/kernel/code.html#get_
| object_...
| manveru wrote:
| You can run https://www.erlang.org/doc/apps/kernel/code.h
| tml#modified_mo... in some process and make it send
| notifications to your monitoring when anything stays
| modified for too long.
| toast0 wrote:
| That's part of it yeah. But, at least in my experience,
| that tells me you pushed code (to disk) and didn't load
| it. You could probably just notify at 4 am every day if
| erlang:modified_modules() /= []; assuming you don't
| typically do operations overnight. No big deal if you're
| doing emergency fixes at 4 am, you'll get an extra
| notification, but you're probably knee deep in
| notifications, what's one more per node?
|
| But, that's not enough to tell you that the code on disk
| doesn't match what it's supposed to be. You'd need to
| have some infrastructure that keeps track of that too.
| But if you package your code, your package system
| probably has a check, which you can probably also run at
| 4 am.
| jacquesm wrote:
| Being boring is _the_ hallmark of technology that it is worth
| to invest a career into.
| noir_lord wrote:
| > You'll never see the people behind Erlang be confrontational
| or evangelists, they just do what they're good at and it is up
| to you whether you adopt it or not.
|
| The big open source projects where pretty much _all_ like that
| in the past, in the 80 's/90's/early 2000's - in that respect
| they feel like a pleasant anachronism before everything
| _needed_ to be promoted /self-promotional influencer like, the
| users did the evangelism but the creators where usually much
| more chill.
|
| Obviously the vast majority of open source projects are still
| like that but there is definitely a lot more in your face
| promotion of things that feels different somehow almost
| aggressive/corporate style _even when there is no paid
| product_.
|
| Not knocking the ones who do it, if it's open source they can
| sing it from a mountain top for all I care, the license it's
| under matters more.
| actionfromafar wrote:
| I think it's because we are wired that attention is it's own
| currency nowadays. And it's also true. Even if there's no
| paid product, you get strength in numbers. If you depend on
| an open source library, it's usually better for you if others
| depend on it too.
| noir_lord wrote:
| Certainly an element of that but there are also cases where
| the superior product "lost" to the inferior product because
| the inferior one was better marketed.
|
| So doing some level of promotion becomes necessary if you
| want users even when you have the better product - the
| superior product speaks for itself doesn't often apply any
| more.
| marcosdumay wrote:
| > doesn't often apply any more
|
| It actually never did, for almost any product.
|
| And programming languages are in the lower end of quality
| actually impacting decisions. People are incredibly
| resistant to changes there, and just can't evaluate
| competing options at the same time.
| isodev wrote:
| I think what has changed mainly is that today we have tools,
| languages and entire ecosystems that exist only as means to
| support someone's product line.
|
| Take Swift for example. A giant gatekeeper of a corp decided
| to make it the only (reasonable) way to build apps and so it
| exists, powered by countless indie developers constantly
| creating content around it. Would Swift be a thing without
| everyone being forced to use it? I don't know, but I don't
| think so.
|
| So in some ways we've traded unique and effective solutions
| to "popular and mainstream" things that scream the loudest.
| You wouldn't get fired for choosing Swift. Or Azure.
| Cthulhu_ wrote:
| When I was working with it (I was there, 4000 years ago)
| there was some talk about Swift for the server, but neither
| obj-C nor Swift ever really breached containment of the
| Apple ecosystem and -tooling. Which is a shame because at
| the time I enjoyed working in XCode. Who knew using a mouse
| swipe to go back in your code would be so natural? Not any
| other IDE developer, ever.
|
| Last time I worked with it it felt very sluggish and buggy
| though, in theory building UI elements with SwiftUI is
| great, in practice it was slow and needed to restart very
| often, and that was with simple components.
| skydhash wrote:
| That is why I don't like those ecosystems. They're all
| relying on magic (code generation and indexing) for
| everything instead of just providing a good notation.
|
| If you're creating that closed of an ecosystem, at least
| learn from history and create something like smalltalk.
| ModernMech wrote:
| Yeah, Swift was born because Apple had an ecosystem and
| they needed to fill it with a language. Erlang was born
| because Ericsson had a _problem_ and they needed to _solve_
| it with a language.
| kace91 wrote:
| >somehow almost aggressive/corporate style even when there is
| no paid product.
|
| For those who collaborate with open source for
| political/ideological reasons (which does not need be the
| case), it makes sense to join the battle for attention.
|
| As long as the product isn't compromised in the way, I think
| it's very good to see open source influencers.
| pxc wrote:
| GNU Guix has a good blog, but I don't feel like they are
| very "marketing" focused.
|
| It's hard to describe precisely, but a lot of free software
| projects do a good job of putting themselves out there in
| an unfussy way. There really is something refreshing and
| cozy about that.
| keeganpoppen wrote:
| i think this is especially true of projects run by people
| with deep experience in the field and are in it "for the
| love of the game", and don't feel the need to stunt on
| everyone in hopes that they are taken seriously.
| leoc wrote:
| It isn't entirely true though. The original Erlang guys made
| _Erlang: The Movie_
| https://www.youtube.com/watch?v=xrIjfIjssLE and the sadly
| missed Joe Armstong made plenty of blog posts
| https://joearms.github.io/ and public appearances and
| expressed a number of strong opinions (though genially)
| https://www.youtube.com/watch?v=lKXe3HUG2l4 . Robert
| Virding's public profile is not as high, but he's by no means
| in hiding either. https://www.youtube.com/watch?v=naTisAcey5Q
| -- or indeed https://news.ycombinator.com/user?id=rvirding )
| mikepurvis wrote:
| What were the major projects that changed that? Rails and
| Prototype.js feel like early examples where there was a major
| cult of personality around their creators, but I don't know
| if that was really unique to them or something that was just
| an extension of the webdev / css / web standards blogger
| culture of the era-- A List Apart and all the people who
| would got to SXSW every year to chit chat with each other on
| panels and share the hottest new way to make a row of tabs
| without using a <table>.
| maeln wrote:
| > The big open source projects where pretty much all like
| that in the past, in the 80's/90's/early 2000's - in that
| respect they feel like a pleasant anachronism before
| everything needed to be promoted/self-promotional influencer
| like, the users did the evangelism but the creators where
| usually much more chill.
|
| I must have been living in a different world then. I mean
| maybe in the 80's and 90's but I feel like people acting
| weirdly obsessive about a piece of tech and going about
| evangelizing it every where, usually in a detached from
| reality kind of way, goes back to at least newsgroup, when
| suddenly you could have an audience outside of physical event
| (with their limitation and all). I mean there was the text
| editor flame wars, and I am sure you can find post like "why
| are you not using language/database/tool X instead of Y???!!"
| in the most ancient of mailing list and forums.
| SeanDav wrote:
| I am just wondering when the next "We-Love-Haskell" cycle is
| going to start!
| jimbokun wrote:
| Feels like Rust has stolen a lot of Haskell thunder, in the
| sense you can write similar code and satisfy that functional
| programming itch in a much more popular language, while
| falling back on imperative programming if you really need it.
| leoc wrote:
| I haven't been following closely, but my impression is that
| the dependently-typed languages/theorem-provers have stolen
| some of Haskell's "most purely functional, most strongly
| typed" hype-thunder even though they're even further from
| being a mainstream implementation language for most
| projects.
| sph wrote:
| I don't think it's cycles, more like newcomers rediscovering
| the future.
|
| I've learned Elixir in 2016 after a lull in my interest in
| programming languages, and 9 years later it's still my
| favourite environment by a country mile. It's not the language
| per se, but the BEAM, the actor model, the immutability -- just
| makes sense, and doing things the C/Rust/Javascript/Python way
| is like building bridges out of cardboard.
|
| For example, I've stepped into the world of game dev and Godot,
| which is fantastic and uses a regular object-oriented model.
| After trying to build a non-trivial desktop app with it, my
| thoughts are consumed by the fact that mutable state and object
| orientation is the silliest idea, and I'm speaking as someone
| that really got into Smalltalk and message-passing objects.
|
| I don't even need actors and OTP, I just want some immutable
| data structures and functions operating on them. Erlang/Elixir
| are fantastic to build servers, but there is a sore lack of
| something closer to the metal within 80% the speed of a native
| language. I would build an entire operating system out of it.
| Why has no one put microkernels and Erlang into a blender? I
| know there's QNX, but it's still UNIX, not Erlang.
| mycall wrote:
| What about OCAML, does that fill your needs?
| sph wrote:
| It's perennially in my list of languages to check out. It
| felt harder when I looked into it 15 years ago. Now that
| functional programming is second-nature, it should be much
| easier.
|
| Thanks for the reminder.
| ccortes wrote:
| I really want to get into ocaml but the syntax is sooo ugly
| I feel like you need a great IDE set up to be able to be
| productive with it.
| codr7 wrote:
| Might want to check out ReasonML.
| svieira wrote:
| You may be one of today's lucky 10K.
|
| https://github.com/cloudozer/ling
|
| Erlang on Xen.
|
| But also one of today's unlucky 10K as it hasn't been updated
| for 10 years.
| jacquesm wrote:
| > Why has no one put microkernels and Erlang into a blender?
| I know there's QNX, but it's still UNIX, not Erlang.
|
| That's a very good question. There are some even lesser known
| dialects out there that do this but you are going to find it
| hard to get to the same level of feature completeness that
| Erlang offers out of the box.
|
| QNX and Erlang embody quite a few of the same principles, but
| QNX really tried hard to do this at the OS process level in a
| way that destroyed a lot of the advantages that doing the
| same under Erlang would have. I think the main obstacle is
| the fact that the CPU does not support reductions natively.
| Maybe you could take it a step further and design an FPGA CPU
| that implements the core features of Erlang at the hardware
| level?
|
| That would be an absolutely awesome project. Usually when you
| can think of it someone has already done it so a bit of
| googling would be a good way to start with that.
| shanemhansen wrote:
| You nerd sniped me a little and I'll admit I'm not 100%
| sure what a reduction is but I've understood it to be a
| measurement of work for scheduling purposes.
|
| A bit of googling indicates that actually you can use
| performance monitoring instur to generate an interrupt
| every n instructions.
| https://community.intel.com/t5/Software-Tuning-
| Performance/H...
|
| Which is part of the solution. Presumably the remainder of
| the solution is then deciding what to schedule next in a
| way that matches erlang.
|
| Disclaimer: this is based off some googling that makes it
| seem like hardware support the desired feature exists, not
| any actual working code.
| sph wrote:
| > That would be an absolutely awesome project. Usually when
| you can think of it someone has already done it so a bit of
| googling
|
| I've done a bit of googling and research, nothing viable
| has surfaces, and I still haven't found the time to create
| a prototype myself, just some doodling around here and
| there. I do agree that it's an awesome idea, and it's been
| stewing in my head for a couple years now!
|
| There are a lot of moving parts (scheduler design, probably
| needs its own high level language and bytecode, mapping
| capabilities onto actor semantics, etc.) that are outside
| what current OS-research seems to be focused on.
|
| EDIT: I've just seen the mention of your QNX-like OS in
| your profile. Lovely! Any reason you haven't posted it on
| Github/Codeberg?
| toast0 wrote:
| I've got a hobby OS you may want to check out. Crazierl
| is a just enough kernel that can run the FreeBSD build of
| BEAM as a single OS process.
|
| Features include: x86-32 only, bios boot only, SMP
| capable, drivers in Erlang (there's nifs for managing
| memory with devices or i/o; and the kernel manages the
| interrupt controller(s) and has console output before
| userspace takes over), a kind of working IPv4 stack,
| dist!
|
| It doesn't run on all my machines, but it does on some
| (it does some VGA things that I guess aren't well
| supported and also non uefi is iffy these days too. I
| typically run it in qemu and v86, but I think it will
| work in VMWare as well.
|
| https://crazierl.org/ https://github.com/russor/crazierl/
|
| There's a hosted v86 demo as well (works better on a
| desktop than a phone):
|
| https://crazierl.org/demo.html
|
| It's also in the weird OS section at https://copy.sh/v86/
| jacquesm wrote:
| Very neat! I have my own OS to work with that I know like
| my back pocket, so if I ever go this route I'll probably
| just carve that up.
| toast0 wrote:
| Did you get your serial ports working? :)
|
| If it doesn't take much time, it's worth trying to get it
| to run in v86; it's so much easier to send people a link
| to a web page to poke at your OS than to send them an
| image and tell them to run qemu against it.
|
| Edit: I misinterpretted --- you'll carve your OS up, not
| mine, that makes more sense!
|
| Old comment: Feel free to carve away, just be aware that
| just because it's committed doesn't mean it works... I
| wouldn't take my memory management code, for example.
| There's some fiddly issues I haven't tracked down because
| it doesn't break consistently.
| sph wrote:
| That last link deserves its own HN post!
| toast0 wrote:
| v86 has been posted a few times [1], I'm pretty sure
| that's how I became aware of it to use as a target
| platform. It's a nice project, and they've taken three
| PRs from me (so far) that make it easier for me to run my
| weird OS :) Lots of other contributions here and there
| from others which is great, because I thought I was going
| to have to build a virtio-net device in v86 or write a
| ne2k driver in crazierl, and other people built and
| debugged the virtio-net so I can just use it.
|
| [1] https://hn.algolia.com/?dateRange=all&page=0&prefix=f
| alse&qu...
| jacquesm wrote:
| > Any reason you haven't posted it on Github/Codeberg?
|
| Yes, I don't want Microsoft to be able to pretend claim I
| gave it to them for some particular purpose which I
| didn't. They'll have to come and take it.
|
| Feel free to use that code and do anything you want with
| it, and if there are no more seeds for the code let me
| know and I'll serve up the torrent.
| sph wrote:
| I hear you. These days all my projects are on private SSH
| repositories on my servers.
| dzonga wrote:
| > want some immutable data structures and functions operating
| on them.
|
| Clojure has that for you. plus its jvm which means for your
| desktop use cases it works. hell with graalvm can be ported
| to native.
| jacquesm wrote:
| I used to think that Clojure was going to be the first FP
| language that was going to go mainstream but it seems to
| have fizzled. What went wrong?
| skydhash wrote:
| FP language is very hard on novice programmers. You can
| write thousands of lines of bad javascript/java/python
| code, but you won't write ten in FP without the whole
| thing blowing up.
|
| And then there's the whole evaluation instead of
| instructions. With FP, you're always thinking
| recursively. With imperative, you can coast on a line by
| line understanding.
| sodapopcan wrote:
| In my experience it's still very possible to write many,
| many lines lines or utterly shit FP code, but I know what
| you're saying.
| dzonga wrote:
| yeah - without an easy ramp up for beginners most
| languages / frameworks die.
|
| I wish most language / framework designers knew that
| part.
|
| again - another point why not hiring junior developers cz
| A.I or outsourcing those will cause catastrophic effects
| in the future.
| gf000 wrote:
| > What went wrong?
|
| Well, we have FP at home.
|
| It just got ingrained into pretty much every mainstream
| language, and most [1] of the wins can be had even when
| it's applied to certain parts of the code base only.
| Like, Java has immutable data classes (records), ADTs
| with pattern matching, etc.
|
| As much as I like Clojure, I just don't think Lisps can
| ever become too mainstream, their readability simply
| repels too many people (and even though I am okay with
| reading it, I do think it's less readable than an
| equivalent Java-style code would be).
|
| [1]: I would even argue that a properly mixed pure and
| (locally) side-effecting code is the happy ground, as
| they strengthen each other
| mercer wrote:
| in some ways Elixir is a child of Clojure!
|
| > JOSE: Yeah, so what happened is that it was the old
| concurrency story in which the Clojure audience is going
| to be really, really familiar. I've learned a lot also
| from Clojure because, at the time I was thinking about
| Elixir, Clojure was already around. I like to say it's
| one of the top three influences in Elixir, but anyway it
| tells this whole story about concurrency, right?
|
| https://www.cognitect.com/cognicast/120
| cultofmetatron wrote:
| I work with elixir daily and I would concur. elixir's
| semantics line up nearly 1:1 with the clojure code I used
| to write a few years ago. Its basically if you replaced
| the lisp brackets with ruby like syntax. The end result
| is a language that is much easier to read and write on
| the daily with the disadvantage of making macros more
| difficult. I would argue that it should be difficult
| since you should avoid using it until absolutely
| necessary. Lisps on the other hand, practically beg you
| to use macros as the entire language is optimized for
| their use.
| lomase wrote:
| Lets count the number of comercial sucesful released games
| that don't use mutability or object orientation....
|
| I can't find any.
| simoncion wrote:
| > Lets count the number of comercial sucesful released
| games that don't use mutability or object orientation....
|
| 1) I suspect game engines that Carmack designed towards the
| end of his career are built in a largely-functional style.
| He's on record [0] as thinking that writing code in a
| functional style is generally a good thing to do.
|
| 2) Running on the BEAM doesn't mean that you give up
| mutability. In my experience with Erlang, functions that
| return updated state are very, very, very common.
| Similarly, functions that mutate state external to the
| function [1] are also common... it's rare that a program
| that has _no_ visible effect on the outside world is
| useful.
|
| It's generally quite a lot easier to understand what your
| program does when most or nearly all of its functions take
| input and return output without mutating external state as
| a side effect.
|
| [0] There's some Twitter thread of his that I CBA to find
| saying -in effect- "Writing in a functional style makes
| your code much easier to understand. Obviously, if you're
| writing a video game, you have to pass around pointers for
| efficiency reasons, but that doesn't preclude writing most
| of your code in a functional style."
|
| [1] Such as in an ETS table, a external database, with a
| network call to a remote system, or even writing data to
| disk.
| sph wrote:
| Meh, I remember hearing that no one would release a
| commercially successful game in a managed language with a
| GC 15 years ago. Time flies.
|
| Most things are said to be impossible until someone tries
| to do it anyway.
| quaunaut wrote:
| > Lets count the number of comercial sucesful released
| games that don't use mutability or object orientation.... >
| > I can't find any.
|
| They use it, but the best tend to minimize mutability. And
| as for object orientation- merely 'having classes' is not
| the same thing.
| pron wrote:
| > more like newcomers rediscovering the future.
|
| I have nothing but admiration for Erlang, and it is, without
| a doubt, one of the most inspired languages I've encountered
| in my career. But when I was at university in the late-ish
| nineties, they taught us Haskell as "the language of the
| future." So I guess some languages are forever languages of
| the future, but they still inspire ideas that shape the
| actual future. For example, Erlang monitors were one
| inspiration for our design of Java's structured concurrency
| construct [1].
|
| If you're interested in another "language of the future" that
| bears some superficial resemblance to Erlang, I'd invite you
| to take a look at Esterel
| (https://en.wikipedia.org/wiki/Esterel), another language we
| were taught at university.
|
| [1]: https://docs.oracle.com/en/java/javase/25/docs/api/java.
| base...
| cultofmetatron wrote:
| > but there is a sore lack of something closer to the metal
| within 80% the speed of a native language.
|
| As someone who built an entire startup in elixir, its a good
| time to bring up that elixir has an excellent interop with
| rust via rustlr.
| rat9988 wrote:
| Nice write up. Thank you for taking time to evangelize it.
| mycall wrote:
| Does anyone know if matrix.org has any Erlang implementations?
| It seems like the perfect fit to me.
| Arathorn wrote:
| https://www.uhoreg.ca/programming/matrix/polyjuice is closest
| cpursley wrote:
| 1/3 of hn posts (maybe more) are "look at this thing we built!"
| or a combo of that with "plus all this VC money!" where op has
| basically re-invented something that has existed in Erlang
| since forever. I don't mind all these cool new things (it's why
| I visit). But personally, I prefer to cut to the chase and just
| use Erlang (well, in my case - Elixir).
| zelphirkalt wrote:
| Unfortunately, I have to disagree on the absolute notion, that
| you will never see someone being not nice in the Erlang world.
| OK, you technically said "behind Erlang", not "in Erlang
| ecosystem". But in the Erlang ecosystem and related languages
| I've had at least 2 encounters, that were not nice. One
| outright called lack of good documentation for some projects in
| the Erlang ecosystem bullshit in a public chatroom, and it
| killed all my motivation to continue exploring that part of the
| ecosystem, the other one probably without knowing gave low
| effort dismissive responses to questions about how to best do
| something, without even knowing the context in which my code
| appeared, mixing in their personal taste and treating me like a
| little child.
|
| So there are definitely unpleasant people around, just like in
| many ecosystems. Maybe less so, but I don't know about that.
| The question is only whether one lets that keep one from doing
| whatever one came to do.
| jacquesm wrote:
| I meant it the way I wrote it, so that makes this a strawman.
|
| Every group of > 10 people will have at least one jerk in it.
| bodhi_mind wrote:
| There's no denying that Erlang is bad ass.
| mrkeen wrote:
| The hyperbole that Haskellers invoke around pure-functional vs
| impure is that you're never quite sure whether a function call
| you make will "fire the missiles".
|
| It's colourful language, but it's just a stand-in for other
| properties you might care about. For instance, in
| _head(sort(list))_ , will the whole list be sorted, or will the
| smallest element be returned? In _atomically(doThis(); doThat())_
| , will _doThis_ be 100% reverted if _doThat_ fails? If you stick
| to pure functions (and in the second example, STM) then you can
| _unfire_ the missile!
|
| AFAIK, Erlang just fires the missile "over there", not "over
| here". The author jumped from: (X = X + 1) is bad
|
| to (mailbox = mailbox + message) is so simple!
|
| I'm not bashing the BEAM, or the ease with which one can send
| messages (as an _Actor_ language), but I am complaining about the
| lack of tooling to write non-missile-firing functions on a single
| node (as a _Functional_ language).
| bargainbin wrote:
| > (mailbox = mailbox + message) is so simple!
|
| The author did not say this at all, they barely even touched on
| capabilities of erlang/OTP. Their focus was on the functional
| syntax of Erlang.
|
| > For instance, in head(sort(list)), will the whole list be
| sorted, or will the smallest element be returned?
|
| Your point isn't clear. The functions have a clear nested call
| sequence, take a list, sort it, get the head.
|
| Also how is it any different than Haskells `head (sort list)`?
| ctenb wrote:
| In Haskell with `head (sort list)` the entire list does not
| have to be sorted, depending on the sort implementation.
| Everything is lazy, so sort can sort the list just enough to
| return the smallest element.
| auggierose wrote:
| Going beyond laziness, a compiler that can understand and
| exploit equations, could use `head (sort list) = smallest
| (list)` to make the program more efficient, going from O(n
| * log n) to O(n) complexity.
| petrzjunior wrote:
| I think the question is whether sort should return a new,
| sorted array or whether it should sort the array in place. In
| functional languages it is the former, in imperative the
| latter.
| knome wrote:
| It can be quite useful to have nondestructive sorting in
| imperative languages as well. Hence python introducing
| 'sorted' even though '.sort()' preceded it.
| mrkeen wrote:
| > The author did not say this at all, they barely even
| touched on capabilities of erlang/OTP. Two
| separate Erlang nodes. On different machines, different
| networks, different continents if I wanted. And they could
| just... talk. No HTTP. No REST API. No serialization
| headaches. Just message passing. Just actors doing their
| thing.
|
| > Their focus was on the functional syntax of Erlang.
|
| They didn't write any Erlang until the ping/pong example,
| which doesn't have any _functions_. What does _pong()_ equal?
| Is it equal to itself even? What 's its domain and range? If
| I wrote a unit test for it, what test inputs would I give it
| and what outputs would I assert?
| simoncion wrote:
| Right. The author barely touched on the capabilities of
| Erlang/OTP. That section was pretty much a demo of the
| syntax and an advertisement of the fact that the language
| syntax and runtime system makes it trivial to have a
| distributed program that runs on separate machines.
|
| If the author actually _talked_ about the capabilities of
| Erlang, they would -at minimum- answer the questions that
| you 'd raised, that the return value of both 'ping/1' and
| 'pong/0' are irrelevant because they are ignored, and that
| the range of 'ping/1' is not only infinite, it can accept
| any type for which it's legal to '+ 1'. [0] They would have
| also mentioned why they call 'ping' and 'pong' at the end
| of the respective function, the reason for which is kinda
| strange if you're coming from a more-normal language.
|
| One can add annotations to functions that indicate what
| their input and output types are, and if you do a little
| bit of work, you can also indicate valid ranges/values for
| those types. These annotations are not checked at runtime,
| but can be checked by tools such as dialyzer. But, because
| this blog post barely even touched on Erlang/OTP's
| capabilities, none of that was mentioned.
|
| [0] I _think_ the valid types are only integers and floats,
| but definitely don 't bet your career on that information.
| andoando wrote:
| My confusion here is it always seemed liked a simple mapping to
| take = to mean "make x equal to x+1" rather than "x is already
| equal to x+1".
|
| It is declaring a relationship, between the previous value and
| the current. One way or another, youre defining transformations.
|
| I mean even in the sum example, you see the statement "N is n-1"
| which is the exact same thing as x = x+1 with = swapped for "is"
| lionkor wrote:
| That's why I like the x := x + 1
|
| syntax better, or the let x = 2;
|
| syntax
| mrkeen wrote:
| It's _N1 is N - 1_ , not _N is N-1_
| ceayo wrote:
| > even in the sum example, you see the statement "N is n-1"
|
| That wasn't actually what the example said. It said N1 = N - 1,
| and continued using the N1 value somewhere else. In that
| example, no actual mutation occured.
| andoando wrote:
| Oh my weary eyes, my bad
| davidsainez wrote:
| It is difficult to understand the full beauty (or horror,
| depending on your pov) of functional programming with such a
| simple example. But as you scale up in complexity, it can be
| someone's full time job to make sure the model is accurately
| translated to the computer's memory. With a pure language, the
| compiler is responsible for maintaining the mapping to memory,
| so you (mostly) just focus on the symbolic relationships of
| your model. This can be extremely freeing once you train
| yourself to think in functional terms. Of course, there is a
| performance cost, but this can be managed and in cases where
| people turn to functional programming reliability and
| correctness outweigh the cost.
| fpoling wrote:
| Pure languages still use stack to store mutating state. In a
| single-threaded programs this is almost non-observable except
| for occasional stack overflow crashes. But with multiple
| threads and message passing one can emulate arbitrary state
| mutation just by using messages and stack.
|
| Then I have found the code that is a heavy user of closures
| is harder to understand even if it is single-threaded and
| closures can pass arbitrary state even if the state is
| immutable.
|
| What I have found useful is persistent data structures. Those
| really simplify modelling. But then those can be used in
| imperative languages as well.
| sam-cop-vimes wrote:
| I can totally relate to this. Programming in Erlang felt so
| natural compared to the knots I was twisting myself into writing
| C++. I was churning out C++ code, but wasn't having fun. Suddenly
| Erlang made it fun and programming became addictive.
| tommica wrote:
| > Suddenly Erlang made it fun and programming became addictive.
|
| I'm saying this with complete sincerity: WHAT IS IT THAT YOU
| PEOPLE SEE!? What is the fun? What are you addicted to? Typing
| and seeing the output? Solving a problem?
|
| I feel like I am missing out on some amazing life altering
| experience when I see people state that. The same thing I have
| with the article - what does it mean to love a programming
| language?
| cmoski wrote:
| Solving problems I guess. Have you used painful languages
| before? Imagine doing that, then discovering one that wasn't
| getting in your way all the time. It's easier to do things
| that are difficult in other languages. You can do so much on
| the BEAM, and you don't have to waste your time with thread
| pools or other nonsense.
| christophilus wrote:
| It's a subjective thing, but when a language clicks for you,
| work becomes pleasant. You get into (and maintain) a flow
| state. It feels as if you're crafting something beautiful and
| elegant and simple. It's the same reason people love
| painting, drawing, or sculpting with one specific medium over
| an other. They just like the aesthetic and process better.
|
| Also, some languages just really stink-- slow compilation
| times, obscure errors, loads of footguns and require much
| more care and focus on things which are orthogonal to the
| problem you're trying to solve.
| sam-cop-vimes wrote:
| I'll try and answer this.
|
| Expressiveness: I could express a solution to a problem with
| very few lines of code and without the clutter of
| housekeeping operations like memory management.
|
| Recursion: Erlang properly introduced me to recursion whereas
| I hadn't encountered it before. This is again related to
| expressiveness. There is something strangely beautiful about
| seeing a problem solved using recursion elegantly.
|
| Message passing: when I was trying to figure out how
| Microsoft's C++ socket classes were implemented and I dug
| into the code, it turned out there was a hidden window for
| every socket created and messages were being passed to/from
| it, but message passing wasn't available anywhere in Visual
| C++ as a first class construct (at least as far as I remember
| it). I was overjoyed when I discovered that message passing
| was a first class citizen in Erlang and how much easier it
| was to implement concurrent programs than using native
| threads in C++.
|
| Compared to OO programming in C++ where I was never sure
| whether I was using inheritance correctly, whether I needed
| inheritance at all, memory management, difficulty with
| threads, writing code in Erlang was a breeze.
|
| And the whole support for distributed programming, hot code
| loading, list comprehensions! I fell in love again with
| Erlang when I discovered list comprehensions. Man, I could go
| on.
| knome wrote:
| when I program, I am visualizing the machine I am building in
| my head. some language semantics are cleaner than others,
| allowing the bits and pieces to flow together more naturally,
| composing in elegant ways that do not require pointless
| effort be spent manually wrangling footguns and minutia.
| jacquesm wrote:
| It's a bit like cutting wood. Cutting wood can feel terrible.
| You do it every day because you have to. Along the grain, in
| wet wood, with a handsaw.
|
| And then, one day you discover the chainsaw, and the fact
| that you should cross cut.
|
| Suddenly cutting wood no longer feels terrible, it's smooth,
| stuff works the way you expect. Your chainsaw turns out to
| have features for all kinds of wood and for many different
| kinds of joinery that you were hand carving before. It turns
| out that your chainsaw can be used to control an army of
| chainsaws without having to do anything at all. You just
| declare it to be so and it works.
|
| Instead of focusing on your tools all day long you find
| yourself focusing on the thing that you are actually trying
| to solve. Where you needed 50 people before, now you need 5.
| jimbokun wrote:
| It's kind of like this:
|
| https://xkcd.com/224/
|
| Also this:
|
| https://www.infoq.com/presentations/Simple-Made-Easy/
|
| For me, there's a dopamine hit in taking a complex problem,
| and breaking it into simple interacting parts that solve the
| problem in an elegant way. Overly complex programming
| languages add lots of incidental complexity that slow down
| this process. A clear, simple, consistent semantics
| accelerate this process.
|
| If that doesn't inherently excite you, the life altering
| experience probably isn't going to happen for you.
| FredPret wrote:
| > https://xkcd.com/224/
|
| > "My God, it's full of 'cars'"
|
| Classic
| jayd16 wrote:
| You ever get a fresh pair of sharp scissors or a new very
| good knife? It feels like that.
| simoncion wrote:
| > WHAT IS IT THAT YOU PEOPLE SEE!?
|
| I'm a hobbyist high-availability dork, so the idea that I
| could update my program without interrupting any user of the
| program was very, very attractive to me. I'm also quite sick
| in the head and have a life-long torrid love affair with
| Bash's switch statements, so Erlang's "pattern match to make
| most decisions" syntax was a huge attracter.
|
| Having said that, I didn't really _get_ Erlang until I had a
| project for which it and the OTP were a good fit. I needed to
| build a server for an unfamiliar-to-me protocol, so I
| expected to regularly have protocol handlers fail due to
| incorrect implementation. This server would be long-running,
| so VM startup time was not a problem. This server would
| perform next-to-no number crunching. This server could be
| very effectively modeled as a swarm of message-passing
| processes. The core functionality of the server was best
| modeled as an FSM.
|
| Erlang's "share nothing, use message passing" design, along
| with OTP's supervisor and friends kept my server up and
| running while my protocol handlers exploded because of
| incorrect or absent handler code, or too-pessimistic
| assertions about the valid bounds of input data. Hot code
| reloading let me fix broken code paths (or experiment with
| non-broken ones) without affecting users of other code paths
| in the server. [0] The built-in FSM library made it trivial
| to express the parts of my program that were an FSM _as_ an
| FSM. Not only did Erlang 's syntax satisfy my sick
| fascination with Bash's switch statements, it permitted me to
| write _nearly all_ of my server as simple, sequential code
| and let Erlang /OTP handle the nasty problems of concurrency
| for me.
|
| Oh yeah, and the extremely high quality of Erlang's
| documentation was _really_ helpful. In the reference manual
| for the standard library, the documentation for every single
| function provided in Erlang /OTP told you the valid types and
| acceptable ranges/values for both function arguments and
| return values. They told you which functions would throw,
| what would be thrown, and under what conditions. They also
| described _what_ the function did, and -when needed- why it
| did it. I could be confident that if I programmed according
| to the docs, then my program would behave as the docs said it
| would... unlike where documentation for most Web Development
| stuff leaves you. [1] There 's also official documentation
| about the design of Erlang/OTP and the reasons behind that
| design. Those docs (along with Learn You Some Erlang)
| definitely helped me understand Erlang and OTP.
|
| Like I said... if your project isn't a good fit for what
| Erlang provides, I think you're not going to _get_ what makes
| Erlang /OTP special. But if it _is_ , there's a very good
| chance that you will.
|
| [0] Supervisors + hot code reloading made it _emotionally_
| really easy to build my server incrementally. Knowing that I
| didn 't have to get the entire protocol right to have a
| server that would never die was calming. As was knowing that
| implementation failures (or deliberately unhandled parts of
| the protocol) would provide me with usually-good diagnostic
| information, rather than a core dump (or nothing at all(!)).
|
| [1] This was prior to the big redesign of Erlang's docs to
| ape the style used by HexDocs. Whoever did that redesign
| very, very clearly did not understand what made Erlang's
| documentation so good. Switching from EBNF-ish to raw Erlang
| spec format not only takes up far more vertical space, but
| adds yet another new thing someone new to Erlang needs to
| learn. But far, far, far worse is that some of the
| documentation about the valid _ranges_ of input to functions
| has been lost.
| gorgoiler wrote:
| For me, strictly immutable and side-effect free programming
| was a forcing function* to make me really decompose problems
| into isolated parts. Only when I could do that could I truly
| say I understood the problem (and its distinct sub-problems)
| in full.
|
| In that sense, Erlang isn't really different from any other
| functional programming _except that_ it also ships with a lot
| of actor / message passing concurrency dogma which solves a
| different and equally delightful set of problems (low-bug
| concurrency) at the same time.
|
| So it's a double hit of two great ideas in one paradigm.
|
| *Oops, no pun intended.
| srpablo wrote:
| Every coder has parts of programming they love, and parts
| they hate. Additionally, they have a mental model of what is
| risky, and what isn't. Languages, by their design, will make
| some things easier and some things harder, and so when people
| "love a language," they typically mean "it maps to what gives
| me dopamine."
|
| A good example is mutable state: for a bunch of people,
| functional languages that enforce immutability has this
| calming effect, since you know your data isn't mutating where
| you can't see it. You've been burned by C++ code that's
| passing references as arguments, and you don't know if the
| list you received as an argument will be the same list after
| you've passed it as an argument to a different function. You
| don't know if you can futz with that list and not make a
| problem for someone somewhere else.
|
| But for most people, they much prefer how "intuitive" it is
| to have mutable state, where they just change the thing in
| front of them to be what they need. This is especially true
| in the context of for loops vs. recursion: "why can't I just
| use a for loop and increment a counter!" A lot of Golang
| folks love that it explicitly rejects functional mapping
| primitives and "all you need is a for loop."
|
| It's a very personal decision, and while IMO it doesn't
| really matter for the ultimate business success (usually
| companies fail because of something that's not tech-related
| in the least), it does shape _how_ it feels to work on a tech
| stack, and I'd argue, what kinds of technical problems you
| run into.
| rozap wrote:
| For me (and I've been writing Elixir for probably a decade
| now...) Joe Armstrong's post here encapsulates it pretty
| well: https://joearms.github.io/published/2013-11-21-My-
| favorite-e...
|
| And for me, what it comes down to, is, doing powerful things
| in Erlang/Elixir is trivial where it would be really
| convoluted in other languages. When applied to the right
| problem, it genuinely makes a whole class of problems
| evaporate, and that's addicting.
| spelunker wrote:
| Pattern matching and function guards sold me. I'll never look
| back, you can take patterns out of my COLD DEAD HANDS!
| ctenb wrote:
| I think the older programmer was hinting at gauss's formula with
| the summing 1 to 10 without using a loop? Recursion is also a
| loop in some sense.
| donatj wrote:
| > X equals X plus one? That's not math. That's a lie.
|
| That's really interesting... My wife, who has no real
| mathematical background had the EXACT same reaction when I was
| trying to teach her some simple programming. I tried to explain
| that equals in that context was more of a storage operator than a
| statement that said line is true. She found it very frustrating
| and we gave up on the endeavor shortly thereafter.
|
| I've personally always had a soft spot for languages like TI-
| BASIC that use a storage operator rather than overloading = so
| for example:
|
| X + 1 -> X
|
| I wonder if I should try a functional language with her.
| SeanDav wrote:
| It is not a lie it is just apparently familiar notation that
| actually has an entirely different meaning. It is not an
| equation, it is an assignment.
|
| X := X + 1 is perhaps less confusing, even if meaning the same
| thing.
| npteljes wrote:
| That's exactly right. Looking at the Assignment Operator Wiki
| page, it's also clear where these notations come from.
|
| I think an easy way to look at it, for someone coming from a
| math background, is to think of programming lines as
| instructions, instead of statements. x=x+1 can be then read
| as "let x be x+1", and that's it.
|
| https://en.wikipedia.org/wiki/Assignment_(computer_science)
| sodapopcan wrote:
| Although in Erlang it's closer to an equation with assignment
| being a side effect. `=` is the pattern matching operator.
| Eshell V15.2.6 (press Ctrl+G to abort, type help(). for help)
| 1> X = 1. 1 2> X = X. 1 3> 1
| = X. 1 4> X = 2. ** exception error:
| no match of right hand side value 2 5>
| npteljes wrote:
| Pascal also had := for assignment, if I remember correctly. I
| disliked it, to be honest, = is pretty much universally
| accepted in the IT world to mean "assign to".
|
| I don't think this is something that keeps someone from
| programming. If it does, then the other 100000 hoops won't be
| better, every trade has its "why the fuck is this the way it
| is" moments.
|
| If you'd still try programming with her, I think you could
| start with a visual programming thing. Maze from Blockly Games
| is a simple online logic game that can be overcome with visual
| programming. No need to register or anything. The levels get
| progressively harder, as it teaches to apply programming
| concepts, and makes the player combine them. As a programmer, I
| found the game really fun, and I think it's suitable for
| beginners as well, seeing how for example LEGO used a very
| similar system for its programmable sets.
|
| https://blockly.games/maze?lang=en
| jacquesm wrote:
| > I don't think this is something that keeps someone from
| programming.
|
| Not everybody is wired the same way. That exact thing
| happened to me, it was some kind of mental block. And when
| that fell away I found the rest of programming to be fairly
| easy.
| npteljes wrote:
| Thanks for sharing your experience. I guess in a case like
| this, even trying another language can work.
| davidsainez wrote:
| I highly recommend How to Design Programs. I recall being
| repeatedly mind blown working through the book. It was great
| fun. The authors start by composing pure functions. IIRC you
| get quite far before you have to do any mutation. Take a look!
| https://htdp.org/2003-09-26/Book/curriculum-Z-H-5.html
| ngriffiths wrote:
| I think it makes more sense in languages where you use the
| "let" keyword. Then it sounds like assignment, though you still
| have to get comfortable with the X being on the right side too.
| macintux wrote:
| I've shared it here once recently, so might as well again.
|
| I gave a talk at Midwest.io (sigh, such a great conference,
| shame it faltered) building Erlang from the ground up, starting
| with the = sign and the implications (side effects?) of it
| being a runtime assertion of truth in addition to a binding.
|
| https://youtu.be/E18shi1qIHU
| marcosdumay wrote:
| Yes, people with mathematical background tends to fare better
| with declarative languages.
| jacquesm wrote:
| This blocked me from understanding computer programming for 3
| years. I thought of 'variables' as immutable and the fact that
| they were not didn't really click at all. Once I mentally
| transitioned from 'it's a label attached to a value' to 'it's a
| named box which holds a value' life got a lot easier. I was 15
| when it finally clicked (on a TI programmable calculator...).
| galangalalgol wrote:
| I wonder if haskell would have made more sense to you at the
| time with everything being immutable.
| jimbokun wrote:
| Or maybe Erlang.
| lysace wrote:
| That is fascinating.
|
| I guess I got through that when I was 7 on a pass-me-down
| ZX81 from a relative who just had upgraded to a Spectrum (I
| assume).
|
| I mentally called bull when reading boragonul's story
| because:
|
| a) BASIC has a REPL
|
| b) Kids back then had near infinite patience/time.
|
| c) These computers came with pretty good manuals explaining
| BASIC
|
| There was very little external stimuli. As an example: TV
| broadcasters in Europe were literally mostly shut off during
| the day to save power. Radio was on all day, but it was 99%
| boring adult stuff.
| jacquesm wrote:
| I learned to program in the 8 bit era, initially in BASIC
| on the TRS 80, then later assembly on the KIM-1 and then
| the 6809 based Dragon 32 (CoCo clone), which for the first
| time felt like a real computer. After that the BBC Micro
| and then the ARM, and eventually PCs.
|
| Those first years were a real slog. I wanted to understand
| this stuff so much but it just did not click. I actually
| remember when it did, it was like a lightbulb going on and
| I went from 'this sucks, I can't hack it' to 'this is my
| future' overnight.
|
| The I read a book by Niklaus Wirth and it opened my eyes to
| structured programming and various data structures (beyond
| variables and arrays). It's funny because even though I've
| read a mountain of books on computer programming by now
| that is still the one that gave me the most practical day-
| to-day knowledge which comes in handy every day.
| lysace wrote:
| Boy can I confirm that happening to find the right book
| back then was absolute key. And they were so expensive!
| Never really bought one.
|
| These days it's almost painful to come across great books
| that would have been so awesome to have in like 1984.
| tmtvl wrote:
| That's a funny thing to get hung up on, though I can understand
| it. I suppose that's the downside of some programming languages
| going with the worst assignment operator. If they didn't they
| could use = for (numerical) equality tests. If your wife has a
| strong mathematical background you could also show her some
| logic programming like Prolog or Mercury.
|
| Also, various ways of assignment:
|
| Pascal style: x := x + 1
|
| Scheme: (set! x (+ x 1))
|
| Forth: x 1 + x !
| jasperry wrote:
| Am I wrong to be skeptical that this was a thought author had
| at 8 years old? I don't doubt that 8-year-olds can learn
| programming and advanced math, but even the brightest 8-year-
| old would still be in the "sponge" stage. It's hard to believe
| they would have a sufficiently fixed idea about algebra to be
| troubled that X = X + 1 is "wrong".
| SatvikBeri wrote:
| Kids can be flexible but also rigid about the most random
| things. My two year old gets really annoyed if I use the
| wrong spoon to stir my tea, saying certain spoons are only
| for food or cereals. I don't know where she got that - it's
| definitely not a practice we ever enforced!
| isaacremuant wrote:
| It's a common Tactic to pretend children are some sort of
| tabula rasa full of innocent wisdom that can be use to prove
| points.
|
| It's ridiculous, usually fake and hide the biases of those
| who nurtured them to believe whatever they believe, even if
| it's by pure imitation.
|
| So you're absolutely right to call BS.
| brabel wrote:
| Mutation should be an advanced topic in programming teaching.
| Even in procedural languages. It should be seen as an
| optimization technique you only use when analysis has shown
| that to be the only way to solve a difficult bottleneck. Using
| mutation as a basic tool in programming was a mistake.
| zelphirkalt wrote:
| Yes, see SICP (Structure and Interpretation of Computer
| Programs).
| brabel wrote:
| I saw it. That's how I know it.
| ghssds wrote:
| I think it's mental rigidity. In BASIC, the = symbol means both
| assignation as in
|
| X = X + 1
|
| and equality as in
|
| IF X = 3 THEN 'Do something
|
| and it's as natural as 'to dust' meaning both removing the dust
| and adding dust, depending on context, and 'to sanction'
| meaning both to approve and to punish. And the Prolog way seems
| all good too. There are more than one way to think about
| things.
| overhead4075 wrote:
| I explain "X equals X plus one" as though each variable has an
| implicit version that increases whenever it's written to or as
| time goes on, but we can only access the lastest version.
|
| For example X = X + X
|
| is really Xv2 = Xv1 + Xv1
| igouy wrote:
| Cuis Smalltalk x - x + 1
|
| Although you'd need to type x _ x + 1
|
| and it might copy/paste as x := x + 1
| mncharity wrote:
| > She found it very frustrating [...] I wonder if I should try
| a [different language] with her
|
| Or, perhaps, preprocess left-arrow to equal?
|
| Customizing a language to taste. Especially for shallow
| syntactic issues. Like "no multi-line string literals allowed
| ... I'm sorry, that's just not ok". Or "ok kid, what nicknames
| would you like to give the keywords today"?
|
| When programming for just fun, I'll sometimes go "this aspect
| of the language bugs me - I could of course just live with
| it... but here, I think it will be more fun not to". So for
| recent example, a few lines of recast.js ast tweaking, and I
| could use infix unicode mathematical symbols as javascript
| functions.
|
| I wonder if one could teach programming by build-your-own
| language. Perhaps even of the video-scanned desktop variety.
| "Draw a circle around your toys to create a collection. Label
| it with a letter. Now you can sort/filter it by..."
| themafia wrote:
| Tell her there are transparent subscripts on each use of =.
|
| x(0) = 1
|
| x(1) = x(0) + 1
|
| There's no way to reference the subscripts. They're implicit
| and the language manages it for you. Ask her to think of the
| Kronecker delta function and it's definition.
| 4gotunameagain wrote:
| Calls a simple swap function with pointers inscrutable (the only
| hard to decipher character is the asterisk), and as a good
| counterexample provides this ? -module(ping).
| -export([start/0, ping/1]). start() ->
| register(ping, spawn(fun() -> ping(0) end)).
| ping(Count) -> receive {pong, Pong_PID}
| -> io:format("Ping received pong (~p)~n",
| [Count]), Pong_PID ! {ping, self()},
| ping(Count + 1) end.
|
| I am not against functional programming, or using the tools you
| love, but at least make a valid argument about it ;)
| cess11 wrote:
| They didn't make such an argument. It's a biographical
| rumination about the authors personal development and feelings.
| mrkeen wrote:
| Port ping.erl and pong.erl to C and we'll compare them.
| 4gotunameagain wrote:
| But I am not contrasting the two languages, I'm very aware of
| their respective strengths and weaknesses.
|
| I am just disagreeing with the fact that C is hard to parse.
| jacquesm wrote:
| Decades long C programmer here. C is hard to parse. The
| thing is, you get used to it and then it feels like it is
| normal, but it really isn't. Not as bad as Perl, but pretty
| bad. And it is easy to construct one liners that are tricky
| to understand, I think C is the only language that has an
| obfuscation contest that keeps turning up gems year after
| year.
| simoncion wrote:
| > ...at least make a valid argument about it ;)
|
| Like other folks have said, show the equivalent C program and
| then we can have a discussion about implementation complexity
| and comprehensibility.
|
| Do note that the equivalent C program permits IPC between two
| instances of the program that could be either running on the
| same machine or could be running on different machines
| connected by an IP network.
|
| Edit: For general information, here's an Erlang implementation
| of increment and swap. Swap is made a bit complicated because
| Erlang doesn't support multiple returns... returning a tuple or
| list is the way that's handled, so I had it accept a two-
| element tuple for consistency with what it returns:
| increment(A) -> A + 1. swap({A, B}) -> {B, A}.
| bishabosha wrote:
| this whole article stinks of AI prose, why should i read it
| croisillon wrote:
| the author loves Erlang, but not to the point of writing their
| love themself
| nakamoto_damacy wrote:
| Will it ever run in WASM?
|
| EDIT: there is Lumen, but not sure if it's stalled or still
| going.
| calvinmorrison wrote:
| Usage
|
| It is not immediately clear what the intended usage pattern for
| Lumen and WebAssembly is.
|
| Pros and Cons
|
| Things we like: The idea of having both
| runtime and code compile is cool
|
| Things we're not big fans of: We could not
| immediately figure out exactly how Lumen works, and builds
| appear to be failing The project might be stalled or
| unmaintained. It has not been updated in over a year.
| nakamoto_damacy wrote:
| WebAssembly's goal is to be a "portable execution layer" --
| an OS abstraction. If WASM becomes the standard runtime
| across browsers, servers, and edge networks, something still
| has to orchestrate thousands of concurrent tasks, message
| queues, supervisors, restarts, etc.
|
| Erlang/OTP already solves that -- beautifully.
|
| So, the motivation is:
|
| "What if BEAM's concurrency runtime could itself be compiled
| to WebAssembly -- and become the actor system of the
| WebAssembly world?"
|
| That's why projects like Firefly and Lumen are interesting:
| they're exploring whether Erlang's runtime model can become
| part of the WASM ecosystem -- just like how Go and Rust
| shaped the serverless world.
| simoncion wrote:
| > Will it ever run in WASM?
|
| A ten-second search reveals [0]. (Have Kids These Days
| forgotten all about Emscripten?) However, given that web
| browser pages are often short-lived, I don't see what benefit
| bringing in all of Erlang and its VM gets you, other than the
| fact that you've pulled off the stunt.
|
| [0] <https://www.antvaset.com/erlang-otp-wasm>
| imglorp wrote:
| > "How can you sum the numbers from 1 to 10 without using a
| loop?"
|
| Sum = n(n+1)/2
| KingMob wrote:
| Yeah, I assume it's missing some context that the numeric
| solution was off the table.
| javcasas wrote:
| When all you know is hammers, all you can think of are nails.
| Screws are impossible to use and understand. How are you
| supposed to hammer in a screw? All those ridges are in the
| way!
| FredPret wrote:
| Not even Erlang can beat Gauss
| robochat wrote:
| I remember being amazed when I learnt about summing arithmetric
| series.
| macintux wrote:
| I discovered Erlang from Bruce Tate's book[0] and it was such an
| obviously pragmatic and interesting language that I started
| participating in the Twitter Erlang community, discovered Basho
| was using it for Riak and looking for a tech evangelist in the
| Midwest, and thus began my all-time favorite job.
|
| I'm still more of a infrastructure guy than a software developer,
| but working with such incredibly smart people was a delight.
| Basho was good at hiring people who could learn Erlang (and,
| perhaps unsurprisingly, was almost entirely remote).
|
| [0]: https://pragprog.com/titles/btlang/seven-languages-in-
| seven-...
| bmacho wrote:
| There is also Erlang the Movie 2 trying to sell Erlang (called
| _Outlaw Techno Psyhchobitch_ in the video) with rock and hot
| chick: https://youtu.be/rRbY3TMUcgQ?t=262
|
| And they were right, rebranding was all Erlang needed 13 years
| ago
| jacquesm wrote:
| That's absolutely terrible _and_ hilarious at the same time.
| davidw wrote:
| Same guy as 'MongoDB is web scale'. I wish they'd done more
| videos; they're hilarious.
| RickJWagner wrote:
| Fantastic article, my thanks to the author.
|
| I must go dig up the Erlang book from my library. As I recall, it
| was a great read.
| jrm4 wrote:
| For what it's worth, I'm stuck on the very first x = x + 1 thing.
|
| Not sure if you want to call it a screwup or bad grammar or
| whatnot, but it is perhaps the huge mistake that the "equals"
| sign was used for something that feels like, but emphatically
| DOES NOT mean, "is equal to."
|
| It's "put this into that". It's an action verb. Should have
| perhaps insisted on x <- x + 1 or maybe better x + 1 -> x
| kwanbix wrote:
| I prefer pascal's way: x := x + 1.
| mock-possum wrote:
| That's funny, because to me, it was always immediately obvious
| that once that line runs, then it must be true - once that line
| runs, x is now equal to whatever it was before, + 1. It's the
| price opposite of the lie, it's the literal definition of
| truth, in the sense that what is true is set by that line.
|
| Programming is telling things to the computer, and in this
| case, you're telling it what x is. Whatever you tell a computer
| is all the computer knows, whatever a computer does can only be
| what it's told. If you never told it what x was, then x
| wouldn't be anything... _that's_ the truth.
| munificent wrote:
| _> once that line runs_
|
| This is the key point. Some people have a mental model that
| algebraic syntax is describing a set of immutable properties.
| You are defining things and giving them names, but not
| changing anything. There is no notion of time or sequence,
| because the universe is unchanging anyway. All you're doing
| is elucidating it.
|
| Then there is a model where you are molding the state of a
| computer one imperative modification at a time. Sequence is
| essential because everything is a delta based on the state of
| the world before.
|
| You have the latter model, which is indeed how the hardware
| behaves. But people with a mathematical mindset often have
| the former and find the latter very unintuitive.
| jrm4 wrote:
| It's hard for me to not suggest though that, essentially --
| the math people are "right." Which is to say, "=" meant
| what it meant for 400 years, and then computers come along
| and redefine it to be an action verb and not an identity.
| And I think it's fair to consider that _a mistake._
| 9rx wrote:
| _> It 's an action verb._
|
| The difference is that it is an instruction. Conventional
| mathematical notation, while declarative by default, switches
| into instruction mode just the same with the "let" keyword. The
| usage of the "=" operator then becomes equivalent: e.g. let x =
| 1.
|
| But as the aforementioned x = x + 1 comes from notations that
| are never declarative, where every statement is an instruction,
| the "let" keyword is unnecessary and redundant. You already
| know you are looking at an instruction.
|
| _> Should have perhaps insisted on x <- x + 1 or maybe better
| x + 1 -> x_
|
| While that would obviously work, it strays further from the
| conventional notation. Which doesn't matter to the universe in
| any way, but the topic of discussion here is about trying to
| stay true to conventional notation, so...
| jrm4 wrote:
| Is that the topic?
|
| I do think what I'm trying to say here is: sorry, but your
| "conventional notation" sucks because "what is actually
| happening" is so very different from how the thing is
| overwhelmingly used for most people.
| 9rx wrote:
| _> Is that the topic?_
|
| Yes. "=" doesn't mean anything in the void of space.
| Conventional mathematical notation is what established "="
| as meaning "equal to", as referenced by the original
| comment. But the same notation also uses it for assignment
| when in instruction mode, so imperative languages that use
| x = x + 1 syntax are quite consistent with it.
|
| _> but your "conventional notation" sucks_
|
| Maybe, but it's all anyone really knows nowadays. It's what
| you are going to learn in math class in school. It's what
| you are going to find used in mathematical papers. It is
| how you are going to express mathematical concepts to your
| friends and colleagues. Worse is better, I suppose, but it
| is what has set the standard. It is the de facto language
| of math. For whatever shortcomings it does have, virtually
| everyone on earth recognizes it, which is _very_ powerful.
|
| _> so very different from how the thing is overwhelmingly
| used for most people._
|
| I'm not sure how to grok this. let x = 1 is something
| anyone who has taken high school math will have
| encountered. Assignment is perfectly in line with the
| understandings of most people.
|
| Do you mean that expression entirely using imperative
| constructs is unfamiliar to those who grew up with a
| primarily declarative view of math? That might be fair, but
| I'm not sure x = x + 1 is a specific stumbling block in
| that case. One has to understand imperative logic in its
| entirety to use these languages anyway, at which point
| nobody is going to think that x = x + 1 is intended to be
| declarative equality.
| igouy wrote:
| In one character x - x + 1
| munificent wrote:
| I believe you can blame Ken Thompson for this. In DMR's paper
| about early C history, he says:
|
| _> Other fiddles in the transition from BCPL to B were
| introduced as a matter of taste, and some remain controversial,
| for example the decision to use the single character = for
| assignment instead of :=. _
|
| I think Ken did most of the early design of B and DMR came
| along later to help with C. Ken has a famously terse style, so
| I can definitely see it being on brand to shave of a character
| from `:=`, which is what BCPL uses.
|
| It's sort of a tricky little syntax problem. It makes perfect
| sense to use `=` for _declarations_ : int x =
| 1;
|
| At that point, you really are defining a thing, and `=` is the
| natural syntax for a definition. (It's what BCPL uses for
| defining most named things.)
|
| You also need a syntax for mutating assignment. You can define
| a separate operator for that (like `:=`). Then there is the
| question of equality. From math, `=` is the natural notation
| because the operator there is often overloaded as an equality
| predicate.
|
| Now you're in a funny spot. Declaring a variable and assigning
| to it later are semantically very similar operations. Both
| ultimately calculate a value and store it in memory. But they
| have different syntax. Meanwhile, defining a variable and
| testing two expressions for equality use the same syntax but
| have utterly unrelated semantics.
|
| Given that math notation has grown chaotically over hundreds of
| years, it's just really hard to build an elegant notation that
| is both familiar to people and consistent and coherent.
| igouy wrote:
| As you say there was a familiar declarative notation. Was
| there a familiar imperative notation? x - x
| + 1
|
| Not familiar, perhaps understandable.
| jrm4 wrote:
| Doubling down on my downvotes, then:
|
| Look, I _teach IT_ (to both novices and interested folks at a
| college) for a living; count this idea as one that, when I
| present it this simply, many a lightbulb goes on for those new
| to programming. Much like for zero-indexed arrays, I do very
| well with "look, this is stupid, but here's why it got that
| way, we'll just deal with it."
|
| And while on occasion I take pride in nerd-dom, I feel like --
| especially with the advent of AI for coding -- this is dinosaur
| stuff, where we would do better to go along with what's WAY
| more intuitive than to try to stick with mathematical or
| programming purity, etc.
| groundzeros2015 wrote:
| I want to get into Erlang, but I also know a lot of languages
| that are cool, effective, but rarely used in jobs.
| SoftTalker wrote:
| That's the downside. If you look at the monthly "who is hiring"
| posts here on HN, you rarely see Erlang jobs. Elixir shows up a
| bit more often but it's still uncommon.
| davidw wrote:
| Yeah, I've really enjoyed the jobs where I got to use Erlang,
| but there haven't been enough of them. Even Elixir is kind of
| scarce.
| SoftTalker wrote:
| Only had one, a contract where I got to choose the
| implementation. Job was to simulate a bunch of sensors on a
| network and Erlang was perfect for that.
| tamnd wrote:
| If you like Erlang, I recommend reading Making Reliable
| Distributed Systems in the Presence of Software Errors by Joe
| Armstrong: https://erlang.org/download/armstrong_thesis_2003.pdf
|
| His PhD thesis explains the thinking behind Erlang, especially
| how it handles failures, message passing, and concurrency. It was
| last updated in 2003, 22 years ago, time really flies!
| b_e_n_t_o_n wrote:
| Thank you for this, I'm unlikely to ever touch Erlang but looks
| like a fascinating read nonetheless.
| foobarian wrote:
| Obligatory link to Erlang the Musical:
| https://www.youtube.com/watch?v=upiNIQOS4WE
| mock-possum wrote:
| > "How can you sum the numbers from 1 to 10 without using a
| loop?" ... And there it was: recursion.
|
| Wait, is there something I don't actually understand about
| recursion? When a recursive function calls itself, is that not a
| loop?
| sodapopcan wrote:
| It depends on how technical you want to get. It's certainly not
| a loop in the classic sense, like a for loop etc. Like there
| are no `continue` or `break` semantics and you can't return out
| of it (and yes yes of course you can still do all that stuff,
| just not with dedicated keywords). I call it a loop, though.
| Whenever I make a lil' server in Elixir (mostly always for
| teaching) I always call the function `loop`:
| defmodule Server do def start_link do
| spawn_link(&loop/0) end defp loop do
| receive do msg -> IO.puts(msg)
| loop() end end end
| simoncion wrote:
| To put it another way: anything you can express with
| iteration, you can express with recursion (just as long as
| you don't run out of call stack).
|
| Once you get it, it's obvious, but if you're not already
| familiar with the notion, the understanding can be pretty
| amazing.
| sodapopcan wrote:
| > just as long as you don't run out of call stack
|
| And with tail-call you don't even need to worry about that
| :)
| mrburton wrote:
| R.I.P Joe Armstrong - he was an amazing man, engineer, and human
| overall. :(
| morshu9001 wrote:
| I used Erlang for a couple of years. It's cool and elegant for
| sure, but it always felt like it took longer to write than JS or
| Py like I'd otherwise use. Recursion with matchers is sometimes
| natural, sometimes roundabout to what you want to do.
|
| The multiprocess stuff is cool too, but a premature optimization
| for what I was doing. If I needed to scale, I don't know if
| that'd be the chosen approach.
| sbuttgereit wrote:
| I do a lot of Elixir programming, which is different and not at
| the same time :-) . What I find is that it takes me longer to
| write the initial code than I might in, say, JavaScript, but
| that the refactoring and ongoing maintenance of code is
| significantly faster. This is because I think the functional &
| actor paradigms force you to think harder upfront, but once
| those decisions are made are easier to manipulate. For me
| personally, I'd take that trade since I'm either refactoring or
| maintaining much more frequently... but I understand there are
| other considerations which could drive a different preference.
|
| Also, I'm sure my personal experience isn't necessarily true
| for everyone... so weight this anecdote accordingly.
| humamf wrote:
| Thats interesting. In my case, elixir does take a longer
| time. Probably because i dont get used to or just use it not
| as frequent as other languange.
|
| Would you mind telling me your elxir program about? Is it a
| webapps or something similar?
| waynesonfire wrote:
| One of the features I really like about the BEAM is that it
| solves the problem of organizing the topology of the
| applications I build. It's unlikely you're even close to
| doing this in other languages / frameworks.
|
| The supervisor tree is one of the killer-app features of
| BEAM. I hit the benefits of this ALL the time. I notice how
| it keeps getting solved over and over again in unique ways
| that are half-baked. In some ways, this quote is what I'm
| hinting at, except, things don't even have to be
| concurrent. That's just a cherry-on-top.
|
| "Virding's First Rule of Programming: Any sufficiently
| complicated concurrent program in another language contains
| an ad hoc informally-specified bug-ridden slow
| implementation of half of Erlang."
|
| I'd also argue that "sufficiently complicated" bar isn't
| very high.
| morshu9001 wrote:
| There are matured ways to do multi-service outside of
| BEAM. I get that it's extra work vs something built in,
| but this is only an issue at large scale, and you'd
| probably need to set that up anyway unless every service
| is Erlang/Elixir.
| sbuttgereit wrote:
| The one that I can share is at:
| https://github.com/MuseSystems/musebms
|
| A few things to keep in mind. This is a "labor of love"
| personal project... sure a large one... but that's what it
| is. Another thing to consider is that I go off standard
| Elixir practices in a number of different ways and for
| reasons(tm); in this sense the project isn't representative
| of what a typical Elixir project looks like.
|
| When I say that things take longer for me to initially
| code, I'm not including "self-inflicted" time dealing with
| novel issues which arise from taking a less common path...
| which does have its own time cost. In my previous comment
| I'm only really thinking of the typical aspects of Elixir
| development time.
|
| Finally, I do need to emphasize: for me the cost is worth
| it. Once I get to maintaining that now-developed code or
| doing refactors, so long as I'm not throwing away
| everything and starting from scratch, the development time
| for me is rather less than I have with code of similar
| complexity developed in other languages. All personal
| experience... but there you have it.
| calvinmorrison wrote:
| I have been trolling for a while now to find a great project to
| write in Erlang. I can't write any erlang and it's sufficiently
| foreign it's been fun to try to get my LLM to do it for me. This
| is because I cannot make any useful suggestions on _how_ to write
| it.
|
| I have a toy replacement for syslog.
|
| i supervised an LLM writing a discord-esq chat program that
| implemented a imaginary JMAP extension called 'JCHAT'.
|
| i had the LLM write a Erlang based dimensional accounting system
|
| So far in real life i don't have any uses, which is a shame
| because it's a great language and OTP comes so batteries included
| I can think of many use cases.
| robby22 wrote:
| 500 Internal Server Error nginx/1.24.0 (Ubuntu)
| stevenjgarner wrote:
| Took me a long time to figure out what gets lost with Erlang is:
|
| a) Ubiquity -- everything understands HTTP. Erlang nodes only
| talk to Erlang (or a compatible runtime)
|
| b) Because there are no middleware standards (REST, GraphQL,
| OAuth, etc.), you must build or integrate your own abstractions
|
| c) Giving up infrastructure (reverse proxies, load balancers,
| CDNs), You handle distribution yourself or through OTP design
|
| d) Interoperability with browsers and APIs, requiring bridging
| via something like Cowboy or gRPC gateway
|
| setcookie secret in Erlang does not create or use an HTTP cookie,
| SSL certificate, or HTTPS connection. It sets the Erlang
| distribution cookie, a shared secret string used for node
| authentication within the Erlang runtime system (the BEAM VM).
|
| Erlang's built-in distributed networking subsystem allows them to
| connect to each other if:
|
| 1) They can reach each other over TCP (default port 4369 for the
| EPMD -- Erlang Port Mapper Daemon -- plus a dynamically assigned
| port for the node-to-node connection).
|
| 2) They share the same cookie value (here "secret").
|
| The author's insight "No HTTP. No REST API", reframes the reality
| that Erlang moves things down the ISO OSI model - HTTP being on
| layer 7 and TCP being on layer 4. Erlang therefore misses the
| "benefits" of operating on a higher ISO layer, but gains powerful
| advantages of operating on layer 4:
|
| i) True concurrency
|
| ii) Transparent message passing
|
| iii) Fault tolerance
|
| iv) Soft real-time guarantees
|
| v) Persistent cluster connections
|
| Erlang's design assumes a trusted, closed system of cooperating
| nodes, not a public Internet of clients. In other words, Erlang
| doesn't live below Layer 7 -- it IS its own Layer 7.
| quaunaut wrote:
| This reads as if it isn't trivial to have an HTTP API for your
| public API in Erlang/Elixir, which is weird. Sure there isn't
| an included HTTP API for Erlang processes, but why exactly
| would you want one? They're not _for_ the public internet, as
| their an implementation detail of your system. The majority of
| what they 're capable of just isn't relevant to the public
| internet.
| stevenjgarner wrote:
| Unfortunately very little is trivial for me. Personally I
| have found the real value of Erlang to be internally between
| trusted nodes of my own physical infrastructure as a high-
| level distributed "brain" or control plane for health
| monitoring, config distribution (env vars, static config
| files, etc), smart failover decisions etc. Keep the "outside
| view" (HTTP, SMTP, DNS) all standards-based OSI, internally
| mapped to daemons each of which is individually robust
| (HAProxy, MySQL Cluster, Apache/Node.js, Postfix, PowerDNS
| etc.). Then use an Erlang/Elixir service as a live config and
| state authority, replicating state across infrastructure,
| pushing updates in real time, and having my legacy
| PHP/Python/JavaScript/etc code query this config via a simple
| HTTP/JSON API into the Erlang service. I'm not all the way
| there yet, but what works is most encouraging.
| marcus_cemes wrote:
| This stands to reason. If you need to bridge different
| languages together like in your case, they need to speak a
| common tongue. REST/GrahQL/gRPC solve this problem in
| different ways. There is no technical limitation keeping
| you from serving HTTP traffic from Erlang/Elixir, but from
| my own experience it isn't a pleasant experience.
| JavaScript or Python are dead simple, until you realise
| that 64-bit integers are not a thing in JS, and need to be
| handled as strings. Similarly, tuples will give you hell in
| Python.
|
| On the other hand, if you don't need to cross that
| boundary, the BEAM will very happily talk to itself and let
| you send messages between processes without having to even
| think about serialisation or whether you're even on the
| same machine. After all, everything is just data with no
| pointers or cyclic references. That's more that can be said
| for most other languages, and while Python's pickle is
| pretty close, you can probably even share Erlang's
| equivalent of file descriptors across servers (haven't
| tried, correct me if I'm wrong), which is pretty insane
| when you think about it.
|
| > I have found the real value of Erlang to be internally
| between trusted nodes of my own physical infrastructure as
| a high-level distributed "brain" or control plane
|
| I think this is pretty high praise, considering it's about
| as old as C and was originally designed for real-time
| telephone switches.
| zachrip wrote:
| 64 bit ints are a thing in JS for a while now
| marcus_cemes wrote:
| No, they aren't. You have to use BigInt, which will throw
| an error if you try to serialise it to JSON or combine it
| with ordinary numbers. If you happen to need to
| deserialise a 64-bit integer from JSON, which I sadly had
| to do, you need a custom parser to construct the BigInt
| from a raw string directly.
| toast0 wrote:
| > There is no technical limitation keeping you from
| serving HTTP traffic from Erlang/Elixir, but from my own
| experience it isn't a pleasant experience.
|
| I would be interested in what was unpleasant? I've run
| inets httpd servers (which I did feel maybe exposed too
| much functionality), and yaws servers and yaws seems just
| fine. maybe yaws_api is a bit funky, too. I don't know
| the status of ACME integration, which I guess could make
| things unpleasant; when I was using it for work, we used
| a commercial CA, and my current personal work with it
| doesn't involve TLS, so I don't need a cert.
|
| > you can probably even share Erlang's equivalent of file
| descriptors across servers (haven't tried, correct me if
| I'm wrong)
|
| Ports are not network transparent. You can't directly
| send to a port from a different node. You could probably
| work with a remote Port with the rpc server, or some
| other service you write to proxy ports. You can pass
| ports over dist, and you can call erlang:node(Port) to
| find the origin node if you don't know it already, but
| you'd definitely need to write some sort of proxy if you
| want to receive from the port.
| toast0 wrote:
| > a) Ubiquity -- everything understands HTTP. Erlang nodes only
| talk to Erlang (or a compatible runtime)
|
| OTP includes an http client and server. And ERTS includes an
| http mode for sockets. You may prefer 3rd party http servers
| (yaws and Cowboy are popular) or clients, but you have options
| that come with Erlang.
|
| [No comment on b; I'm not sure I aprechiate the concept of
| standardized middleware]
|
| > c) Giving up infrastructure (reverse proxies, load balancers,
| CDNs), You handle distribution yourself or through OTP design
|
| You can put all this stuff between the users and you Erlang
| cluster. Within your Erlang cluster, I don't think it makes
| sense to leave the cluster and go back in... If you had a large
| server process in [language of choice], you probably wouldn't
| send request out to a load balancer to come back into the same
| process. If you have an n-tier system you may use a load
| balancer for requests to the other tier... In Erlang, the
| simplest analog is processes that serve the same request queue
| would join a pg group, and processes that want to send a
| request send to one of the members of the group.
|
| > d) Interoperability with browsers and APIs, requiring
| bridging via something like Cowboy or gRPC gateway
|
| If you want to talk http, you need something that talks http;
| there's at least 3 reasonable options, plus an http parser for
| sockets so you can do it yourself without as much fiddly bits.
| I guess I don't understand what you're looking for here.
| btbuildem wrote:
| Incidentally, it makes Erlang-built systems robust. I used to
| run yaws-based web servers (and still do). One laughs at the
| logs, the feeble adversarial attempts to run this exploit or
| that. Nothing fits, nothing penetrates, nothing is even
| remotely relatable.
| 29athrowaway wrote:
| It's a Galapagos island full of stuff that evolved
| independently.
|
| Concurrency is important, but if you are not familiar with
| concurrency primitives like mutexes, condition variables,
| barriers, semaphores, etc. and skipped directly to the actor
| model, that's a bit like you care a lot about concurrency while
| not caring at the same time.
|
| Functional programming is great, but your CPU has registers and
| the way it works is closer to the imperative paradigm.
| immibis wrote:
| There's probably not as much advantage to HTTP as you think.
| However, something like JSON is pretty useful for its ubiquity.
|
| The simplest RPC protocol is where you connect to a TCP socket,
| send a newline-terminated string (JSON encoding optional - or
| protobuf) per request, and get a similar response back. You
| don't need HTTP for that. It's presumably also not something
| Erlang easily supports.
| adamddev1 wrote:
| The only thing holding me back from Erlang is the lack of type
| checking. Convince me?
| igouy wrote:
| https://www.erlang.org/doc/system/typespec.html
| simoncion wrote:
| Yep. You feed files annotated with those to Dialyzer or
| similar for not-runtime typechecking. That plus the basic
| runtime checking provided by guard expressions [0] gives you
| a bunch of coverage... and I think some of the folks who like
| Elixir are working on their own typechecker thing? I don't
| really know, because I don't use Elixir.
|
| [0]
| <https://www.erlang.org/doc/system/expressions.html#guard-
| exp...>
| modernerd wrote:
| You might like https://gleam.run/, another BEAM language but
| with type-checking.
|
| https://tour.gleam.run/basics/type-checking/
| Alupis wrote:
| Gleam compiles to Erlang. So you can skip Erlang entirely but
| get all of the BEAM and ecosystem's benefits.
|
| Gleam is very much worth checking out. It's syntax is very
| nice and natural feeling.
| bora_g wrote:
| Author here, I'm really surprised to see the story reached top 3.
| All of them is true and thanks to Erlang still surprises me.
|
| My current stack is Elixir + Rustler on server and Rust + Wasm at
| frontend. Thanks for reading :)
| jjtheblunt wrote:
| can you give advice on frontend pertinent Rust crates?
| btbuildem wrote:
| It's funny, because I find Erlang to be one of the least
| accessible languages I've ever tried (and my entry into this
| world of digital wonders was thru disassembling cracktros on a
| M68k, before internet, in a then-foreign language).
|
| That said, the metaphors are so elegant, the key concepts so well
| chosen -- yes, the initial onramp may be a cognitive slog, but
| it's well worth it. It makes everything downstream so much
| easier.
___________________________________________________________________
(page generated 2025-11-11 23:00 UTC)