[pjmlp]

Additionally Julia works on Windows, lots of its issues have been ironed out throught the last decade, and many folks are invested into it, instead of a single company product.

Yes many of the mainstream languages started as single company product, but lets put it this way, would anyone be writing one of such languages today, had those not been languages gatekeeped to access a specific platform?

So outside accessing Max and its value preposition as product enabler for XYZ, who would be rushing to write Mojo code, instead of something else.

[MohamedMabrouk]

I think the modular proposition is to solve the AI infra problem using a modern systems programming language but with a python syntax (to keep the mental overhead low) it is mainly trying to replace C++/CUDA. I am not sure Julia is suitable for such endeavour. Julia is not marketed as a systems programming language and I find it hard to believe that it can be one as dyamically typed langauge with GC and JIT. Could Julia replace python in the high-level dynamic code space used in research and training? maybe. but I find it really hard to believe that it can replace CUDA/ROCm/C++ .. etc.

[pjmlp]

Lisp Machines from Xerox PARC, Texas Instruments and Genera proved their point, even if the market wasn't up to their price point versus UNIX graphical workstations.

Dylan was going to be Newton's system programming language, and while the language group lost the the C++ team (Apple had two competing teams for the Newton OS), it was still NewtonScript for everything userspace, and it was getting a JIT by the time the project was canceled.

Objective-C is dynamically typed beyond the common subset with C, and was used even to write NeXTSTEP drivers.

I don't know how much of a chance Julia has against CUDA/ROCm/C++, especially now that everyone on the GPU space has decided to give feature parity to Python on their hardware, via day one bindings to the compute libraries and JIT DSLs, so that makes Mojo even less of a chance than Julia has.

Julia has an established ecosystem, and presence on the scientific community with ties to MIT.

Python is the champion, and most folks writing CUDA/ROCm/C++ are already using it.

So who would be reaching out to Mojo, instead of Python JIT DSLs/bindings or Julia, when having Fortran, C, C++ allergy?

[MohamedMabrouk]

Creating DSL/Bindings for Julia or python to underlaying platform like CUDA is not really replacing it, it is yet adding another layer on top of the existing platforms or creating a prototyping envirnoment for research. The question is not can Julia interface with CUDA, it is can Julia replace C++/CUDA/ROCm in an end-to-end scenarios (preferably with portability across GPUs vendors)? if not then there is no comparison between the stated goals of Julia and Mojo. they are different langauges targeting completly different use cases.

[ChrisRackauckas]

Julia does not just have bindings to CUDA. Native Julia code can compile to build .ptx kernels https://cuda.juliagpu.org/stable/development/kernel/. This same code can also generate kernels for AMD GPUs, Intel GPUs, and Metal.

We for example built software that generates kernels on-demand that embed user functions for all 4 of these systems and showed it's much faster than just CUDA bindings for array functions for certain nonlinear systems (https://www.sciencedirect.com/science/article/abs/pii/S00457...)

[eigenspace]

Julia is much more like a static language than you might realize. In fact, within a fixed world-age, as far as julia's JIT is concerned, it is a static language. Our JIT also isn't like other JITs, we sometimes call it a "Just Ahead Of Time" compiler because it is built much more like a traditional compiler than a tracing JIT.

We have quite fantastic GPU compilation stuff too, and julia functions can be compiled to Nvidia, AMD, Intel, and Apple GPUs through their respective GPU compiler packages, and one can use KernelAbstractions.jl to write code that is GPU vendor agnostic and works on all of them.

We're also getting an (experimental) fully ahead-of-time compiler built into the language with v1.12 that spits out an executable or dylib.