4 ms·

Funny how the already weak case for not working on Julia instead of creating a new language is becoming even more flimsy : FAQ: > Why not make Julia better? >

Funny how the already weak case for not working on Julia instead of creating a new language is becoming even more flimsy : FAQ: > Why not make Julia better? > We think Julia is a great language and it has a wonderful community, but Mojo is completely different. While Julia and Mojo might share some goals and look similar as an easy-to-use and high-performance alternative to Python, we’re taking a completely different approach to building Mojo. Notably, Mojo is Python-first and doesn't require existing Python developers to learn a new syntax. https://docs.modular.com/mojo/faq/#why-not-make-julia-better https://docs.modular.com/mojo/faq/#why-not-make-julia-better Now : >We oversold Mojo as a Python superset too early and realized that we should focus on what Mojo can do for people TODAY, not what it will grow into. As such, we currently explain Mojo as a language that's great for making stuff go fast on CPUs and GPUs.

dragonwriter 1y ago
The share of projects that start out “we’re going to do X, and conpletely support using the syntax and semantics of existing language Y, but add more on top” that end up “we’re going to do X, in a language vaguely reminiscent of Y” is very hard to distinguish from 100%.
- fulafel 1y ago
  I guess there's survivorship bias, but the ones that first come to mind fared pretty well with compatibility (eg C++, Typescript, Ocaml)
amval 1y ago
Even funnier: https://github.com/tensorflow/swift/blob/main/docs/WhySwiftForTensorFlow.md https://github.com/tensorflow/swift/blob/main/docs/WhySwiftF... > Julia: Julia is another great language with an open and active community. They are currently investing in machine learning techniques, and even have good interoperability with Python APIs.
- Staross 1y ago
  Yeah that was a missed opportunity fore sure, joining forces 8 years ago would probably had yield better results that the current situation.
ddaud 1y ago
I think the real reason is that Chris Lattner doesn’t want to work on Julia. He’s likely very (and justifiably so) opinionated about these topics, and probably wants a certain degree of creative authority over his projects.
- serial_dev 1y ago
  Why deal with others when you are big enough of a name to launch your own and make all the decisions yourself?
- pjmlp 1y ago
  Although from the way some Modular videos are done, it seems nowadays he is more in an overseer role and setting up the direction, while others are the ones actually pushing Mojo and Max tooling forward. Maybe I just misunderstand it from the presentation format.
  - melodyogonna 1y ago
    He works on Mojo a lot, mostly on weekends. In the past few months, he has worked on strings, collection literals, dependent types, reference captures, comprehensions, and many other nice language features.
pjmlp 1y ago
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 1y ago
  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 1y ago
    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?

dragonwriter 1y ago

The share of projects that start out “we’re going to do X, and conpletely support using the syntax and semantics of existing language Y, but add more on top” that end up “we’re going to do X, in a language vaguely reminiscent of Y” is very hard to distinguish from 100%.

fulafel 1y ago
I guess there's survivorship bias, but the ones that first come to mind fared pretty well with compatibility (eg C++, Typescript, Ocaml)

amval 1y ago

Even funnier: https://github.com/tensorflow/swift/blob/main/docs/WhySwiftForTensorFlow.md https://github.com/tensorflow/swift/blob/main/docs/WhySwiftF... > Julia: Julia is another great language with an open and active community. They are currently investing in machine learning techniques, and even have good interoperability with Python APIs.

Staross 1y ago
Yeah that was a missed opportunity fore sure, joining forces 8 years ago would probably had yield better results that the current situation.

ddaud 1y ago

I think the real reason is that Chris Lattner doesn’t want to work on Julia. He’s likely very (and justifiably so) opinionated about these topics, and probably wants a certain degree of creative authority over his projects.

serial_dev 1y ago
Why deal with others when you are big enough of a name to launch your own and make all the decisions yourself?
pjmlp 1y ago
Although from the way some Modular videos are done, it seems nowadays he is more in an overseer role and setting up the direction, while others are the ones actually pushing Mojo and Max tooling forward. Maybe I just misunderstand it from the presentation format.
- melodyogonna 1y ago
  He works on Mojo a lot, mostly on weekends. In the past few months, he has worked on strings, collection literals, dependent types, reference captures, comprehensions, and many other nice language features.

pjmlp 1y ago

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 1y ago
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 1y ago
  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?