The "feedback and answer" below the gist already covers a bunch of things I wanted to mention. So I'll skip those and only talk about the rest:
> You can't make it a CLI script, because it compiles the whole code WITH dependencies every time
The "with dependencies" part is mostly untrue nowadays, with constantly better pre-compiled caches for dependencies with every release. The overall issue of compile times getting in the way of interactive development still has some truth to it, but much less than the comment implies.
1. The subheadings in the ToC are mostly based on comparisons with the best-in-class: for eg. "Julia can't easily integrate into other languages [compared to C]", "Weak static analysis [compared to Rust]".
2. Seeing this actually gave me hope about Julia's progress, based on how many of these issues have been largely mitigated or have been actively worked on in the last three years since the post.
3. As a side note, the author of the post is still an active user of and contributor to Julia, so I think this kinda falls under the "There are only two kinds of languages: the ones people complain about and the ones nobody uses" banner. As in, the complaints are there because they like and actively use the language enough to want it to be the best in every way.
> Even though Julia 1.6 was a lot faster than 1.5, it still took too long.
I agree - I think pre-1.9 Julia experience sucked, and overselling the language in that period hurt its reception a lot. (I've mentioned elsewhere in the thread that the developer experience is still one of the weaker points of Julia.)
> (in CL a hello world weighs ±20MB):
In Julia 1.12, with the experimental --trim feature, a hello world is <1MB. Still too early to tell how that'll translate to real programs though.
> false ? 1 : 2 : 3 : 4
This is hilarious and awful at the same time. There's no beating CL in this - I've learnt that every language with syntax unfortunately develops "wat"s like this over time when well-intended syntax features interact.
> A few months ago, I tried to write a program that should receive UDP packets over IPv6 multicast.
> It didn't work. I never figured it out. This works in Java and Python.
> This might be unfair or untrue, but I get the feeling that it doesn't work because no one has seriously tried to use the language this way.
I don't think it's either of those: it seems like networking was and remains a weak area in Julia. For eg., though the language itself is blazingly fast, there have been a bunch of reports about how HTTP traffic performance is several time slower than ostensibly slower languages like Ruby. The reason is probably what the quote says too, there just isn't as much of a userbase or demand for this side of things.
> my packages seem to really like breaking when I try to load them about once a month
There's no source for this one, and no info on what "breaking" means or what the packages do, so I can only say this isn't a common experience. It's very easy to "pin" dependencies to preserve a reproducible state of dependencies and replicate it as well, which is greatly useful in a language used for science.
> I migrated from Lisp to Julia for the ecosystem. It hasn't been worth it from my point of view. I'll migrate back to Lisp eventually. [on a post] about lisp-stats
I'm not very surprised, given the lisp-stats context - it seems to be a common assumption/misconception, because Julia gets compared to Python and R often, that it's a data science and stats focused language. It's great for greenfield stats work, pleasant in many ways compared to those two, but the ecosystem is not particularly focused specifically on it. I'd suggest choosing Julia for the ecosystem if you're doing science science - quantum computing, diffeq modeling, numerical optimization, many others - but on the data science side, what Julia offers is consistent syntax, performance without C reliance, while retaining niceties like DataFrames and Tidier that other languages offer.
