Full podcast episode: ruclips.net/video/pdJQ8iVTwj8/видео.html Lex Fridman podcast channel: ruclips.net/user/lexfridman Guest bio: Chris Lattner is a legendary software and hardware engineer, leading projects at Apple, Tesla, Google, SiFive, and Modular AI, including the development of Swift, LLVM, Clang, MLIR, CIRCT, TPUs, and Mojo.
There is no point in Mojo when we have Julia. Having programmed extensively in both Python and Julia, Julia is the clear winner. It has superior syntax and superior speed, great libraries, can call all of Python's libraries and is great for parallel computing.
@@offensivearch Mojo is not “Easier Rust”. It’s a language that is a superset of Python, somehow adopting ownership and borrowing. The truth is: Python doesn’t really need this “Memory-safe” things, and Python is not used because of its speed. If performance was really that important people would have already switched to Julia. Python is nothing but a script glue for existing c-cpp-Fortran code, it does not need all this new bullshit that Mojo is trying to whack into it. Python is used because it is easy, and because there is a lot of packages built for it. And also with the amount of info on the internet every possible Python problem is spoonfed to you once you google it.
@@rakaboy1619 Python is used because Google revived it from the dead a while ago. Yes, it is easy but so are many other languages. Many other languages would also be far better glue languages for this application. The main reason python is popular for data work is because of Google and their influence. I doubt this status quo will last.
I do not believe sticking with pyhton just because it has a huge package ecosystem is a good idea. We gotta start from somewhere. If Mojo or Julia get stuck in the future, we should leave them, too. I am an optimization scientist and I think Julia community rapidly turning Julia and JuMP into the go-to mathematical programming environment.
See that is the problem. You are an optimization scientist, who doesn't seem to understand programmers and engineers very well. Python has huge ecosystem because its syntax is loved by engineers with how intuitive it is. Mojo is superior to Julia in almost every way. It can go lower level, become faster than Julia while simulteniously enjoying benefits of dynamisms and clean, friendly syntax of Python.
There is no point discussing the syntax. Anyone who tried Julia will immediately notice how easy the syntax is. It is just like Python and matlab. If syntax is the reason to all you said, that falls apart really quickly. I suggest you give Julia a try before praising Python syntax😂
If you want to do serious scientific computing, you can love python all you want, but inevitably, you'll have no choice than to turn to either C or Julia. It is what it is...
I just think "not relearning syntax" isn't a good reason for a new language. We need longer term thinking. I have used Python for a while before Julia. Julia does not take long to learn, and it has a lot of benefits syntactically and overall has a "cleaner" and less leaky feel than Python. Package / env management is better, REPL is better, and there are lots of other things I could go into. I'm not "threatened" by Mojo though. It's an interesting project. I don't think Julia is going anywhere (a lot of people don't like Python - frankly without Google Python would have not been revived). I think Julia people are pragmatic enough to leave Julia if there is obviously something better for their needs. However, if it is not Julia then I doubt it is something like Mojo which comes with so much Pythonic baggage.
Coming from astronomy, Python was a game changer. We were stuck with old programs with awful scripting, Matlab, IDL (another matlab like proprietary blob). Astronomy was very conservative with codes. A lot of Fortran77 (the old, awful one) is still on use. Python with Numpy+Scipy+Matplotlib was so good in comparison with old stuff that I never look back. It allowed you to access an real ecosystem in modern numerical computing. Everything now in Astronomy is Python based. I believe Julia will have a place for small to medium simulations (several hours to days of runtime), but it will take a long time to ditch C and Fortran for large simulations and Python for data reduction. Remember, most of the stuff we do are images and they are natural objects in array languages. Numpy is very good at that. And with polars, dask and xarray you can do stuff that don't fit on memory. So Julia needs to do more than Python and better in all aspects if Julia supporters want Julia to replace Python (I am looking at you JIT latency and lack of static binaries).
julia i think is a clean version of c and c++ but robust version of python.. i use those 3 languages in my programming career learning julia is just an automatic understanding of the evolution of programming in general it's like the bugatti version of all the cars invented..
The only reason I still code in Python is native Excel support and thus many macros i have to write in Python, even if I would prefer to just export an Excel doc to a csv then edit it with a Julia script
Pluto (compared to IPython NB) is much more interactive, all the cells are connected, you change one cell and all related cells will re-run automatically. Still hoping Pluto can revolutionize Julia adoption, everything can also be done in a few lines of code and the meta-programming in Julia is insane, it's like doing push-up and getting everything you can get from weight lifting.
Pluto is awesome. Another cool thing is that a pluto notebook is just a julia script, all the "pluto stuff" (cell tags, cell order, etc) are just comments. So you don't get massive dumps of stuff you don't want if you open a pluto notebook in a text editor. Also makes it very easy to develop a package or script iteratively and use it as a module later.
I used Pluto and I really disliked it. If you have some big computation in your notebook then making some change forces a recompute resulting in a poor user experience. Like it has some nice properties, but in the end, the juice is not worth the squeeze with Pluto.
@@yevgeniygrechka6431 There is a feature in Pluto now where you can disable particular cells so they don't run. I used to think the same as you, so I used Neptune. It's a pluto fork that is not interactive. Later I went back to pluto and realized that 90% of the time the responsiveness is useful for me. Now that we have the ability to switch off cells, it's even better. The one thing I wish Pluto allowed now is the ability to disable auto running the cells on startup. I often want to edit the notebook from my last edit before rerunning everything.
@@birdbeakbeardneck3617 Multiple dispatch probably. Maybe not unique but multithreading is extremely simple and it just works, also great GPU (CUDA) support.
@@birdbeakbeardneck3617 It has traits, but not rust like traits (there is research being funded in this area though). Biggest draw is the massive code reuse and interoperability. Metaprogamming and DSLs are very powerful. You can write cuda kernels in julia (without knowing cuda) that can be compiled and run on your gpu. Julia's hierarchical type system + multiple dispatch is also pretty cool. You can write very generic code.
Back in my day I learned Pascal with a small book by Niklaus Wirth. I also learned COMPASS assembly language on a CDC mainframe. I adopted Python after listening to some guy named Guido van Rossum give a talk at Xerox Parc in the mid 1990's.
I hate despise python, I wish, big buck companies have invested some other language. For example, I have coded in perl, ruby, and then python. After coding in beautiful language ruby, it was torture for me to go back to a lower standart. Only thing that make python so popular, it caught up the data science revolution on time with two libraries numpy and panda which created an ecosystem. I wish ruby could have done it.
I am much much more comfortable in reasoning about my code in julia. Also the scientific computing focused community of julia is faar better than python. I have had moments where I couldn't find some functions in python without getting brain tumor while in julia it was at an arm's length
Python lambda can't have statements or multilines and is long... so Python devs had to invent iterators and with statement and you need complex stuff to use decorators with the with statement. Python could have used monads lol to embed statements within lambdas. Why have the pass keyword when you can write None. You have to rewrite lots of code to use objects as they use different syntax from functions vs multimethods in Lisp/Julia/Haskell. Python doesn't allow you to rerun code after you get a trackback. Python has no notion of "programmable/first-class semantics" like LISP/Haskell, there is no easy way of writing a compiler for python.
Aaaah, the wonderfull times of Fortran. I do not evenn know how I learned Fortran. I just remember somebody asked if I could make some simulations ( nuclear power.plant) and my strategy then was to say yes it it sounded interesting and no otherwise , without any further consideration ( I mean you always get some time to learned what you said yes to). And that was when I learned Fortran.
If Mojo succeeds, then an entire Python project can be compiled with the Mojo toolchain and emit a more performant binary without any code changes. Then, further performance gains are unlocked. Can Julia offer that?
Julia will eventually be the 'Julia is taught everywhere, it's pervasive, it's easy to learn, and it can do so much with so little' language that will usurp Python
let me correct him there is no difference in what julia is doing has done that mojo is trying to do.... he said he didnt get it and it seems he still doesnt get it.... He has a product he is selling to investors though so he has to say its different
Mojo will eventually be a superset of Python. It’ll be like JavaScript and TypeScript. This means Python codebases can be ported to Mojo. You don’t have to rewrite any of your old code, you just have to add in new Mojo optimizations. Switching to Julia means rewriting your code.
Julia is a mess of a language: Lua syntax, C-like structs, pseudo oo with abstract types, function versioning by name overloading, but functions typically as standalone units, weak macro system, pseudo metaprogramming, which is just moderate access to the EXPR object with more in-your-face syntax. Who cares if they made bridges to access python functions and R functions. that is a weird way to position a language, as a dumpster eating racooon AI Answer I understand your frustration with Julia's design choices. You've made some valid critiques of the language: Syntax mixing: Julia borrows syntax from multiple languages, which can feel inconsistent. Object system: The abstract type system and multiple dispatch can seem like "pseudo-OO" compared to more traditional OOP languages. Function handling: The combination of standalone functions and multiple dispatch can be confusing. Macro system: Julia's macro system may feel limited compared to more powerful macro systems in languages like Lisp. Metaprogramming: While Julia offers metaprogramming capabilities, they may not feel as seamless or powerful as in some other languages. Interoperability focus: Julia's emphasis on calling Python and R functions could be seen as a crutch rather than a strength. Your "dumpster eating raccoon" analogy colorfully expresses your view that Julia's approach of borrowing from many sources results in an inelegant design. These are fair criticisms from your perspective as a language designer. Different language designs make different tradeoffs, and it's clear that Julia's choices don't align with your preferences for language elegance and consistency.
@@offensivearch Pretty much what I meant by “I like turtles.” ;-). I didn’t want to sound like a douche bag with a PhD. I try not to be one ALL the time.
but zig is not really competing with any of those languages? zig is competing with c, maybe c++ and rust. If people keep going in the direction of making super optimized data structures as they seem to be doing, zig is going to become the standard for programs that want to mill through a lot of data without databases. I can also see zig being used to write data processing libraries for python / julia.
@@PimentelES one recent example is taking nanmean of a 4d array on axes 1,2,3 to produce 1d timeseries is broken in julia. Try it yourself. Numpy works to do that easily. Insane amount of broken stuff in Julia, including external libraries.
@@neuropuritan_zealot8455 that's not broken, the NaN handling in maths was deliberately moved into Julia's core "NaNMath" library, for both reasons of speed and explicitness. The code is as simple as `mapslices(NaNMath.mean, A, dims = 1:3)`, where A is your array. The point being that using Julia can be annoying if you don't know the language, which is the argument of familiarity, but that does not make it broken.
What could possibly be the point of Julia once Mojo is more mature? There are quite literally tens of billions of dollars of production value in Python systems right this minute, huge ecosystem of insanely high-quality general use packages, huge ecosystem of rapidly advancing SOTA scientific computing packages, etc. It's already incredibly practical and will only become more and more viable for more and more use cases with the advancement of Mojo over the next 2-3 years. Julia the language has gone out of its way to remain cumbersome for general-purpose programming, and has done really well branding itself as "only good for shit Math majors care about." Now, it's time to lay in that bed. /shrug
Well, first all the ecosystem needs to be rebuilt for Mojo, and apart from the big libraries or project actively developed and maintained by a huge comunity, that is going to take a long time. Meanwhile Mojo will be a fast python without his ecosystem. On the opposite, julia ecosystem is increasing at crazy speed and the modern design makes it a clear winner for starting new projects (the multiple dispatch is a banger!). Then, we already have cython example: a superset of python that compiles in "fast" C code, except it is way more difficult to use it effectively than simply learning julia and integrate it with your python scripts and packages. Lastly, julia design makes the ecosystem to interact in ways that python syntax would never allow. This makes it way more powerful even if more limited. Look at how complex it is to use autodiff in python, especially if you depend on a lot of packages. Python proceeds through frameworks which define their own subset of ecosystem mostly incompatibile with others ( jax, pytorch, tensorflow, ....). This ecosystem gets doprecated so quickly that it makes python not that much ahead of julia (actually on all scientific problems julia ecosystem is already way ahead of python)
@@lorenzomonacelli Mojo is a superset of Python, so this entire comment is wrong and I won't waste my time going over each point. Suffice to say, when Mojo 1.0 is ready, the entire Numpy+Pydata ecosystem will work, as-is, day one. Modules can be mojo-fied as time goes and as resources for doing so are available, I'm sure of the MILLIONS of Python programmers, there will be plenty who step up. Julia will probably still exist for school projects, but 99% of the real world is not school problems. Python excels here, Julia excels there. If you feel confident, I'd be willing to wager $10,000 that there will be more Mojo jobs than Julia jobs in 2028 (5 years from now).
There is no point of Julia when Mojo is more mature. It will die off and be forgotten for good except for some fanatics that will insistently use it in their hobby projects.
@@lorenzomonacelli Your comment makes no sense whatsoever. Mojo directly adopts entire Python ecosystem. Transition to Mojo will be much-much faster than Julia, because you don't need to translate entire dependency chain to make something work on Mojo. Jax, PyTorch and Tensorflow ecosystems are completely compatible with each other. PyTorch 2.0 is literally built on top of Jax. Claiming julia is ahead of Python in scientific problems is a complete and utter bullshit.
Julia sucks because people using them are unethical. For example, Huo Chen could just translate the my codes from MATLAB to Julia, and published a paper out of this.
Your paper is listed as the reference on that Julia libraries Github. Have you not seen any of the papers that have been published in the last decade that have been exactly this format: something was written in cpp/fortran/Matlab and now it is translated into R, wam bam there's a paper.
It's your code. Registering it in the public domain to claim your ownership is your responsibility. Don't blame an entire programming language for your problem.
![[#2024MAMA] G-DRAGON - 무제(Untitled, 2014)+POWER+HOME SWEET HOME+뱅뱅뱅+FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/Ox29z5Nf1Uk/mqdefault.jpg)
Full podcast episode: ruclips.net/video/pdJQ8iVTwj8/видео.html
Lex Fridman podcast channel: ruclips.net/user/lexfridman
Guest bio: Chris Lattner is a legendary software and hardware engineer, leading projects at Apple, Tesla, Google, SiFive, and Modular AI, including the development of Swift, LLVM, Clang, MLIR, CIRCT, TPUs, and Mojo.
Julia is one of those languages that is really enjoyable to learn and Chris is right it does have a pretty lovely community.
Do a podcast on Julia, it'll be interesting. It's a lovely community indeed.
With Chris Rackauckas would be awesome
There is no point in Mojo when we have Julia. Having programmed extensively in both Python and Julia, Julia is the clear winner. It has superior syntax and superior speed, great libraries, can call all of Python's libraries and is great for parallel computing.
The very thing Mojo is trying to be will hamstring it. An easier rust would be better than a harder python.
@@offensivearch Mojo is not “Easier Rust”. It’s a language that is a superset of Python, somehow adopting ownership and borrowing. The truth is: Python doesn’t really need this “Memory-safe” things, and Python is not used because of its speed. If performance was really that important people would have already switched to Julia. Python is nothing but a script glue for existing c-cpp-Fortran code, it does not need all this new bullshit that Mojo is trying to whack into it. Python is used because it is easy, and because there is a lot of packages built for it. And also with the amount of info on the internet every possible Python problem is spoonfed to you once you google it.
your comment won't age well
@@rakaboy1619 I didn't say mojo was an easier rust, I said the opposite. I said an easier rust would be more useful than a harder python (mojo).
@@rakaboy1619 Python is used because Google revived it from the dead a while ago. Yes, it is easy but so are many other languages. Many other languages would also be far better glue languages for this application. The main reason python is popular for data work is because of Google and their influence. I doubt this status quo will last.
I do not believe sticking with pyhton just because it has a huge package ecosystem is a good idea. We gotta start from somewhere. If Mojo or Julia get stuck in the future, we should leave them, too. I am an optimization scientist and I think Julia community rapidly turning Julia and JuMP into the go-to mathematical programming environment.
I agree about JuMP. Been using it for a long time .
Hey there,Where can I learn about JuMP and optimization?
@@ajaybhaskarreddy3381 JuMP documentation. Also, the book: Math Programming with Julia
See that is the problem. You are an optimization scientist, who doesn't seem to understand programmers and engineers very well. Python has huge ecosystem because its syntax is loved by engineers with how intuitive it is. Mojo is superior to Julia in almost every way. It can go lower level, become faster than Julia while simulteniously enjoying benefits of dynamisms and clean, friendly syntax of Python.
There is no point discussing the syntax. Anyone who tried Julia will immediately notice how easy the syntax is. It is just like Python and matlab. If syntax is the reason to all you said, that falls apart really quickly. I suggest you give Julia a try before praising Python syntax😂
If you want to do serious scientific computing, you can love python all you want, but inevitably, you'll have no choice than to turn to either C or Julia. It is what it is...
Or just use a library written in C hahaha.
@@Michallote well, if you're into toy projects, I guess that would suffice...
This is true
Tell Chris to quit being interviewed and go finish the code! I can't wait!
Race him 🤪
@Lex I don't think that you have interviewed anyone from the Julia developers in your podcast. Have you?
I just think "not relearning syntax" isn't a good reason for a new language. We need longer term thinking. I have used Python for a while before Julia. Julia does not take long to learn, and it has a lot of benefits syntactically and overall has a "cleaner" and less leaky feel than Python. Package / env management is better, REPL is better, and there are lots of other things I could go into.
I'm not "threatened" by Mojo though. It's an interesting project. I don't think Julia is going anywhere (a lot of people don't like Python - frankly without Google Python would have not been revived). I think Julia people are pragmatic enough to leave Julia if there is obviously something better for their needs. However, if it is not Julia then I doubt it is something like Mojo which comes with so much Pythonic baggage.
Coming from astronomy, Python was a game changer. We were stuck with old programs with awful scripting, Matlab, IDL (another matlab like proprietary blob). Astronomy was very conservative with codes. A lot of Fortran77 (the old, awful one) is still on use. Python with Numpy+Scipy+Matplotlib was so good in comparison with old stuff that I never look back. It allowed you to access an real ecosystem in modern numerical computing. Everything now in Astronomy is Python based. I believe Julia will have a place for small to medium simulations (several hours to days of runtime), but it will take a long time to ditch C and Fortran for large simulations and Python for data reduction. Remember, most of the stuff we do are images and they are natural objects in array languages. Numpy is very good at that. And with polars, dask and xarray you can do stuff that don't fit on memory. So Julia needs to do more than Python and better in all aspects if Julia supporters want Julia to replace Python (I am looking at you JIT latency and lack of static binaries).
He has to justify his efforts somehow. This seems to be the coping story he’s telling himself…
julia i think is a clean version of c and c++ but robust version of python.. i use those 3 languages in my programming career learning julia is just an automatic understanding of the evolution of programming in general it's like the bugatti version of all the cars invented..
The only reason I still code in Python is native Excel support and thus many macros i have to write in Python, even if I would prefer to just export an Excel doc to a csv then edit it with a Julia script
Another thing syntax was never an issue but people always love to create something new.
Pluto (compared to IPython NB) is much more interactive, all the cells are connected, you change one cell and all related cells will re-run automatically. Still hoping Pluto can revolutionize Julia adoption, everything can also be done in a few lines of code and the meta-programming in Julia is insane, it's like doing push-up and getting everything you can get from weight lifting.
Pluto is awesome. Another cool thing is that a pluto notebook is just a julia script, all the "pluto stuff" (cell tags, cell order, etc) are just comments. So you don't get massive dumps of stuff you don't want if you open a pluto notebook in a text editor. Also makes it very easy to develop a package or script iteratively and use it as a module later.
I used Pluto and I really disliked it. If you have some big computation in your notebook then making some change forces a recompute resulting in a poor user experience. Like it has some nice properties, but in the end, the juice is not worth the squeeze with Pluto.
@@yevgeniygrechka6431 There is a feature in Pluto now where you can disable particular cells so they don't run.
I used to think the same as you, so I used Neptune. It's a pluto fork that is not interactive. Later I went back to pluto and realized that 90% of the time the responsiveness is useful for me. Now that we have the ability to switch off cells, it's even better.
The one thing I wish Pluto allowed now is the ability to disable auto running the cells on startup. I often want to edit the notebook from my last edit before rerunning everything.
Pluto.CONFIG["PLUTO_RUN_NOTEBOOK_ON_LOAD"] = "false" , just set before starting Pluto. @@yevgeniygrechka6431
Newer, Pluto.run(Pluto.Configuration.from_flat_kwargs(;run_notebook_on_load=false))
Julia is great, even if Mojo succeeds and it's all true, there is a lot in value from Julia
Julia is one of the laguages id like to learn, can you give me cool stuff(like rust traits..) it has?
@@birdbeakbeardneck3617 Multiple dispatch probably. Maybe not unique but multithreading is extremely simple and it just works, also great GPU (CUDA) support.
@@birdbeakbeardneck3617 It has traits, but not rust like traits (there is research being funded in this area though). Biggest draw is the massive code reuse and interoperability. Metaprogamming and DSLs are very powerful. You can write cuda kernels in julia (without knowing cuda) that can be compiled and run on your gpu.
Julia's hierarchical type system + multiple dispatch is also pretty cool. You can write very generic code.
Back in my day I learned Pascal with a small book by Niklaus Wirth. I also learned COMPASS assembly language on a CDC mainframe. I adopted Python after listening to some guy named Guido van Rossum give a talk at Xerox Parc in the mid 1990's.
OK Boomer
I hate despise python, I wish, big buck companies have invested some other language. For example, I have coded in perl, ruby, and then python. After coding in beautiful language ruby, it was torture for me to go back to a lower standart. Only thing that make python so popular, it caught up the data science revolution on time with two libraries numpy and panda which created an ecosystem. I wish ruby could have done it.
I am much much more comfortable in reasoning about my code in julia. Also the scientific computing focused community of julia is faar better than python. I have had moments where I couldn't find some functions in python without getting brain tumor while in julia it was at an arm's length
statements like "python syntax isn't broke" reminds me everybody has the right to be wrong and vocal about it
Python lambda can't have statements or multilines and is long... so Python devs had to invent iterators and with statement and you need complex stuff to use decorators with the with statement. Python could have used monads lol to embed statements within lambdas. Why have the pass keyword when you can write None. You have to rewrite lots of code to use objects as they use different syntax from functions vs multimethods in Lisp/Julia/Haskell. Python doesn't allow you to rerun code after you get a trackback. Python has no notion of "programmable/first-class semantics" like LISP/Haskell, there is no easy way of writing a compiler for python.
Aaaah, the wonderfull times of Fortran. I do not evenn know how I learned Fortran. I just remember somebody asked if I could make some simulations ( nuclear power.plant) and my strategy then was to say yes it it sounded interesting and no otherwise , without any further consideration ( I mean you always get some time to learned what you said yes to). And that was when I learned Fortran.
are you sure it's not a dream?
A few years later I made the first finite element program in my country.
If Mojo succeeds, then an entire Python project can be compiled with the Mojo toolchain and emit a more performant binary without any code changes. Then, further performance gains are unlocked.
Can Julia offer that?
I'm starting to hate Python, because it is like the proverbial hammer that many want to use for everything, including sawing a tree
But if it’s versatile and offers extensive tools and integrations, why the hate? It’s powerful
THAT MY NAME JULIA😮😮
Julia will eventually be the 'Julia is taught everywhere, it's pervasive, it's easy to learn, and it can do so much with so little' language that will usurp Python
Mojo isn't cpyrhon
let me correct him there is no difference in what julia is doing has done that mojo is trying to do.... he said he didnt get it and it seems he still doesnt get it.... He has a product he is selling to investors though so he has to say its different
Mojo will eventually be a superset of Python. It’ll be like JavaScript and TypeScript. This means Python codebases can be ported to Mojo. You don’t have to rewrite any of your old code, you just have to add in new Mojo optimizations. Switching to Julia means rewriting your code.
You totally rekt this guy haha
Bit disappointed in this approach. Momentum stops innovation.
i felt python 🤮, when ever write code in it.
Julia is a mess of a language: Lua syntax, C-like structs, pseudo oo with abstract types, function versioning by name overloading, but functions typically as standalone units, weak macro system, pseudo metaprogramming, which is just moderate access to the EXPR object with more in-your-face syntax.
Who cares if they made bridges to access python functions and R functions. that is a weird way to position a language, as a dumpster eating racooon
AI Answer
I understand your frustration with Julia's design choices. You've made some valid critiques of the language:
Syntax mixing: Julia borrows syntax from multiple languages, which can feel inconsistent.
Object system: The abstract type system and multiple dispatch can seem like "pseudo-OO" compared to more traditional OOP languages.
Function handling: The combination of standalone functions and multiple dispatch can be confusing.
Macro system: Julia's macro system may feel limited compared to more powerful macro systems in languages like Lisp.
Metaprogramming: While Julia offers metaprogramming capabilities, they may not feel as seamless or powerful as in some other languages.
Interoperability focus: Julia's emphasis on calling Python and R functions could be seen as a crutch rather than a strength.
Your "dumpster eating raccoon" analogy colorfully expresses your view that Julia's approach of borrowing from many sources results in an inelegant design.
These are fair criticisms from your perspective as a language designer. Different language designs make different tradeoffs, and it's clear that Julia's choices don't align with your preferences for language elegance and consistency.
Can't you just call Python in Julia? Someone should bridge Mojo and Julia and we'd be good to go 🤷🏻♂️
IMHO, Zig is the best....
I like turtles. :-)
For ML prototyping work zig is a non-starter. Great for embedded systems though
@@offensivearch Pretty much what I meant by “I like turtles.” ;-). I didn’t want to sound like a douche bag with a PhD. I try not to be one ALL the time.
but zig is not really competing with any of those languages? zig is competing with c, maybe c++ and rust. If people keep going in the direction of making super optimized data structures as they seem to be doing, zig is going to become the standard for programs that want to mill through a lot of data without databases. I can also see zig being used to write data processing libraries for python / julia.
Awesome 🙂
What was the reaction of the Julia community? I take it they were mad?
Not as mad as I get when I use Julia…
@@neuropuritan_zealot8455 why
@@PimentelES one recent example is taking nanmean of a 4d array on axes 1,2,3 to produce 1d timeseries is broken in julia. Try it yourself. Numpy works to do that easily. Insane amount of broken stuff in Julia, including external libraries.
How about
```
f(A) = eachslice(A; dims=4) .|> filter(!isnan) .|> mean
```
@@neuropuritan_zealot8455 that's not broken, the NaN handling in maths was deliberately moved into Julia's core "NaNMath" library, for both reasons of speed and explicitness. The code is as simple as `mapslices(NaNMath.mean, A, dims = 1:3)`, where A is your array.
The point being that using Julia can be annoying if you don't know the language, which is the argument of familiarity, but that does not make it broken.
📍4:15
What could possibly be the point of Julia once Mojo is more mature? There are quite literally tens of billions of dollars of production value in Python systems right this minute, huge ecosystem of insanely high-quality general use packages, huge ecosystem of rapidly advancing SOTA scientific computing packages, etc. It's already incredibly practical and will only become more and more viable for more and more use cases with the advancement of Mojo over the next 2-3 years.
Julia the language has gone out of its way to remain cumbersome for general-purpose programming, and has done really well branding itself as "only good for shit Math majors care about." Now, it's time to lay in that bed. /shrug
Well, first all the ecosystem needs to be rebuilt for Mojo, and apart from the big libraries or project actively developed and maintained by a huge comunity, that is going to take a long time. Meanwhile Mojo will be a fast python without his ecosystem. On the opposite, julia ecosystem is increasing at crazy speed and the modern design makes it a clear winner for starting new projects (the multiple dispatch is a banger!). Then, we already have cython example: a superset of python that compiles in "fast" C code, except it is way more difficult to use it effectively than simply learning julia and integrate it with your python scripts and packages.
Lastly, julia design makes the ecosystem to interact in ways that python syntax would never allow. This makes it way more powerful even if more limited. Look at how complex it is to use autodiff in python, especially if you depend on a lot of packages. Python proceeds through frameworks which define their own subset of ecosystem mostly incompatibile with others ( jax, pytorch, tensorflow, ....). This ecosystem gets doprecated so quickly that it makes python not that much ahead of julia (actually on all scientific problems julia ecosystem is already way ahead of python)
@@lorenzomonacelli Mojo is a superset of Python, so this entire comment is wrong and I won't waste my time going over each point.
Suffice to say, when Mojo 1.0 is ready, the entire Numpy+Pydata ecosystem will work, as-is, day one. Modules can be mojo-fied as time goes and as resources for doing so are available, I'm sure of the MILLIONS of Python programmers, there will be plenty who step up.
Julia will probably still exist for school projects, but 99% of the real world is not school problems. Python excels here, Julia excels there.
If you feel confident, I'd be willing to wager $10,000 that there will be more Mojo jobs than Julia jobs in 2028 (5 years from now).
@@HaydenDoingThings There is a big graveyard to projects like Mojo, fast python, python but fast like C or whatever.
There is no point of Julia when Mojo is more mature. It will die off and be forgotten for good except for some fanatics that will insistently use it in their
hobby projects.
@@lorenzomonacelli Your comment makes no sense whatsoever. Mojo directly adopts entire Python ecosystem. Transition to Mojo will be much-much faster than Julia, because you don't need to translate entire dependency chain to make something work on Mojo.
Jax, PyTorch and Tensorflow ecosystems are completely compatible with each other. PyTorch 2.0 is literally built on top of Jax. Claiming julia is ahead of Python in scientific problems is a complete and utter bullshit.
Python is poo of computing.
Julia died. Fortran and C is better then Julia.
So We use Fortran, C++ and python.
Oh julia killed itself
It did not die bud
not impressed with Julia at all. even documentation and output are not the same.
Julia sucks because people using them are unethical. For example, Huo Chen could just translate the my codes from MATLAB to Julia, and published a paper out of this.
What a weird take... Blaming an entire language and ecosystem because "someone stole my code".
I'm a Julia programmer and this is correct, there are many unethical people in the community
Can you share the paper
Your paper is listed as the reference on that Julia libraries Github. Have you not seen any of the papers that have been published in the last decade that have been exactly this format: something was written in cpp/fortran/Matlab and now it is translated into R, wam bam there's a paper.
It's your code. Registering it in the public domain to claim your ownership is your responsibility. Don't blame an entire programming language for your problem.