I followed that introduction to start hacking on my first compiler (in an interpreted language with no system calls or any concept of variable scoping). I think I got to implementing an AST before I quit. When I do it again I'll be using a different language (probably Gambit/Gerbil if I can find time to learn them).
Makes me wonder why python is so much easier for me than Gambit? I think it might just be the sheer volume of SE posts, tutorials, and documentation...
Would be a fun data science project: given the READMEs of all github projects, find the longest chain of programming language implementations without (close) duplicates.
Prove that it is a valid chain by actually running all compilers.
Bonus points for less common languages such as SNOBOL and Mumps, or languages rarely reimplemented and/or rarely used for writing compilers such as TI-59 or Lotus-123 macro language.
Would it? The basics of the language are at least easy, you might have trouble when python drops into it's ffi. Same holds in the reverse; you can't easily do elixir ffi in python.
FFI aside, I don't see a good way of implementing Kernel.spawn/1, Process.monitor/1, etc. in python, without rebuilding the entire erlang VM from scratch.
You can mock mutable variables in actors. Actors and genservers are a first class module in the standard library. Elixir is not Haskell. There are plenty of places with accessible statefulness/mutability, it's just shielded in a functional wrapper and made slightly difficult to dissuade you from using statefulness unnecessarily, so you make fewer coding and concurrency mistakes in annoying places and you can focus on delivering features and solving hard problems.
