Comment by pca006132 | Hacker News Reader

Comment by pca006132 | Hacker News Reader

Parent Full thread

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.

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/

> 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.

> 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

> 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

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.

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.

Can you please list outrageous claims by V?

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

Not 3 years ago.

Here's the version of the website 3 years ago:

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/

> V manages memory at compilation time (like Rust). Right now only basic cases are handled. For others, manual memory management is required for now.

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.

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.

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.

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.

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.

> 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.

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.

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.

Reply on news.ycombinator.com