To the OP: I'm certain you're an experienced and seasoned programmer, but your CV (on your website: https://matt.sh/files/a-resume/resume.html) is an example of how not to write one. It's a wall of text and fluff, with too much focus on fanciness and design. I hire and interview people all the time, and your CV leaves me with zero sense of the impact of your work - only with the fact that you've done a bunch of stuff over the years...
"Designed & Built a Redis Replacement", "nobody really wants to buy it when free worse performing choices exist". Give me a break...
"Employment vibes"?! "The entire industry was sleeping on SSL and DHE ciphers..."?! And that self-quote at the top, wow. No names of the companies he worked for. It's hard to take this seriously.
Over 15 years of experience each in Erlang, Smalltalk, Scheme, Objective C, regular C, Python, JS, and then 9 years of Swift. Seems... impossible. I'd be willing to believe C + Python + JS + one or two others, since that mix is quite possible and maybe a personal project on the weekends. Everybody is going to have years of Python + JS. But almost nobody uses Erlang, Smalltalk, and Scheme, so how are you going to be using them regularly? Where would one combine these with UI-languages like ObjC/Swift? Things like Erlang + C seem unlikely; their whole purposes are different. I think you'd need to have a completely different project in a different language every month for this, and I don't think 15 years of 1 month projects equates to 15 years of experience, even assuming this is what happened, which I doubt. This list looks more like "I started using this language N years ago and maybe have used it at least once or twice since".
The whole tone of this and the blog reminds me of the kid in Catcher in the Rye.
> Things like Erlang + C seem unlikely; their whole purposes are different.
Erlang and C are complimentary.
Erlang calls code written in NIFs, coordinates C Nodes, and/or programs talking to the emulator over ports.
The original design goal of Erlang was to make it easy to write correct, concurrent, fault-tolerant supervisors and coordinators for complex, high-performance systems. (Like suchas telecom switches.) Erlang wasn't intended to be particularly fast, but to make writing concurrent systems easy, and provide fairly low and fairly predictable latency. One bounces out to C for performance-critical stuff, rather than writing it in Erlang... even today.
Thanks for the explanation! I knew it focused on concurrency, but just assumed Erlang was another functional language. Your description makes me curious about it. Also makes me wonder how useful it would be as a systemd sort of thing, given your description as "supervisor and coordinator".
You could probably use Erlang (or any other BEAM language with access to OTP) as a service control system (like openrc, or systemd or similar), yeah.
But yeah, I find writing servers and other such systems with many moving parts that can be reasonably modeled as Actors passing messages between themselves in Erlang to be so, so, so enjoyable.
If you're interested in picking up the language, I'd recommend Learn You Some Erlang [0]. It's a bit out of date (for instance, it talks about "maps" as being a new thing that's being designed, but they've been in the language for ages), but it's still a really good introduction to the fundamentals of the language and its runtime system. Fred Hebert is generally a good technical writer, so taking a look through his blog is also generally recommended.
The Erlang docs are also good. The top-level directory is here [1], and you if you're not looking for desk reference docs, you might start reading at either "Getting Started" [2] or maybe "Design Principles" [3]. Learn You Some Erlang covers a fair bit of what's in those two sections, but sometimes it's helpful to see the same information written another way.
> 8,000 hours of development on top of a lifetime of working in high performance distributed systems experience, yet nobody really wants to buy it when free worse performing choies exist.
He misspells choices, fair, I make typos too. But might want to catch that on a résumé. Then comes across like he’s not getting the proper traction or respect for it. Fine, but probably don’t complain about that there, idk. I’d still hire him though.
"Designed & Built a Redis Replacement", "nobody really wants to buy it when free worse performing choices exist". Give me a break...