melodyogonna

Good. I too I'm not a fan of MCPs, but these days I do find them useful. In Claude Code I connected to my company's MCP which made Claude Code infinitely more useful for everyday work stuff

The pace the American government is willing to adopt new technology is underrated. Americans are very nimble

Yup. Go maturity is realising how little you need to use channels and Goroutines. You probably just need a setup in one place, like in front of incoming requests ... which using net/http already does for you.

Spamming them all over the place is a red flag imo

Very neat, and comes pretty close to how Mojo handles portable SIMD.

It's great to see two of my favorite languages finally making SIMD easy to use. It's such low-hanging fruit for performance, yet somehow languages have ignored it for years. Portable SIMD, even with some performance penalty, still beats scalar computation whenever vector operations are needed. Yet language implementations always seemed to assume that hardware-specific SIMD APIs were the only way to go. That did nothing but make SIMD unusable excepting special cases where performance is absolutely critical, rather than just something anyone can use in day to day programming.

How so? I imagine you'd still want to constrain the length to the maximum vector size supported by the lowest platform you want to support or you lose the portability and actually end up with code that performs much worse than the scalar alternative on some platforms.

Mojo has an even more portable simd[1] type that isn't just generic over length but also over type. In my opinion it is almost always better to specialize for each platform and use portable implementation as fallback. It's a shame that just very few languages support Zig-like comptime, because it would be excellent for specializations without introducing runtime penalties.

1. https://mojolang.org/docs/std/simd/SIMD/

Comes to Rails conference. Gives a keynote with nothing about Rails. Leaves.

I have an application usecase where this will be very helpful indeed.

Did you finish the video? It has CI, but I don't know if they implemented merge gating. Though I suppose that could be part of the land skill

What do you mean?

You could also use Mojo, one language for all targets.

Why?

I'm going to give this a try because I once also tried to make a slick GUI ide with Vim key bindings. Unfortunately I was trying to use Rust then, of which I had no experience, while trying to write a desktop app, of which I also had no experience.

When you see seemingly simple products have too many engineers, most are almost always there to cater for enterprise customers.

The thing is, you can only program what is programmable. If a CPU has some capability that isn't programmable, I don't know what C or any other language is expected to do.

Well, C does give you the control when it matters, even if they feel bolted on for more modern features.

I actually believe Mojo is the only modern language not designed to pretend every computer is a PDP-11. C has been so successful that many succeeding languages just did C things as a matter of course.

In Mojo, everything is designed with the complexity of the modern computer in mind, and at every stage the programmer has complete control of outcomes. You decide what gets inlined, what gets passed in registers, what gets unrolled, etc. The language has excellent ... ney, probably the best portable SIMD support there is; all integers are built on top of SIMD, and the scalar integers are just SIMD with length of 1. You get complete control of what gets compiled as well due to powerful compile-time programming that is similar to, but more powerful than Zig's (imo, because you can supply a lot more information). While C and Rust allow inline asm, Mojo goes further by letting you supply inline MLIR and LLVM as well, so in situations that warrant it, you can tell the compiler to compile to a specific LLVM intrinsic. The language also does not assume you're compiling to run on just one machine; every modern computer is heterogeneous by nature and may contain multiple programmable units, so the compilation pipeline is designed to allow compiling certain parts of code for one target and other parts for other targets... as one compilation unit.

Uber was never really in Nigeria much, despite apparently being here a long time. I use ride-hailing a lot, and I've never used it because it is not available in my state, or in most states, for that matter.

I wouldn't say they suck, but they're general-purpose. Anyway, you've gotten into the core of what makes Modular's stack useful. GPUs are great, but it has become obvious that they leave performance on the table, so dedicated AI accelerators get built; however, these don't have software infrastructure and kernels that have been tuned and optimised for years, like CUDA. The bet here is that you can build great hardware, and with a little bit of effort you can unlock all the necessary software for your hardware.

It is still a goal. Mojo's semantics are still driven by Pythons, and can only deviate where safety or performance is an issue. Eventually it'll get the dynamic parts of Python

Mojo's concurrency model is yet to be figured out.

PR here: https://github.com/modular/modular/pull/6904

Chris Lattner is now Qualcomm's VP of AI Software and Tooling, so he is now responsible for all of Qualcomms AI software. Mojo wouldn't be doing any dying

I think people underestimate the fact that Nvidia's GPUs are really good. Modular/Qualcomm's stack will provide a lot more optionality, but from what I saw in the Modcon conference on Tuesday, most of the target audience is towards other hardware vendors. At the moment, after designing a new hardware, you'd have to also build the entire software stack already existing on Cuda, ROCm, etc - this can double or triple your hardware bring up time. If you plug into Max (not Mojo), you get most of the software stack for free, so your software bring up time can go from months of engineering hours to probably weeks.

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.

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.

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

I think this submission should be merged with this much older one since they link to the same post: https://news.ycombinator.com/item?id=49348079

One of my favourite features of Mojo is linear types and how deeply they have been integrated into manual memory management - see:https://x.com/melodyogonna/status/2085089269484343725?s=20. When I first learned about linear types, my first thought of the use case was making manual allocations and deallocations safer without sacrificing usability, but I didn't know what that could look like; now I do. This is great because in Mojo, pointers are surfaced a lot more than in, say, Rust, but such sharp tooling in a language you expect to be safe by default can be problematic. Linear types, combined with the origin system, give the language a lot of flexibility; it is like using a sharp tool with a safety glove: the tool isn't any less sharp, but the chances of accidentally injuring yourself are reduced.

I don't understand this premise. And the more I think about it, the less sense it makes. On the grand scale of things, Windows is the niche platform here. For consumer desktop use cases, it is king, but nobody deploys on it for the use cases that the first version of Mojo is optimised for.

Such an exciting time for Mojo, I don't think people realize just yet the innovation being brought to fore here.

Related post with relevant pr: https://news.ycombinator.com/item?id=49347777