Mojo is a much better “Objective-C without the C” than Swift ever was

My access was approved within one hour.

It's really minor thing but a pet peeve of mine, I remember how twenty years ago every new language claimed to be as fast or faster than C, and every time the benchmark was some ultra-optimized non-idiomatic program in that new language against a naive C implementation, and the C version was usually still 20% faster and use 10% as much RAM with the right compile flags.

Are there even Mojo benchmark in the wild? The FAQ entry[1] just finds excuses for situations where it does not perform well...

[1] https://docs.modular.com/mojo/faq.html#performance

This is a self-fulfilling prophesy.

"Please don't comment about the voting on comments. It never does any good, and it makes boring reading." https://news.ycombinator.com/newsguidelines.html

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.

https://m.youtube.com/watch?v=pdJQ8iVTwj8

https://www.crunchbase.com/organization/modular-ai

Andrew Kelley predicts the future:

https://youtube.com/watch?v=YXrb-DqsBNU&t=22m17s

I think their strategy makes quite a bit of sense. Superficially Python like, can use Python libraries, fast and safe like Rust, automatically determines where algorithms should run (to some extent).

One thing that comes to mind however, is library performance. I'm assuming it will be ~3X faster than Python (like basic Python code) but if you are coming from Rust or C, this could be an issue.

Lattner is an open source fan, I believe it will be open sourced eventually, but maybe the early Swift development was traumatizing. Just a guess.

> we expect that Mojo will be open-sourced. […] We don’t have an established plan for open-sourcing yet.

But I'm not trusting "don't be evil" tag lines anymore.

So we'll see when they actually make something open enough that we can entrust our programming stacks to it.

Also the team behind the project includes very smart people with a history of delivering other great projects (LLVM, Clang, MLIR and Swift).

I don't see how discouraging other people for trying to innovate is helpful. In the end this project could benefit all of us.

I thought it was odd at first that they weren't letting me run it locally too, but if they control the compute environment then they can force push interpreter(?)/compiler updates and eliminate a lot of bug reports from folks that are just using an out of date build. Seems pretty reasonable to me for something that's so early in development.

There appears to be confusion here. Mojo is trying to align itself with and be a kind of superset of Python, like C++ was to C. It's also an alternative for Python users, to use it, instead of reaching for C++ or C when they need speed or going lower level. From their website, that's not what V devs ever claimed nor is it their angle for users. V is a different programming language (and compiled), which provides benefits such as greater speed, type safety, etc... in comparison to Python. It would be a switch over, not a superset.

V is more of an alternative to Go and then C (in terms of ease of use and greater safety). Mojo and V are mostly in different lanes, where they appeal to different audiences, and how they are marketing themselves has nothing to do with the other.

> Anyway, never gonna try it, unless I'm absolutely forced. I hate their marketing strategy, it sounds too bad

This comes across as weird, to claim one will never use or gives the impression to never have used the programming languages they are talking down on. If not using Mojo or V, why be so preoccupied? Just skip over to what one does like and not be worried.

> ...hate their marketing strategy

Just about all programming languages attempt to sell themselves to the public. If they don't, people don't hear about them, and they die in obscurity.

And a lot of times, people are allowing themselves to be brainwashed by what big corporations have to sell, because they have big budgets for marketing. People often like, what big companies told them to, because of their infomercials and marketing campaigns. Sometimes, it can be good or at least fair to give alternatives a shot.

On the front page of their website, they claim to have full compatibility with python code, an ownership model and a borrow checker, and being as fast or faster than C++. These are just some of the first things I noticed!

Apparently one of the people involved with the creation of this language have some credibility which is pretty confusing. They are the CEO of the company behind "mojo" as well.

I think this is going to be another V-lang situation personally, despite the credibility of Lattner. I think this is just someone seeing an opportunity to cash in on the "AI hype" situation that exists currently.

Even reputable people can be influenced to do shady things when lots of money is involved!

This is of course just my opinion and I wouldn't mind being proven wrong, but I'm definitely very skeptical right now!

It compiles to llvm. This means the python environment headaches will disappear.

Huh? Swift interop with C is basically painless (it has to be, because all C code is ObjC code, so without C interop there is no ObjC interop).

"without the C"... ;-)

And of course it's not really "seamless inter with C", because Objective-C just is C, or more specifically a superset of C. It's sort of "interop with yourself". Of course, most Objective-C programmers do treat C as a distinct language, and one that they won't touch. Which is interesting.

And you are right, the article wasn't really about whether it is a better language overall, particularly not from the grass root user perspective.

It was about the specific aspect of being an "Objective-C without the C".

Which, of course, is just Smalltalk when taken literally. But if you just use Smalltalk, you lose Objective-C's capability of going really fast as well (and the interop).

Of course using Python instead of Smalltalk as the base is sad, but it is understandable given the market that they're going for.

RE objects, I guess they are referring to Smalltalk-style objects. Objective-C has them while Swift has a somewhat different flavor of objects. This author seems to consider that a regression of sorts.

RE the connection and component languages — your “white collar” and “blue collar” languages (BTW, I like your terminology, so I’ll use it), I think they are making the point that Objective-C started with a blue collar language, C, and extended it with while collar language features (derived from smalltalk), while Mojo started with a white collar language, Python, and are extending it with blue collar features. The author likes the Mojo approach, though doesn’t really explain that. I think they are claiming Swift is somehow more aligned with the blue collar side than Objective-C and feel that’s bad, but it’s too vague to really mean anything.

(I think the idea with Swift and some other newer languages is that you can have a single language that is good at both white collar and blue collar things and “native” to both. I don’t think Swift has quite pulled it off, but it’s still evolving, so we’ll see.)

With Objective-C, they started with the "blue collar" language (C) as the base language, and added in "white collar" language features (Smalltalk), to achieve a language where you could switch between blue collar and white collar programming without switching languages.

Mojo starts with the white collar language (Python) and adds blue collar language features to it (the Mojo additions that allow you to control the memory layout and execution at a lower level).

That's really all the article is saying.

Nope.

The analogy you came up with is interesting, but although there is some overlap, it doesn't really capture the distinction and is the reason why you're not understanding the bit I wrote about connection languages and component languages.

You can have a component language that is just as "white collar" as the connection language. And you can (probably) have a connection language that is quite blue collar, although that might be a bit harder.

The reason I find your analogy interesting is that despite actually not capturing what is there, it does seem to capture how many people (erroneously) view and use the distinction between connection and component languages.

Objective-C added Smalltalk as a connection language, a language for plugging together the Software ICs you would write in C. See, for example https://blog.metaobject.com/2019/01/swifter-sieving-of-prime... It did not add Smalltalk as a "white collar" language that didn't need to get its hands dirty, and it didn't have the facilities to do that. Over time, people discovered that the connection language was in many ways more convenient to use, and so did what you describe, use it as a "higher level", more "white collar" language. But once again, that was an abuse of the language, it wasn't made for that and, due to not being made for it, it wasn't very good at it. Even after they added some facilities to make that use-case more possible.

I agree, though. I don’t see much basis for comparison.

https://youtu.be/pdJQ8iVTwj8

To be clear, I didn't spend too much time examining this, so I might be way off. Grafting types onto a language doesn't interest me.

So it makes sense that it's not open, and you can only use it via their notebook. It probably doesn't work on normal hardware + Linux. That's the monetization strategy. You have to run their system and pay for it.

At the end of the day, mojo is very very early, not even open source yet.

Furthermore, mojos success will be largely bound to modulars success, which is a VC backed company. A decent looking one but still that means it's more likely to fail fast than succeed slowly.

> Mojo is a general purpose language and can be used to replace C use cases like Rust does etc, but that isn't where we're focusing initial development. That doesn't mean we're excluding it, just that the libraries etc aren't the focus for us to build. We hope the community will be interested in filling that in and building out the use cases in time though.

https://github.com/modularml/mojo/discussions/302#discussion...

Maybe it's true, maybe it isn't. But who do you think has a vested interest in that meme being repeated? Mojo is a commercial, closed source language implementation backed by $30M of investor cash looking to turn a profit.

I wish them luck and watch with interest. Like a lot of people I've had "write a very fast Python and ??? and profit" on my todo list for a while (it remains below "job to pay the bills" though) because there's been obvious user interest for some years, although it's not clear if that translates to much commercial demand. I think if they are successful and if they remain closed source, an open source clone will appear soon after, and within a year or two will match or outperform them on reported performance, but they will still have a business for the same sorts of reasons Red Hat remains profitable.

Whether it is or not, that was Apple’s own language when they announced it.

Still I do like the idea of "scalable" languages. Nim accomplishes this largely by making programming the "low level" mostly as simple as programming in the large. To be fair Nim doesn't offer too much special for "component programming" like Obj-C's aside from basic objects. Though one could argue making good DSL's is certainly a superpower and benefits component programming.

Mojo is aiming to be a state of the art systems language that has Python embedded seemlessly. It's exactly the other way around from numba/Cython which embedd compiled C in performance silos inside Python.

I used to do heavy numba work and this has no relationship to that. Just look at what the devs are actually targeting/implementing right now: Better lifetime/ownership semantics and ergonomics.

This is not in the same universe as numba (or even Julia).

I think it's far too early to tell whether it will be good, but I haven't seen any other approach that resembles it.

That being said, I wouldn't describe it as 'open' at the moment. It's more just that you can verify any claims they make.

if you took the c out of objective-c you basically have smalltalk but you still might need c-ish level expressions to get better performance

the expectation from swift then, was that you'd start out with that high-level paradigm and then provide lower level constructs only when needed for performance or other reasons, but the reality is you start off closer to a really well-designed and clean c++ (structs, classes, enums, generics) that adds higher level features (actors, async, etc) when you need it than something that starts off high-level as smalltalk or python from the get-go

the reason the author likes mojo more in that respect then is because it starts with the high-level constructs (python) as the substrate and allows for tuning where needed... the presupposition i think is that will lead to higher productivity and simpler code in the long run (this is my interpretation)