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

191–200 of 252 posts

Re: Mojo 1.0 Beta

#191

Post by archargelod »

bobajeff wrote: post #182

I've been keeping my eye on mojo. Honestly though the thing I least like about Python is it's syntax. Someone else here is bringing up Julia. Which I think is a fine language but the compiler error messages and the library documentation are not what I would want in a language as far along as it is. I'm also worried about the correctness issues I've read about in a blog awhile back. Also I don't feel like I can make t…

> the thing I least like about Python is it's syntax.

For me it's the opposite - the only thing I like about Python is it's syntax. That's why I really like Nim - you get C speed, "comptime", metaprogramming, powerful type system, memory safety and code is often short and elegant.

Mojo seems interesting too, but so far they're mostly focused on ML stuff and not general programming. And I believe compiler is still not open-source?

Re: Mojo 1.0 Beta

#194

Post by jadar »

Congrats to Chris Lattner and crew! Seems like a neat project. I listened to him talk about Mojo on some podcast a while back and was really impressed. Swift was a runaway success, and I hope he can pull it off again with Mojo! :)

Re: Mojo 1.0 Beta

#195

Post by Conscat »

fiedzia wrote: post #181
loglog wrote: post #136

Earlier quoted context omitted.

Mojo is NOT Python compatible (although they initially wanted it to be). So they got all downsides without the upsides.

They claim you can easily mix them so there is some degree of compatibility.

Every reasonable language has a Python interop story. All it takes is C FFI. But what Mojo promised early on was the eventuality of compiling a large amount of Python code if not entire wheels as Mojo.

Re: Mojo 1.0 Beta

#196

Post by Conscat »

fibonacci112358 wrote: post #22

Sadly for them, Nvidia didn't stay still in the meantime and created the next generation of CUDA, CuTile for Python and soon for C++, through CUDA Tile IR (using a similar compiler stack based on MLIR). Event though it's not portable, it will likely have far greater usage than Mojo just by being heavely promoted by Nvidia, integrated in dev tools and working alongside existing CUDA code. Tile IR was more likely a res…

My understanding from speaking with a few Tile IR devs on dates is that its primary motivation was providing better portability for programming tensor cores than PTX offers. Nobody ever told me they saw it as a response to anything other than customer feedback.

Re: Mojo 1.0 Beta

#197

Post by nextaccountic »

chrislattner wrote: post #145
flakiness wrote: post #115

Earlier quoted context omitted.

https://mojolang.org/docs/roadmap/#contributing-to-mojo > We're committed to open-sourcing all of Mojo, but the language is still very young and we believe a tight-knit group of engineers with a common vision moves faster than a community-driven effort. So we will continue to plan and prioritize the Mojo roadmap within Modular until more of its internal architecture is fleshed out. I hope they stick to their original…

Indeed, this fall 100%

Why didn't you just do this the sqlite way, and open source this, some time ago?

Release the source, but don't take code from external contributors. Take issues and discussion instead

Re: Mojo 1.0 Beta

#198

Post by rao-v »

teleforce wrote: post #188
rao-v wrote: post #174

Earlier quoted context omitted.

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…

>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. It's already (partly) existed called D language, by default it's garbage collected (GC), can also be program without it or hybrid. It's a modern, backward compatible with C and it's included in GCC. The linear algebra sys…

Delightful thank you! Would love to see a version of D that auto vectorizes to Vulkan or something

Re: Mojo 1.0 Beta

#199

Post by tosh »

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…

Still a bit early but I'm working on kiwi, a k-dialect that can lower to Apple MLX.

Currently supports CPU and GPU on macOS and CPU on linux.

https://kiwilang.com

https://github.com/kiwi-array-lang/kiwi

Kiwi runs computations on small dense arrays in its own runtime, when they are larger it will lower to MLX CPU and eventually to MLX GPU when it is worth it.

As user you don't have to change any code, you just write k.

I'm sure there are other languages designed to take advantage of modern GPUs.

But even with SIMD you can get quite far with array oriented code and many array language implementations will make use of it (BQN, ngn/growler/k, goal, ktye k has a version with SIMD support, …)

Re: Mojo 1.0 Beta

#200

Post by rao-v »

throwup238 wrote: post #190
rao-v wrote: post #184

Earlier quoted context omitted.

Surely a high level language can own the contract of making sane choices of when to auto vectorize and when not to (or just inefficiently auto vectorize - that is fine too!)

That’s like saying “surely a high level language can solve the halting problem.” Yes, it can, but only by eliminating the features that make it Turing complete. It’s relatively easy to vectorize map with a closure that can’t mutate anything but once you have nontrivial control flow, the compiler can’t make those kinds of assumptions.

It’s really not! We’re not requiring the language to make optimal choices, just that it convert the same code to these different paradigms (and honestly you could just brute force run the 12 versions and choose the fastest one). Absolutely no theory barriers apply!
Post reply on HN