same here, but I reach for python for scripting.
There is just a lib for everything.
But would never build an application in python again.
Sebb
2
rahil627
wow, so many replies! thanks everybody. i def got the feeling of validation that i was perhaps wanting. i guess I felt uncertain of using such old langs, or worse, starting to use an old language, especially when a more contemporary one is right here, but it’s cool to find out languages/libs don’t die. I wish the lispers may lisp forever.
err, maybe the title should have been “should elixir replace scripting languages”? it didn’t have to be ruby. Python, perl, lisp/emacs, lua?, whatever! Glad to know everyone has their own little tool-kit though 
. just not bash/sed/awk 
ratatouille def feels more complicating, lol, but thanks! I’ll look into it again once i’m deep into elixir mode.
unfortunately, I come from the gaming world, so I don’t know any standard library too well. 
just game engines. The engine decided the language I had to use. I just pray ai isn’t choosing an outdated ruby lib 
.
0
Hisako1337
in general, the probably best tool choice for CLI apps is Golang.
It allows for very simple and straightforward imperative code, so upgrading from bash scripts is a rather easy experience. It also bundles most things you might need right away in the stdlib, and there also are great libraries (like cobra for more sophisticated CLI stuff). Then it also compiles (instantly) into a standalone binary with zero dependencies needed, and can cross-compile to target architectures right out of the box. Not to mention performance is really good and it feels snappy to use such tools.
However, I personally would like to use Elixir more for scripting, but there are … issues. I think the whole coding experience of nontrivial things is much better and gets very noticeable when things get complex, and you can spin up a nice LiveView UI if needed ontop of everything. My dealbreaker is not the coldstart speed at all, since I would use it for nontrivial things that are running a while to begin with, and when you need to do API calls during the task its a different story altogether, here its more important to have a “renderer” process in parallel that shows realtime update about the current task progress.
What is the core issue for me is the distribution part. I need to give a tool to users that don’t have elixir (or any of its deps) installed at all, like a fresh macbook from a designer or a windows box of an office clerc, both are capable only of clicking a file I send them in terms of setup complexity. Thats like the absolute primary use case for my scripting. Distant second is ssh’ing a script to a server and ./run it there, but this is kinda the same issue again: standalone distribution.
coming from a devops background, this one (missing) feature is absolutely stellar to unlock “scripting” in a broad sense. Go is made for that in a perfect way, python/ruby had the advantages of being preinstalled on certain setups so it was good as long as you didn’t need external dependencies or a specific language version.
anything from elixir releases to escript files are good for sharing stuff with developers - but those are perfectly capable of git clone a repo to begin with (and often prefer it), so these are non-options.
2
D4no0
I think the inclusion of go is out of scope here, since it is impossible to do scripting in golang.
You need to have the precompiled binaries for the correct architecture and you will never be able to edit the source files on the target system (since you don’t have them 
), which IMO is the whole idea of using scripts and not entire applications.
2
adw632
One possible approach would be to have a script launcher that passes the env, script and standard file descriptors to a semi-persistent Erlang VM (using Unix domain sockets to transfer them to the Erlang VM) the VM can be already started and waiting for script launchers to connect and the launcher would start the VM if it’s not already running. That way you wouldn’t face VM startup delays on every invocation but you do have the script parsing overhead and even that could be reduced with some code caching land cache busting logic.
The launcher would take care of controlling terminal aspects and signal the VM to exit/hup the Erlang script process.
I’m sure there are a few more technicalities like needing module namespace separation between scripts but that may be eliviated with dynamic per script module prefixes.
The worst outcome would be needing to fork the VM but hey KDE does that using a single init process that it forks to eliminate intolerable app startup times due to the number of libraries and symbols that need to be resolved by the library loader.
Just spit balling but doesn’t seem like Mt Insurmountable.
1
lud
I use Elixir for scripting all the time. Of course you don’t want Elixir for tools such as ls or tree or grep, and for tools that you want to start very fast (like a note taking CLI app for instance).
But for all custom scripts that have something to do with the filesystem, or call to HTTP Apis, the scripts are easy to write, to test and to debug.
If you are going to use that script only 100 times but spend 1 hour instead of 3 to write it then you win against the BEAM startup time. mix test take some time to start, but ExUnit is great, it’s worth it, and honestly it’s not that slow anyway.
5
tme_317
I don’t know about the Windows part as we are all Macs but beyond simple escripts, GitHub - bake-bake-bake/bakeware: Compile Elixir applications into single, easily distributed executable binaries · GitHub (which works great for me) bundles OTP and Elixir into a binary. I think a newer take on that is GitHub - burrito-elixir/burrito: Wrap your application in a BEAM Burrito! · GitHub but I haven’t used that yet.
Then there’s GitHub - elixir-desktop/desktop: Building Local-First apps for Windows, MacOS, Linux, iOS and Android using Phoenix LiveView & Elixir! · GitHub which I’ve only used to get a Hello World on iOS. I think this is more for GUIs not CLIs though.
I love using Elixir for scripting because I can develop in it much faster than all other options, it has everything in stdlib and hex packages I need, and I don’t care about ~300ms boot times for interactive CLI apps.
3
yolo007wizard
I am also very interested in Elixir scripting, and love the single file Mix.install exs examples. The cold boot imo could be solved if there was an elegant way to setup/teardown multiple mix projects in a single beam instance.
As example, even livebook has to setup a new dedicated beam instance for every notebook with its own Mix.install. The UX is amazing imo and would like to scale it for automated app idea.
0
cevado
for that particullar use case of small scripts i’ve been using babashka as a way to keep practicing clojure.
you define the dependencies in the actual script(like you would do in a elixir script with Mix.install), and once you have the dependencies installed, it’s way faster than a elixir script to start once it’s optimized for this type of script.
and you can install babashka with asdf-vm
2
