The article: *quotes Prime's own points back at him" Prime: "I totally agree"

JUNIOR MOJO DEVELOPER REQUIRED. Must have 15 years MOJO development experience. Apply within.

Green hair = rust expert

I'm totally learning Mojo to be able to call myself a Mojito

Having done some research about the speed claim, decompiling both of the rust and mojo binaries, I saw that mojo optimized out everything, making the resulting binary call main and returning without any work; this was proven by making a program with only a main function, and running it through the same benchmark test, which lead to the exact same results. Rust does the same optimization in any version equal or newer to 1.75.0, and its execution is so much faster that it cannot be properly calculated. In older rust versions, the compiler would create the entire recursion, and the content inside the loop looks something like: allocate 336 bytes, deallocate 336 bytes, check branch condition, call recursion function; this is slower than mojo because it is actually doing work by having to call the allocator multiple times, and having to manage a branch; also note that the compiler did do TCO, shown by having the deallocation happen before the branch condition check. This is a case where the benchmark was cherry-picked to something rust did not optimize at compile time, while also lying about rust not doing TCO, as well as using non-ideomatic rust (as shown in the video, `vec![0; size]` is preferred over `Vec::with_capacity(size)`, and results in a faster execution time than mojo). If they cannot properly explain why their language has the faster execution in the benchmark, having to assume things about how rust works to make something believable, then I do not see how any claims they make will be trusted in the foreseeable future. I am willing to change my mind in the matter if the article writer is able to explain themselves about this discrepancy, but for now, here's the truth about those benchmarks.

9:20 C# is in an even weirder spot, its between 1, 2 and 3 tier. It can compile to native code, it can run without a garbage collector and it can run in IL mode. its insane

Prime is called "Rust Experts" now.

Mojo programmers should clearly be called Jojos

9:25 What is kind of missing in this pyramid are insane languages like haskell, that explicitly don't surface things like execution order and other details to the user and therefore are able to do aggressive optimizations. Haskell can often get within ~5% of C performance, which is kind of insane for a high-level language.

26:13 you typically see a chip wide downclock when running AVX instructions on a lot of chips. You also have an overhead on the loading the input/fetching the results in many cases. In my experiments I typically see a 40X improvement, not a 64X improvement but it's constantly creeping towards that 64 number by each new architecture.

as a AI researcher using python all the time... my compute heavy workloads are already running on C++ under the hood. dataset.map isn't the same as a for loop... and if I use a for loop or two --- it takes a few second once or twice. Sure thing, that is good enough. The developers who integrate a c library below python via cffi are the real heros. That stuff is tough - and I am also working on something like that.

TCO does not "unroll it into a loop" it "reuses the stack frame". When you call a non-inlined function you allocate a stack frame (by incrementing the stack pointer), this holds space for the arguments and the return value and possibly a little other bookkeeping. TCO reuses all the values in the stack frame, including the return address, and as a side effect never has to increment the stack. It can only be used in very exacting conditions (the conditions related to everything the function does must be able to be aggregated into a return value and/or argument variables, and the stack frame must be identical in size). Its real benefit is not so much performance (though it does give some) , its that it prevents a stack overflow from happening (which happens when your stack pointer overflows the preallocated stack space of your application. In this case, the vec initialization creates memory on the heap. If the next call were to rewrite the contents of that variable, the underlying vector on the heap would be leaked. Mojo is greedy in that since _stuff is never used and deleted on its "last use" there is nothing that is not stack allocated, whereas in rust it cannot. Rust can use TCO, just not with heap allocated variables. Granted, I would try an explicit drop in there after the vec init and see what happends.

I'm sorry but Mojician is hilariously awesome

40:22 Vec::new simply doesn't allocate. Unless you push to it, it will simply point to null. That's really helpful, as that way it can just simply be used in Default impls without having to do any allocations.

One thing that doesn't seem to get mentioned at all - mojo is proprietary and not open source? That alone means it's a non-starter for so many projects and use cases that I highly doubt it will reach any kind of critical mass as a language to replace and / or supplement Python / C++ / Rust in the ML space (or any other space for that matter).

Contrived use case of the recursive example. In production Rust you'd use a for loop and allocate the Vec once outside and not destroy it for each iteration.

45:51 Doing SIMD manually in rust really isn't fun, but often you really don't need to do it anyway. If you structure your code correctly (i.e. have it have the right alignments and sizes and stuff), LLVM is *really* good at optimizing code for your platform. So instead of doing SIMD manually you structure your code *as if* you want to use SIMD and let the compiler do the rest.

Rust definitely has TCO in that example, no way that it can create like 1 billion stack without hitting stack limit if they didn’t unroll it into loop

I’m keen to see what a really capable Mojo dev vs a really capable Rust dev can build in a fixed time window and the performance of the 2 solutions. Hell, throw a C++ and Zig dev in there too. Effort is the biggest constraint in my work.

I like Mojician. Also, not surprising that Chris Lattner is iterating on the intermediate language design from LLVM seeing as he was a core (founding?) dev on it for a long time.

I just checked the article and the benchmarks got actually updated

About vec![0; 42], it actually memsets the first 42 elements. So it allocates and sets, so it might allocate on the first push. With capacity only allocates, so as long as you push less than capacity, you're guaranteed to not allocate.

Will not use a programming language requires my email address to install

That TCO example they did is so bad, Rust do have the issue of not being able to do TCO, but that example just does it, because stuff is never used or black_boxed, to demonstrate this you will need a function that counts sheep down starting at n, prints a message for each sheep counted, and returns the total number of sheep that have been counted. This function does not TCO, because the addition operation is performed after the recursive call and the result being used, so the compiler does not automatically optimize it.

I don't like that "owned" thing in Mojo, because the caller of the function may not be aware that a copy of the string is being made! That's why I like that in Rust you have to explicitly use foo clone() at the caller site, making it immediately obvious to who reads that code for the first time what is going on.

31:17 The reason why rust uses drop flags is actually really interesting: If a value gets dropped conditionally, (for example when one branch has a drop(value) and another does not) rust still has to keep track of whether the value was dropped or not at the end of the scope. The solution to remove this overhead would be, to rather than keeping track of whether the value was dropped, to always drop the value at the earliest point of time that it is not used. So in the other branch that does *not* call drop(value) (As a partially deinitialized can't be used anyway, that would be totally doable.) The big downside would be that that would make the deinitialization of values slightly non-deterministic, which is also the reason this method was decided against. (Though sometimes I think it would have been nice if rust had just decided to just do the deinitialization always as soon as possible, but it might also have some other considerations like code size.)

There is an additional difference between semaphore and mutex. Semaphore can be controlled by anyone who got access to it, while mutex can only be released by the thread that locked it. Mutex is more of a monitor rather than semaphore.

He always reminds me of one of the voice actors in elder scrolls. Especially when he speaks the way he does in the first second of this video

I work with AI, I use both Python and Rust. I don't know Mojo (yet). This debate irritated me quite a bit - good debate, but I mildly disagree 🙂 We don't use python for its speed! Python is good language to "configure" frameworks like Keras, Torch, Tensorflow or Scikit - that are implemented in c++. Rust is a great replacement for that c++, not for python. Will Mojo be that c++ replacement? I have doubts. Can you trust a language rooted in Python-like prototyping to write hardcore numerical libraries? I would need some more convincing. When somebody says that it is 50% faster than Rust, that does not elicit trust - it just creates hype. On the other hand, to replace Python, Mojo would need to have a library support comparable to python - why would you use it otherwise? Again - we don't use python for its speed... Funny enough - Rust's speed or safety may as well not be the main reason to use it. I have started to rewrite some of my python code to Rust not to gain speed, but mainly for the excellent type-system and secondary for its ability to compile to wasm.

1. you can just quote the command `hyperfine "node src/index.js"` 2. The point about dropping I think is because the drop for the Vec is put after the recursive call, so it's preventing the TCO?

For those that don’t know C# can compile to native code just like Go. In terms of speed C#, Java and Go are very similar for many tasks. For pure synthetic benchmarks it’s C# > Go > Java. You have greater memory control in C# than the competitors.

I almost ended up with a Arc mutex hashmap but you saved me from that mistake a few days ago lol.

It sounds like mojo copy on write is like swift. What rust offers is contiguous memory layouts which gains from cache hits.

I was skeptical of Mojo, but when I looked to the example in this video I said to myself: "they are mixing Rust and Python, ok lets them cook". I downloaded mojo and play with it a bit. Looks good. I am doing some test. The python library integration is ok but not perfect. The killer feature over Rust is not speed but the mojo REPL! I need a REPL for developing my data analysis code. That is the thing all those lispers were saying all this time. And Mojo gives me an REPL for dev and static compilation. That is huge win. Julia didn't have that and struggled with the JIT lag for more than 10 years due to bad language design. Now I am waiting if the guys from Modular deliver and release the language to the public (with a proper foundation) and they don't mess up the syntax too much. I am starting to feel the hype, and it worries me.

10:35 actually got me there prime, damn, ''ruby is not skill issue, it's just slow'' Phew xD, really messed up with my head, got me in the first half, had to recheck the video for the graph xD

Modular pinned Primeagen who then passed Modular by reference.

To prove the TCO example, you could write a for loop that allocates the vector the same number of times. I mean if the idea of TCO and TCE is to make recursive algorithms work as iterative then this should be a fair example of the advantages of having that optimization. My understanding is that since stack variables are eagerly destructed, every time you stop using a variable, the stack pointer decrements so when you get at the end of the funcion, your next stack starts where the old one was. This improves locality and you can work exclusively in cache, making the mojo version significantly faster, your playing with registers at that point.

If you compile targeting a native CPU typically rust will auto-generate SIMD code for you, which you can see on compiler explorer with quite simple code. It becomes more fiddly if you want something that is more platform independent, or if you have dynamic input sizes which always mean you get a couple of items left at the end of the array, the remainder from array_size / sims_block_size, then you need to write painful hand-cranked stuff, but if you know what platform you are running on and compile for it you get most of the benefit without writing specialist code, just as MOJO does.

If the argument for migrating from python adding 15% learning to get 100x performance would be an irresistible value proposition, then everyone would be writing Nim or Julia

Bro I’m never forgetting what a mutex or semaphore is after that godly explanation. 13:00

To be honest though, Ruby also comes with a JIT compiler (a recent new feature) so it can be sped up if needed.

So the problem with tail-call optimization in this instance is that they added an extra semicolon, that's it. That's a feature that's in C as well, tail-call optimization only happens when you're returning the final expression. Also, the reason Vector::new() is faster is the allocation gets optimized away.

I'd love to see Prime react to an interview Chris Lattner did on how Mojo works and what's happening behind the scenes. I don't think most people realize that Mojo is simply using Python as the syntactical glue for a completely different set of backend processes. To use a car analogy, if Python is a Toyota Camry it's syntax is the paint job and decaling on the outside of the car. Mojo is a Formula 1 car that uses the same paint color as Python's Toyota Camry but it also has cool racing stripes and decals for the superset features/syntax. When I hear people talk about Mojo it's as if they think the language is still a Python Toyota Camry with some aftermarket mods to make it faster which leads them to think it can't possibly be as fast as something like Rust which to them is racecar. Nope Mojo is an actual Formula 1 car with a familiar Python paint job. That's about all they have in common. Which clears up why there's so much appeal. Mojo is basically telling Python programmers you just need to learn a few new concepts and some additional syntax and you'll be able to drive this Formula 1 car. What's even better is that it'll feel almost as easy to drive as your Toyota Camry which you can still drive whenever you want.

I honestly LOVE that Mojo programmers are called Mojicians. It just sounds cool. A programming magician. Honestly sounds better than Rustaceans and Pythonistas.

At 17:25 did the article confuse move semantics and copy semantics? Rust moves by default to avoid copying the string. In case of copy the original foo would be available for dbg!(foo) and there wouldn't be a compiler error. Primagen should point this out.

27:00 i believe odin does that with their built vector classes and matrices. able to get the power out of simd but have it implicitly built in. Zig is also getting them as well, but Odin is technically 1.0 already.

He's saying tail call optimization isn't possible because of the scope level deferred memory managment. Meaning for that specific use tail call optimization isn't possible for Rust. Whereas for Mojo, given they are not deferring scope cleanup at the end of each call (end of scope), it easily facilitates tail call optimization. In other words Mojo will provide tail call optimization for generalized use whereas Rust only provides it in subsets where scope does not require memory allocation clean up until scope destruction. This is also why the "drop" didn't fix the issue because it's not changing the deferred scope destruction. In Rust, "drop" flags the allocation for scope destruction. Effectively changing nothing.

I have no idea what's going on in this video, but I find it fascinating

the point prime made at @19:24 about the ownership being orthogonal to the type is actually quite good. I wish rust did this the other way round. It seems the fell into a trap trying to make references similar to C++ references. the could required you to say things like `ref` and `owned/copy/clone`. and also remove the idea of implicit copies and require you to always .clone() something.

As a mainframe coder I used Java/several other packages/ assemble/cobal (note it can talk to rust code)/etc./c/c++(overloaded, virtual memory problems) ... Java to talk to Rust, Go to manage HTML NONSENSE, ETC., ...

How would mojo work e.g. with scope_guards? Are there any ways to extend the lifetime to the end of the scope?

great we needed one more language, can't wait for the next one

Why do you harp about Arc over and over, it is a way for multiple threads/tasks to safely share same recourse, it is not specific to Rust, other languages have that too.

You use hot-reloading to solve compile times in the debug builds It's the best of both worlds

If Mojo can have Pydantic data structs with validation, HTTP libs for serving and posting, database connectors and a kafka connector or something in addition to the AI stuff on the standard library, it could potentially be THE lang for AI powered web

There’s a “tailcall” crate which adds an annotation (derived trait) to functions.

If there is one person qualified to make a new language it's chris lattner. These discussions are better approached with a very fresh perspective + very open mind. that's the only way to properly evaluate them and truly understand the essence behind the point that the other side is making

28:57 What he might have omitted there is that RAII does not necessarily means heap allocation. Basically, if you are not using new, the memory for the object will be allocated in the stack. And allocating in the stack is one instruction, freeing is one instruction, no matter how many objects are allocated in the function. So this is far better than GC (if you forget that C# allows to put structs in the stack). On the other hand, yeah, malloc/free can feel slower than a GC in many cases.

~40:00 Maybe rust in current iteration of the compiler in release mode can detect that vec is not used and DCE it out of existence. More proper test would be to do something with vec. Honestly, at that time it'd be necessary to look at assembler code. (I'm not fan of their copies, it seems it can create a lot of headaches, if some things will be copied deeply, some not, but hopefully they thought of it and there will be no auto_ptr 2.0 but with every copyable type)

Has he already covered with the community the Julia Language ?

They've actually changed the article on part for Tail Call Optimization. it might be worth rereading that part.

recently doing vhdl for a course. A simple clock have a complie time of 10 minutes.

CNC maschines are programmed with C here in germany. Depending on cpu and how mojo works their will be a bright future for it. But for I dont know how this will be on a cnc maschine cuz they need execute one after the other and not parallel thats how a cnc works

One thing i don’t like about rust is it is not predictable what the compiler does in many cases in terms of optimization. I frequently find some weird not-optimized-away reason here or there in the user forum. But i guess this improves over-time.

respect to mojo for using "fn" instead of "def"

I was curious and did some reading, because I was curious how Mojo can claim pass-by-reference as a default, and also better semantics. Maybe folks in the know could clear things up for me? I see that Mojo currently has implementations of neither explicit lifetimes, nor enforcement around taking immutable references when a mutable reference is still alive. I'm also unclear on how Mojo ending lifetimes at point of last call makes reference lifetime semantics easier to reference about. Does that just mean that every reference is an RC by default? Also, doesn't the eventual implementation of mutable borrow enforcement have the potential to introduce a lot of complexity into this system? And, if passing by `owned` sometimes references, and sometimes moves, doesn't that also force the programmer to understand how the Mojo compiler works to identify performance bottlenecks, and gets an extra level of complication when mutable borrows are enforced? It must be that Mojo will eventually *actually* move the value if it's mutated and has other references alive, so that introduces a third branch of implicit behavior that you might have to track. At least, presumably, package authors will. It's logically impossible that Mojo can be faster than Rust (or even faster than Go above a certain level of borrowing complexity?), have less implicit copying (or much more use of reference counting), and have simpler ownership semantics, right? Unless they've found some new proofs around ownership that unlock fundamentally different approaches to resolving ownership. I just want to make sure I'm not missing something/too stupid to understand it before I form a strong opinion about how much this cart is being put before the horse. EDIT: I see now that Mojo doesn't support *returning* references, because that's obviously what causes the need for explicit lifetimes. That removes the needs for RCs, surely reasoning about lifetimes becomes *more* difficult, and not less, when ownership doesn't necessarily last until the end of a scope?

I'm all about the idiot-matic...i write code, come back 6 months later and think: "which idiot wrote this?...oh"

Hey, I wonder if you could have a proc macro in Rust that would get passed a standard function and would transform all `i32`, `f64`, etc into their SIMD counterparts behind the scenes

the compatibility of linux distros is only limited to ubuntu, as a debian user I haven't experienced what it's like to program using mojo.

Sounds like hype to me. Good to keep an eye on it

The article is updated, one more reason to trust Modular, they react to community feedback and point out their mistakes.

This article is pure marketing. These guys should have just taken the L and walked away. They make a lot of false arguments and they cherry picked that final benchmark, with something that was completely simulated. In the mojo example, the compiler actually just calls the main function and then returns because no work is being done in the program. The same happens in the rust variant when you use the vector macro instead of the with capacity call. Rust can use the same back end as mojo and it also can be optimized for SIMD. This idea that somehow a Python dev is going to have zero friction learning mojo and also get the better performance that rust is absurd. With the straight up false statements that they made in this article, I'm not going to believe anything that these people write in the future.

GC requires indirect access. Direct allocation/deallocation can cause fragmentation. Rust tends to have larger continuous struts than copy on write memory management. Explicit memory management can run in far smaller memory usage.

The Vec with capacity allocates the vector whereas the new Vec is removed by the compiler because it's never used. I do not know Rust but from a general compiler viewpoint, this would be logical. Rust might even "zero" out the memory allocated to the Vec of capacity. Mojo seems to just wait to allocate until a value is pushed to the vector meaning it never allocates any memory for the Vector in the given example.

One more Important thing to realise, If you know python and have learned Rust, you are more close to learn Mojo. Because Mojo also introducing features from Rust like Ownership and Borrowing etc. Adding such features will have a skill issue impact on Python developer interested in learning Mojo. Because al-least you need to learn those concept before using them.

What is the Rust book shown at the beginning of the video? 5:03

For games use their custom interfaces along with Mojo/Java/etc.

46:15 Prime agrees with Prime

42:52 my guess is that, because they delete objects as soon as they arent in use, and becausethe vec‘s never in use, that they never alocate until u write code that uses it.

wait i am watching him after like 6 months, why does he have a lettuce on his head??

32:20 TCO i know, but what is TCE tail call elimination?

What happened to the earlier upload? Was watching it partway, refreshed the page, and suddenly it got privated lol (it was about HTNX)

Resource Acquisition is Initialization!

9:12 And *_Odin_* !!! And *_Ada_* !!! How dare you forget about them, @ThePrimeTimeagen ? 😄

You should write an LSP in C++

I don't why you can't use Go and Rust together as appropriate, java/Rust, HTML/etc. Mojo ... (mainframe does do assemble), Mojo < internet>, heavy data management: Rust ,Java for human interactive code to the other systems.

22:24 FLASHBANG WARNING!

If we start to account for skill issues, then Java can be as fast as Rust/C++ or even faster (after warmup), because having enough skill you can write garbage-free code and make mnual memory allocations/deallocations. And the part that can make it faster is JIT optimizations, which can be done in current specific usecase, like look-unwinding or operation reordering, which C++ or Rust simply cannot do, because they don't know how the code they produce will be used every time you run a program.

47:30 I think "Would you switch to typescript if introducing this new syntax would allow it to run 100x faster than javascript?" would be even closer analogy. And even I would stop writing vanilla JavaScript if TypeScript were actually faster.

I think Primeagen misread that as "Explain that like I'm 5 years into a Computer Science program"

@22:13 I don't quite get that point they made. if every object has an identity then there must be some indirection happening there. if every object has an identity then that means there is a lookup to get any object ( aside from direct memory location ). If the lookup is insignificant then the argument is fine. but if you always have to first lookup the objects id then get it's location in memory that's obviously a penalty that you don't have to pay with Pinning in rust. The idea of pining is that data can be at 0x01 and it moves to 0x9. any one who assumed it was at 0x01 needs to know that it's now at 0x9. pinning allows you to not have allocate dynamic memory all the time.

22:37 Mojoheads🔥

9:33 couldn't explain any better. The higher tier requires skill cause even though you can produce correct code in c but if you end up freeing memory more often than a garbage collected language your program will be slower. It's not only the fact that the freeing is done manually, it's cause you can do it less often and in moments where it bothers the less. I call the top tier languages deterministic, you know what they are doing at a given moment.

Whenever you consider performance, you also have to consider the optimizations you never had time to do - and the slow "good enough" implementations that you don't have time to improve. This is why I advocate for Python and am super excited about Mojo. Mojo will be 10x faster than Rust/Go (in individual real-world applications) if it improves the speed of iteration, the number of developers who can contribute, and the readability of the code.

I have no clue what any of this means but I can't stop watching.

Vec::with_capacity allocates on the heap. Vec::new doesn't

From the official Mojo manual: "Mojo uses a third approach called “ownership” that relies on a collection of rules that programmers must follow when passing values. The rules ensure there is only one “owner” for each chunk of memory at a time, and that the memory is deallocated accordingly. In this way, Mojo automatically allocates and deallocates heap memory for you, but it does so in a way that’s deterministic and safe from errors such as use-after-free, double-free and memory leaks. Plus, it does so with a very low performance overhead." So it's much closer to Rust than Java or J# or JS.

mans killing it with the semi transperant hair - special effects like 1940

27:36 RAII (cpp) vs GC (gsrbage collector)

Java and C# run on a runtime which is faster than running on an interpreter but not as fast as it could be by running straight on the metal, like compiled languages