3 ms·

Last time I played with Elixir (I'll assume it's similar enough to Erlang), I found the REPL / interactive experience not as rich as CL's (which I must say, rea

Last time I played with Elixir (I'll assume it's similar enough to Erlang), I found the REPL / interactive experience not as rich as CL's (which I must say, reassured my beliefs), even though the command-line tools are great: - can't install libraries from the REPL while working on your program - can't "compile this function" with a keystroke (I did find "send region/line/buffer to REPL" which is different, or "reload module")… - … and get type errors and warnings - can't get an interactive debugger on an error, go to the bogus line (while keeping the debugger), fix the function, compile it, switch back to the debugger, resume execution from any point in the stack. I only found out IEx.pry which is useful and all, but looks like Python's ipdb break point. - lack of little useful editor commands, at least in the Emacs modes I tried like "write this function in the REPL", "eval and print the last expression". I struggled to have the "go to definition" feature but that depends on the IDE I suppose. The Emacs modes are not in good shape :S - no cross-references? doubting. And maybe other small things only about the REPL, didn't find my notes. differences of runtimes are also at play here, but I still find it interesting to compare the REPL experience, I'll welcome more comparisons.

cess11 2y ago
BEAM/OTP is rather different from CL:s image-based REPL experience. You can get relatively close by putting your application into processes and keep them in a collection or registry, then when you've found an issue and changed the code in your editor you can run recompile and relaunch affected processes. You'd lose a subtree in the application, and hence in-memory storage tightly coupled to those processes, but I find it rather easy to do it this way. Often you'll put in-memory data in separate caching processes and that reduces friction in restarting processes with application logic even more. The 'let it crash'-foundation of the BEAM system isn't exactly tailored towards trapping and recovering from errors but if you really want to you could probably implement something like that with try/rescue but I suspect it would turn out quite obtuse compared to the CL mechanics.

cess11 2y ago

BEAM/OTP is rather different from CL:s image-based REPL experience. You can get relatively close by putting your application into processes and keep them in a collection or registry, then when you've found an issue and changed the code in your editor you can run recompile and relaunch affected processes. You'd lose a subtree in the application, and hence in-memory storage tightly coupled to those processes, but I find it rather easy to do it this way. Often you'll put in-memory data in separate caching processes and that reduces friction in restarting processes with application logic even more. The 'let it crash'-foundation of the BEAM system isn't exactly tailored towards trapping and recovering from errors but if you really want to you could probably implement something like that with try/rescue but I suspect it would turn out quite obtuse compared to the CL mechanics.