The Little Schemer Exercises in Elixir(github.com)
github.com
The Little Schemer Exercises in Elixir
https://github.com/jwhiteman/a-little-elixir-goes-a-long-way
23 comments
Note that modern Scheme implementations have pattern matchers that eliminate much of the car/cdr'ing done in the Little Schemer, making it much shorter.
Yes, or just use match.scm which provides this functionality as well.
The point of Scheme is not the features it has, but how it allows you to build the features yourself. Try doing logic programming in Elixir, probably it won't work that well (just probably, I don't know Elixir).
The point of Scheme is not the features it has, but how it allows you to build the features yourself. Try doing logic programming in Elixir, probably it won't work that well (just probably, I don't know Elixir).
Erlang is greatly influenced by Prolog. The first Erlang implementation was actually written in Prolog. Erlang and Elixir are just fine for logic programming.
There's a good Elixir implementation of MicroKanren: https://github.com/lyons/ExKanren
There is a whole bunch of implementations of The Little Schemer (and other great Lisp books) in Clojure here: http://juliangamble.com/blog/2012/07/13/amazing-lisp-books-l...
I am completely unfamiliar with Elixir but I love the aesthetics of the language. That's a really neat piece of work, thank you for sharing.
I often wonder what are some good usecases for Elixir? What kind of problem do you solve using Elixir?
I often wonder what are some good usecases for Elixir? What kind of problem do you solve using Elixir?
It runs on BEAM, the erlang vm, and has essentially the same usecases as erlang. Good for distributed systems, including web applications, bad for cpu bound tasks, for systems programming. Not great for scripting but usable if you want.
> bad for cpu bound tasks
Just to elaborate on this: Elixir is slower at CPU work than C/C++/Java but still significantly faster than Ruby/Python/etc. not to mention a lot easier to do work in parallel due to SMP and the BEAM's concurrency model.
Just to elaborate on this: Elixir is slower at CPU work than C/C++/Java but still significantly faster than Ruby/Python/etc. not to mention a lot easier to do work in parallel due to SMP and the BEAM's concurrency model.
Plus, if you have a big task it's a whole lot easier to add CPUs to do additional work in Elixir/Erlang than in any of those languages-- C/C++/Java/Ruby/Python/etc.
If your work requires more than one node, Elixir is a lot faster than trying to create distributed system in another language-- you can just spread the work over many machines almost trivially by comparison.
Literally just tell other nodes to run the function.
If your work requires more than one node, Elixir is a lot faster than trying to create distributed system in another language-- you can just spread the work over many machines almost trivially by comparison.
Literally just tell other nodes to run the function.
I hear about the distributed properties of the vm often, but every example seems naive in that the work is passed to a named node, where in practice it seems the need would be to load balance between nodes available nodes.
For example, I have a system in Go that uses redis to pull jobs, each process I spin up uses a buffered channel allowing 20 concurrent requests. I looked at elixir because I liked having a the process isolation and the dynamic nature of the language (the jobs scrape data from the interwebs), but I couldn't find a simple way to distribute jobs to nodes unsuring each node is capped at 20 concurrent jobs.
For example, I have a system in Go that uses redis to pull jobs, each process I spin up uses a buffered channel allowing 20 concurrent requests. I looked at elixir because I liked having a the process isolation and the dynamic nature of the language (the jobs scrape data from the interwebs), but I couldn't find a simple way to distribute jobs to nodes unsuring each node is capped at 20 concurrent jobs.
A simple way to do that in Elixir / Erlang is to just have each node spawn 20 processes that fetch work from redis (or a central coordinating process on another node)
Yeah, so the details of such is what I have not seen any examples of. I do plan to figure it out soon and then hopefully share it to benefit others. From what I understand thus far, I'll create a GenServer to connect to redis (so only using a single redis connection), pull jobs from redis and spawn Tasks on all nodes registered with the GenServer. And then I need to figure out how to limit the GenServer to a single instance per app on all nodes, or if too much hassle, just allow a GenServer per node and only spawn Tasks on the local node (so 1 redis connection per node).
A simple approach: Set up your apps' supervision tree such that you got poolboy [1] with a fixed pool of 20 worker processes and the one GenServer that distributes the work.
If you go with one GenServer per node, then that one just connects to redis and just pulls jobs (using BLPOP or whatever). When it has gotten a job it checks out a worker from poolboy and assigns it that work.
You could also just have every single worker process go directly to redis and have it pull jobs in a loop. But where's the fun in that ;)
If you want a single global coordinator instead of one per node you can use :global [2] to globally register a process in the cluster. This process is then cluster-wide reachable under its registered name. It can talk to each of your worker pools in the cluster and round-robin try to check out workers and assign them work. And if you do this you might as well ask yourself if you really need redis instead of keeping it all within your Elixir system.
Deciding on which node this process lives is still up to you, but there are libraries like locks [3] that allow you to automatically determine a leader in your cluster.
And once this is done you can start dealing with overload :)
Of course this is just a simple and naive approach, there are a lot of really useful Erlang libraries to check out. Here's a list of libs that helped me when getting started by reading their docs and sources in no particular order:
https://github.com/heroku/canal_lock - Erlang lock manager for concurrently variable resource numbers
https://github.com/jlouis/safetyvalve - queueing facilities for tasks to be executed so their concurrency and rate can be limited on a running system
https://github.com/fishcakez/sbroker - process broker for matchmaking between two groups of processes using sojourn time based active queue management to prevent congestion.
https://github.com/ferd/backoff - exponential backoffs and timers to be used within OTP processes when dealing with cyclical events, such as reconnections, or generally retrying things
https://github.com/jlouis/fuse - A Circuit Breaker for Erlang
https://github.com/basho/sidejob - Parallel worker and capacity limiting library for Erlang
https://github.com/pspdfkit-labs/sidetask - My humble Elixir wrapper for basho's sidejob
[1] https://github.com/devinus/poolboy also used in Ecto, look through the Ecto sources if you want to see how it's used in Elixir.
[2] http://erlang.org/doc/man/global.html
[3] https://github.com/uwiger/locks and then https://github.com/uwiger/locks/blob/master/doc/locks_leader...
If you go with one GenServer per node, then that one just connects to redis and just pulls jobs (using BLPOP or whatever). When it has gotten a job it checks out a worker from poolboy and assigns it that work.
You could also just have every single worker process go directly to redis and have it pull jobs in a loop. But where's the fun in that ;)
If you want a single global coordinator instead of one per node you can use :global [2] to globally register a process in the cluster. This process is then cluster-wide reachable under its registered name. It can talk to each of your worker pools in the cluster and round-robin try to check out workers and assign them work. And if you do this you might as well ask yourself if you really need redis instead of keeping it all within your Elixir system.
Deciding on which node this process lives is still up to you, but there are libraries like locks [3] that allow you to automatically determine a leader in your cluster.
And once this is done you can start dealing with overload :)
Of course this is just a simple and naive approach, there are a lot of really useful Erlang libraries to check out. Here's a list of libs that helped me when getting started by reading their docs and sources in no particular order:
https://github.com/heroku/canal_lock - Erlang lock manager for concurrently variable resource numbers
https://github.com/jlouis/safetyvalve - queueing facilities for tasks to be executed so their concurrency and rate can be limited on a running system
https://github.com/fishcakez/sbroker - process broker for matchmaking between two groups of processes using sojourn time based active queue management to prevent congestion.
https://github.com/ferd/backoff - exponential backoffs and timers to be used within OTP processes when dealing with cyclical events, such as reconnections, or generally retrying things
https://github.com/jlouis/fuse - A Circuit Breaker for Erlang
https://github.com/basho/sidejob - Parallel worker and capacity limiting library for Erlang
https://github.com/pspdfkit-labs/sidetask - My humble Elixir wrapper for basho's sidejob
[1] https://github.com/devinus/poolboy also used in Ecto, look through the Ecto sources if you want to see how it's used in Elixir.
[2] http://erlang.org/doc/man/global.html
[3] https://github.com/uwiger/locks and then https://github.com/uwiger/locks/blob/master/doc/locks_leader...
Is BEAM slower due to the constrain bound by the concurrency model, or could one day BEAM gets further improved to the point close to JAVA?
AFAIK, there's nothing stopping BEAM from being as fast at math and so forth as the JVM is (both being JITing bytecode interpreters.) It's just that nobody has really bothered to optimize it for that use-case.
The .exs extension and mix integration makes elixir better than one might expect for scripting. It doesn't get to ruby or perl territory, but definitely good enough for scripting to keep code homogeneous in a project.
I've written many a map-reduce job in a .exs file. It's very easy to do a parallel_map and take advantage of all available cores.
From a numerics standpoint, both Elixir and Erlang have some issues. One of the annoying ones is that there isn't the concept of NaNs like you'd expect--it will actually throw an error if you divide by zero. For certain applications, this is annoying.
Further, there isn't really any hope (right now) of accessing hardware SIMD due to the way that the Erlang VM handles its numbers. Lists are cons-cell lists, tuples are arrays of bundled atoms, and neither will give you numbers in adjacent memory slots.
I toyed with the idea of using bitstrings and storing "raw" vectors in NIFs, but it feels so clunky to do that and then have to marshal into and out of native code all the time.
All of that said, it's downright pretty how you can write some of your tests.
Source: I've written a vector math library for Elixir.
Further, there isn't really any hope (right now) of accessing hardware SIMD due to the way that the Erlang VM handles its numbers. Lists are cons-cell lists, tuples are arrays of bundled atoms, and neither will give you numbers in adjacent memory slots.
I toyed with the idea of using bitstrings and storing "raw" vectors in NIFs, but it feels so clunky to do that and then have to marshal into and out of native code all the time.
All of that said, it's downright pretty how you can write some of your tests.
Source: I've written a vector math library for Elixir.
Last week I picked up Fabio Mascarenhas (of Lua fame) at the airport for an event. I was surprised when he told me that like Lua, elixir also has Brazilian roots. Few Brazilians know that.
Speaking of this, just how did Elixir's Jose Valim (who I assume is Polish) wind up working at the Brazilian Plataformatec? Last I checked, Brazil is a quite a bit more than a stone's throw away from Poland, and I would imagine even the tele-commute must be hell much less the physical commute.
You assume wrong, José Valim is Brazilian.
These exercises are great for anyone curious about the language. While I drank the elixir koolaid a while ago, it continues to be a really pleasant language to write stuff in.