Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mojo 1.0 Beta

mojolang.org

Post reply on HN
Print view View original

81–90 of 252 posts

Re: Mojo 1.0 Beta

#81

Post by pjmlp »

melodyogonna wrote: post #80
pjmlp wrote: post #69

Earlier quoted context omitted.

Indeed, but Intel and AMD are also upping their Python JIT game, and in the end Mojo code isn't portable anyway. You always need to touch the hardware/platform APIs at some level, because even if the same code executes the same, the observed performance, or in the case of GPUs the numeric accuracy has visible side effects.

It is portable in that you can write code to target multiple platforms in the same codebase. Mojo has powerful compile-time metaprogramming that allows you to tell the compiler how to specialise using a compile-time conditional, e.g. https://github.com/modular/modular/blob/9b9fc007378f16148cfa... Of course, this won't be necessary in most cases if you're building on top of abstractions provided by Modular. You don't…

Yes you do, you get PyTorch or whatever else, built on top of those vendor-specific libraries.

That is the thing with Mojo, when it arrives as 1.0, the LLM progress and the investment that is being done in GPU JITs for Python, make it largely irrelevant for large scale adoption.

Sure some customers might stay around, and keep Modular going, the gold question is how many.

Re: Mojo 1.0 Beta

#82

Post by Certhas »

pjmlp wrote: post #67
Certhas wrote: post #53

Earlier quoted context omitted.

If you paid very close attention it was actually clear from the start that the idea was to build a next gen systems language, taking the lessons from Swift and Rust, targeting CPU/GPU/Heterogeneous targets, and building around MLIR. But then also building it with an eye towards eventually embedding/extending Python relatively easily. The Python framing almost certainly helped raise money. Chris Lattner talked more ab…

So basically Chapel, which is actually being used in HPC.

I don't know Chapel in detail, I was more thinking Hylo. I don't think Chapel has a clear value/reference semantics or ownership/lifetime story? Am I wrong here?

The Mojo docs include two sections dedicated to these topics:

https://mojolang.org/docs/manual/values/

https://mojolang.org/docs/manual/lifecycle/

The metaprogramming story seems to take inspiration from Zig, but the way comptime, parameters and ownership blend in Mojo seems relatively novel to me (as a spectator/layman):

https://mojolang.org/docs/manual/metaprogramming/

I was sort of paying attention to all these ideas and concepts two-three years ago from the sidelines (partially with the idea to learn how Julia could potentially evolve) but it's far from my area of expertise, I might well be getting stuff wrong.

Re: Mojo 1.0 Beta

#83

Post by pjmlp »

Certhas wrote: post #82
pjmlp wrote: post #67

Earlier quoted context omitted.

So basically Chapel, which is actually being used in HPC.

I don't know Chapel in detail, I was more thinking Hylo. I don't think Chapel has a clear value/reference semantics or ownership/lifetime story? Am I wrong here? The Mojo docs include two sections dedicated to these topics: https://mojolang.org/docs/manual/values/ https://mojolang.org/docs/manual/lifecycle/ The metaprogramming story seems to take inspiration from Zig, but the way comptime, parameters and ownership bl…

You make use of 'owned', 'shared', 'unmanaged', 'borrowed'.

https://chapel-lang.org/docs/language/spec/classes.html#clas...

Re: Mojo 1.0 Beta

#84

Post by Certhas »

pjmlp wrote: post #83
Certhas wrote: post #82

Earlier quoted context omitted.

I don't know Chapel in detail, I was more thinking Hylo. I don't think Chapel has a clear value/reference semantics or ownership/lifetime story? Am I wrong here? The Mojo docs include two sections dedicated to these topics: https://mojolang.org/docs/manual/values/ https://mojolang.org/docs/manual/lifecycle/ The metaprogramming story seems to take inspiration from Zig, but the way comptime, parameters and ownership bl…

You make use of 'owned', 'shared', 'unmanaged', 'borrowed'. https://chapel-lang.org/docs/language/spec/classes.html#clas...

I see, seems like the design is not complete and a work in progress (which is the same for Mojos Origins concept I think):

"The details of lifetime checking are not yet finalized or specified. Additional syntax to specify the lifetimes of function returns will probably be needed."

I think Rust proved that lifetimes, ownership and borrow checking can be useful for a mainstream language. The discussions in the Mojo context revolve on how to improve the ergonomics of these versus Rust.

Re: Mojo 1.0 Beta

#85

Post by kibwen »

pjmlp wrote: post #72
kstrauser wrote: post #29

Earlier quoted context omitted.

I’ve written Python for the past 25 years or so. I dig it. But I don’t think I’ve started a new Python project since starting to experiment with Rust. A lot (not all!, but a lot ) of Rust patterns look a lot like Python if you squint at it just right. I also think that writing lots of Rust has made me better at writing Python. The things Rust won’t let you get away with are things you shouldn’t be doing almost anywhe…

I can't go get coffee so many times per day, there are better compiled languages to chose from, while offering Python like ergonomics.

I can only go get coffee waiting for my Python test suite to finish so many times per day. I write Rust because the strict type system accelerates the iteration speed for producing correct code more than any other language in its class.

Re: Mojo 1.0 Beta

#86

Post by pjmlp »

kibwen wrote: post #85
pjmlp wrote: post #72

Earlier quoted context omitted.

I can't go get coffee so many times per day, there are better compiled languages to chose from, while offering Python like ergonomics.

I can only go get coffee waiting for my Python test suite to finish so many times per day. I write Rust because the strict type system accelerates the iteration speed for producing correct code more than any other language in its class.

Which is why the solution is to pick neither, rather something with Python like productivity and a mix of JIT/AOT tooling.

Some alternatives are as old as 1958.

Re: Mojo 1.0 Beta

#87

Post by adev_ »

pjmlp wrote: post #66

Julia is more mature for the same purposes, and since last year NVidia is having feature parity between Python and C++ tooling on CUDA. Python cuTile JIT compiler allows writing CUDA kernels in straight Python. AMD and Intel are following up with similar approaches. If Mojo will still arrive on time to gain wider adoption remains to be seen.

> Python cuTile JIT compiler allows writing CUDA kernels in straight Python.

It is currently not straight Python and will never be.

All these "Performance friendly" python dialects (Tryton, Pythran, CuTile, Numba, Pycell, cuPy, ...) appears like Python but are nothing like Python as soon as you scratch the surface.

They are DSL with a python-looking syntax but made to be optimized, typed and inferred properly. And it feels like it when you use it: in each of them, there is many (most?) python features you simply can not use while you still suffer of inherent python issues.

Lets not lie to ourself: Python is inherently bad for efficiency and performance.

And that goes way beyond the GIL: dynamic typing, reference semantics, monkey patching, ultra-dynamic object model, CPython ABI, BigInt by default, runtime module system, ... are all technical choices that makes sense for a small scripting language but terribly sucks for HPC and efficiency.

The entire Numpy/scipy ecosystem itself is already just a hack around Python limitations for simple CPU bound tensor arithmetics. Mainly because builtin python performance sucks so much that a simple for loop would make Excel looks like a race horse.

Mojo is different.

Mojo tries to start from a clean sheet instead of hacking the existing crap.

And tries to provide a "Python like experience" but on top of a well designed language constructed over past language design experience (Python is >30y old)

And just for that, I wish them success.

Re: Mojo 1.0 Beta

#88

Post by pjmlp »

Certhas wrote: post #84
pjmlp wrote: post #83

Earlier quoted context omitted.

You make use of 'owned', 'shared', 'unmanaged', 'borrowed'. https://chapel-lang.org/docs/language/spec/classes.html#clas...

I see, seems like the design is not complete and a work in progress (which is the same for Mojos Origins concept I think): "The details of lifetime checking are not yet finalized or specified. Additional syntax to specify the lifetimes of function returns will probably be needed." I think Rust proved that lifetimes, ownership and borrow checking can be useful for a mainstream language. The discussions in the Mojo con…

Contrary to Mojo, plenty of people are using it in HPC, and is open source.

https://hpsf.io/blog/2026/hpsf-project-communities-to-gather...

https://developer.hpe.com/platform/chapel/home

See "Projects Powered by Chapel".

Re: Mojo 1.0 Beta

#89

Post by pjmlp »

adev_ wrote: post #87
pjmlp wrote: post #66

Julia is more mature for the same purposes, and since last year NVidia is having feature parity between Python and C++ tooling on CUDA. Python cuTile JIT compiler allows writing CUDA kernels in straight Python. AMD and Intel are following up with similar approaches. If Mojo will still arrive on time to gain wider adoption remains to be seen.

> Python cuTile JIT compiler allows writing CUDA kernels in straight Python. It is currently not straight Python and will never be. All these "Performance friendly" python dialects (Tryton, Pythran, CuTile, Numba, Pycell, cuPy, ...) appears like Python but are nothing like Python as soon as you scratch the surface. They are DSL with a python-looking syntax but made to be optimized, typed and inferred properly. And it…

I love when dialects for C and C++ count as being proper C and C++, are even argued as being more relevant than ISO standards by themselves, but anyone else that does the same, it is no longer the same language.

As for Python not being the ideal, there we agree, but the solutions with proper performance already exist, Lisp, Scheme, Julia, Futhark,...

Heck maybe someone could dig out StarLisp.

Re: Mojo 1.0 Beta

#90

Post by Certhas »

pjmlp wrote: post #88
Certhas wrote: post #84

Earlier quoted context omitted.

I see, seems like the design is not complete and a work in progress (which is the same for Mojos Origins concept I think): "The details of lifetime checking are not yet finalized or specified. Additional syntax to specify the lifetimes of function returns will probably be needed." I think Rust proved that lifetimes, ownership and borrow checking can be useful for a mainstream language. The discussions in the Mojo con…

Contrary to Mojo, plenty of people are using it in HPC, and is open source. https://hpsf.io/blog/2026/hpsf-project-communities-to-gather... https://developer.hpe.com/platform/chapel/home See "Projects Powered by Chapel".

So? What point are you making? A different language with different design philosophy, has success in a different niche than Mojo is targeting?
Post reply on HN