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

171–180 of 252 posts

Re: Mojo 1.0 Beta

#171

Post by zzzoom »

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.

Is it? Spack has only one package that depends on chapel.

Re: Mojo 1.0 Beta

#172

Post by momojo »

totalperspectiv wrote: post #147
taylorallred wrote: post #122

I know Mojo is aimed at ML, but I'm actually really interested in trying it for game development :)

Me too! I've been using it for bioinformatics related work, and it is absolutely fantastic. I can't wait for it to hit fully open source status so it can be easily recommended.

I work in bioimaging. What kind of bioinformatics are you doing that requires mojo level power?

Re: Mojo 1.0 Beta

#173

Post by xiphias2 »

insumanth wrote: post #9

I was excited when Mojo launched and thought it might grow big quick. I don't see much traction. The pitch is compelling. What could be the issue?

It's a language that wanted to make money from the start.

For example you need to use some Mojo Max library to have fast optimized LLM kernels, but at that point you can just stay with Python that has fast optimized LLM kernels, like flashinfer.

Re: Mojo 1.0 Beta

#174

Post by rao-v »

ainch wrote: post #10

As someone in ML who's interested in performance, I'm keen for Mojo to succeed - especially the prospect of mixing GPU and CPU code in the same language. But I do wonder if the changes they're making will dissuade Python devs. The last time I booted it up, I tried to do some basic string manipulation just to test stuff out, but spent an hour puzzling out why `var x = 'hello'; print(x[3])` didn't work, and neither did…

I still don’t understand why we lack a language that will take uncomplicated computation heavy code and turn it into SIMD / multi thread / multiprocessing / GPU code with minimal additional syntax.

Surely this is the sort of thing compiler / language design nerds dream about?

It doesn’t have to guarantee efficiency or provide cutting edge performance in any context … it should just exist!

My understanding is that we can make such a language … but it’s not caught the fancy of someone who could do it

Re: Mojo 1.0 Beta

#175

Post by infraredshift »

melodyogonna wrote: post #127
ainch wrote: post #12

Earlier quoted context omitted.

In their original pitch that was definitely part of it: take Python code, add type hints, get a big speedup. As they've built it out it seems to have diverged.

It was always going to be a long-term thing, if it were even possible. You can't make a compiler that can compile Python into efficient machine code in just a year (which was how long Mojo had been in development when it was announced). The messaging was changed because people got sold too hard on that, and kept trying Mojo with the expectation that it could compile existing Python code when it couldn't. What Modular…

[dead]

Re: Mojo 1.0 Beta

#176

Post by JBits »

rao-v wrote: post #174
ainch wrote: post #10

As someone in ML who's interested in performance, I'm keen for Mojo to succeed - especially the prospect of mixing GPU and CPU code in the same language. But I do wonder if the changes they're making will dissuade Python devs. The last time I booted it up, I tried to do some basic string manipulation just to test stuff out, but spent an hour puzzling out why `var x = 'hello'; print(x[3])` didn't work, and neither did…

I still don’t understand why we lack a language that will take uncomplicated computation heavy code and turn it into SIMD / multi thread / multiprocessing / GPU code with minimal additional syntax. Surely this is the sort of thing compiler / language design nerds dream about? It doesn’t have to guarantee efficiency or provide cutting edge performance in any context … it should just exist! My understanding is that we…

If you're happy with NumPy's API, then surely JAX is exactly what you're looking for.

Re: Mojo 1.0 Beta

#177

Post by oldmanhorton »

rao-v wrote: post #174
ainch wrote: post #10

As someone in ML who's interested in performance, I'm keen for Mojo to succeed - especially the prospect of mixing GPU and CPU code in the same language. But I do wonder if the changes they're making will dissuade Python devs. The last time I booted it up, I tried to do some basic string manipulation just to test stuff out, but spent an hour puzzling out why `var x = 'hello'; print(x[3])` didn't work, and neither did…

I still don’t understand why we lack a language that will take uncomplicated computation heavy code and turn it into SIMD / multi thread / multiprocessing / GPU code with minimal additional syntax. Surely this is the sort of thing compiler / language design nerds dream about? It doesn’t have to guarantee efficiency or provide cutting edge performance in any context … it should just exist! My understanding is that we…

Both ahead of time compilers and JIT compilers often perform autovectorization of tight loops. The problem is that lots of hot loops are not necessarily simple loops, and in particular a lot of source code is written in a way which uses sequential dependencies that can’t be modeled in SIMD code. Aside from undefined behavior in C/C++, most compilers will fail to autovectorize because doing so would very slightly change the behavior of your code in a very hard to understand way.

Re: Mojo 1.0 Beta

#178

Post by totalperspectiv »

momojo wrote: post #172
totalperspectiv wrote: post #147

Earlier quoted context omitted.

Me too! I've been using it for bioinformatics related work, and it is absolutely fantastic. I can't wait for it to hit fully open source status so it can be easily recommended.

I work in bioimaging. What kind of bioinformatics are you doing that requires mojo level power?

"requires" is a strong word, but I implemented an alignment kernel that can do alignments on the GPU.

Overall I think there is going to be a lot of "old" gpu compute hanging around, and now that writing kernels is a lot easier than it has been, we might as well try and see what algorithms we can get working there.

I originally picked up Mojo for the SIMD, not for the GPU kernels. The SIMD usability in Mojo is outstanding.

Paper on the tool I wrote: https://doi.org/10.1093/bioadv/vbaf292

Re: Mojo 1.0 Beta

#179

Post by runarberg »

FacelessJim wrote: post #169
runarberg wrote: post #18

I am actually on a lookout for a low level language which compiles to web assembly to write a (relatively small) supervised learning model which I plan to be good enough for 5 year old phone CPUs. I have a working prototype in Julia and was planning on (eventually) rewrite it in Rust mostly for the web assembly target. I come from a high level language background so the thought of rewriting in rust is a little daunti…

Might want to take a look at WasmTarget.jl it’s rather new and experimental but could be what you’re looking for!

Too much vibe code for my taste.

Re: Mojo 1.0 Beta

#180

Post by csvance »

Mojo looks neat but I'm pretty satisfied with Julia at this point for high performance numerical computing across CPU, GPU, etc. I can't help but feel this niche is already mostly solved beyond having Python like syntax. Even Python has things like Numba and Triton that are effective for less complicated / more self contained type problems.
Post reply on HN