HN Academy

The best online courses of Hacker News.

Hacker News Comments on
Functional Programming in Erlang

FutureLearn · The University of Kent · 83 HN points · 7 HN comments

HN Academy has aggregated all Hacker News stories and comments that mention FutureLearn's "Functional Programming in Erlang" from The University of Kent.
Course Description

Learn the theory and practice of functional programming in Erlang, through practical exercises and suggested projects.

HN Academy Rankings
  • Ranked #27 all time · view
Provider Info
This course is offered by The University of Kent on the FutureLearn platform.
HN Academy may receive a referral commission when you make purchases on sites after clicking through links on this page. Most courses are available for free with the option to purchase a completion certificate.

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this url.
Sep 01, 2021 · scns on Why Erlang?
On my phone and in a hurry now, excuse my not ddging it, there was one by a british university, paid though. I may have it in my bookmarks. Will respond with link later if noone else does.

(edit) There you go:

There are older videos from them on YT:

Found this in my Erlang bookmarks:

Appreciate it!
May 13, 2020 · moviedo on OTP 23
I'm currently learning erlang/elixir and I'm really enjoying the language constructs.

I had originally taken a Programming Language Paradigms class in college with racket, and I really didn't appreciate functional ideas(i.e. syntax is my excuse). I'm now a really big fan of functional language idioms.

Anyone interested should try the futurelearn class,

I was in the same boat until discovering elixir/erlang it has by far been the most approachable functional language for me and it has been a gateway drug of sorts into experimenting with ocaml and various lisps.

I personally think elixir is really special and an amazing fit for any project that needs high IO concurrency.

Agreed! I found learning Elixir to be a great gateway to learn Erlang as well. When I first tried learning Erlang (before Elixir was released), it became a bit too much to wrap my head around. It was a lot easier when I had gotten the fundamentals of FP down through Elixir, though!
Yes definitely, I would have never even bothered with Erlang before using Elixir and having it introduce me in a friendly way to Erlang, which is a shame because honestly the EVM and OTP are amazingly strong at what they both do.
IMO erlang (and arguably even more, elixir) is "functional for the working programmer". It doesn't drown itself in academic abstractions, uses functional programming as a tool to guardrail you from mistakes (in the same way that C guards the programmer from making asm mistakes), with escape hatches that are battle-tested and justified based on decades of experience.

I would say the only other functional language that has the same bent is Julia, which is "functional for the working scientist". It makes different choices about where to expose state, understandable, since scientific computing has different tradeoffs from systems programming.

I think Scala is the ultimate "gateway" FP language, for better or worse. Kotlin would probably meet the requirements, though I've never used it.
Yeah I think that's a great way to frame it, historically one of the turn offs for me with FP was that it was overly academic when I am much more about how practical a tool the language is for what I'm trying to accomplish. Elixir was definitely the first FP that felt that way for me.

That said I have grown an appreciation for more esoteric languages and enjoy seeing the way they handle various problems it's just likely they'll never have a place in my toolkit.

On the Elixir/OTP side I've really enjoyed this course too: They have a current discount code LIVEVIEW (not affiliate), which is advertised on their currently free early access Phoenix live view course.
One of the really nice things about shared-nothing concurrency is that it scales to multiple machines. The same code that works locally will work across a data center. Along the same lines, shared-nothing tends to scale better as you add cores. With lock based programming, as you add cores, many times your contention increases minimizing the benefits of the additional cores.
Same. Or similar, it’s taken longer than it should for me to appreciate the functional paradigm.

Rust and Scheme have been gateway drugs ha. I found I really like OCaml-y languages.

Now, I’m very interested in Erlang (and to some degree elixir). I’m learning as much as I can about Erlang and the ecosystem; I’m trying to answer the question, “why isn’t Erlang more popular?”

Any guesses? Reasons? (syntax aside)

I might sound bitter but after about 3.5 years with Elixir my answer is very simple and boils down to:

Habit, confirmation bias, sunk cost fallacy.

Namely: people have gotten a lot of battle scars by working with what pays their bills -- PHP, Ruby, Python, C#, Java -- and they refuse to look at an alternative because that would render their huge time and energy investment moot (in their eyes at least; I don't see why this has to be the case but plenty of people have been adamant about this without giving an explanation).

I've only become a better programmer since I adopted Elixir but I never stopped using other languages.

All of that plus what PG calls "the middlebrow dismissal" are the main reasons IMO. People are just too set in their ways.

I've got those scars but I still find erlang refreshing when working with it. Unfortunately, as software engineers, we work in groups and there are many people having these scars. However, the erlang experience changes one forever.
As you said, unfortunately programming turned out to be quite the tribalistic activity indeed.

I got severely disheartened that 2-3 casual mentions of Elixir were enough for several people in this thread to attack and quickly stereotype me. I think I'll just keep quiet, or at least not mention what I work with. This seems to get the message across much better.

Interesting. Is FutureLearn something analogous to Coursera and edX?
Yes, very much the same as Coursera. Almost 1 to 1.
Did you go to Northeastern? Glad to see a fellow Husky in the wild!
I never understood why people rave so much about functional programming wrt Erlang/Elixir, when its functional programming is clearly only a means to an end (fast and safe message passing requires immutable data, which requires FP) and not a driving design goal in its own right.

I mean, unlike in typical hard FP languages like Haskell or Elm, mutable state is rampant in your average Elixir app, it's just spread out across many (global singleton) little processes. Only inside a process you're doing "true" FP but given how small the average process is in scope, in practice the only real big difference is that you can't to an `i++` style for loop. Oh no!

But once you leave the process boundary, and often even before it, all bets are off. The amount of Elixir forum messages I've read that go "you can't do X at that point, because Y hasn't completed yet" is nuts.

Eg you can't broadcast in a phoenix channel `join` because the channel hasn't been fully initialized yet. So you send yourself an :after_join message and do the broadcast in there. I don't know about you but to me this feels a lot more like C++ than like Haskell.

Or consider the library module Agent which is exactly identical in semantics to a global singleton variable in an OO/imperative language. It's just a blob of data that you can get or set.

Now, I don't think any of these are disadvantages. I did mostly C# and JavaScript before Elixir, so I'm used to the occasional mutable state flying around.

But I'll never understand that people like Elixir for being FP. You just get such a small subset of the usual advantages of FP that it feels like an implementation detail. There's lots of advantages, but freedom from thinking about state isn't one of them.

> But I'll never understand that people like Elixir for being FP.

To me the answer is: using mutable state is opt-in. I disagree that "mutable state is rampant".

By opting in to the mutable state constructs you are basically saying "I know what I am doing, let me do my work" which is IMO quite fine because "pure" FP languages like Haskell can be a huge hassle when you actually need to deal with the real world.

To me Elixir is a very nice compromise.

Mutable state is essential to the actor model. Local arguments to a tail-recursive message loop which change based on the last received message and the previous arguments, and determine behavior (i.e. messages sent and side effects), are equivalent to local mutable state. State machines are a lot better than unstructured, freely mutable global variables, but they are still mutable state.
That tail-recursive message loop is acting as a State monad, as the code sending messages is forced to transition through the sequence of actions one at a time and can't go back to a prior state by accident; so, while I agree that it is "mutable state", it is "mutable state" that could be implemented in the exact same manner in Haskell. I feel like the real issue here is about concurrency and shared state (as many actors are able to drive that monad forward in Erlang, and I am not sure off the top of my head if that could be at all possible in Haskell).
Sure. That's absolutely unavoidable in any FP language. All their compilers invisibly produce a lower-level code that's intrinsically using the mutable paradigm. It's how our hardware works currently.
No, in an actor based model the mutable parts that the comment you replied to mentioned are surfaced to the user.

It's not about how the Erlang VM is implemented. You could implement it in pure Haskell and compile it so some hypothetical pure CPU. Wouldn't change that part of how you interact with it that is stateful as described.

(And I liked programming in Erlang.)

And I still disagree with that comment that "mutable state is rampant". There are realities which we all have to take into account. To give an extreme example, should we get rid of all mutable databases and use append-only journals? That might help eliminate another class of bugs but there are a number of (practical and political) limiting factors in commercial projects.

But maybe we'll talk the same language if you give a few examples. I was under the impression that my parent poster made the point of "but your FP code gets compiled to imperative mutable code so FP is not good" or something. If I was mistaken in my interpretation then we're talking past each other.

As far as I can tell, that's not what the great-grand parent comment was about.

Have you ever programmed in Erlang?

About your first paragraph: not all databases should be append only, but it would be a good idea to make append-only the default and only deviate for a good reason. (Instead of making mutable the default, and only weirdos go for append-only.)

I work almost exclusively with Elixir for 3.5 years and love it. But I am not seeing that poster's point still.
I understand the point as: being able to send a message to a particular actor, passing it a value that you can later retrieve by sending that same actor another message, is semantically exactly the same as calling a setter on an object reference, and later calling a getter to get the value back. In both cases you have a pocket of mutable state, potentially accessible by multiple unrelated places in code, that isn't reflected in function signatures.
Mostly true, minus the fact that the mutable state's access is serialized / centralized due to the nature of Erlang's actors (lightweight threads; usually called fibers in other languages, and even that is not a good analogy since they are preemptive and not cooperative). So the semantics being similar is not strictly and 100% true. You can't do non-atomic volatile modification like you can in C/C++.
> You can't do non-atomic volatile modification like you can in C/C++.

Yes, exactly. No one was implying that Erlang's model is mimicking those particularly weird languages. The statement was much more narrow.

My point was that the actor model has the semantics of local mutable state. The fact that an actor model language is compiled for a von Neumann machine is irrelevant to my point.
Okay, that's true, but especially in Erlang's BEAM VM the mutable state's access is serialized / centralized. An actor's state is not a globally modifiable volatile variable a la the C/C++ ones.

Though I don't think anyone ever suggested the actor model (or Erlang) was doing C/C++ craziness.

> I mean, unlike in typical hard FP languages like Haskell or Elm

What is a "typical" FP language? Are Scheme, Common Lisp, OCaml, SML, atypical?

> mutable state is rampant in your average Elixir app

I don't think this is generally true, or at least not on my experience, but I guess it may depend on what would one consider rampant.

Well, my main Elixir project is the backend of a web service. The input is JSON from the frontend and JSON or XML from a number of third party APIs. We process it, hit the db with select, update, insert and usually return a value. The same function with the same inputs usually returns different values because the db is stateful.

What I like of Elixir is not functional programming, it's the extensive use of pattern matching. What I like less is the convoluted syntax of GenServer with all those handle_cast/calls that obfuscate the real code. As a GenServer is usually a way to store a state, they should have had the courage of calling them objects and give them an object like syntax. After all they initially sold Elixir to developers coming from OO languages. If they had given it a Java like syntax maybe it would be 10 or 100 times as big by now.

I think you are misunderstanding what GenServers are and are for.

GenServers do have their own state, but they are used for way more than just storing state. It's probably best to literally think of it as a server in your running application, analogous to a server running on a network.

If storing state is all you're trying to do you might want to look at Agent or possibly ETS.

Further, GenServers come from Erlang, not Elixir. They're intended to model all sorts of runtime properties of code.

Thankfully they didn't give it Java like syntax! The syntax is currently a bit more verbose and explicit on dealing with local/micro state which I now like, but without using 100 lines of boilerplate getter/setters. Using pipes gets one enough "OO" syntax feel.

While GenServer's store state they are, in my mind, more akin to microservices than Java/C++ Objects. They're like microservices, but without needing a separate service bus, global naming system (pg2), etc. Now I do wish Dialyzer/Dialyxer also had better support for checking GenServer handler's and messages, especially intra-process. You have a point the syntax their could be spruced up some perhaps. The process / GenServer paradigm kind of remind me of Smalltalk in a way, where you're passing messages that object may or may not want to respond to. That's not really possible with C++/Java objects.

Practical tools often achieve that practicality by avoiding dogma.
"Dogmatic" is a great description of OTP, though. You have to adopt the OTP mindset, adhere to the OTP principles, and organize your architecture in the OTP style. There's a long initiation process where you learn esoteric vocabulary, become familiar with bespoke tooling, etc.

This isn't meant as criticism -- I think Erlang/OTP is a brilliant piece of work. But arguably Erlang/OTP is a practical tool that achieved practicality by embracing dogma.

I think it's more accurate to say that OTP's dogma comes specifically from it having chased down pragmatism to a fault, to the point where whether or not OTP's doing something is a reasonably-reliable indicator of whether or not that something is a good idea (at least for Erlang's typical use cases) and therefore arguably warrants the dogmatism.
That's a good way to put it. I think we're in agreement that dogma wasn't avoided in this case.
I mean, yes? OTP is a framework—a paradigm for writing your code in, essentially—but it's an optional one. That's why it's split out from Erlang itself. You can write Erlang however you like. Most people choose to write it in the OTP paradigm. But sometimes that's not the best choice (e.g. the type of code that leex/yecc generates, does not obey OTP principles, nor would it help it in any way if it did.)
Fair point. Big frameworks and dogma go hand in hand, and I suppose Erlang without OTP is at least as practical as any other language.

I wonder though if Erlang might have been a footnote in programming history if it weren't for the mindshare that OTP generated. "Simple functional language" is attractive, but "simple functional language with world-class platform" turned out to be a game-changer.

> I wonder though if Erlang might have been a footnote in programming history if it weren't for the mindshare that OTP generated.

It absolutely would be. There's plenty of "simple FP languages" out there. OTP is very definitely the main selling point of Erlang, and nowadays of Elixir as well.

> You just get such a small subset of the usual advantages of FP

Yeah but you're using that small subset in 90% of your code.

Look, this is not a thing to worry about in elixir:

    def p(my_array):
      return my_array
what is my array? I don't know. It could be anything. The company I work for just hired a sloppy python programmer that I don't want anywhere near my code, and you know what, if we change a section of our code to Elixir I am way more willing to have him work on our team.
I have a prototype system where I am passing over 100k msg/sec between a dozen backend services written in python (asyncio+redis) and I keep on wondering when my bottleneck will become functional programming and safe message passing by making copies. When will the madness end?
Tradeoffs. In the setup you describe I'd pick correctness over performance any day.

If you hit a performance bottleneck you might as well just use RabbitMQ or Kafka to queue up stuff and process it as it comes along. Or apply back-pressure if your current code allows for it.

I actually use redis hashsets to queue stuff when I need correctness. Much more performant than rmq's mnesia
i don't think erlang is requiring FP + immutable + message passing for performance, but rather for correctness. Making copies is actually more expensive in terms of perf.
me too, and I have no clue as to how changing language can increase correctness in my case. I can think of other use cases where in-process concurrency and mutating data structures could cause problems, but I avoid those scenarios entirely anyway.
If you look closely enough at Haskell, you’ll realize that it also can have a lot of mutable state. Haskell just puts state into various monads and STM to make its functions pure. You can even spawn numerous isolated threads, all with their own state, and have them communicate with one another like you do in Elixir. It does provide a lot of structure and guarantees compared to your standard imperative language, but I assure you mutable state is still there.

To be clear, the Elm model of putting everything into a big tree and and transforming that at every user input is very unusual among even FP languages, and is not the model typically used in Haskell. This might be what you are thinking of.

Edit: I also want to point out that Elixir processes can be registered globally to act as singletons, but by default you can spawn any number of agents or other processes at runtime, meaning they are not singletons.

a process is a singleton even tho the code it runs is reused
I’m not sure what you mean. A singleton is something your program only has one of. You can have any number of processes. By your logic, every object in an object-oriented language is also a singleton.
Actor frameworks with message passing, just like direct mutation, don't compose.

On Haskell, yes, you can just work off a thread and write shared buffers. But you are better off using STM or Async (these are a bit like futures), which compose, and you can write pipelines out of them.

Everything that you pointed out can be achieved in Elixir, quite easily too. If I understood you correctly.

Not sure what you mean by "actor frameworks don't compose"?

Actor frameworks don't compose, because actors are an atomic compute unit. You can't really take a horse actor and a bird actor and turn them into a pegasus actor. There are non-trivial interactions between message handling logic that would prevent such a thing with some fairly trivial-to-generate breaking cases.

Maybe composition for compositions' sake isn't that important?

You can write great and useful software in non-composable languages. People write good stuff in C or Go.

But if you have the choice, composability always seems much nicer to me and stops me wanting to tear my hair out.

This is definitely true, I am just not sure how well it applies to actors. For all data-modelling scenarios and OOP/FP ways of doing polymorphism, composability is a life-saver though.
It's a good question. Let me meditate on actors and STM. Perhaps there's a way to get something like vectors that's composable.
The point of the actor model, at least in OTP, is not to have the actor model as a unit of computation (as was imagined by Hewitt, et, al) but as a failure domain. Erlang was not designed to be an actor system, it was designed to be a robust system and they later discovered that what they had built was more or less the actor model (if an impure version) and it was easy to communicate the architecture's computational capabilities and mental model as actors. Actually I think if anything it's led to a fair share of misunderstandings, and truly misses the important and unique aspects of Erlang processes.

In the sense of being failure domains, OTP "actors", or processes, ARE composable. With very little boilerplate, that is built in as primitive BIFs in the standard library, I can bundle failure domains together and orchestrate them using links, monitors, and supervision strategies, with the ultimate failure domain being a single erlang VM operating inside a cluster of erlang VMs, all supported without third party libraries as a part of the way of doing things.

Interesting idea, but I'm not sure I agree. I was doing a lot of telephony/mobile back in those early 1990s and there was a huge amount of formalism. We tried to model everything as FSM that transitioned states based on received messages. We even used code generators to generate code directly from diagrams. I believe Erlang grew out of that same approach. And initially, systems that failed would simply restart by default.

Then the idea of adding a supervising and observability was a natural addition to these systems.

That said, I think OTP is a great tool for modeling failure domains and I think it does a great job.

> Maybe composition for compositions' sake isn't that important?

Definitely. I was about to ask "but when did you actually need to compose actors and how does that even make sense?" -- and while I am sure there are people who would find a scenario I feel that would still be tarrying on minutiae.

Obviously the actor model is not a panacea. But for my commercial work Elixir -- and thus Erlang's OTP -- has been a true blessing. There aren't many commercial scenarios where OTP is a very poor fit. They do exist but I'd dare saying they are no more than 10-15% of everything you can stumble upon out there.

Yep I love Elixir too. Just, you know, I try to only sip the kool-aid.
Well, I am just now arguing with people in another thread that nobody claims that Elixir is an end-all be-all.

It's quite sad how fiercely the average HN audience is attacking people who are trying to show an alternative way of doing things.

Aug 16, 2019 · javajosh on Just Enough Erlang
This looks like a nice intro (although I didn't read it in detail), however I wanted to mention the way I learned Erlang, from (the late) Joe Armstrong via the Erlang course at FutureLearn. It was a very good course and quite practical. (I am not affiliated with them, I just liked their course)
Jun 21, 2017 · marianoguerra on Erlang/OTP 20.0
if you want to get started but don't know where this is a good place to start:

there's a online course by Simon Thompson from the University of Kent that started 2 days ago, you may be able to join:

if you like the ideas but want to try something different there are alternative languages that run on the Erlang VM:

* Elixir with a ruby-like syntax:

* LFE (Lisp Flavoured Erlang):

* Efene with a python-like syntax:

and one in development but already looking really interesting: Alpaca, an ML inspired language:

There's a lot of overlap with Spawned Shelter, and I haven't touched it in a few months, but is a list of free Erlang resources I try to maintain.
I was not aware about Spawned Shelter and your list of resources wow, I need to check the first be as soon as I click on your link I needed to write you some thanks message! awesome job with the list.
Please don't forget about Luerl: Lua has GREAT support inside the BEAM VM ecosystem
yep, there's also an erlang implementation of prolog

the only different with the others is that since they implement existent languages following the spec, which means that some things don't map directly to the VM semantics and pay a little overhead, for example lua is a mutable language and the BEAM is immutable, this means that mutability is implemented by passing an immutable environment and mutating it.

This doesn't mean you can't use them, but they are mostly used as extension languages and for scripting than for complete projects.

The original Lua has also designed to be used as extension language to be embedded and give the base systems scripting super-powers! The beauty of the Luerl Lua implementation is that is really a full implementation of the Lua language is not something inspired by Lua or some kind of handicap version of the language. I agree of course with your statement about a little overhead, but it is a real true Lua.
Luerl lacks tail call optimization, coroutines, and "proper handling of __metatable". Without those three things Lua is just a simpler JavaScript and not that interesting.

(Lua also has a first-class C API, but we'll let that slide.)

What do you mean with proper handling of __metatable?, I'm not aware about the lack of tail call optimization that you mention please share your sources, about coroutines luerl is designed to use Erlang processes instead of coroutines that's the beauty of its implementation, you have millions of independent lua vm's running on top of independent beam processes.

Coroutines are replaced by concurrency of multiple lua processes running in parallel if you have more than one physical core on your machine all in the same battle tested Erlang VM.

(Luerl is an implementation of that fist-class C API, but for the BEAM Erlang/OTP VM)

I'm not exactly sure what's meant about __metatable, either. I merely quoted directly from the project website:
I assume they don't fully implement some of the metatable semantics, such as __gc on tables or operator overloading. They don't mention lacking coroutines, but the interfaces are missing from their list of supported interfaces.

Coroutines aren't just about green threading or async I/O. I often write tree walkers similar to this:

  local function walk(t)
    local function walk_next(node)
      if node then
        coroutine.yield(node, "preorder")
        coroutine.yield(node, "postorder")

    return coroutine.wrap(function ()

  for node, order in walk(tree) do
Basically, coroutines allow you to easily reverse consumer/producer roles such that both consumer and producer can be implemented in the most natural style. That's hugely helpful when dealing with complex data structures and complex code flow, and Lua is somewhat unique in providing stackful coroutines. (Scheme is perhaps the only other language providing something at least as powerful--call/cc is even more powerful. MoarVM has stackful coroutines, but they're hidden behind Perl 6's narrow gather construct. Though, FWIW, the gather interface works well for the particular example I gave above.)

I understand that Erlang is all about message passing, which can provide similar semantics. But when programming in Lua, stackful coroutines are a huge asset. They don't require copying of messages and are basically free--creating a new coroutine has about the same cost as creating a function closure in terms of memory, and invocation costs are the same as a pcall, which means there's basically no significant performance impact. More importantly, because they're stackful you can generally call unrelated module and library routines without that code needing to be aware that they're running in a coroutine, or that a function they've been passed might yield the coroutine. (The only niggle is if library code passes a function, which itself might yield, into another coroutine. In that case the function might yield to the wrong resume point. But IME this is very rare, specifically because coroutines often obviate the need rely on callbacks as an interface for result production. Aside: Does Erlang support passing functions--and closures--to another Erlang process?)

First thanks for the quality of your response.

Yes, I notice the quote from the project github repo, just guessing I thought that it was referring to the lack of getmetatable and setmetatable functions, but I see them in the debug module, I'm no Lua expert so I don't really know how this lack of handling of __metatable feature affects the implementation.

But it's no related with the garbage collector or any type of missing feature that could make the Luerl project unusable.

About coroutines, there is no coroutines in Luerl but that's on purpose and I know it may seems counter intuitive coming from a solid Lua background.

I can't agree more with your statement about that coroutines aren't just about green threading or async I/O, I agree with you on this completely... BUT

In the BEAM ecosystem you kind of want to use processes instead, the VM it's build for handling independent isolated processes that are very small and like you said basically free at creation time and also at context switching.

The main difference between processes and coroutines is that, literally, in a multiprocessor machine a OTP release on the BEAM runs several processes concurrently in parallel. Coroutines, on the other hand, are running only one at the time on a single core and this running coroutine only suspends its execution when it explicitly requests to be suspended.

> there's a online course by Simon Thompson from the University of Kent that started 2 days ago, you may be able to join:

First time doing a MOOC - is this considered a good quality one? I find his ordering of course material not always logical, and he omits useful info in places (discovered through Googling)

Thanks! I came here to ask the "How do I Erlang?" question. Erlang has been on my radar for a long time but I've never taken the time to dig in. 85% of my code output is obscure protocol stacks in Python+Twisted, the other 15% is real-time embedded C over an RTOS. Even if I can't use Erlang in production, I'm sure I'd find food for thought in the concepts.
You run close to the metal, eh? Then you might find this project interesting to hack on:

FWIW, the class for it was the first class to sell out for the upcoming

Here's a great presentation by Garth Hitchens on Nerves (he uses it in production at his company,, which builds sort of vertical-market marine navigation hardware). He mentions some performance stats as well.

Yes, thanks. Good link. I do live on the hardware/software frontier and always have.

I'm a big fan of Micropython, Python on bare metal. Noob question: What is the chance of an Erlang VM on bare metal?

Pretty decent chance:
wow, first I've heard about this. How does this differ from the Nerves project, which also boots directly into the Erlang VM?
Nerves boots into the ErlangVM, but runs on a buildroot Linux. This makes it possible to run on a wide variety of hardware, but with the associated baggage.

GRiSP uses RTEMS[0] as its base which should make its performance more predictable.


The tutorials and core library documentation are really very clean.. You should be able to go pretty far just by installing a package and starting through the tutorials, although OP also has some links to more docs too

That book is a good place to start.

> Even if I can't use Erlang in production, I'm sure I'd find food for thought in the concepts.

Oh boy are you going to be in for a treat. The concept for no loop construct other than recursion and recursive thinking was worth it for the little time I dabble in Erlang.

Sounds excellent. Procedural imperative programming is the curse of computer science. Program counters be damned! Data-flow FTW.

I'm sure there's some tee-shirt art in that rant somewhere.....

As an erlang newcomer, the non-loop seems to be one of the most intriguing concepts, IMO.
You still have list comprehensions, map, filter, fold and foreach using higher order functions
Since some people were asking on how to get started with Erlang, some time ago this MOOC was posted on HN for an intro to learning Erlang/functional programming.

What I liked about it is that it assumes you have an imperative programming background so it isn't entirely like learning at a very slow pace (which leads me to lose interest):

The next course after this is on the concurrency part of Erlang which is also on FutureLearn that I'm currently taking. It has video clips from Joe Armstrong teaching concurrency (one of the creators of the language).

I strongly feel that Erlang really, really needs more visibility in the world. It is an important language for distributed systems, but the language itself is startlingly spare, using recursion and pattern-matching in lieu of conditionals. There are two resources that I like, a 3 week Future Learn course [1] and Learn You Some Erlang [2].

It is my belief that the Erlang "process" is a true object, as opposed to Ruby/Java/C++ etc object which is, ultimately, a thin easily-torn veneer over global spaghetti.

WhatsApp's acquisition for $1B for a 57-person team that could run a large, world-wide messaging system with Erlang should also be considered a resounding endorsement.

Last but not least, I personally have come to see the overall trend toward statelessness is a coping mechanism to deal with bad technology.

(If I could change my name to ErlangJosh, and if it sounded good, I would.)



What about languages like Smalltalk and Lisp? ... Well, Lisp at least have some acknowledgments, but Smalltalk can be compared to Erlang in lot of aspects.
Mar 09, 2017 · javajosh on The System Design Primer
I am only learning Erlang now (through the futurelearn course[1], posted here, about a month ago now). One of the reasons it interests me is that it was designed from the start to support high-availability concurrent, distributed processes. It's a functional, dynamic language meaning that you can reprogram a system at runtime if you want (see: gen_server).

Like I said, I'm only starting and I don't know how real Erlang systems are built. However, I suspect that they tend to eschew the orthodoxy of treating a relational database as a single source of truth, with stateless app servers (these two features are the core of all the systems in the OP's thing) and embrace distributed, redundant statefulness. If this can be done (without becoming impossible to reason about) I suspect it represents an optimal server system, in terms of resource usage, availability, and probably even in performance in a world where most organizations' datasets can fit entirely in RAM, from when they are a twinkle in someone's eye to their eventual dissolution.

I should stress that "questioning orthodoxy" is something of a hobby, which probably biases me.

[1] [2] keeps coming up as a good learning resource.

Feb 20, 2017 · 83 points, 1 comments · submitted by ivarvong
I'm taking this course, very excited to learn some erlang
You'd be better off reading LYSE and writing something to actually work with network (and trying to deploy it). From what I saw in the curriculum, it's just using Erlang as a toy calculator and masturbating over syntax trivia and tail recursion vs. direct recursion, like the two were supposed to be opposites.
HN Academy is an independent project and is not operated by Y Combinator, Coursera, edX, or any of the universities and other institutions providing courses.
~ yaj@
;laksdfhjdhksalkfj more things ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.