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

131–140 of 252 posts

Re: Mojo 1.0 Beta

#131

Post by MohamedMabrouk »

ModernMech wrote: post #128
jlundberg wrote: post #125

Earlier quoted context omitted.

With Chris Lattners track record, there is little reason to doubt they actually will open source this.

It’s not Chris Lattner who gets to make the call though. He has investors to the tune of $300 million, and making them happy is the reason it hasn’t been done yet. A lot of people, very reasonably, relieve it’s not possible to satisfy them and also the development community, and when when push comes to shove it’ll be the investors who win because they have the money. So it’s not Chris Lattner’s track record that make…

how is it in investors self interest to keep a programming language (some thing which no one makes money on today) closed? It also means that library authors can't reason about their code well enough because they don't know the language internals, this also hurts ecosystem growth. Their is no money to be made with a closed language that no body uses. probably modular investors know this.

Re: Mojo 1.0 Beta

#132

Post by adev_ »

pjmlp wrote: post #105
adev_ wrote: post #92

Earlier quoted context omitted.

> 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 o…

I would argue Chapel or Futhark could be such languages, but they aren't cool.

Chapel maybe, but it is too low level to attract a large public outside of the HPC community.

Re: Mojo 1.0 Beta

#133

Post by CodeArtisan »

dtj1123 wrote: post #35
noduerme wrote: post #15

Am I old or remembering this wrong... didn't Zuck write the first iteration of Facebook in PHP, and then spend millions to hire people to write something that converted the code to C++?

https://en.wikipedia.org/wiki/Hack_(programming_language)

Hack came after. Noduerme is referring to https://en.wikipedia.org/wiki/HipHop_for_PHP

Re: Mojo 1.0 Beta

#134

Post by adev_ »

jdiaz97 wrote: post #112
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…

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

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

To my understanding, they offer a full python compatibility but guide the user to something else.

For instance, Mojo itself is statically typed.

Re: Mojo 1.0 Beta

#135

Post by Derbasti »

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.

Current LLMs have been trained on extensive libraries of past code. Therefore, LLMs will for the foreseeable future work better for established languages than new ones. Especially languages with a lot of open source code available, like Python. That's a big problem for incumbents without any existing code to train LLMs on.

Thus this desparate "AI native" marketing is probably necessary to even be considered relevant in an "agentic" world. Whether it's enough, only time will tell.

Re: Mojo 1.0 Beta

#136

Post by loglog »

geodel wrote: post #107
sureglymop wrote: post #62

Earlier quoted context omitted.

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.

> All the flaws I can think of in Kotlin are due to the Java compatibility. All the use of Kotlin in industry are due to Java compatibility. Else there would be ~0% marketshare of Kotlin.

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

Re: Mojo 1.0 Beta

#137

Post by kstrauser »

rvz wrote: post #129
logicchains wrote: post #8

Very bold of them expecting people to use a language with a closed source compiler in the 2020s.

CUDA is closed source (and will never be open sourced) and everyone is fine with it. Modular is giving you at least a public promise that they will open source Mojo it this year but some how here it is a problem. Unbelievable.

CUDA is not a programming language. It's a package with adapters for lots of languages. IMO, it's not relevant here at all. Sure proprietary packages exist for just about every language, but most modern languages are open source. You can use them, distribute them, patch them, or whatever else.

For instance, you can write Python without using CUDA. CUDA's existence doesn't make Python less useful. But what do you do when you bump into a bug in Mojo? You have no ability to fix it yourself. At best, you can report it to the authors and hope they care enough about it to put in the work and release an update. If you run into a Python problem, you, or someone in your org, or a paid consultant, can fix it even if the Python core team doesn't care about it.

Re: Mojo 1.0 Beta

#138

Post by loglog »

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…

> on top of a well designed language constructed over past language design experience

While I believe that Chris Lattner is a great compiler designer, his language design record has been less stellar. Swift bidirectional type inference for instance feels like it was implemented because they had a compiler algorithm that they wanted to use, rather than a genuine need, and is just a completely avoidable problem. Trying to make a HPC language that is also Python compatible was doomed from the start. Hopefully the damage from going into this direction will remain limited.

Re: Mojo 1.0 Beta

#139

Post by coppsilgold »

Python is basically the master glue language at this point.

If more than a few percent of execution time is spent in Python you are probably doing it wrong.

Personally I don't even understand why Cython is a thing, just write performance critical functions in other languages:

https://pypi.org/project/rustimport/>

https://pypi.org/project/import-zig/>

Note that you can even start threads in those languages and use function calls as pseudo-RPC. All without an overly complex build system.

Re: Mojo 1.0 Beta

#140

Post by physicsguy »

coppsilgold wrote: post #139

Python is basically the master glue language at this point. If more than a few percent of execution time is spent in Python you are probably doing it wrong. Personally I don't even understand why Cython is a thing, just write performance critical functions in other languages: https://pypi.org/project/rustimport/ > https://pypi.org/project/import-zig/ > Note that you can even start threads in those languages and use f…

Cython and PyBind and Nanobind are good for wrapping an existing library written in C++ and crafting an interface that doesn’t feel like it’s a C++ one. They were a big step from ctypes and SWIG
Post reply on HN