The title says "GPU vendor-agnostic". But in fact for AMD only professional (expensive) GPUs are supported (ROCm is officially unsupported on most consumer and integrated GPUs).
To be truly vendor-agnostic it needs to support OpenGL or Vulkan.
Also this is the first time I saw examples of Julia code and the syntax looks worse than C++.
You may be confusing front end APIs and the compiler backends.
Julia is flexible enough that you can essentially define domain specific languages within Julia for certain applications. In this case, we are using Julia as an abstract front end and then deferring the concrete interface to vendor specific GPU compilation drivers. Part of what permits this is that Julia is a LLVM front end and many of the vendor drivers include LLVM-based backends. With some transformation of the Julia abstract syntax tree and the LLVM IR we can connect the two.
That said we are mostly dependent on vendors providing the backend compiler technology. When they do, we can bridge Julia to use that interface. We can wrap Vulkan and technologies like oneAPI.
As for syntax, Julia syntax scales from a scripting language to a fully typed language. You can write valid and performant code without specifying any types, but you can also specialize methods for specific types. The type notation uses `::`. The types also have parameters in the curly brackets. The other aspect that makes this specific example complicated is the use of Lisp-like macros which starts with `@`. These allow for code transformation as I described earlier. The last aspect is that the author is making extensive use of Unicode. This is purely optional as you can write Julia with just ASCII. Some authors like to use `ε` instead of `in`.
The colon is a bit overused (ranges, ternary, quoting), but this would be pretty clear with parentheses and spacing, i.e. ex.head == :(.) and ex.head == :(call). Now you can see it's a comparison against the symbols '.' and 'call'. Kind of like saying C has too many weird character combinations because there's a "--> operator".
> Also this is the first time I saw examples of Julia code and the syntax looks worse than C++.
That's surely an exaggeration, but just for context, most Julia code isn't nearly this macro-heavy. The first half of the final code showcase is all macros and expression manipulation, and those always look a bit weird. Usually, those comprise less than 10% of your code though; and if you're a regular user and not a package author, probably much less than that.
To be truly vendor-agnostic it needs to support OpenGL or Vulkan.
Also this is the first time I saw examples of Julia code and the syntax looks worse than C++.