4 ms·

Has anyone used elixir for building command line tools? It seems like this would be very useful for distributing them.

zorbash 6y ago
I have and blogged about it here https://zorbash.com/post/building-command-line-applications-with-elixir/ https://zorbash.com/post/building-command-line-applications-... I'll give bakeware a go and probably update the post with the results.
nickjj 6y ago
The readme file in the repo mentions a ~500ms start up time. Maybe it's just me, but I wouldn't want to wait half a second for a tool to start running. For context most popular Unix tools start up in 1-2ms.
- pzmarzly 6y ago
  On my PC: time node -e "console.log('a')" # 0.377 total time ruby -e "p 'aaa'" # 0.084 total time python3 -c "print('a')" # 0.020 total time elixir -e "IO.puts 'a'" # 0.117 total time _build/prod/rel/bakeware/simple_script Hi # 0.205 total without zstd, 0.212 with Another question is which language loads modules the fastest (afaik Ruby is kind of slow when it comes to `require`).
  - YorickPeterse 6y ago
    > Another question is which language loads modules the fastest (afaik Ruby is kind of slow when it comes to `require`). I think both Python and Ruby loosely follow a similar model. The difference is that IIRC Python caches bytecode files, while Ruby compiles them from scratch every time. Not sure how big of a performance impact that has, especially for simple cases like this. And just to toot my own horn, using Inko (https://inko-lang.org/ https://inko-lang.org/), I get: inko /tmp/test.inko # 0.470 total Note that this invokes the horribly slow Ruby compiler currently in use. If you invoke the VM directly on the compiled bytecode, it only takes about 10 milliseconds to run. Using the `master` branch: vm/target/release/ivm /home/yorickpeterse/.cache/inko/bytecode/release/43/38021ddc9a3449ace13288a2fac894d1d3e2aaa.ibi # 0.008.8 total In this case all modules (including the standard library) are included in the bytecode file, meaning no disk IO is necessary, and modules can be parsed in parallel. This is something dynamic languages like Ruby and Python can't do, as loading modules is something that can be done anywhere at any time, so you have to process them one by one.
  - johnisgood 6y ago
    Perl's startup time is pretty good.
- vendiddy 6y ago
  I wouldn't use Elixir for short lived cli commands because of startup time. For that I'd probably turn to Go or Rust. However for distributing long running server apps--where Elixir shines--I'm happy with this start-up time.
freedomben 6y ago
I've used it to write CLI tools for myself and found it to be great for medium to large tools. Small tools it's still much faster and easier to grab Ruby (assuming a quick bash script isn't appropriate). But yeah distribution is mostly a pain. I use the escript method but it's far from perfect. I'm excited about Bakeware and plan to try it.
brightball 6y ago
I've always felt like the ideal way to use Elixir for command line tooling would be to have some way to let a pipe feed into a new BEAM process from an already running application.

I have and blogged about it here https://zorbash.com/post/building-command-line-applications-with-elixir/ https://zorbash.com/post/building-command-line-applications-... I'll give bakeware a go and probably update the post with the results.

nickjj 6y ago

The readme file in the repo mentions a ~500ms start up time. Maybe it's just me, but I wouldn't want to wait half a second for a tool to start running. For context most popular Unix tools start up in 1-2ms.

pzmarzly 6y ago
On my PC: time node -e "console.log('a')" # 0.377 total time ruby -e "p 'aaa'" # 0.084 total time python3 -c "print('a')" # 0.020 total time elixir -e "IO.puts 'a'" # 0.117 total time _build/prod/rel/bakeware/simple_script Hi # 0.205 total without zstd, 0.212 with Another question is which language loads modules the fastest (afaik Ruby is kind of slow when it comes to `require`).
- YorickPeterse 6y ago
  > Another question is which language loads modules the fastest (afaik Ruby is kind of slow when it comes to `require`). I think both Python and Ruby loosely follow a similar model. The difference is that IIRC Python caches bytecode files, while Ruby compiles them from scratch every time. Not sure how big of a performance impact that has, especially for simple cases like this. And just to toot my own horn, using Inko (https://inko-lang.org/ https://inko-lang.org/), I get: inko /tmp/test.inko # 0.470 total Note that this invokes the horribly slow Ruby compiler currently in use. If you invoke the VM directly on the compiled bytecode, it only takes about 10 milliseconds to run. Using the `master` branch: vm/target/release/ivm /home/yorickpeterse/.cache/inko/bytecode/release/43/38021ddc9a3449ace13288a2fac894d1d3e2aaa.ibi # 0.008.8 total In this case all modules (including the standard library) are included in the bytecode file, meaning no disk IO is necessary, and modules can be parsed in parallel. This is something dynamic languages like Ruby and Python can't do, as loading modules is something that can be done anywhere at any time, so you have to process them one by one.
- johnisgood 6y ago
  Perl's startup time is pretty good.
vendiddy 6y ago
I wouldn't use Elixir for short lived cli commands because of startup time. For that I'd probably turn to Go or Rust. However for distributing long running server apps--where Elixir shines--I'm happy with this start-up time.

freedomben 6y ago

I've used it to write CLI tools for myself and found it to be great for medium to large tools. Small tools it's still much faster and easier to grab Ruby (assuming a quick bash script isn't appropriate). But yeah distribution is mostly a pain. I use the escript method but it's far from perfect. I'm excited about Bakeware and plan to try it.

brightball 6y ago

I've always felt like the ideal way to use Elixir for command line tooling would be to have some way to let a pipe feed into a new BEAM process from an already running application.