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

71–80 of 252 posts

Re: Mojo 1.0 Beta

#71

Post by pjmlp »

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?

- Doesn't support Windows, which is what many companies give their employees, outside Silicon Valey like culture

- The MLIR approach, which was also designed by Chris Lattner while at Google, has proven quite valuable to create Python JIT DSL

- The Python ecosystem now being taken seriously by the main GPU vendors, thanks to MLIR, as all their proprietary compilers are based out of LLVM

- Others remember Swift for Tensorflow

Re: Mojo 1.0 Beta

#72

Post by pjmlp »

kstrauser wrote: post #29
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…

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.

Re: Mojo 1.0 Beta

#73

Post by tveita »

Is there any project that showcases Mojo for running neural network models on the GPU - like ideally something like llama.cpp that could run one or more existing models to showcase the readability and performance?

Re: Mojo 1.0 Beta

#74

Post by [deleted] »

tweakimp wrote: post #61
vga1 wrote: post #41

Earlier quoted context omitted.

I have tons of experience with python, possibly more actual work experience than any other language, and I do think the indentation is a bit of a problem. Obviously not a huge one, but still something I wished they had done differently. Because I like to have a robust format-on-save wired into my editor, and you just cannot quite have that when indentation is meaningful.

Use black as format on save and you will never have a problem with that. https://github.com/psf/black

[deleted]

Re: Mojo 1.0 Beta

#75

Post by _aavaa_ »

Certhas wrote: post #60
coldtea wrote: post #57

Earlier quoted context omitted.

> 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. Unless it's open sourced, it's a moot point, as most Python devs wont come anyway.

This is a bit ironic, given that people seem to have no problem using CUDA all over the place... Plus they promise to open source with the 1.0 release. We'll see...

I don’t see irony there. We’re locked into CUDA due to past decisions. And in new decisions we don’t want to repeat that mistake.

Re: Mojo 1.0 Beta

#76

Post by vga1 »

tweakimp wrote: post #61
vga1 wrote: post #41

Earlier quoted context omitted.

I have tons of experience with python, possibly more actual work experience than any other language, and I do think the indentation is a bit of a problem. Obviously not a huge one, but still something I wished they had done differently. Because I like to have a robust format-on-save wired into my editor, and you just cannot quite have that when indentation is meaningful.

Use black as format on save and you will never have a problem with that. https://github.com/psf/black

Sure, black's pretty good and definitely better than nothing.

Just wanted to provide an easy counterpoint to the logical fallacy by IceDane.

Re: Mojo 1.0 Beta

#77

Post by tasuki »

sureglymop wrote: post #62
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…

Mojo is cool but I just don't understand the python backwards compat thing. They're holding themselves back with that. All the flaws I can think of in Kotlin are due to the Java compatibility. They could've made it work here by being more explicit but the way it currently works seems doomed.

They coulda made it Scala!

Re: Mojo 1.0 Beta

#78

Post by tasuki »

IceDane wrote: post #32
thefounder wrote: post #30

Does it have the indentation thing? That would be a no go for a lot of people

Only incredibly inexperienced people think indentation in python is a problem.

Yes, indeed, indentation is one of the very few things in Python which aren't problematic!

Re: Mojo 1.0 Beta

#79

Post by pjmlp »

sureglymop wrote: post #62
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…

Mojo is cool but I just don't understand the python backwards compat thing. They're holding themselves back with that. All the flaws I can think of in Kotlin are due to the Java compatibility. They could've made it work here by being more explicit but the way it currently works seems doomed.

Same story with C and Objective-C, C and C++, JavaScript and TypeScript, Java and Scala, Java and Clojure,.....

Yes the underlying platform they based their compatibility on, is the reason they got some design flaws, some more than other.

However that compatibility is the reason they won wide adoption in first place.

Re: Mojo 1.0 Beta

#80

Post by melodyogonna »

pjmlp wrote: post #69
melodyogonna wrote: post #50

Earlier quoted context omitted.

People keep mistaking Mojo as good syntax for writing GPU code, and so imagine Nvidia's Python frameworks already do that. But... would CuTile work on AMD GPUs and Apple Silicon? Whatever Nvidia does will still have vendor lock-in.

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 get this choice using vendor-specific libraries; you're locked into this or that.

Post reply on HN