As someone who switched from python to Julia, Julia syntax supports things like list comprehensions, but also many better things like broadcasting that python really needs. The only thing python has over Julia is that Julia requires an “end” keyword where python uses indentation. But julia has so much more than python (like macros) that it’s just better syntax wise.

Python has macros too.

as of 2020 (PEP 638), python has macros (but they're still slightly janky). Before that there were decorators which look kind of similar but are a lot less powerful.

Are they implemented anywhere? It looks like the PEP is draft. You can do all the macro like things you want using framehacks and eval at the top level. Where they are hard to apply w/o direct support is down inside some function. Then you have to bytecode patch the result on first execution.

> as of 2020 (PEP 638)

>> Reference Implementation >> None as yet.

> but they're still slightly janky

maybe you're from the future?

Not just decorators, but all kinds of functionalities that allowed types to be constructed at runtime.

well. python has ALOT of stuff but alot of it is garbage compared to how they should be done. like python's lambda, you literally have to write the word lambda. it's ugly af

i bet the python macros will be ugly af too.

also walrus operator = bdfl no more.

It is not just syntax. While python has Java-like OOP from a far, Julia has a distinct language design. It doesn't have a concept of "class" in the traditional sense. It instead has multiple dispatch, which is very flexible but sometimes too flexible to control. I found Julia harder to write for an averaged programmer. Furthermore, the time-to-first-plot problem had pissed off many early adopters (I know a few and they won't come back) and apparently remains a problem for some [1].

Julia is a great niche language for what it is good at. It will survive but won't gain much popularity.

[1] https://discourse.julialang.org/t/very-slow-time-to-first-pl...

Time to first plot should be all but solved as of v1.9.0 (first stable release ~two days ago).

Technically we've only released the first release candidate for 1.9. There's still a few bugs in it, and we'll probably have at least 1 more release candidate before 1.9.0 is released.

It's not going to be solved. Stop saying this. It's a great step forward and a real user experience improvement, but it doesn't solve it.

Packages need to precompile, and they don't. They need to fix invalidations, and they don't. They need to fix inference issues in their packages and they don't. "Using" time remains quite high.

"solved" is a big claim. better to just let the speed speaks for itself. ttfp is still somewhat of an issue

There are even more issues with Julia than you mention there. But the point is there are _many issues_ with _every_ programming language: Python is slow, its package management story is a dumpster fire, its object model is bizarre and confusing, its typechecking mechanism sucks. Also, its documentation is terrible (docstrings and documentation of functions) and the built-in REPL is basically useless. Rust has slow compile times, too much macro magic leading to unreadable code, the 90% of what the borrow checker rejects is perfectly fine code, its trait coherence rules are too restrictive, async sucks, and it's totally unsuitable for quick experimentation.

These are all real limitations, but users of these languages learn to live with them. Rustacenans learn to start a build, then so something else while it builds. That is, on its face, totally unacceptable to a Pythonista. Pythonistas learn to always ship performance sensitive applications with _another language_ doing all the hard work: Totally unacceptable for a Rustacean.

If someone tries out Python, spends five minutes getting package management to work and fails, they have not seriously thought about Python as a language. I feel people do just that with Julia: Try it out, then reject it on the first rough edge.

Fair enough: There are many people for whom lack of static type checking or Julia's latency is a showstopper, making the language unsuitable. But I'm still firmly convinced that for scientists/engineers at least, Julia, on balance, offers a better language than Python. I hope you're wrong that it won't gain much popularity.

i work in a bank leading some numerical work and I've been training my staff on Julia so we can write monte-simulation code that is fast. heck, the team builds their model in C++ and we soundly beat them with Julia on the code that generates the same results.

when we looked at it, it was because c++ is hard af to learn and the developer dont use it to its full potential. they just use some quantlib which where you look under the hood has many unoptimized parts.

with julia, the code is so simple and clean we even put in some GPU code in one place using CUDA and complete blows the C++ out of the water.

I did achieve some good performace with numba once thought with the avx so pythoni snot all bad but numba is only a small subset of python but with julia i can do crazily fast stuff that looks like python and is readable.

It seems that Julia has been used for numerical stuffs often. Its redmonk ranking is above some great languages like nim and erlang. This is already an achievement for a community-backed open-source language. By "much popularity", I meant "as popular as Java or Python". I had a high hope for Julia.

Actually Python OOP is closer to C++ and Smalltalk than Java, but I digress.

One of the features that I dislike the most abiout Julia is how list comprehensions have been directlly ported from Python. This was a conscious choice they made out of pragmatism, not because of the merits of the design.

I don't doubt that what you say it's true, but to me, it comes down more to lack of familiarity with other languages than any actual merits of Python syntax and semantics. Frankly, I am glad the didn't take more from Python.