Live data from Hacker News

Mojo – a new programming language for AI developers

modular.com

241–250 of 272 posts

Re: Mojo – a new programming language for AI developers

#241
post #154
post #146

Hi Jeremy Howard here. I pop up in the launch video to demo super-fast matmul and mandelbrot in mojo. I'm pretty excited about this language, to say the least - not just for AI/ML, but for pretty much everything! Lemme know if you have any questions and I'll answer as best as I can. (I'm an advisor to Modulo.)

Are there plans to port any major existing Python libraries to pure mojo (mojo that will not use CPython)? Is there a plan for a general purpose matrix or tensor library like numpy or pytorch, but in pure mojo?

Open-cv would benefit tremendously by migrating to mojo.

Re: Mojo – a new programming language for AI developers

#243

Earlier quoted context omitted.

I guess their argument is the reason those things suck is because they are hooking in some c++ monstrosity (tensorflow) or making rpcs to an external daemon (redis, horovod). So rather than writing another Python wrapper over c++ they are making a new performant language that can call Python. To me it makes sense as torch is great and hard to compete with, but everything feeding into it is a mess today (Data loading,…

> a new performant language that can call Python don't forget the control layer/data layer separation principle. Performance mostly only matters at the data layer, and I don't believe that python ML really has a substantial problem with this, aside from not having a real distribution story. So "having a more performant python" doesn't really solve that much. I'll tell you what could make the control layer better. - n…

> control layer/data layer separation principle

Could you explain or give references to what you exactly mean by this? I've heard of separation of concerns, but is this a specific realization of that principle?

Re: Mojo – a new programming language for AI developers

#244
post #202
post #183

Earlier quoted context omitted.

Julia is doing quite well for such a young language, lets not forget how many decades it took for Python to actually matter beyond OS scripting. https://juliahub.com/case-studies/

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

Julia 1.0 was released in 2018. That is just 5 years ago. I would say that is very young. Especially since a language today needs more than in the past. Julia has package manager, virtual environments, version management. Stuff that tends to be bolted on much later.

You needed much less stuff supported out of the box when Python first came on the scene. Today expectations have gotten much bigger. A minimal viable language has far more requirements.

Re: Mojo – a new programming language for AI developers

#245

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…

>Python has amazing strengths as a glue layer, and low-level bindings to C and C++ allow building libraries in C, C++ and many other languages with better performance characteristics. This is what has enabled things like numpy, TensorFlow and PyTorch and a vast number of other libraries in the ecosystem. Unfortunately, while this approach is an effective way to building high performance Python libraries, its approach…

A clear complexity cost difficulty in extending these libraries. This separation force libraries to become huge complex monoliths. In Julia the equivalent is done with absolutely hilariously tiny libraries. In fact they are so small that many Python guys exploring Julia decide to not explore further thinking most of the Julia ML libraries aren't done or have barely started.

They are just not accustomed to seeing libraries being that small. That is possible in Julia because it is all native Julia code which means interfacing with other Julia code works seamless and allows you to mix and match many small libraries very easily. You can reuse much more functionality which means individual libraries can be kept very small.

For PyTorch and TensorFlow e.g. activation functions have to be coded specifically into each library. In Julia these can just be reused for any library. Each ML library doesn't need to reimplement activation functions.

That is why you get these bloated monoliths. They have to reinvent the wheel over and over again. So yeah there is a cost which is constantly paid.

Every time you need to extend these libraries with some functionality you are paying a much higher price than when you do the same with Julia.

Re: Mojo – a new programming language for AI developers

#246
post #93

Earlier quoted context omitted.

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.

This is not true at all! Julia usually being JIT-compiled makes it very unsuitable for real time applications (and there's no reason why it should be great for it). GC is the least issue here, and I say that as a fan and daily user of Julia.

That is not really true. People think that because they have spent time with Java which is excessively GC dependent. More modern GC languages such as Go and Julia have opted to use GCs in a far more conservative manner. They don't produce the exorbitant amount of garbage that Java produces. I've talked to NASA guys using Go for real time systems. They say it works great. GC doesn't need to be a problem if you do it right.

Re: Mojo – a new programming language for AI developers

#247

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…

Are there any plans on making linear algebra, numeric operations and so on first class citizens, the same way Julia does it? I believe that also a very compelling characteristic from Julia, for people working in Physics, Mathematics, Artificial Intelligence and Machine Learning is all the "sugar syntax" Julia gives you, is not the same translating a formula from a paper to numpy than translating it to Julia, in Julia writing the expression from a paper is almost a one-to-one mapping. I believe it will be a huge point in favor to Mojo, since UX when writing mathematical code in Julia is a huge advantage to it, the same way Python gained popularity as a General Purpose language because it is almost like writing plain English

Re: Mojo – a new programming language for AI developers

#248

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?

FAQ says they expect to open source it: https://docs.modular.com/mojo/faq.html#will-mojo-be-open-sou...

Re: Mojo – a new programming language for AI developers

#249

Earlier quoted context omitted.

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…

> Very strange to have no GC as a innovative feature for a modern programming language. It's because, first, there was manual memory management, which was error-prone. Then came garbage collection, which was safe but slow. Most recently came borrowing and move semantics, which offers the best of both worlds -- safety and speed -- at the cost of some (arguably justified) cognitive overhead and code flexibility.

Garbage collection isn't slow. good GC systems have similar overhead to malloc/free.
Post reply on HN