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

91–100 of 252 posts

Re: Mojo 1.0 Beta

#91

Post by kstrauser »

smartmic wrote: post #36

Advertising prominently with "AI native" seems necessary today, at least for some folks. To me, that's kind of off-putting, since it doesn't really say anything. Can anyone of the AI enthusiasts here explain, why, or, what is meant by > As a compiled, statically-typed language, it's also ideal for agentic programming.

It’s the new “…on the blockchain”.

Python+ruff+pycheck and TypeScript are compiled to bytecode instead of machine code. They’re not statically typed in the Rust sense. And yet, I’ve watched model crank out good, valid in both of those without needing to be either strictly “compiled” or “statically typed”. Turns out AI couldn’t care less about those properties as long as you have good tooling to quickly check the code and iterate.

Re: Mojo 1.0 Beta

#92

Post by adev_ »

pjmlp wrote: post #89
adev_ wrote: post #87

Earlier quoted context omitted.

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

> 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

I did not argue about CUDA being proper C++ :)

I honestly believe that the best days of C++ as an accelerator language are behind.

That is the main problem currently: We do miss a modern language for system programming that play well with accelerators. C++ is not (really) one of them (Hello aliasing).

I do not know if Mojo will succeed there, but I wish them good luck.

Re: Mojo 1.0 Beta

#93

Post by kstrauser »

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…

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

Which is the whole point. Python has properties that make it bad for massive, fast number twiddling. However, it’s exceptionally nice for doing all the command line parsing and file loading and setup and other wrapping tasks required to run those pipelines.

Fortran’s fantastic at math stuff. I’d sure hate to have to write all the related non-math stuff in it.

And yes, Python’s slower than other languages. But in production, most Python code spends a huge chunk of its time waiting for other code to execute. It takes more CPU for Python to parse an HTTP request or load data files than an AOT language would take, but it’s as efficient sitting there twiddling its thumbs waiting for a DB query or numeric library to finish.

Re: Mojo 1.0 Beta

#94

Post by kstrauser »

frizlab wrote: post #37
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…

If you’re searching for a language that has the same strong memory safety than rust but is a bit easier to write, you should give Swift a go.

Good call. It’s not the first language I think of for most things but there’s no great reason why not to. I probably reach for Rust first because I’m more familiar with it and the projects I want to work on were already written in it.

Re: Mojo 1.0 Beta

#95

Post by pjmlp »

Certhas wrote: post #90
pjmlp wrote: post #88

Earlier quoted context omitted.

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?

One is used in production already by key laboratories in HPC research, the other wants to be and is far away from being 1.0.

Chapel current version is 2.8.0.

Re: Mojo 1.0 Beta

#96

Post by melodyogonna »

pjmlp wrote: post #81
melodyogonna wrote: post #80

Earlier quoted context omitted.

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.

Pytorch is built on an amalgamation of these different frameworks, not on one of them used to target different vendors.

Re: Mojo 1.0 Beta

#97

Post by DeathArrow »

>As a compiled, statically-typed language, it's also ideal for agentic programming.

Since there is not much Mojo code in the wild so the LLMs were trained on it, I wonder how it will work in practice.

Probably the agents will make lots of mistakes and you will spend 10x the tokens compared to using a language the model are well versed in.

Re: Mojo 1.0 Beta

#98

Post by melodyogonna »

pjmlp wrote: post #95
Certhas wrote: post #90

Earlier quoted context omitted.

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

One is used in production already by key laboratories in HPC research, the other wants to be and is far away from being 1.0. Chapel current version is 2.8.0.

Mojo isn't that far away from 1.0. Some point this year is the target

Re: Mojo 1.0 Beta

#99

Post by MohamedMabrouk »

pjmlp wrote: post #95
Certhas wrote: post #90

Earlier quoted context omitted.

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

One is used in production already by key laboratories in HPC research, the other wants to be and is far away from being 1.0. Chapel current version is 2.8.0.

I don't understand this framing, so? Cpp, Julia are more widely adopted, used in HPC. it does not mean that people shouldn't start, learn new languages.
Post reply on HN