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

121–130 of 157 posts

Re: Mojo 1.0

#121

Post by usef- »

dgellow wrote: post #112
usef- wrote: post #94

Earlier quoted context omitted.

When has it ever been an issue in use? People complained about this in 1999 but then I used it and it's never mattered.

It’s an issue when generating python, I can tell you from experience. It’s also a pain to not be able to safely rely on an auto formatter

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)

Re: Mojo 1.0

#123

Post by jmalicki »

pansa2 wrote: post #116
woadwarrior01 wrote: post #47

Earlier quoted context omitted.

The value has already been materialized. They were acquired by Qualcomm for $3.9 billion.

That’s insane, for a language that seems to be Temu-Python. OTOH Python itself is the world’s most popular programming language, yet has only recently had the money to support more than a single full-time developer.

What else are you going to write CUDA kernels in that will be better than Mojo?

This doesn't compete with Python.

Like if someone wrote a competitor to VHDL that looked like TEMU Python... Python would not be its competitor, VHDL would.

Re: Mojo 1.0

#125

Post by melodyogonna »

nu11ptr wrote: post #66
totalperspectiv wrote: post #58

Earlier quoted context omitted.

Having written a lot of Mojo over the last two year, just for fun, it's a really cool language. Ownership model adjacent to Rust, comptime in the realm of Zig, rich type system, first class SIMD support, etc. Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig. Very excited for Mojo once it's open source…

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 languages. But on the other hand, it can be very fast since it doesn't have to do all the complicated resolving.

Another reason is how LLVM is used, Modular found ways to parralize LLVM code generation by introducing novel techniques that'll likely become a lot more popular with other languages.

Re: Mojo 1.0

#126

Post by adgjlsfhk1 »

jmalicki wrote: post #123
pansa2 wrote: post #116

Earlier quoted context omitted.

That’s insane, for a language that seems to be Temu-Python. OTOH Python itself is the world’s most popular programming language, yet has only recently had the money to support more than a single full-time developer.

What else are you going to write CUDA kernels in that will be better than Mojo? This doesn't compete with Python. Like if someone wrote a competitor to VHDL that looked like TEMU Python... Python would not be its competitor, VHDL would.

Julia

Re: Mojo 1.0

#127

Post by skavi »

afdbcreid wrote: post #110
skavi wrote: post #101

Earlier quoted context omitted.

I'd assume Mojo does more complex transformations at the MLIR level than Rust does at its MIR level.

First, I'm not sure. Rust has MIR optimizations and also other transformations. But even if yes, MLIR is part of the LLVM project, so it's technically still "just an LLVM wrapper".

MLIR is more a library for building a compiler than a compiler itself IIUC. LLVM can be thought of similarly, but IMO, it's more self contained.

Re: Mojo 1.0

#128

Post by ashu1461 »

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.

Pydantic is mainly about making Python strongly typed.

Mojo addresses the actual need to write code in other languages, such as C++ or CUDA, for low level and hardware specific work.

But I wonder if it has already missed the AI hype cycle, when a lot of low level code is being written. I'm not sure how the developer ecosystem will react now.

Re: Mojo 1.0

#129

Post by osigurdson »

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…

From experience, Zig compile times are at least as fast as Go for debug builds that don't need to do linking with C libraries, etc. It does have to use LLVM for release builds however which is a lot slower.

Re: Mojo 1.0

#130

Post by dgellow »

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

Earlier quoted context omitted.

It’s an issue when generating python, I can tell you from experience. It’s also a pain to not be able to safely rely on an auto formatter

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
Post reply on HN