Hacker News Reader

Comment by melodyogonna | Hacker News Reader

If you like C++, you're going to like Mojo (if you're looking for alternatives). Some of the semantics and designs are inspired by C++, but wrapped in a Python-like skin. The way to think about Mojo, when compared to Rust, is that it was designed by expert C++ programmers as what they imagine a good C++ will look like. When I see Rust, I see designers who loved the functional programming paradigm and wanted to make a lot of the concept mainstream. This is why some of the semantics can seem awkward if you're coming from a procedural language

View on HN

This isn't quite accurate; Mojo uses the same memory safety approach as Rust. It has some mutable aliasing, but only intra-function, so in practice programs will be pretty much Rust-shaped.

Their comment seems to be mostly focused on surface-level syntax from what I can tell (e.g. "wrapped in a Python-like skin"; "what they imagine a good C++ will look like"). Rust code probably does resemble functional languages to someone who uses C++ primarily, and Mojo doesn't resemble them as much. I don't find that to be a particularly enlightening insight, but I have to imagine that the syntax of Mojo is one of the first things that will catch people's attention, so it's not surprising to me that it's something that people will have a lot to say about.

My hot take is that what a good C++ will act like is basically just already Rust, mostly because the main problems with C++ can only be solved by taking away some of what makes it C++ in the first place. Some C++ developers will probably not be happy with a language that takes away the parts they still want to use, but others might just not like what Rust "looks like", so if dressing up the same Rust semantics in a new skin ends up getting the world more code written without the bad parts of C++, that's probably a good thing.

Yeah exactly. Rust could also be thought of as a much better C++ (semantically) but syntatically it is much more functional, while Mojo adopts (and even extends) similar memory safety ideas but dressed in a skin that is potentially much more approachable to people used to procedural programmng.

Can you explain this in more detail? I'm not really familiar with Mojo but I can't think of obvious ways in which Rust's semantics (as opposed to syntax) are more functional than C++'s.

Rust's type system is very Haskell/ML inspired, specifically the first class support for algebraic types and pattern matching.

Modern C++ has come a long way with typed optionals and variants, but it's very tacked-on and lacks the safety guarantees and ergonomics of a language designed with this paradigm at a fundamental level.

So what does this actually translate to in terms of Mojo? Rust has algebraic types and pattern matching, C++ has some specific use cases that are "tacked-on", to use your phrasing, so when the parent comment says that Mojo is what a good C++ would look like, they're saying...it doesn't have algebraic types, or that they're tacked on? It's not clear to me why that would be a selling point, so giving the parent commenter the benefit of the doubt, I don't think this sounds like what they were trying to say.

I don't know about Mojo. I was just answering "...I can't think of obvious ways in which Rust's semantics (as opposed to syntax) are more functional than C++'s"

I consider it basically an accident of history that the first non-research languages to support ADTs were functional. (The first language to have them was actually CLU, which was imperative, but it was a research language.) There isn't really anything about ADTs that makes them incompatible with imperative languages.

> expert C++ programmers as what they imagine a good C++ will look like

Mojo looks nice but with coding agents the landscape has shifted at least in my view. There is no need for DSLs and abstractions that reduce human cognitive load. So, I still struggle with the usecase for Mojo. If you want close to metal performance, code in something that touches metal (c,c++), and doesnt abstract you away from it or require unsafe primitives. As a programmer who cares for performance, you want the least separation between your tools and the hw in the sense that you can visualize precisely what the hw is doing with no abstractions to hide it.

I'm confused, C and C++ do require unsafe primitives? I think I must be misunderstanding your comment somehow.

It sounds like they were saying that they think you shouldn't have to use a language primitive like `unsafe` to be able to do the stuff that C/C++ does. (To be clear, I completely disagree with this viewpoint, because I don't think there's any evidence at all that agents won't struggle with the same fundamental problems in writing C/C++ that humans do, but I think it's what they're saying).

that you can visualize precisely what the hw is doing with no abstractions to hide it.

How can one hold the nuances of different architectures in their head, unless you stick to something like a console that doesn't evolve much for a half a decade or more? Don't you want at least some abstraction?

How I wish people will stop spamming me with this garbage, or at least do some basic research first; C/C++ are not lower-level than Mojo, in fact, a core semantic of Mojo is that the programmer is as explicit as possible while defining what they want to accomplish rather than relying on compiler optimisations. You have facilities to interact with MLIR, LLVM, and Assembly intrinsics... in fact, most (if not all) of built-in Mojo types is exactly this, types wrapping low-level compiler MLIR intrisics.

> it was designed by expert C++ programmers as what they imagine a good C++ will look like

This also describes Rust. The mistake here is thinking that being an expert C++ programmer means that you can't also be an expert OCaml programmer.

Reply on news.ycombinator.com