I just started using Julia last week.

The REPL-based workflow and the compile time latency just need to go.

Stop defending it. Its a problem. It harms adoption. Fix it and move on and you'll stop hearing endless complaints about it. Sometimes the endless complaints have a point and you need to listen to it.

Coming from a decade-long history with ruby I do think that dynamic, duck-typed languages are inherently flawed, but c'est la vie and Julia is miles better than Matlab. I'm not looking at Julia to be exactly like go or rust, I want automatic differentiation. Don't particularly care about the memory bloat either.

Newbie documentation does need to be a whole lot better. I suspect that would probably get fixed if the compilation and REPL-centric issues got fixed and it wasn't so immediately hostile to your time on day 1.

Package management also needs to get better. Rubygems gets the shape mostly right if you don't look too close at the details, cargo seems to be excellent. Languages created in the past 10 years really should have strong package management from the start and not treat it as an afterthought and not try to reinvent the wheel without understand the successful systems that have come before them.

But really its about the compilation and REPL-centric issues. That should have been a requirement for 1.0, and I can't believe that a language that is nearly 10 years old could have that bad of an initial workflow for users.

> Package management also needs to get better.

In my experience it is close to perfect. What issues did you encounter?

Might just be the REPL-centric workflow and lack of docs again and the general experience of "WTF does `activate .` even do?"

You might want to pick up a course on using google, cause the first hit on "julia package manager" is the documentation: https://docs.julialang.org/en/v1/stdlib/Pkg/

"WTF does `activate .` even do?" If you then read it, it says "If you are ever stuck, you can ask Pkg for help:".

    (@v1.6) pkg> ?activate
     activate
     activate [--shared|--temp] [path]
     
     Activate the environment at the given path, or the home project environment
     if no path is specified. The active environment is the environment that is
     modified by executing package commands. [...]
Also the docs tell you in a highlighted blue bubble that if you don't want to use the "REPL-centric workflow" there is also the API:

> This guide relies on the Pkg REPL to execute Pkg commands. For non-interactive use, we recommend the Pkg API. The Pkg API is fully documented in the API Reference section of the Pkg documentation.

Most other language have cli gools like `gem` or `cargo` and if you're in a directory with a Project.toml why do you even need to remember to do that all the time?

If you're in a directory with a Project.toml do

    julia --project
and it's activated.

The downside of a separate cli tool is that it's unclear what julia version you're using. E.g. pip vs pip3.

You can expose it as a CLI tool if you wish: https://github.com/fredrikekre/jlpkg