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

111–120 of 252 posts

Re: Mojo 1.0 Beta

#111

Post by jdiaz97 »

dtj1123 wrote: post #34
modeless wrote: post #4

When I first heard about Mojo I somehow got the impression that they intended to make it compatible with existing Python code. But it seems like they are very far away from that for the foreseeable future. I guess you can call back and forth between Python and Mojo but Mojo itself can't run existing Python code.

They also advertised a 36,000x speedup over equivalent Python if I remember correctly, without at any point clarifying that this could only be true in extreme edge cases. Feels more like a pump-dump cryptography scheme than an honest attempt to improve the Python ecosystem.

The modern way to advertise: lie a lot.

Re: Mojo 1.0 Beta

#112

Post by jdiaz97 »

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…

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

Their whole original pitch was to be a superset of Python btw.

Re: Mojo 1.0 Beta

#113

Post by pjmlp »

zozbot234 wrote: post #109
pjmlp wrote: post #104

Earlier quoted context omitted.

CUDA won because AMD and Intel made a mess out of OpenCL, and Khronos had no vision to support anything beyond C99 dialect until it was too late. Doesn't matter if it was closed, when the alternatives were much worse.

SYCL is the de facto successor to OpenCL that supports higher level languages. So the vision was and is there.

As mentioned, Khronos only changed their mind when it was too late.

I can also recite the whole story, the missteps in OpenCL 2. , OpenCL C++, the OpenCL 3.0 reboot, how SYCL came to, CodePlay only proper available implementation, Intel acquisition of CodePlay and everything else.

Re: Mojo 1.0 Beta

#114

Post by [deleted] »

coldtea wrote: post #57
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…

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

[deleted]

Re: Mojo 1.0 Beta

#115

Post by flakiness »

coldtea wrote: post #57
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…

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

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 promise. And the 1.0 release would be a great time to deliver this.

Re: Mojo 1.0 Beta

#116

Post by adamnemecek »

flakiness wrote: post #115
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.

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…

This is exactly how the open sourcing of Swift went so I imagine it will be the same.

Re: Mojo 1.0 Beta

#117

Post by melodyogonna »

pjmlp wrote: post #102
melodyogonna wrote: post #96

Earlier quoted context omitted.

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

The point still stands as middleware.

Have you ever wondered how much work would have been saved by the Pytorch team if they could have used just Cuda for all the platforms they support? If they didn't have to write compatibility abstractions or layers, and instead just focused on the problem of training neural networks? What if all the primitives they used from Cuda and cuDNN worked just as well on AMD GPUs, Apple GPUs, and probably Google's TPUs as they did on Nvidia GPUs?

Mojo and Modular's Max platform would do to heterogeneous compute what LLVM did to programming language development. People who dismiss the real value offering here know nothing. Modular have already raised $350m+ from industry giants (including Nvidia and Google) to solve this, and I believe they will.

Re: Mojo 1.0 Beta

#118

Post by davidatbu »

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.

I'm pretty sure that they have decided that backwards-compat is not the best path for Mojo. Matter of fact, the following is the _last_ item on the roadmap on the home page:

> Supporting more of Python's dynamic features like classes, inheritance, and untyped variables to maximize compatibility with Python code.

What's more, note how it says "to maximize compatibility" not "to achieve full compatibility."

Re: Mojo 1.0 Beta

#119

Post by fwip »

modeless wrote: post #4

When I first heard about Mojo I somehow got the impression that they intended to make it compatible with existing Python code. But it seems like they are very far away from that for the foreseeable future. I guess you can call back and forth between Python and Mojo but Mojo itself can't run existing Python code.

That's because Mojo told you that. https://web.archive.org/web/20231221132631/https://docs.modu...

> Our long-term goal is to make Mojo a superset of Python (that is, to make Mojo compatible with existing Python programs). Python programmers should be able to use Mojo immediately, and be able to access the huge ecosystem of Python packages that are available today.

Re: Mojo 1.0 Beta

#120

Post by otabdeveloper4 »

flakiness wrote: post #115
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.

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…

> We're committed to open-sourcing all of Mojo

Translated from corporatese it means "it will never happen".

Post reply on HN