Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mojo 1.0

modular.com

Post reply on HN
Print view View original

141–150 of 168 posts

Re: Mojo 1.0

#141

Post by usef- »

dgellow wrote: post #130
usef- wrote: post #121

Earlier quoted context omitted.

Every python developer I know uses an auto formatter today, and never needs to think about it (ruff, black). It's not ambiguous and is immediately visible if something has the wrong indent. (On other projects, I often wish other languages had formatters as good and standard as the Python ecosystem. I have many complaints about Python but whitespace is just not a problem I've seen)

You missed the point. I’m well aware python has formatters, I use them and implemented my own. The point was that when generating/manipulating python code you cannot just generate in whatever format then run a formatter. you need to carefully keep track of the exact indentation at place where the code in written

Fair. That is a very slight friction on what is quite a small niche, though (compared to the wider ecosystem of developers). And most that need similar will use AST or runtime construction.

The trivial kind of raw source generation is still trivial, but I'm guessing you're doing embedding/templates or something?

Re: Mojo 1.0

#142

Post by ameliaquining »

dgellow wrote: post #130
usef- wrote: post #121

Earlier quoted context omitted.

Every python developer I know uses an auto formatter today, and never needs to think about it (ruff, black). It's not ambiguous and is immediately visible if something has the wrong indent. (On other projects, I often wish other languages had formatters as good and standard as the Python ecosystem. I have many complaints about Python but whitespace is just not a problem I've seen)

You missed the point. I’m well aware python has formatters, I use them and implemented my own. The point was that when generating/manipulating python code you cannot just generate in whatever format then run a formatter. you need to carefully keep track of the exact indentation at place where the code in written

If I were doing this, and the code generator was itself in Python, I'd probably use ast and/or tokenize to avoid having to manipulate literal whitespace.

Re: Mojo 1.0

#144

Post by edflsafoiewq »

melodyogonna wrote: post #125
nu11ptr wrote: post #66

Earlier quoted context omitted.

How are compile times compared to Rust? Zig? Go?

Mojo is much faster than Rust, but slower than Go. I don't have much experience with Zig. Mojo is designed to be very fast to compile, so many decisions were made to keep the core language simple, one example is in `where` clause, the checking there happens entirely in the parser. It can be stupid in situations where other languages are smart, and make you explicitly do checks that could be inferred in other language…

> Modular found ways to parralize LLVM code generation by introducing novel techniques

What techniques?

Re: Mojo 1.0

#145

Post by TylerE »

usef- wrote: post #95
redlewel wrote: post #19

Earlier quoted context omitted.

This exactly. Doesn't scream confidence that its still closed upon release.

Why? The creators have a strong open source background and it's work to properly open source.

Because they promised 1.0 would be 100% FOSS. That has proven to be a lie.

Re: Mojo 1.0

#146

Post by TylerE »

jibal wrote: post #109
minraws wrote: post #29

> Finally, we will continue to progressively open-source more of the Mojo language, as well as components in MAX that we have built with it. Our commitment remains unchanged – we will open source the Mojo compiler and toolchain in 2026. Why not now though? Why wait for 4 more months? What magic is there to hide in just making it source available at least.

Who said anything about 4 months? Your "logic" seems to be that they are releasing it in 2026 and there are 4 more months in 2026 so they will be releasing it in 4 months. That's obviously flawed thinking. They will probably be releasing it coincident with their August 18 conference.

So why not either delay the 1.0 release by a week or move the open sourcing up by a week? This "strategy" makes absolutely no sense.

Re: Mojo 1.0

#147

Post by SJMG »

giancarlostoro wrote: post #46
swiftcoder wrote: post #39

I feel like this language would really benefit from some sort of 1-pager overview. I just spent a fair bit of time on the official site, and I still don't think I have a very good grasp of what problem this language aims to solve, or why I would select it over other similar languages

It's supposed to be (currently) a fully native, Python-like language, but for GPUs primarily. Though I am seeing it as having a future as a fully native Python alternative that might get interesting. I hope with 1.0 (havent fully read the article yet) they stop breaking language features / syntax because they did quite a few different changes over time, their overall goal is to be a fully native superset of Python. I…

Language-feature-wise it seems like Nim will be competitive. Ecosystem-wise… yeah it's kind of a nonstarter over in Nim land. There are not many go-to libraries and its culture is not very collaborative. People seem more enamored at what they can hack together than what they can contribute to.

Re: Mojo 1.0

#148

Post by SJMG »

seanw444 wrote: post #14
charlieyu1 wrote: post #8

Interesting. Heard about Mojo a few years now, never really tried it. My Python brain cannot really write C++ or Rust but still need the performance.

You may have heard of it already, but Nim has existed in this space for some time.

Julia as well.

Re: Mojo 1.0

#149

Post by zer0zzz »

redlewel wrote: post #6

Don't see the value of using a language with a closed source compiler... Much better options out there. Python already has libraries like Pydantic that offload performance to functions written in Rust under the hood.

They are going to open source it eventually

Re: Mojo 1.0

#150

Post by burntcaramel »

mort96 wrote: post #12
my123 wrote: post #7

Earlier quoted context omitted.

> Finally, we will continue to progressively open-source more of the Mojo language, as well as components in MAX that we have built with it. Our commitment remains unchanged – we will open source the Mojo compiler and toolchain in 2026.

It's categorically uninteresting until and unless that happens. Weird to release 1.0 without it. What are they waiting for?

From listening to Chris Lattner in interviews my guess it’s learning from when Swift became open source. The beta versions of Swift had massive language changes in how value types worked like with Array. Mojo is trying to get this language design locked down first, which is easier to do behind closed doors.

A compiler promising source stability is a different commitment than the compiler’s code being ready for outside contributors. Which is also different to having ABI stability, which took until 5.0 for Swift to achieve (I think Mojo does not have ABI stability as a goal as it doesn’t have to link to OS frameworks).

Post reply on HN