3 ms·

Tbh, Modular getting acquired happened sooner than I would have expected, if ever. Don't know how to feel about this one. Also so many mixed feelings about Moj

Tbh, Modular getting acquired happened sooner than I would have expected, if ever. Don't know how to feel about this one. Also so many mixed feelings about Mojo, the programming language powering Modular. Of course Chris Lattner is free to pursue whatever he wants, his many contributions to tech will always be highly regarded, but to me it feels as if he "wasted" lots of his precious mental capacity on making Mojo a python-like language instead of trying to come up with something better from first principles. I know, the promise of Mojo eventually being a Python superset has been taken back, which I think is the right move, and I understand why Mojo's initial motivation for being close to Python was to attract ML folks, but I'm getting counterfactual regret just by thinking about what Chris Lattner could have achieved by making a new programming language truly from scratch and not letting some undesireable pythonisms muddy the language. Anyway, sorry for rambling. Congrats to the team at Modular!

samuell 3mo ago
I'm actually mostly worried about the future of Mojo at this time. Though hopefully it will be fully released open source still, but I feel there are question marks around whether it will be a priority to continue to develop by Qualcomm, or if they are mainly interested in the AI compute stack? Time will tell I guess, but a lot feels to be up in the air.
- samuell 3mo ago
  Maybe Chris was a little unhappy about where Mojo ended up, and sees this as an opportunity to start anew on a properly designed language from scratch :D
  - roflcopter69 3mo ago
    [flagged]
    - samuell 3mo ago
      No, this was pure speculation based on what seems like a popular view on where Mojo ended up, where the initial Python-focus don't seem to help it that much anymore.
      - roflcopter69 3mo ago
        I'm sorry, I read your message slightly wrong. Okay, makes sense to me.
      - throwawaygod 3mo ago
        But they changed their goal from being a python superset to pythonish language with great python interoperability. The only other thing they could've done differently is making the language not look like python superficially. I think chris achieved his goal of creating a language which takes full advantage of MLIR and also not repeating some of the mistakes made with swift's development.
      - augment_me 3mo ago
        Which is interesting given the Mojo blogs where they shit on the other pythonic eDSLs like Triton saying that it's a dead end
- ainch 3mo ago
  They've said that Mojo is still on track to be open-sourced this year, post-acquisition.
- dagi3d 3mo ago
  According to their website, yes it will be opensourced soon
- mshockwave 3mo ago
  indeed, open sourcing is only half (or even less) of the picture: who is driving the open source community and how it is driven (i.e. governing structure) are probably more important IMHO. There are countless of cases where an open source project is either killed by slow death, or dictated by a single entity. Chris's previous projects like LLVM and MLIR are fortunate enough to grow and thrive organically, and that takes years if not decades to cultivate
pjmlp 3mo ago
He already did that, Swift for Tensorflow, the project hardly survived one year after the public announcement.
- adonese 3mo ago
  I think that was the motivation to make Mojo a superset of python.
  - pjmlp 3mo ago
    Yes, but apparently even that ended up being a pivot, with just enough Python, and now lets see what Qualcom makes out of it.
- adev_ 3mo ago
  > Swift for Tensorflow, the project hardly survived one year after the public announcement. This was doom to fail from the beginning. Swift will always have the image of an Apple product binded and controlled by the Apple ecosystem. This is very unlikely to change. Nobody sane of mind would bind there entire technology stack on something half proprietary with a support was from the beginning secondary outside of Apple platforms.
gugagore 3mo ago
To say nothing of "Swift for TensorFlow" when Julialang was an option. To each their own!
jdub 3mo ago
"first principles" and "from scratch" are predictable failure modes... he had very good reason to pursue a Python-like language given the circumstances and objectives
- roflcopter69 3mo ago
  I think I get what you mean and I should have been more precise in my wording. I didn't mean that an alien language that looks nothing like we have ever seen but for the sake of doing it "right" from scratch would have been a good idea. A new programming language definitely should steal the ideas of other languages that turned out to be good. But Mojo also adopted some of the arguably bad ideas from Python just because there was too much design pressure to appeal to Python programmers. I wonder what Mojo could have looked like without this particular pressure. Basically, with what kind of programming language would a person with as much experience and good taste as Chris Lattner come up with if there were no such external pressures?
  - boxed 3mo ago
    > But Mojo also adopted some of the arguably bad ideas from Python Like what?
    - roflcopter69 3mo ago
      The "else" after a for-loop that executes only when the loop completely finished without a "break" or "return". While maybe a nice concept in general, using "else" for this is only to look familiar to Python programmers. The "else" word itself is really counter intuitive here in my opinion. For more, see https://mojolang.org/docs/manual/control-flow/#for-loop-control-statements https://mojolang.org/docs/manual/control-flow/#for-loop-cont... Then there's "foo if cond else bar" which is Python's kind of ternary operator and it's at least slightly contentious. One could argue if a language even needs such a construct, but at least for me, I have an easier time reading the control flow when I look at "cond ? foo : bar". It gets even worse when you nest that stuff, although that's something you shouldn't do anyway. For more, see https://mojolang.org/docs/manual/control-flow/#conditional-expressions https://mojolang.org/docs/manual/control-flow/#conditional-e... Also, indentation based syntax... well, it's a choice. I don't know if Lattner would have chose that in a language that he would have designed to his liking from scratch. For more, see https://mojolang.org/docs/reference/compound-statements/ https://mojolang.org/docs/reference/compound-statements/ Then there is some scoping related badness from Python that I think is really awful. In Python and Mojo (with a caveat) you can do this: if cond: foo = 42 print(foo) So the scope of a variable is function-level and Mojo adopted this and called it implicitly-declared variables (https://mojolang.org/docs/manual/variables/#implicitly-declared-variables https://mojolang.org/docs/manual/variables/#implicitly-decla...) as opposed to the concept of explicitly-declared variables (https://mojolang.org/docs/manual/variables/#implicitly-declared-variables https://mojolang.org/docs/manual/variables/#implicitly-decla...) they added on top which uses the "var" keyword and forces block-level scoping which I'd argue is the sane default. But no, to appease Python programmers, they have this awful function-level scoping by default and you have to opt into block-level scoping by adding a "var" in front of your variable declaration. But earlier, I was talking about a caveat in Mojo, so it's slightly less awful, because the compiler would complain in the code example above that "foo" might be uninitialized when getting to the print statement, so that's at least something nice, where the static type system prevents stupid mistakes that function-level scoping makes possible. To be fair, all the serious type checkers for Python would catch this as well. But I hope you get the idea. Those are things I highly doubt would have made it into the language if Lattner could have designed it to his liking from scratch.
adev_ 3mo ago
> sorry for rambling. You're right to ramble. I also believe that the world need a high level language fitting for accelerators that is not Python. However developing something like that is by all means not a trivial task and many failed there.
- havercosine 3mo ago
  Though, Modular should have been the team to do it. My theory is that they raised too much money too soon. With that kind of money, you get anxious investors waiting to see some magic on quarterly timelines. So Modular was forced to be compatible with Python as there's no other way to win quick developer mindshare. (Though I don't think they managed to do that either). A closest counter path I would have expected Modular to follow was Zig or Oxide computers (I know not apples to apples comparision). Start actually attacking the problem with hindsight and lessons of 30 years of Python, build something fresh, and try to patiently win the market. Rust is not going to win this market. The language has too much syntax friction to win over data science/AI folks and doesn't offer too much in parallel programming world. Julia, although beautiful attempt, couldn't gather enough support outside academia. In fact, if Nvidia cuTile, Triton, Jax keep delivering, Python seems unmatched at the moment. It is likely to be in the similar position that C/C++ have been in embedded and firmware world.
  - adev_ 3mo ago
    > My theory is that they raised too much money too soon. That's also my feeling. And that's the curse of many VC funded companies. And they are not even in the classical state of enshitification yet. > Rust is not going to win this market. Agree. Rust will never win this market. Nor Zig, which has the same genetical flaws as C++ for accelerators (excessive usage of pointer semantics among others). > Julia, although beautiful attempt, couldn't gather enough support outside academia. I will look mean, but for me, Julia is a language that never went to the design board. It sticked to a "Let's put Python on top of LLVM and add a proper GC" with one single objective: "let's make a clone of Python but fast". My feeling is also that it is an academia niche and will remain one. > In fact, if Nvidia cuTile, Triton, Jax keep delivering, Python seems unmatched at the moment. It is, and it is honestly pretty depressing. Triton solves most of the performance issues of Python for accelerators but also introduces one (several on fact) more DSL, one more tooling ecosystem and solves none of the (long list of) issues related to Python/Numpy programming model.
khurs 3mo ago
Looked up Mojo "Mojo aims to combine the usability of a high-level programming language, specifically Python, with the performance of a system programming language such as C++, Rust, and Zig Mojo builds on the Multi-Level Intermediate Representation (MLIR) compiler software framework, instead of directly on the lower level LLVM compiler framework like many languages such as Julia, Swift, C++, and Rust.[16][17] MLIR is a newer compiler framework that allows Mojo to exploit higher level compiler passes unavailable in LLVM alone, and allows Mojo to compile down and target more than only central processing units (CPUs), including producing code that can run on graphics processing units (GPUs), Tensor Processing Units (TPUs), application-specific integrated circuits (ASICs) and other accelerators. It can also often more effectively use certain types of CPU optimizations directly, like single instruction, multiple data (SIMD) with minor intervention by a developer, as occurs in many other languages" https://en.wikipedia.org/wiki/Mojo_(programming_language) https://en.wikipedia.org/wiki/Mojo_(programming_language)
- teleforce 3mo ago
  >Mojo aims to combine the usability of a high-level programming language, specifically Python, with the performance of a system programming language such as C++, Rust, and Zig Providing usability without GC is an oxymoron. The best attempt so far for Pythonic compiled language is D, that's probably why it's not mentioned in the Wikipedia entry along side other languages comparison. D has GC by default but manual memory management is supported as well. Probably compiler researchers need to come with truly determinstic GC like the automotive industry invented the automatic gear. So that other existing compiled programming languages with GC like Go and D can thrive.
agreeablegoose 3mo ago
Disclaimer: I work for Modular. Just wanted to confirm that we're still open sourcing Mojo this year! And appreciate the nuanced feedback.

samuell 3mo ago

I'm actually mostly worried about the future of Mojo at this time. Though hopefully it will be fully released open source still, but I feel there are question marks around whether it will be a priority to continue to develop by Qualcomm, or if they are mainly interested in the AI compute stack? Time will tell I guess, but a lot feels to be up in the air.

samuell 3mo ago
Maybe Chris was a little unhappy about where Mojo ended up, and sees this as an opportunity to start anew on a properly designed language from scratch :D
- roflcopter69 3mo ago
  [flagged]
  - samuell 3mo ago
    No, this was pure speculation based on what seems like a popular view on where Mojo ended up, where the initial Python-focus don't seem to help it that much anymore.
    - roflcopter69 3mo ago
      I'm sorry, I read your message slightly wrong. Okay, makes sense to me.
    - throwawaygod 3mo ago
      But they changed their goal from being a python superset to pythonish language with great python interoperability. The only other thing they could've done differently is making the language not look like python superficially. I think chris achieved his goal of creating a language which takes full advantage of MLIR and also not repeating some of the mistakes made with swift's development.
    - augment_me 3mo ago
      Which is interesting given the Mojo blogs where they shit on the other pythonic eDSLs like Triton saying that it's a dead end
ainch 3mo ago
They've said that Mojo is still on track to be open-sourced this year, post-acquisition.
dagi3d 3mo ago
According to their website, yes it will be opensourced soon
mshockwave 3mo ago
indeed, open sourcing is only half (or even less) of the picture: who is driving the open source community and how it is driven (i.e. governing structure) are probably more important IMHO. There are countless of cases where an open source project is either killed by slow death, or dictated by a single entity. Chris's previous projects like LLVM and MLIR are fortunate enough to grow and thrive organically, and that takes years if not decades to cultivate

pjmlp 3mo ago

He already did that, Swift for Tensorflow, the project hardly survived one year after the public announcement.

adonese 3mo ago
I think that was the motivation to make Mojo a superset of python.
- pjmlp 3mo ago
  Yes, but apparently even that ended up being a pivot, with just enough Python, and now lets see what Qualcom makes out of it.
adev_ 3mo ago
> Swift for Tensorflow, the project hardly survived one year after the public announcement. This was doom to fail from the beginning. Swift will always have the image of an Apple product binded and controlled by the Apple ecosystem. This is very unlikely to change. Nobody sane of mind would bind there entire technology stack on something half proprietary with a support was from the beginning secondary outside of Apple platforms.

gugagore 3mo ago

To say nothing of "Swift for TensorFlow" when Julialang was an option. To each their own!

jdub 3mo ago

"first principles" and "from scratch" are predictable failure modes... he had very good reason to pursue a Python-like language given the circumstances and objectives

roflcopter69 3mo ago
I think I get what you mean and I should have been more precise in my wording. I didn't mean that an alien language that looks nothing like we have ever seen but for the sake of doing it "right" from scratch would have been a good idea. A new programming language definitely should steal the ideas of other languages that turned out to be good. But Mojo also adopted some of the arguably bad ideas from Python just because there was too much design pressure to appeal to Python programmers. I wonder what Mojo could have looked like without this particular pressure. Basically, with what kind of programming language would a person with as much experience and good taste as Chris Lattner come up with if there were no such external pressures?
- boxed 3mo ago
  > But Mojo also adopted some of the arguably bad ideas from Python Like what?
  - roflcopter69 3mo ago
    The "else" after a for-loop that executes only when the loop completely finished without a "break" or "return". While maybe a nice concept in general, using "else" for this is only to look familiar to Python programmers. The "else" word itself is really counter intuitive here in my opinion. For more, see https://mojolang.org/docs/manual/control-flow/#for-loop-control-statements https://mojolang.org/docs/manual/control-flow/#for-loop-cont... Then there's "foo if cond else bar" which is Python's kind of ternary operator and it's at least slightly contentious. One could argue if a language even needs such a construct, but at least for me, I have an easier time reading the control flow when I look at "cond ? foo : bar". It gets even worse when you nest that stuff, although that's something you shouldn't do anyway. For more, see https://mojolang.org/docs/manual/control-flow/#conditional-expressions https://mojolang.org/docs/manual/control-flow/#conditional-e... Also, indentation based syntax... well, it's a choice. I don't know if Lattner would have chose that in a language that he would have designed to his liking from scratch. For more, see https://mojolang.org/docs/reference/compound-statements/ https://mojolang.org/docs/reference/compound-statements/ Then there is some scoping related badness from Python that I think is really awful. In Python and Mojo (with a caveat) you can do this: if cond: foo = 42 print(foo) So the scope of a variable is function-level and Mojo adopted this and called it implicitly-declared variables (https://mojolang.org/docs/manual/variables/#implicitly-declared-variables https://mojolang.org/docs/manual/variables/#implicitly-decla...) as opposed to the concept of explicitly-declared variables (https://mojolang.org/docs/manual/variables/#implicitly-declared-variables https://mojolang.org/docs/manual/variables/#implicitly-decla...) they added on top which uses the "var" keyword and forces block-level scoping which I'd argue is the sane default. But no, to appease Python programmers, they have this awful function-level scoping by default and you have to opt into block-level scoping by adding a "var" in front of your variable declaration. But earlier, I was talking about a caveat in Mojo, so it's slightly less awful, because the compiler would complain in the code example above that "foo" might be uninitialized when getting to the print statement, so that's at least something nice, where the static type system prevents stupid mistakes that function-level scoping makes possible. To be fair, all the serious type checkers for Python would catch this as well. But I hope you get the idea. Those are things I highly doubt would have made it into the language if Lattner could have designed it to his liking from scratch.

adev_ 3mo ago

> sorry for rambling. You're right to ramble. I also believe that the world need a high level language fitting for accelerators that is not Python. However developing something like that is by all means not a trivial task and many failed there.

havercosine 3mo ago
Though, Modular should have been the team to do it. My theory is that they raised too much money too soon. With that kind of money, you get anxious investors waiting to see some magic on quarterly timelines. So Modular was forced to be compatible with Python as there's no other way to win quick developer mindshare. (Though I don't think they managed to do that either). A closest counter path I would have expected Modular to follow was Zig or Oxide computers (I know not apples to apples comparision). Start actually attacking the problem with hindsight and lessons of 30 years of Python, build something fresh, and try to patiently win the market. Rust is not going to win this market. The language has too much syntax friction to win over data science/AI folks and doesn't offer too much in parallel programming world. Julia, although beautiful attempt, couldn't gather enough support outside academia. In fact, if Nvidia cuTile, Triton, Jax keep delivering, Python seems unmatched at the moment. It is likely to be in the similar position that C/C++ have been in embedded and firmware world.
- adev_ 3mo ago
  > My theory is that they raised too much money too soon. That's also my feeling. And that's the curse of many VC funded companies. And they are not even in the classical state of enshitification yet. > Rust is not going to win this market. Agree. Rust will never win this market. Nor Zig, which has the same genetical flaws as C++ for accelerators (excessive usage of pointer semantics among others). > Julia, although beautiful attempt, couldn't gather enough support outside academia. I will look mean, but for me, Julia is a language that never went to the design board. It sticked to a "Let's put Python on top of LLVM and add a proper GC" with one single objective: "let's make a clone of Python but fast". My feeling is also that it is an academia niche and will remain one. > In fact, if Nvidia cuTile, Triton, Jax keep delivering, Python seems unmatched at the moment. It is, and it is honestly pretty depressing. Triton solves most of the performance issues of Python for accelerators but also introduces one (several on fact) more DSL, one more tooling ecosystem and solves none of the (long list of) issues related to Python/Numpy programming model.

khurs 3mo ago

Looked up Mojo "Mojo aims to combine the usability of a high-level programming language, specifically Python, with the performance of a system programming language such as C++, Rust, and Zig Mojo builds on the Multi-Level Intermediate Representation (MLIR) compiler software framework, instead of directly on the lower level LLVM compiler framework like many languages such as Julia, Swift, C++, and Rust.[16][17] MLIR is a newer compiler framework that allows Mojo to exploit higher level compiler passes unavailable in LLVM alone, and allows Mojo to compile down and target more than only central processing units (CPUs), including producing code that can run on graphics processing units (GPUs), Tensor Processing Units (TPUs), application-specific integrated circuits (ASICs) and other accelerators. It can also often more effectively use certain types of CPU optimizations directly, like single instruction, multiple data (SIMD) with minor intervention by a developer, as occurs in many other languages" https://en.wikipedia.org/wiki/Mojo_(programming_language) https://en.wikipedia.org/wiki/Mojo_(programming_language)

teleforce 3mo ago
>Mojo aims to combine the usability of a high-level programming language, specifically Python, with the performance of a system programming language such as C++, Rust, and Zig Providing usability without GC is an oxymoron. The best attempt so far for Pythonic compiled language is D, that's probably why it's not mentioned in the Wikipedia entry along side other languages comparison. D has GC by default but manual memory management is supported as well. Probably compiler researchers need to come with truly determinstic GC like the automotive industry invented the automatic gear. So that other existing compiled programming languages with GC like Go and D can thrive.

agreeablegoose 3mo ago

Disclaimer: I work for Modular. Just wanted to confirm that we're still open sourcing Mojo this year! And appreciate the nuanced feedback.