Live data from Hacker News

Mojo – a new programming language for AI developers

modular.com

211–220 of 272 posts

Re: Mojo – a new programming language for AI developers

#211

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 Mojo also has a bunch of technical a…

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

Re: Mojo – a new programming language for AI developers

#212
post #166
post #2

Well, I'm blown away. If this succeeds, it will allow you to use Python for the entire AI stack: high-level model composition (as usual), fast compiled CPU code (instead of, say, libs written with C++), and on-device operations (instead of, say, libs that use CUDA). Oh, and it will make your Python code parallel (i.e., there's no GIL). Obviously, we'll have to wait until Mojo is production-ready, but I'm excited afte…

> Jeremy, who sometimes hangs out on HN, must have been dying to tell the world about this for a long while Oh yes!

:-)

Re: Mojo – a new programming language for AI developers

#214
post #204
post #202

Earlier quoted context omitted.

Can 11 years old still be considered young for a programming language?

Yes, Python is 32 years old by now, and the first 10 years was largely ignored, I bet most don't even remember Zope.

So what is the cut off? At what age is a language no longer "young"? 15 years? 20?

Re: Mojo – a new programming language for AI developers

#215
post #93
post #76

Earlier quoted context omitted.

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

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.

I have wanted deterministic timing in Julia for years. It's come up periodically in the forums.

That, and optimized static binaries, would make Julia truly general purpose.

I don't mind Python syntax, I hope Mojo lives up to all these claims...it could easily (and finally!) hit the sweet spot of C performance, elegance, and expressiveness!

Re: Mojo – a new programming language for AI developers

#216

Is this usable as a general purpose language, or is it too tailored to AI/ML tasks and thus missing a lot of 'general' libraries and such? How does performance compare to Python in the general case, when not dropping into tricks? Either way, kudos, exciting stuff, just questions I had after reading about it.

Yeah, obviously curious if a fastapi port could be written in mojo

Re: Mojo – a new programming language for AI developers

#217
Wow. Could someone do this for Typescript/JavaScript?

Like the language is full interop with the existing JS ecosystem, but if I opt into certain restrictions (and run on some novel runtime), I get an insta-performance boost?

Personally wonder if the Typescript team themselves could drive this short of evolution, albeit I know that lately they're very committed to being "just types" and nothing that affects runtime. Which I get.

Re: Mojo – a new programming language for AI developers

#218
post #48

Are you afraid that you're going to "inherit" the issues the python ecosystem has through your goal of full compatibility? Or is Mojo more like Numba, in that only parts of python will actually be supported for full acceleration? At least your docs[1] seem to say so.. -- [1]: https://docs.modular.com/mojo/why-mojo.html#intentional-diff...

Agreed. I think this effort is completely missing the real pain points that ML suffers from. While python the language is easy, and in many ways great for its original purpose as a teaching language, I'll take note of the few ways that Python ML suffers: - pip hell. Really, having globally installed dependencies was great for the 90s and is terrible now that disk space is more or less a non-issue relative to dependen…

It might make the issues worse, actually, if you end up with a language that promises full support for python as a subset, but indefinitely doesn't actually do that, and is nevertheless encouraging people to import python libraries. Then it's like a wrapper around a wrapper around a dependency tangle...

This post has me interested in mojo a lot and it has a lot of potential but it's difficult for me to get too excited about it at the moment because so much of it doesn't actually exist at the moment. Nothing is open sourced yet, and from the docs it seems they don't even have classes implemented.

My experience with new languages is that the devil is often in the details and the stuff that gets put off is sometimes where the sticking points are, where performance starts to decline relative to other languages, and where you start to run into dependency hell. It's not so much I want mojo to fail or anything — the contrary in fact — but it's so hard to know where it will end up this early in its development.

Re: Mojo – a new programming language for AI developers

#219

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 Mojo also has a bunch of technical a…

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 te…

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.
Post reply on HN