9 ms·

There are a bunch of questions about Julia, so I'll do my best to give a short answer to a very long and complicated topic. Up front, Julia is a wonderful lang

There are a bunch of questions about Julia, so I'll do my best to give a short answer to a very long and complicated topic. Up front, Julia is a wonderful language and a wonderful community, I am a super fan. That said, Mojo is a completely different thing. It is aligned with the Python community to solve specific problems outlined here: https://docs.modular.com/mojo/why-mojo.html https://docs.modular.com/mojo/why-mojo.html Mojo also has a bunch of technical advancements compared to Julia by virtue of it being a much newer development and being able to learn from it (and Swift and Rust, and C++ and many many other languages). Including things like ownership and no GC. We also think there is room for a new language that is easier to deploy, scales down to small envelopes, works directly with the full Python ecosystem, is designed for ML and for MLIR from first principles, etc. Julia is far more mature and advanced in many ways. Many folks have and will continue to push Julia forward and we wish them the best, it is a lovely ecosystem and language. There is room for more than one thing! :) EDIT: Just in case there is any confusion, I work for Modular, built LLVM, Swift, Clang, MLIR and a variety of other things. I wasn't trying to misrepresent as being unaffiliated.

travisoliphant 3y ago
Congratulations on the launch and work so far! This is indeed very interesting. I believe a language like this is necessary for future progress. I have also been impressed with Julia and its progress. I would have liked to see more progress on Ahead of Time compilation and using it to write Python extension modules. For Mojo, I'm interested in seeing how the language can be used as a path forward for the Cython community. This could be a stepping-stone towards reimplementation of Python in Mojo. For the past 3 year, I have been talking about the need for a Python-Steering-Council-recommended extension language for Python. This will be particularly important as WebAssembly keeps progressing and potentially redefining what we mean by virtualization and containers. We have already been using LLVM extensively in Numba and there have been several explorations around MLIR and related technologies. There are several potential paths forward and I'm looking forward to finding ways to cooperate. Understanding what will be open-source is of course, critical for that.
UncleOxidant 3y ago
I notice that Mojo still seems to use numpy or something that looks "numpyish" for compatibility. Will Mojo also have an alternative syntax for doing things like matrix multiplication that looks more native like Julia's?
- chrislattner 3y ago
  Mojo fully supports arbitrary library designed types, check out the note books for examples that define custom matrix operations of various types.
  - byt143 3y ago
    How does mojo handle function polymorphism and abstraction? Julia uses multiple dispatch, Haskell type classes etc Edit: I see you're going to have protocols/ traits. Can those be specializes/monomoprhized at function call time like Julia abstract types? And how about function specialization? Will functions be attached to structs in a single dispatch fashion or free floating multimethods?
funks_ 3y ago
Are there any plans for native autodiff systems in Mojo?
mirekrusin 3y ago
Hold on, are you behind it? ...looks like it! This "detail" shouldn't be hidden away, it means a lot.
- EGreg 3y ago
  How does it look like it?
  - mirekrusin 3y ago
    From "Team"'s link [0] [0] https://www.modular.com/team https://www.modular.com/team
- mattnewton 3y ago
  As a former apple eng I guess I forgot that some people don’t know who Chris Lattner is haha. There isn’t anything unscrupulous going on here he probably just thought posting under his username was enough of disclaimer.
  - deleted 3y ago
    [deleted]
UncleOxidant 3y ago
> Julia is far more mature and advanced in many ways. Many folks have and will continue to push Julia forward and we wish them the best, it is a lovely ecosystem and language. There is room for more than one thing! :) In general this tends to be true. However, in this case I'm not so sure. Modular seems to have garnered a lot of investment - probably orders of magnitude more than the Julia community has been able to get. There are a lot of nagging problems in Julia (startup times - though that's gotten better recently, ML kernel performance, and executables come to mind) that could have been easily fixed if they had the money to throw at them. Since they haven't had that kind of investment people who kick Julia's tires tend to see these things as built-in limitations and move on.
- moelf 3y ago
  This is too real and any of the great investment of manpower (e.g. Tensorflow for Swift) if happened to Julia would probably be 10x or 100x in terms of ROI -- just look at how few devs and line of code Julia's alternative to pandas/numpy/ML/autodidf/plotting has. If Julia ecosystem can be somewhat competitive while only having part time and researchers' side project contributors, it WILL thrive if properly invested.
  - WinLychee 3y ago
    Just a thought, but perhaps it's the small community and independent culture of Julia that has led to the high quality of its software. Small groups of highly passionate people can accomplish a lot! If I recall the history correctly, scientific Python (numpy, scipy, etc) developed similarly at first and has mostly supplanted Matlab, Fortran, and other tools. There was a point in time when Python was considered niche and not for "serious" work :).
    - LotusTensor 3y ago
      Hard disagree. I think some people (not necessarily you, but way too many people) weirdly envy too much that "lone/few geniuses" image, and when they see bigger communities and their problem, they fallaciously/unfairly assume it's because of the size of the community (and not say, unnecessary bureaucracy that a small part of that community decided to have/had early on long before they got big). One of Julia's often complained about issues is that it could use way more developers than it has now. No amount of romanticizing a small community or "independent culture"(which I just can't see going away due to where a lot of people that come to Julia are coming from in the first place) is going to fix that, just more people coming aboard the ship.
staticfloat 3y ago
I really like the integration of lower-level memory control in a superset of Python. Trying to maintain compatibility with such a large and varied ecosystem is a daunting task, and has the opportunity to be very valuable for many people who don't want (or are unable) to move away from the Python ecosystem. Kudos to you all for tackling such a difficult problem! Good luck, I look forward to seeing how you guys help to increase efficiency across the board!
fulafel 3y ago
No GC and Python compatibility sounds interesting, is there docs about memory management? Edit: seems some current hints are under the roadmap "Ownership and Lifetimes" heading but Python compatibility is not described yet.
mirekrusin 3y ago
Do you have an idea on monetizing it or not yet?
intalentive 3y ago
>Python has amazing strengths as a glue layer, and low-level bindings to C and C++ allow building libraries in C, C++ and many other languages with better performance characteristics. This is what has enabled things like numpy, TensorFlow and PyTorch and a vast number of other libraries in the ecosystem. Unfortunately, while this approach is an effective way to building high performance Python libraries, its approach comes with a cost: building these hybrid libraries is very complicated, requiring low-level understanding of the internals of cpython, requires knowledge of C/C++/… programming... But the cost has already been paid. We have NumPy, we have PyTorch and TensorFlow. So I don't see the value-add here. Maybe there's something I'm missing.
- bjornasm 3y ago
  I believe they are thinking about the cost of building the next NumPy/PyTorch/TensorFlow.
  - sitkack 3y ago
    PyTorch supports fusion and CPU/GPU codegen, https://towardsdatascience.com/how-pytorch-2-0-accelerates-deep-learning-with-operator-fusion-and-cpu-gpu-code-generation-35132a85bd26 https://towardsdatascience.com/how-pytorch-2-0-accelerates-d... Taichi already allows for amazing speedups and supports all the backends (including Metal) https://www.taichi-lang.org/ https://www.taichi-lang.org/ the fact that they didn't mention Taichi is a glaring omission. JAX is that next version of TensorFlow, https://jax.readthedocs.io/en/latest/notebooks/quickstart.html https://jax.readthedocs.io/en/latest/notebooks/quickstart.ht... This looks like a reboot of Numba with more resources devoted to it. Or a juiced up Shedskin. https://shedskin.github.io/ https://shedskin.github.io/ I think Mojo is a minor mistake, I would caution adoption, it is a superset fork of Python instead of a being a performance subset. Subsets always decay back to the host language. Supersets fork the base language. I would rather see Mojo integrated into Python rather than adopting the language and extending. I have a theory why Mojo exists. The team was reading a lot of PyTorch and Tensorflow, getting frustrated with what a PIA working with C++ and MLIR is for their model-backend retargeting codegen, so they created their perfect C++/Python mashup rather than use TVM. They nerd sniped themselves and rather than just use Python3.12+mypy, they made a whole new language based off of Python.
earthboundkid 3y ago
Are you still doing any work with Swift and ML, or not anymore?
- longemen3000 3y ago
  i don't think so
int_19h 3y ago
Why is "no GC" an advantage for something aimed at such high-level tasks?
- Joky 3y ago
  They claim they are writing the actual kernel code (as in the implementation of a matmul) with it, and it was presented as a "system programming language": this goes far beyond "high-level tasks" it seems.
  - adgjlsfhk1 3y ago
    You can write kernels in a language with a GC. You just write kernels that don't allocate.
    - pjmlp 3y ago
      Alternatively have the GC as an OS service.
- ummonk 3y ago
  Yeah funnily enough I think "no GC" would be a much better feature in Julia, which would make it a great language for real time applications.
  - dermesser 3y ago
    This is not true at all! Julia usually being JIT-compiled makes it very unsuitable for real time applications (and there's no reason why it should be great for it). GC is the least issue here, and I say that as a fan and daily user of Julia.
    - sylvaticus 3y ago
      Note that in Julia 1.9 (rc3 currently) and thanks to `PrecompileTools.jl` being adopted by the vast majority of the packages, the compilation latency is a dead issue... (ok, it is moved to the package installation time...)
KenoFischer 3y ago
Congratulations on the launch! I think it's always a great thing to have people who know what they're doing put a new design out there. Raises the bar for everyone. For example, I think the Rust folks' work on error messages has really raised the bar on what is expected of systems is that regard. Sometimes people working on older systems feel a bit uncomfortable they see the bar being raised on them (it's weird to me to think of Julia as on "older" system, but I guess being around for more than a decade counts), but I actually prefer to think about it in the opposite way. There are lots of forces in systems design that push production systems towards conservatism. "We now have a million users, is it really worth spending the time/effort/risk on this new experimental parser/optimizer/feature, etc?", but if the rest of the world raises the bar, it's a great incentive to keep up and make all our systems better. So I very sincerely wish you the best of luck here and that in the areas where there might end up being overlap between Julia and Mojo people will start complaining to us that we need to be better, because we might just take them up on it ;).
- chrislattner 3y ago
  Thank you Keno!
pama 3y ago
Congrats on the launch! In addition to the dramatic possibilities for ML, I hope mojo will have an impact in other scientific software through the ease of specialization to hardware capabilities. The current common subset of Python and “pure” mojo (ie not using CPython) is small, but will expand according to your roadmap. Do you envision porting pure Python libraries as part of the effort, or perhaps help other communities do so? For example einsum in numpy or pytorch are great, but how much more work would be needed to have a mojo-accelerated einsum interfacing with numpy or mojo-specialized arrays? Or have a pure mojo numpy altogether?
- ludgerpaehler 3y ago
  I think some of this consideration, and resulting work is already being looked at in the context of Numba. They came up with PIXIE (Portable Instructions eXchanged in Executable), the concept being to compile your functions into a shared library which embed the low-level compiler IR, and can then be JIT compiled, or "pulled" in at link-time. Modular can do exactly the same with existing Python packages, and lift them into Mojo that way. Reference: https://numba.discourse.group/t/proposal-development-focus-for-2023h1/1773 https://numba.discourse.group/t/proposal-development-focus-f...
sriku 3y ago
Are there lessons to be brought forward to Mojo from the effort to bring autograd to Swift? (Apart from "python ftw", that is)
StefanWestfal 3y ago
A lot of companies build web api's around their ML/AI code and data pipelines in Python, is Mojo suited for these task as well or is it specialized for numerical/AI/ML tasked?
teleforce 3y ago
Very strange to have no GC as a innovative feature for a modern programming language. Personally I think Dlang get it right by making GC as a default and provide no GC as an optional feature. As a comparison, auto industry is moving toward fully automatic transmission especially for the EV but software industry is still undicided and seems cannot even come up with a robust GC mechanism that is on par with no GC in term of performance. With no GC, interpreted programming language e.g. Python will most probably being used well into the future alongside Mojo/C++/Rust because majority of AI/data science/machine learning programmers cannot even bother to touch the underlying codes for the fear of programming complexity of these no GC languages.
- ecs78 3y ago
  Traditional GC isn’t less complex to program then automatic reference counting. Traditional GC has its place in short running extension languages, but in longer running programs you run the same risk of memory leaks as automatic reference counting since you can still over-retain from a poor ownership model. What goes wrong is slightly different, but with automatic reference counting it is easier for the compiler to find and report these issues. I feel you are conflating this with no automatic memory management which would be a higher barrier. Automatic reference counting greatly simplifies inter-op with low-level code and running on specialized hardware vs Python with interop.
  - kaba0 3y ago
    RC is GC, but without cleaning up cyclic references. In general, leaking memory is not a security problem (and with a good debugger it is trivial to fix), so I don’t think it is too important a property. Leaking every cyclic reference is a bit more of a problem, but it has solutions like the occasional tracing phase like with a “traditional”, mark’n’sweep GC, but at that point why not just go with them as they are much more performant?
- dist1ll 3y ago
  > Personally I think Dlang get it right by making GC as a default and provide no GC as an optional feature. I vehemently disagree. D's GC is the #1 reason for its fade into obscurity, instead of becoming a viable C++ competitor. Now it's completely overshadowed by Rust's success.
bsaul 3y ago
Just wanted to share how much of fan of your work i am. I wish you could gave stayed in the Swift ecosystem. i feel like the language has lost its track since you left. Looking forward to see where this new adventure will lead, and congratulations !
pankajdoharey 3y ago
Is this gonna be a commercial compiler ? Why is there a signup waitlist. Is this not gonna be Opensource?
- dangoor 3y ago
  FAQ says they expect to open source it: https://docs.modular.com/mojo/faq.html#will-mojo-be-open-sourced https://docs.modular.com/mojo/faq.html#will-mojo-be-open-sou...
sgaseretto 3y ago
Are there any plans on making linear algebra, numeric operations and so on first class citizens, the same way Julia does it? I believe that also a very compelling characteristic from Julia, for people working in Physics, Mathematics, Artificial Intelligence and Machine Learning is all the "sugar syntax" Julia gives you, is not the same translating a formula from a paper to numpy than translating it to Julia, in Julia writing the expression from a paper is almost a one-to-one mapping. I believe it will be a huge point in favor to Mojo, since UX when writing mathematical code in Julia is a huge advantage to it, the same way Python gained popularity as a General Purpose language because it is almost like writing plain English

travisoliphant 3y ago

Congratulations on the launch and work so far! This is indeed very interesting. I believe a language like this is necessary for future progress. I have also been impressed with Julia and its progress. I would have liked to see more progress on Ahead of Time compilation and using it to write Python extension modules. For Mojo, I'm interested in seeing how the language can be used as a path forward for the Cython community. This could be a stepping-stone towards reimplementation of Python in Mojo. For the past 3 year, I have been talking about the need for a Python-Steering-Council-recommended extension language for Python. This will be particularly important as WebAssembly keeps progressing and potentially redefining what we mean by virtualization and containers. We have already been using LLVM extensively in Numba and there have been several explorations around MLIR and related technologies. There are several potential paths forward and I'm looking forward to finding ways to cooperate. Understanding what will be open-source is of course, critical for that.

UncleOxidant 3y ago

I notice that Mojo still seems to use numpy or something that looks "numpyish" for compatibility. Will Mojo also have an alternative syntax for doing things like matrix multiplication that looks more native like Julia's?

chrislattner 3y ago
Mojo fully supports arbitrary library designed types, check out the note books for examples that define custom matrix operations of various types.
- byt143 3y ago
  How does mojo handle function polymorphism and abstraction? Julia uses multiple dispatch, Haskell type classes etc Edit: I see you're going to have protocols/ traits. Can those be specializes/monomoprhized at function call time like Julia abstract types? And how about function specialization? Will functions be attached to structs in a single dispatch fashion or free floating multimethods?

funks_ 3y ago

Are there any plans for native autodiff systems in Mojo?

mirekrusin 3y ago

Hold on, are you behind it? ...looks like it! This "detail" shouldn't be hidden away, it means a lot.

EGreg 3y ago
How does it look like it?
- mirekrusin 3y ago
  From "Team"'s link [0] [0] https://www.modular.com/team https://www.modular.com/team
mattnewton 3y ago
As a former apple eng I guess I forgot that some people don’t know who Chris Lattner is haha. There isn’t anything unscrupulous going on here he probably just thought posting under his username was enough of disclaimer.
- deleted 3y ago
  [deleted]

UncleOxidant 3y ago

> Julia is far more mature and advanced in many ways. Many folks have and will continue to push Julia forward and we wish them the best, it is a lovely ecosystem and language. There is room for more than one thing! :) In general this tends to be true. However, in this case I'm not so sure. Modular seems to have garnered a lot of investment - probably orders of magnitude more than the Julia community has been able to get. There are a lot of nagging problems in Julia (startup times - though that's gotten better recently, ML kernel performance, and executables come to mind) that could have been easily fixed if they had the money to throw at them. Since they haven't had that kind of investment people who kick Julia's tires tend to see these things as built-in limitations and move on.

moelf 3y ago
This is too real and any of the great investment of manpower (e.g. Tensorflow for Swift) if happened to Julia would probably be 10x or 100x in terms of ROI -- just look at how few devs and line of code Julia's alternative to pandas/numpy/ML/autodidf/plotting has. If Julia ecosystem can be somewhat competitive while only having part time and researchers' side project contributors, it WILL thrive if properly invested.
- WinLychee 3y ago
  Just a thought, but perhaps it's the small community and independent culture of Julia that has led to the high quality of its software. Small groups of highly passionate people can accomplish a lot! If I recall the history correctly, scientific Python (numpy, scipy, etc) developed similarly at first and has mostly supplanted Matlab, Fortran, and other tools. There was a point in time when Python was considered niche and not for "serious" work :).
  - LotusTensor 3y ago
    Hard disagree. I think some people (not necessarily you, but way too many people) weirdly envy too much that "lone/few geniuses" image, and when they see bigger communities and their problem, they fallaciously/unfairly assume it's because of the size of the community (and not say, unnecessary bureaucracy that a small part of that community decided to have/had early on long before they got big). One of Julia's often complained about issues is that it could use way more developers than it has now. No amount of romanticizing a small community or "independent culture"(which I just can't see going away due to where a lot of people that come to Julia are coming from in the first place) is going to fix that, just more people coming aboard the ship.

staticfloat 3y ago

I really like the integration of lower-level memory control in a superset of Python. Trying to maintain compatibility with such a large and varied ecosystem is a daunting task, and has the opportunity to be very valuable for many people who don't want (or are unable) to move away from the Python ecosystem. Kudos to you all for tackling such a difficult problem! Good luck, I look forward to seeing how you guys help to increase efficiency across the board!

fulafel 3y ago

No GC and Python compatibility sounds interesting, is there docs about memory management? Edit: seems some current hints are under the roadmap "Ownership and Lifetimes" heading but Python compatibility is not described yet.

mirekrusin 3y ago

Do you have an idea on monetizing it or not yet?

intalentive 3y ago

>Python has amazing strengths as a glue layer, and low-level bindings to C and C++ allow building libraries in C, C++ and many other languages with better performance characteristics. This is what has enabled things like numpy, TensorFlow and PyTorch and a vast number of other libraries in the ecosystem. Unfortunately, while this approach is an effective way to building high performance Python libraries, its approach comes with a cost: building these hybrid libraries is very complicated, requiring low-level understanding of the internals of cpython, requires knowledge of C/C++/… programming... But the cost has already been paid. We have NumPy, we have PyTorch and TensorFlow. So I don't see the value-add here. Maybe there's something I'm missing.

bjornasm 3y ago
I believe they are thinking about the cost of building the next NumPy/PyTorch/TensorFlow.
- sitkack 3y ago
  PyTorch supports fusion and CPU/GPU codegen, https://towardsdatascience.com/how-pytorch-2-0-accelerates-deep-learning-with-operator-fusion-and-cpu-gpu-code-generation-35132a85bd26 https://towardsdatascience.com/how-pytorch-2-0-accelerates-d... Taichi already allows for amazing speedups and supports all the backends (including Metal) https://www.taichi-lang.org/ https://www.taichi-lang.org/ the fact that they didn't mention Taichi is a glaring omission. JAX is that next version of TensorFlow, https://jax.readthedocs.io/en/latest/notebooks/quickstart.html https://jax.readthedocs.io/en/latest/notebooks/quickstart.ht... This looks like a reboot of Numba with more resources devoted to it. Or a juiced up Shedskin. https://shedskin.github.io/ https://shedskin.github.io/ I think Mojo is a minor mistake, I would caution adoption, it is a superset fork of Python instead of a being a performance subset. Subsets always decay back to the host language. Supersets fork the base language. I would rather see Mojo integrated into Python rather than adopting the language and extending. I have a theory why Mojo exists. The team was reading a lot of PyTorch and Tensorflow, getting frustrated with what a PIA working with C++ and MLIR is for their model-backend retargeting codegen, so they created their perfect C++/Python mashup rather than use TVM. They nerd sniped themselves and rather than just use Python3.12+mypy, they made a whole new language based off of Python.

earthboundkid 3y ago

Are you still doing any work with Swift and ML, or not anymore?

longemen3000 3y ago
i don't think so

int_19h 3y ago

Why is "no GC" an advantage for something aimed at such high-level tasks?

Joky 3y ago
They claim they are writing the actual kernel code (as in the implementation of a matmul) with it, and it was presented as a "system programming language": this goes far beyond "high-level tasks" it seems.
- adgjlsfhk1 3y ago
  You can write kernels in a language with a GC. You just write kernels that don't allocate.
  - pjmlp 3y ago
    Alternatively have the GC as an OS service.
ummonk 3y ago
Yeah funnily enough I think "no GC" would be a much better feature in Julia, which would make it a great language for real time applications.
- dermesser 3y ago
  This is not true at all! Julia usually being JIT-compiled makes it very unsuitable for real time applications (and there's no reason why it should be great for it). GC is the least issue here, and I say that as a fan and daily user of Julia.
  - sylvaticus 3y ago
    Note that in Julia 1.9 (rc3 currently) and thanks to `PrecompileTools.jl` being adopted by the vast majority of the packages, the compilation latency is a dead issue... (ok, it is moved to the package installation time...)

KenoFischer 3y ago

Congratulations on the launch! I think it's always a great thing to have people who know what they're doing put a new design out there. Raises the bar for everyone. For example, I think the Rust folks' work on error messages has really raised the bar on what is expected of systems is that regard. Sometimes people working on older systems feel a bit uncomfortable they see the bar being raised on them (it's weird to me to think of Julia as on "older" system, but I guess being around for more than a decade counts), but I actually prefer to think about it in the opposite way. There are lots of forces in systems design that push production systems towards conservatism. "We now have a million users, is it really worth spending the time/effort/risk on this new experimental parser/optimizer/feature, etc?", but if the rest of the world raises the bar, it's a great incentive to keep up and make all our systems better. So I very sincerely wish you the best of luck here and that in the areas where there might end up being overlap between Julia and Mojo people will start complaining to us that we need to be better, because we might just take them up on it ;).

chrislattner 3y ago
Thank you Keno!

pama 3y ago

Congrats on the launch! In addition to the dramatic possibilities for ML, I hope mojo will have an impact in other scientific software through the ease of specialization to hardware capabilities. The current common subset of Python and “pure” mojo (ie not using CPython) is small, but will expand according to your roadmap. Do you envision porting pure Python libraries as part of the effort, or perhaps help other communities do so? For example einsum in numpy or pytorch are great, but how much more work would be needed to have a mojo-accelerated einsum interfacing with numpy or mojo-specialized arrays? Or have a pure mojo numpy altogether?

ludgerpaehler 3y ago
I think some of this consideration, and resulting work is already being looked at in the context of Numba. They came up with PIXIE (Portable Instructions eXchanged in Executable), the concept being to compile your functions into a shared library which embed the low-level compiler IR, and can then be JIT compiled, or "pulled" in at link-time. Modular can do exactly the same with existing Python packages, and lift them into Mojo that way. Reference: https://numba.discourse.group/t/proposal-development-focus-for-2023h1/1773 https://numba.discourse.group/t/proposal-development-focus-f...

sriku 3y ago

Are there lessons to be brought forward to Mojo from the effort to bring autograd to Swift? (Apart from "python ftw", that is)

StefanWestfal 3y ago

A lot of companies build web api's around their ML/AI code and data pipelines in Python, is Mojo suited for these task as well or is it specialized for numerical/AI/ML tasked?

teleforce 3y ago

Very strange to have no GC as a innovative feature for a modern programming language. Personally I think Dlang get it right by making GC as a default and provide no GC as an optional feature. As a comparison, auto industry is moving toward fully automatic transmission especially for the EV but software industry is still undicided and seems cannot even come up with a robust GC mechanism that is on par with no GC in term of performance. With no GC, interpreted programming language e.g. Python will most probably being used well into the future alongside Mojo/C++/Rust because majority of AI/data science/machine learning programmers cannot even bother to touch the underlying codes for the fear of programming complexity of these no GC languages.

ecs78 3y ago
Traditional GC isn’t less complex to program then automatic reference counting. Traditional GC has its place in short running extension languages, but in longer running programs you run the same risk of memory leaks as automatic reference counting since you can still over-retain from a poor ownership model. What goes wrong is slightly different, but with automatic reference counting it is easier for the compiler to find and report these issues. I feel you are conflating this with no automatic memory management which would be a higher barrier. Automatic reference counting greatly simplifies inter-op with low-level code and running on specialized hardware vs Python with interop.
- kaba0 3y ago
  RC is GC, but without cleaning up cyclic references. In general, leaking memory is not a security problem (and with a good debugger it is trivial to fix), so I don’t think it is too important a property. Leaking every cyclic reference is a bit more of a problem, but it has solutions like the occasional tracing phase like with a “traditional”, mark’n’sweep GC, but at that point why not just go with them as they are much more performant?
dist1ll 3y ago
> Personally I think Dlang get it right by making GC as a default and provide no GC as an optional feature. I vehemently disagree. D's GC is the #1 reason for its fade into obscurity, instead of becoming a viable C++ competitor. Now it's completely overshadowed by Rust's success.

bsaul 3y ago

Just wanted to share how much of fan of your work i am. I wish you could gave stayed in the Swift ecosystem. i feel like the language has lost its track since you left. Looking forward to see where this new adventure will lead, and congratulations !

pankajdoharey 3y ago

Is this gonna be a commercial compiler ? Why is there a signup waitlist. Is this not gonna be Opensource?

dangoor 3y ago
FAQ says they expect to open source it: https://docs.modular.com/mojo/faq.html#will-mojo-be-open-sourced https://docs.modular.com/mojo/faq.html#will-mojo-be-open-sou...

sgaseretto 3y ago

Are there any plans on making linear algebra, numeric operations and so on first class citizens, the same way Julia does it? I believe that also a very compelling characteristic from Julia, for people working in Physics, Mathematics, Artificial Intelligence and Machine Learning is all the "sugar syntax" Julia gives you, is not the same translating a formula from a paper to numpy than translating it to Julia, in Julia writing the expression from a paper is almost a one-to-one mapping. I believe it will be a huge point in favor to Mojo, since UX when writing mathematical code in Julia is a huge advantage to it, the same way Python gained popularity as a General Purpose language because it is almost like writing plain English