[JustFinishedBSG]

> I really wish the Julia ecosystem would stop assuming that you always interact with your computer through the Julia REPL and started supporting proper command line interfaces.

What does it even mean? What is a CLI interface for a programming language if not a REPL ?

[krastanov]

I also do not really get the complaint, but it is along the lines of people wanting to write `julia-pkg install Pluto` instead of `julia -e 'using Pkg; Pkg.add("Pluto")'`. It seems it is a big pet peeve for some people.

[spekcular]

Yes. I agree with this complaint. The REPL is useful in some cases but in general I avoid interacting with it whenever possible. My impression is that workflow is highly task-dependent (perhaps obvious) but there are many of us who just want to write a script, run the script, and repeat.

[simeonschaub]

Check out https://github.com/fredrikekre/jlpkg. It does pretty much exactly what you are describing.

[nerdponx]

The `-e` thing gets very messy quickly if you need to pass non-trivial data from the outside world into the application (have you ever tried to "parameterize" a Sed script?). It also doesn't compose well with other CLI tools.

I think these are two perfectly reasonable things to be annoyed by.

[chillfox]

Thanks for the example.

As someone who has never used Julia... Wow, that looks exceptionally painful compared to most other modern languages.

[krastanov]

The package manager that comes with Julia is actually way better than what is available in python, and it has an unmatched "foreign language dependencies" support. It just happens to be mostly used from the REPL, not the command line (hence the execute -e flag above).

[enriquto]

> > I really wish the Julia ecosystem would stop assuming that you always interact with your computer through the Julia REPL and started supporting proper command line interfaces.

> What does it even mean? What is a CLI interface for a programming language if not a REPL ?

I guess they mean that the julia interpreter should be a good unix citizen (which is quite not at the moment). For example, while you can in theory create "julia scripts" by adding a julia shebang, this usage is not really well thought and has several friction points. Most notably, a very slow startup time, even of several seconds if you import some common packages. This makes said julia scripts essentially unusable.

The usual response of the julia community to these complaints is that "you are holding it wrong", and that you should use julia inside the proper REPL. Some people do not like this answer, and there's a tiny bit of drama around that.

[jakobnissen]

I think there needs to be a distinction between on one hand Julia's startup time, which is an inevitable consequence on its compilation model and unlikely to change, and on the other hand whether there is a lack of command line functionality in Julia, e.g. the package manager. The latter is much easier to amend.

[enriquto]

but is this "compilation model" inherent to the language? It seems to be an implementation choice. It is conceivable an independent interpeter for the same Julia language but with fast startup.

[simeonschaub]

Julia already comes with an interpreter, try starting your session with `julia --compile=min`.

One part of the ongoing effort to reduce latencies is to allow package authors to specify optimization levels on a per-module basis. This is great for plotting packages for example, since they usually don't benefit much from overly aggressive optimizations, so spending less time optimizing codes generally leads to a snappier experience. It is now even possible to opt into a module-specific fully interpreted mode, which can make a lot of sense for typical scripting tasks.

[enriquto]

That's great! Hoping to see julia get snappier at every release! (as it seems to be going)