What would you like to see in Erlang or the BEAM world?

Chat / Discussions
, , ,
42

With JIT on linux here I have:

❯ time erl -mode minimal -noinput -boot no_dot_erlang -eval 'erlang:halt()'
0.09user 0.07system 0:00.10elapsed 158%CPU (0avgtext+0avgdata 44188maxresident)k
0inputs+0outputs (707major+8982minor)pagefaults 0swaps
2 Likes
43

M1, no jit, 24.2 :

$ time erl -mode minimal -noinput -boot no_dot_erlang -eval 'erlang:halt()                                                       

________________________________________________________
Executed in   75.78 millis    fish           external
   usr time   66.32 millis   47.00 micros   66.28 millis
   sys time   46.55 millis  670.00 micros   45.88 millis

M1, jit, OTP master (f8e41f85)

$ time /usr/local/bin/erl -mode minimal -noinput -boot no_dot_erlang -eval 'erlang:halt()   
________________________________________________________
Executed in  228.06 millis    fish           external
   usr time  110.86 millis    0.06 millis  110.80 millis
   sys time   49.60 millis    1.58 millis   48.02 millis

Same as above, but without jit :

time /usr/local/bin/erl -mode minimal -noinput -boot no_dot_erlang -eval 'erlang:halt()'                                              

________________________________________________________
Executed in   75.26 millis    fish           external
   usr time   63.80 millis    0.06 millis   63.74 millis
   sys time   49.44 millis    1.54 millis   47.90 millis
2 Likes
44

I found making CLI in Erlang somewhat challenging for unrelated to boot speed reasons. In fact I don’t care much if it takes 0.1 or 0.2 sec to execute a CLI, but what I do care about is:

  • redistributable ERTS and/or some other way of minimised packaging. Right now Erlang assumes that ERTS/escript is somehow installed on the local system (similar to JRE, Python, …), but I’d really prefer GoLang approach - packaging dependencies in the executable itself. Like a minified self-contained escript
  • build-in command line parser/CLI framework for Erlang. The one I maintain (argparse) is a separate package making it even harder to create a redistributable CLI
8 Likes
45

I forgot this, but it regularly bugs me:

  • a “proper wrapper” for dealing with external processes

There’s a wealth of almost-complete community solutions, but not all of them are friendly licensed, and many of them require yet another shim tool in C or go, or occasionally even in shell scripts.

4 Likes
46

Ah what a great idea! This would remove one common source of confusion and pain for newcomers.

3 Likes
47

Yeah, there are some great libraries that use C shim programs to navigate the normal process control, it would be fantastic if the functionality of those external programs were capable of by the main BEAM itself.

2 Likes