5 ms·

Because the claim is not as outrageous as V did? V claimed to solve the memory management problem automatically without a VM, which no one knows how to solve...

Because the claim is not as outrageous as V did? V claimed to solve the memory management problem automatically without a VM, which no one knows how to solve... Mojo seems to have a strategy similar to Rust, which requires user annotation and we know that this is sufficient in the majority of cases, so I don't think this is something seemingly impossible. Of cause, whether or not this is as easy to use as Python is debatable... For performance, if the compiler backend performs enough optimization, the code is run natively without any VM, the performance can be same or better than C (as some language features may provide more optimization opportunities). At the end of the day, C programs are compiled into some IR code and optimized by the backend as well, so the frontend language is more about balancing limitation for optimization and expressiveness. I do feel a bit uncomfortable about their marketing strategy, which compares a simple implementation against one with SIMD and parallelization... I think the real win here is simpler SIMD/parallel programming comparing with C/C++, instead of the language itself being faster.

Certhas 3y ago
It looks like the Mojo work in parts grew out of MLIR and Lattner has repeatedly stated that he wants less compiler magic and more control in the hands of the programmer (indeed MLIR, which Clang might also move to [1], is directly exposed in Mojo). "Faster than C" is a lot more plausible for Mojo than the claim of running arbitrary Python code eventually ;) [1] https://llvm.github.io/clangir/ https://llvm.github.io/clangir/
- pca006132 3y ago
  > he wants less compiler magic and more control in the hands of the programmer Indeed, I can see this from their emphasis on generic SIMD, which looks pretty nice. It is nice that there is now a language with first-class SIMD support, comparing with something implemented with a library or autovectorization which may not work. > "Faster than C" is a lot more plausible for Mojo than the claim of running arbitrary Python code eventually ;) Seems so. I don't recall reading the claim about running arbitrary Python code, and I think requiring rewriting Python code is reasonable as normal Python code may utilize runtime reflection/dynamic type and they are hard to implement efficiently, and probably require a GC for memory management.
  - Certhas 3y ago
    > I don't recall reading the claim about running arbitrary Python code The term superset of Python kind of implies this I think. Beyond the runtime reflection, Python also has eval.... :D
  - Someone 3y ago
    > It is nice that there is now a language with first-class SIMD support, comparing with something implemented with a library If the language is flexible enough (in particular, it has to support operator overloading), I don’t see any disadvantages to implementing that in a library. See for example https://developer.apple.com/documentation/swift/simd https://developer.apple.com/documentation/swift/simd
MatthiasPortzel 3y ago
> Mojo seems to have a strategy similar to Rust, which requires user annotation Except that it also claims to be a superset of Python. That is, you can use it to run any Python program without changes. So explain to me how it’s faster than C while also literally being Python. That’s more outrageous than V.
- celeritascelery 3y ago
  It’s a superset. You can run regular python, and that won’t be faster than C. But you can also write mojo functions (using “fn” instead of “def”) and those have stricter requirements and more user annotations but also more optimization potential. Mojo function could be faster than C, buts it’s not free.
- pca006132 3y ago
  I guess it is what the other comment mentioned: > what they've actually got at the moment is two languages glued together, where one of the languages will "unlock performance" and the other language is literally the CPython interpreter.
ptx 3y ago
Although not as outrageous as V, I do find the Mojo claims a little misleading. On the main page of the website, they claim it lets you "Write everything in one language" and "Unlock Python performance" – but what they've actually got at the moment is two languages glued together, where one of the languages will "unlock performance" and the other language is literally the CPython interpreter.
- amedvednikov 3y ago
  Can you please list outrageous claims by V?
- Tozen 3y ago
  Didn't Mojo just come out? What Mojo will become in regards to Python, remains to be seen. This will likely take them years. Passing judgment on the project so early, is obviously premature. > Although not as outrageous as V... Comes across as adding drama. Like arguing with one guy, then slapping another who wasn't involved, thinking it will be funny or because one might get away with it.
mr_00ff00 3y ago
So the classic question, if Mojo does not have a GC and does similar Rust-like memory management, is it a systems language? I know it was made for AI, but could it be a rival to rust/C++ in general? Seems like it could replace either of those.
- pca006132 3y ago
  It seems that this language is deeply integrated with CPython, so I doubt if it can be used as a low level language alone. If yes, they probably need to disable a bunch of things. Also, it is still WIP so I am not sure how things like type works in this language, whether or not it support parameterized lifetime, reference counted objects, union type, closure, etc. Currently, they seems to be focusing on numerical applications, targeting the AI crowd, so it is uncertain how things will go later.
amedvednikov 3y ago
V claims to take care of most objects (~90-100%) and uses GC for the stuff it can't figure out during compilation. This is very clearly explained on the website: https://vlang.io/#memory https://vlang.io/#memory
- pca006132 3y ago
  Not 3 years ago.
  - amedvednikov 3y ago
    Here's the version of the website 3 years ago: https://web.archive.org/web/20200629153446/https://vlang.io/ https://web.archive.org/web/20200629153446/https://vlang.io/ Can you point to that claim? Here's 4 years ago: https://web.archive.org/web/20190828170427/https://vlang.io/ https://web.archive.org/web/20190828170427/https://vlang.io/ > V manages memory at compilation time (like Rust). Right now only basic cases are handled. For others, manual memory management is required for now.
    - pca006132 3y ago
      https://web.archive.org/web/20200703221450/https://github.com/vlang/v/blob/master/doc/docs.md#memory-management https://web.archive.org/web/20200703221450/https://github.co... > V doesn't use garbage collection or reference counting. The compiler cleans everything up during compilation. If your V program compiles, it's guaranteed that it's going to be leak free.
      - amedvednikov 3y ago
        Yeah, this docs section was not synchronized with the landing page, and had bad wording. It says "work in progress", meaning that's something that's planned/being investigated. This was later worded better. But I agree, the docs should have never had such wording.
      - Tozen 3y ago
        Plus we are talking about a free open-source project, that's more of a grassroots effort, that didn't start as a corporate plan and creation. There are others contributing and writing documentation (and they aren't all English experts). Mistakes will happen and changes are allowed (many for the good). The language is not 1.0 yet, so should be allowed and will evolve/change over time (as other languages before it). People are also free to join the project or directly make helpful suggestions. That's part of the point of open-source.

Certhas 3y ago

It looks like the Mojo work in parts grew out of MLIR and Lattner has repeatedly stated that he wants less compiler magic and more control in the hands of the programmer (indeed MLIR, which Clang might also move to [1], is directly exposed in Mojo). "Faster than C" is a lot more plausible for Mojo than the claim of running arbitrary Python code eventually ;) [1] https://llvm.github.io/clangir/ https://llvm.github.io/clangir/

pca006132 3y ago
> he wants less compiler magic and more control in the hands of the programmer Indeed, I can see this from their emphasis on generic SIMD, which looks pretty nice. It is nice that there is now a language with first-class SIMD support, comparing with something implemented with a library or autovectorization which may not work. > "Faster than C" is a lot more plausible for Mojo than the claim of running arbitrary Python code eventually ;) Seems so. I don't recall reading the claim about running arbitrary Python code, and I think requiring rewriting Python code is reasonable as normal Python code may utilize runtime reflection/dynamic type and they are hard to implement efficiently, and probably require a GC for memory management.
- Certhas 3y ago
  > I don't recall reading the claim about running arbitrary Python code The term superset of Python kind of implies this I think. Beyond the runtime reflection, Python also has eval.... :D
- Someone 3y ago
  > It is nice that there is now a language with first-class SIMD support, comparing with something implemented with a library If the language is flexible enough (in particular, it has to support operator overloading), I don’t see any disadvantages to implementing that in a library. See for example https://developer.apple.com/documentation/swift/simd https://developer.apple.com/documentation/swift/simd

MatthiasPortzel 3y ago

> Mojo seems to have a strategy similar to Rust, which requires user annotation Except that it also claims to be a superset of Python. That is, you can use it to run any Python program without changes. So explain to me how it’s faster than C while also literally being Python. That’s more outrageous than V.

celeritascelery 3y ago
It’s a superset. You can run regular python, and that won’t be faster than C. But you can also write mojo functions (using “fn” instead of “def”) and those have stricter requirements and more user annotations but also more optimization potential. Mojo function could be faster than C, buts it’s not free.
pca006132 3y ago
I guess it is what the other comment mentioned: > what they've actually got at the moment is two languages glued together, where one of the languages will "unlock performance" and the other language is literally the CPython interpreter.

ptx 3y ago

Although not as outrageous as V, I do find the Mojo claims a little misleading. On the main page of the website, they claim it lets you "Write everything in one language" and "Unlock Python performance" – but what they've actually got at the moment is two languages glued together, where one of the languages will "unlock performance" and the other language is literally the CPython interpreter.

amedvednikov 3y ago
Can you please list outrageous claims by V?
Tozen 3y ago
Didn't Mojo just come out? What Mojo will become in regards to Python, remains to be seen. This will likely take them years. Passing judgment on the project so early, is obviously premature. > Although not as outrageous as V... Comes across as adding drama. Like arguing with one guy, then slapping another who wasn't involved, thinking it will be funny or because one might get away with it.

mr_00ff00 3y ago

So the classic question, if Mojo does not have a GC and does similar Rust-like memory management, is it a systems language? I know it was made for AI, but could it be a rival to rust/C++ in general? Seems like it could replace either of those.

pca006132 3y ago
It seems that this language is deeply integrated with CPython, so I doubt if it can be used as a low level language alone. If yes, they probably need to disable a bunch of things. Also, it is still WIP so I am not sure how things like type works in this language, whether or not it support parameterized lifetime, reference counted objects, union type, closure, etc. Currently, they seems to be focusing on numerical applications, targeting the AI crowd, so it is uncertain how things will go later.

amedvednikov 3y ago

V claims to take care of most objects (~90-100%) and uses GC for the stuff it can't figure out during compilation. This is very clearly explained on the website: https://vlang.io/#memory https://vlang.io/#memory

pca006132 3y ago
Not 3 years ago.
- amedvednikov 3y ago
  Here's the version of the website 3 years ago: https://web.archive.org/web/20200629153446/https://vlang.io/ https://web.archive.org/web/20200629153446/https://vlang.io/ Can you point to that claim? Here's 4 years ago: https://web.archive.org/web/20190828170427/https://vlang.io/ https://web.archive.org/web/20190828170427/https://vlang.io/ > V manages memory at compilation time (like Rust). Right now only basic cases are handled. For others, manual memory management is required for now.
  - pca006132 3y ago
    https://web.archive.org/web/20200703221450/https://github.com/vlang/v/blob/master/doc/docs.md#memory-management https://web.archive.org/web/20200703221450/https://github.co... > V doesn't use garbage collection or reference counting. The compiler cleans everything up during compilation. If your V program compiles, it's guaranteed that it's going to be leak free.
    - amedvednikov 3y ago
      Yeah, this docs section was not synchronized with the landing page, and had bad wording. It says "work in progress", meaning that's something that's planned/being investigated. This was later worded better. But I agree, the docs should have never had such wording.
    - Tozen 3y ago
      Plus we are talking about a free open-source project, that's more of a grassroots effort, that didn't start as a corporate plan and creation. There are others contributing and writing documentation (and they aren't all English experts). Mistakes will happen and changes are allowed (many for the good). The language is not 1.0 yet, so should be allowed and will evolve/change over time (as other languages before it). People are also free to join the project or directly make helpful suggestions. That's part of the point of open-source.