"Designed & Built a Redis Replacement", "nobody really wants to buy it when free worse performing choices exist". Give me a break...
"Designed & Built a Redis Replacement", "nobody really wants to buy it when free worse performing choices exist". Give me a break...
Huge red flag right there as someone that has done hiring.
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.
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.
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.
[0] <https://learnyousomeerlang.com/>
[1] <https://www.erlang.org/docs>
[2] <https://www.erlang.org/doc/system/getting_started.html>
[3] <https://www.erlang.org/doc/system/design_principles.html>
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.