With respect, if static compilation/linking is the key feature
for someone, why would they want to use an essentially
dynamic language?
I will assume the question by Tamas_Papp to be a genuine one
rather than an arrogant top-down question belittling the use
case of people.
I will explain my own use case - this may be different to the
threadstarter, but remember the question here was posed
in a general manner aka “why would xyz want to use a dynamic
language”.
I am a heavy ruby guy. I wrote a “package” manager that is
actually a crappy build system; horrible quality. Don’t
anyone use it!
Anyway. I am tracking almost 4000 different packages so
far - glibc, gcc, binutils etc… - you name it. All of
KDE5, all of GNOME3, mate-desktop. Literally most of
the currently used software stack. And I keep on adding
to this.
I try to be independent, as much as possible, from
distributions - we could see the nightmare of IBM Red
Hat force-abusing everyone via systemd (and arrogant
maintainers such as on debian refusing to give people
a choice here, leading to the devuan-fork; anyway,
this is a separate topic. I wanted to give a background.)
The key here is that I am independent.
Now - I am stuck, though, because I need a clean environment
aka chroot. I can setup most of the chroot, but I do not
understand everything really. In particular there are
hardcoded paths but also glibc being annoying to no ends.
And … ruby is not working in the chroot. Which is
annoying. But a statically compiled bash is working as-is.
So I could use bash scripts. But I hate them.
Compiling a static ruby is difficult. It is easy with
mruby but … you need to know C. I don’t know C. I don’t
want to invest xxx hours into mastering C.
I just want my scripts to work.
As it is, ruby does not work, python does not work, and
getting lua to compile statically is ANNOYING to. So
I was looking whether julia fits the bill.
It would be simpler for me to re-create the CORE aspects
of my scripts (all the packages are actually stored in
yaml files, so I have the information as-is; I can
easily use another language too, which is different
if you look at e. g. homebrew) in another language.
So right now I don’t know whether I can use a minimal
julia, something simple, like --mini or --minijulia
and --enable-static or something like that. That would
be sweet.
No clue if that is possible, but my aim here was to
answer the above question.
So my use case is not related to distributing a static
binary to anyone - I just want my set of tools to work
as it is. (I already tried to make it simpler for ruby
to be compiled statically, and for python too but it
just does not work for me … bash works fine, grep
too, sed, awk … lots of packages work fine statically.
I only need it for the initial bootstrap-part by the
way. Once that works fine, I can bootstrap all the other
parts on a linux system fine.)
Especially if someone doesn’t already have julia installed,
installation times with download, precompilation, etc
easily range between 10-60 minutes right now.
There is no question that this needs to be addressed,
especially if we want to reach a wider audience
Different people have different use cases. IMO, ideally,
in particular the “scripting” languages should be as
flexible and dynamic as possible, to allow for people
to use them in many different scenarios. Sure, C and
C++ will always be faster, but I rather write scripts
in simpler languages, and maintain them, then go and
learn C and C++ properly because they are just less
fun compared to, say, ruby. Or python too. (I can not
use perl because I hate the syntax.)
By the way, for my use cases Go is not an option. I am
aware of many people jumping to the Google empire
but it is unlikely that I will - although this has less to do
with Google per se, and more that I don’t feel Go is
a “scripting” family really, whereas Julia fits a lot more
there, IMO.