|
|
|
|
|
by ZephyrP
2928 days ago
|
|
The benchmark game's "results" peg some toy programs in Erlang an order of magnitude faster than Python 3. Of course, you probably foresaw another classic interpreter-speed justification coming from a mile away, but.... There are very well-developed methods of interfacing with fast native code, ranging from C nodes to nifs. The documentation is circumspect about using C code, but nevertheless provides you with the good, bad and the ugly on these various different methods. If anything, I think Crystal could crib a page from Erlang and elevate what it calls "Fibers" and "Channels". Erlang made these first-class in both design & syntax, which allowed Pids and messages to be not just building blocks of concurrent interaction patterns, but also architectural utility-knifes in consecutive Erlang code. The more Erlang you read, the more you see this really powerful method of dividing concerns "physically" rather than "structurally", in which you can be doing everything from implementing Objects (for some definition of OOP) to representing recursive data structures with lightweight threads as the "backing primitive". This may be obvious to some old-head Lisp programmers, but I about choked on my latte when I saw this demonstrated at the first Erlang shop I worked in. It's a cool and extremely powerful idea that can be implemented in any language, but is best if the spawn/message syntax is concise. |
|
Erlang is a super cool language and were I doing an app which needs millions of concurrent connections over many cores and/or machines, I'd choose it in a second. But Crystal is more of a (potential) replacement for Java or C++.