Mojo Is FASTER Than Rust

Recorded live on twitch, GET IN
/ theprimeagen
Become a backend engineer. Its my favorite site
boot.dev/?promo=PRIMEYT
This is also the best way to support me is to support yourself becoming a better backend engineer.
Article link: www.modular.com/blog/outperfo...
By: Mohamed Mabrouk
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Kinesis Advantage 360: bit.ly/Prime-Kinesis
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts

[@shinjiku144]

How to scare a VIM user? Make them use their mouse 9:08

[@creativecraving]

❤ Real talk! It's a disorienting experience, sometimes. 😅

[@thatmg]

The struggle is real.

[@crimsonmegumin]

it would be funnier if he pressed ":q" lol

[@mgord9518]

Brave of you to assume I have a mouse

[@lezzbmm]

dude was shook tbh

[@CaptainOachkatzl]

write bad code -> write optimized code in different language -> post article -> wait till prime posts it with clickbait title

[@Navhkrin]

1. Comparison to Rust is done aganist best lib that does same operation on Rust, not written by same author. 2. Both are pretty decently optimized and have extremely similar logic flows.

[@J-Kimble]

Yeah and who would have thought SIMD optimization makes processing faster.. the shock..

[@zeratax]

@@J-Kimblesure but if it is easy to write simd in mojo that’s pretty cool

[@PeterKilian]

@@zeratax don’t bother, yt comments are made by zombies.

[@Dooezzz]

'Tensor is one eigenvalue less than elevensor' 😂

[@evian8976]

lol

[@paladynee]

monad is a monoid in the category of endofunctors

[@monad_tcp]

Tensor is just a jagged array with 3 or more levels. Why do physicists have to make their data structures sound fancy.

[@johanngambolputty5351]

@@monad_tcp It really isn't just fanciness lol, tensors are not about the numbers required to represent them in a given coordinate system, they are about making sure that no matter what coordinate system is used, you end up expressing the same quantity.

[@Michallote]

​​@@monad_tcpyou know tensors where arround before computers even existed right? We are talking about 1800's or so mathematics.

[@thatmg]

What an idiomatic pythonic nascent article this was.

[@ninocraft1]

real

[@halneufmille]

The end of the blog post of viralinstruction about this benchmark sums up my thought about Mojo and Julia perfectly: To me, Julia seems like such an obvious solution to the two-language problem in bioinformatics (and in deep learning). All the hard problems with bridging speed and dynamism have essentially been solved in Julia. At the same time, the language remains niche, mostly because it still has too many rough edges and usability issues, such as latency, the inability to statically analyse Julia or compile executable binaries. But these issues are not fundamental to the language - they're rather in the category of ordinary engineering problems. Solving them is mostly "just" a matter of putting in tens of thousands of professional dev hours, which is a matter of getting tens of millions of euros to pay for hiring people to do the job. It does grate me then, when someone else manages to raise 100M dollars on the premise of reinventing the wheel [a.k.a. Mojo] to solve the exact same problem, but from a worse starting point because they start from zero and they want to retain Python compatibility. Think of what money like that could do to Julia!

[@MrAbrazildo]

So has Julia a smaller learning curve than Rust?

[@RazgrizDuTTA]

@@MrAbrazildo Julia is very easy to use. If you avoid a few common mistakes, you can quickly write fast programs. Squeezing the last drops of performance can be tough though.

[@ck-dl4to]

They want Python codes to run fast as C lol

[@MrAbrazildo]

​@@ck-dl4toI guess it's easier to make C++ has efficient high-level features, like ranges.

[@Navhkrin]

This argument is mostly raised by Julia fans, but it really doesn't make sense. It is more of a wishful thinking from a Julia fan rather than a good argument. 1. Julia syntax sucks vs Mojo syntax. 2. Mojo is more than Julia. It isn't "just an alternative". Mojo solves far more problems than Julia ever aimed to solve. Some advantages that Mojo has over Julia: 1. Allows access to MLIR intrinsics directly, which makes adding support for fancy accelerators CONSIDERABLY easier. 2. Native GPU codegen allows un-before-seen heterogeneous compute abilities that is extremely simple to use. 3. Better syntax decisions 4. Supports both AOT and JIT. This makes compiler chain SIGNIFICANTLY more complex and advanced than a language that just supports 1. This is also what supercharges Mojo with dynamism of an interpreted language and performance of a AoT compiled language. At that point, it really wouldn't make to spend dev effort on enhancing Julia. Because Julia has achieved only 5% of what Mojo aims to achieve and it doesn't start on strong foundations to begin with. If we are going to have to engineer 95% anyways, much better to start fresh with better foundations instead.

[@ragectl]

No performance benchmark articles or claims should be taken seriously unless they provide the full code examples, environment details, and details of all optimizations applied. Saying x is faster than y is "trust me bro" level.

[@mahakasem810]

Oh man, go look at the embedded ML space. It's so littered with this exact problem.

[@PeterFaria]

I played around with Mojo after reading that article. The SIMD type doesn’t do any bounds-checking, and also doesn’t zero-out unset values. It sacrifices a lot of safety for the sake of performance.

[@thedoctor5478]

it zeros-out deez nutz pretty gud

[@Julian.u7]

And that is a good thing. Nothing more annoying than unsolicited safety

[@thedoctor5478]

and unsolicited nutz@@Julian.u7

[@isodoubIet]

@@Julian.u7 Sure but the whole marketing spiel around this language was how it's literally python but Blazingly Fast™. In contrast, the code in this article would actually be much superior had it been written in C++.

[@ryanlog]

SIMDeez nuts

[@djupstaten2328]

iterators/generators/coroutines are actually faster than traditional (while and for-in) loops in python because they are very thin c-wrappers under the hood (thinner than the original ones).

[@nevokrien95]

Yes but u r still stuck with dynamic typing and the gill So every single operation is a type check and the you preform it and on top of that you can't use ur 32 cores... If mojo solves this it could be nice but gill is actually a key thing for a lot of the c packages that ai uses. And u need to then compare to Julia and R and I doubt it would be much better. Cython existed for quite a while And it was used to write a lot of these packages. It also gives u low level control and other nice stuff. I think mojo can be basically tensor cython which would be really nice but not a take over everything very nice. It still has a compile step which is a bit to slow for my taste

[@maksymiliank5135]

​@@nevokrien95Mojo has static typing. It also has structs which are a static version of classes. No additional runtime checks if a field exists are needed. It supports simd parallelization and even running your code on the gpu in a pretty simple syntax if I remember correctly. You should check out the original Mojo demo/teaser video.

[@DoomTobi]

Is that true though? Aren't they "just" faster because they avoid appending to a dynamic array all the time?

[@nevokrien95]

@DoomTobi dynamic array appending is 100% fine even c++ does it. Sure usually they reserve it but like.. log(n) slowness is probably not it. Gens and maps are not that much faster in my exprince. U can use ThreadPoolExecutor and map on it then it's like 20x faster because it actually uses the god dam cores. In a regular python for loop here is all the operations I can think of: 1. Allocate a new heap object for the loop var and write to it. 2. Type check the loop var 3. Actually do the arithmetic 4. Decrement the var reference count 5. Figure out the var is our of scope later on. It's like 4 junk operations per actual thing. BTW 5 is actualy very slow it's a whole graph dependency thing and 1. Fucks ur cach locality. Now if u r using a generator and a sum u can change this to 1. Get the next pointer 2. Follow it to the object 3. Type check the object 4.do arithmetic Because u know build in generators don't get to bleed references out. And u know a + operation on an int or float does bot requite u to save the object. And you know because if the Gill no one is freeing those objects. So are they actually use this trick? Idk I bet pypy does and I would venture cython is doing so as well

[@ck-dl4to]

​@@nevokrien95 Compiler does

[@magfal]

I taught a bioinformatician that he could run python or rust inside the database they were using: Postgres He took one of his jobs and moved it to the db to skip the overhead. It was a bit more than 100 times faster than how they had been doing that task.

[@farrela.846]

Care to elaborate or drop some keywords about this? I'm curious about how it works and what we can do with it. Thanks!

[@magfal]

@@farrela.846 you can run your code within the context of the database server rather than have your code fetch data and push it back over a high overhead connection. PGRX is the rust option pl/pythonu is the Python option

[@magfal]

@@farrela.846 pgrx pl/pythonu

[@mateusvmv]

@@farrela.846 Postgres Procedural Languages Reminds me of EVCXR, which can be used in jupyter, but I **think** PL/Rust compiles at creation time

[@thedoctor5478]

Chapter 46. PL/Python - Python Procedural Language of the postgres docs, which is crazy that I didn't even know about until just now despite using both Python and postgres daily since like forever.@@farrela.846

[@ferdynandkiepski5026]

If you're writing an article that mentions performance you have to provide all the compiler options that you used. If the rust implementation didn't have the target-cpu=native codegen flag set and the --release flag then it is an unfair comparison. And since he used a library for the rust implementation true lto would also probably improve performance. So a set of compiler flags for all languages used is needed to make it a fairer comparison.

[@sammysheep]

Bioinformatics often relies on CLI tools, embarrassingly parallel tasks, and pipelined data processing. I think Rust is positioned well for the CS/Bioinformatics methodologist, but maybe not with universal appeal given the learning curve, for data analysts.

[@gristlelollygag]

Sounds interesting, could you elaborate? (tag me/like the comment so i get a notification)

[@mistdoyhta696]

rust is the worst when it comes to GPU computing

[@KilgoreTroutAsf]

As a seasoned HPC developer I have to confess the lack of scientific, mathematuc and engineering knowledge of the average FANG drone is as mindboggling as it is scary. I really have no idea what they teach you for four years of a CS degree at the uni. Fingerpainting, seemingly.

[@the_mastermage]

Mojo won't be useable until it goes Open Source and until it fulfills its promise to be an actual python superset (it still calls the underlying python runtime for pure python code)

[@SMorales851]

What do you mean? Why does calling the python runtime makes it not a superset of python? If it's straight up python with some added things its a superset in the most literal way possible.

[@hammerheadcorvette4]

Cython better?

[@darkalleycomics4028]

I tried it it took me 1 min to hit that I can't create a "class" and I can't use f-strings. The "superset" of python at this time is all marketing. They shouldn't have released anything until python was fully implemented. Why not do that first, then add new features? I kind of feel like they are just taking advantage of every python developer's desire to have a faster python.

[@vsantos1]

Open source enthusiast 🤓

[@bobbymorelli9763]

lol

[@gilpo]

Bioinformatician here (yes, it's a real field of science!). Most of us come from a bio or stats background and were then taught how to program and how to use analysis tools in grad school. Most of us are unfamiliar with low-level languages such as C or Rust because loads of us didn't have a solid CS background and the learning curve is just too steep for people whose main focus is solving biological issues and keeping up to date with literature and modern data analysis techniques. So most low-level tooling is actually made by CS people working in collaboration with bioinformaticians. I mean... think about it, low-level programming is as hard as it is for full-time computer scientists and requires loads of deep knowledge on how CPUs, memory and OSes work now couple that with also having to master the complex science which is biology, knowing how genes, transcription, translation, mutations, DNA/RNA works and large biochemical regulatory networks and you can see why Python and R are so popular in our field. The barrier of entry is much lower for people from hardcore biology backgrounds and it allows us to engineer performant enough complex data analysis pipelines without having to understand and worry about stuff like memory allocation and pointers...

[@halneufmille]

You may want to check Julia then. It was designed specifically to be as fast as C and Fortran, but as easy to write as Python, but with more modern syntax.

[@gilpo]

@@halneufmille I'm aware of Julia, though it seems more like a replacement to MATLAB than Python, it seems more geared towards engineering than data analysis

[@Endelin]

Watch Mojo be the name of some obscure snake species.

[@SPeeSimon]

No. It's the name of a big (music) concert promoter. :)

[@johanngambolputty5351]

Watch WatchMojo make a video of the top ten comments accidentally mentioning WatchMojo.

[@nathanielsimard5908]

The best-case scenario isn't to have a fast programming language so that data scientists can write optimized versions of their algorithms; it's to have a high-level library that does all of those optimizations for free. Way faster experimentation speed this way.

[@kirillgimranov4943]

"Mojo is faster than rust" And the whole article contains just a sentence mentioning rust once that saying "I implemented it in rust and it was slower" Let's just make jokes about the author and say like he just compiled without a release flag or something

[@psychoinferno4227]

The rust crate is searching for both ' ' and ' ' while the Mojo function is only searching for one character which defaults to ' '. Is it any wonder the Mojo version is faster when the Rust version is doing twice the work?

[@marktaylor7162]

5:08 The term for idiomatic Rust should be 'Rustaceous'.

[@iAmPyroglyph]

Why not just "Rusty"?

[@marktaylor7162]

@@iAmPyroglyph Because I think 'Rustaceous' sounds cooler, and also because it sounds more like it's related to 'Rustacean'.

[@Luxalpa]

Rustalicious!

[@raffimolero64]

Rustic

[@thekwoka4707]

Not shwoing any of the Rust code makes this highly sus...

[@adhalianna]

I have a weird suspicion that they might have even done a debug compilation instead of the optimized one. The fact that we cannot check even for that typical mistake is very suspicious.

[@SciDiFuoco13]

According to their Github page however their implementation and needtail have pretty much the same performance (sometimes one wins, sometimes the other). Unfortunately I can't reproduce them since Mojo on my PC (WSL) immediately segfaults due to issue 1260... Also, this is nothing particularly difficult to code: the benchmark is just measuring how fast you can read a file and split it into lines.

[@blenderpanzi]

As I understand it tensors are n-dimensional matrices with all kinds of matrix operations and "broadcasting" of other operations (think SIMD, but because n-dimensions more complex and you have to think about what is happening rows/columns wise). Good tensor libraries have multiple kernels, usually you use a GPU (CUDA) kernel where all the operations run in parallel on your GPU(s). Therefore your ML program can be written in Python, since the actual heavy operations are (JIT compiled? (dunno) and) run on the GPU. PS: Out of curiosity I started to write a small matrix (not tensor) library in Rust nightly. You can do fun optimizations in Rust because of the ownership model where you elide allocations. Think you do mtx1 + mtx2, but at least one of the parameters are passed as owned. You can impl the Add trait so that in that case you simply reuse the memory of that parameter and do a += instead. However, there are limitations. To make this all somewhat nice you need to use nightly for better const generics and it all gets really complex and redundant quickly and I managed to crash rustc.

[@randomcubestuff3426]

a tensor is just an element of a tensor product of vector spaces :thumbsup

[@isodoubIet]

The "right" way to handle those kinds of optimizations is with expression templates (C++ name ofc, have no idea what the idea is called in Rust but from what I know it should be possible). The idea is that you build the computation graph in the type system. For example, instead of having the result of mat1 + mat2 be another matrix, you have it be a MatPlus. Then if you do (mat1 + mat2) * mat3, the type will be MatTimes, and so on. You only actually effect the computation when you actually want to store the result somewhere, at which point the whole thing can be optimized by SIMD, fused-multiply-adds, whatever makes it fastest while minimizing cache misses.

[@gabereiser]

The whole article smells of GPT.

[@WizardofWestmarch]

I don't remember if they were able to leave it on but one thing to keep in mind on C vs Rust is, if LLVM works correctly now, Rust's aliasing rules allows avoiding rechecking memory to ensure the register and memory are still in sync since C lets you arbitrarily alias a block of memory infinite times with multiple of them being writeable.

[@humansaremortal3803]

Worked with some of the people doing "bio-informatics" for two years. They don't code, nor do they have desire to code. I was paid to code, while they were dealing with cells, sequencing, proteins and bunch of other things that I had zero interest in. Some of them are as autistic as average programmer, meaning some of them are decent company.

[@sammysheep]

This is not generally true. We are split between data analysts and methodologists. Most code the equivalent of a data science and data engineering level. Methodologists can be mathematicians and computer scientists, and code at a deeper level or more esoteric level. Hence the two language problem cited above.

[@flynn3649]

Bro dropping new words in his articles

[@karter_devolidad]

Nascent looks to be nascent

[@jazzycoder]

You know when anyone can be a developer these days when you hear them saying 'bro' 😂

[@ninocraft1]

​@@jazzycoder r u retard?

[@_zh3ro_]

nascent comes from Latin, so if you speak any language other than English that happens to be Latin based, it suddenly becomes not that fancy

[@victorybhg]

it’s hard to compare the same class of programming language on performance as any language of the same class ( gc, vm, etc ) can be optimized by their respective compilers to relatively the same performance as everything gets to machine code eventually, what does make the difference is whether the language is able to allow the dev to express the most performant set of algorithms that is allowed by the target hardware resources ( cpu, gpu, memory, disk, etc ). it seems mojo is able to expose these interfaces ( simd vectors etc ) more than other languages doesn’t mean that those other languages can’t also have these interfaces as well. it comes down to what provides the easiest path for the domain experts to do what they need to do.

[@jonnyso1]

Is this the one he forgot to compile in release mode ?

[@jpratt8676]

Nooooo say it ain't so

[@sdi87hhk]

that "cool story bro" sounded personal lol

[@johanngambolputty5351]

I spent a lot of time in python and I'm very glad that I did, because it never needed to be fast, in fact it could have been 1000x slower and I still would have got the same experiments/prototypes done. I swapped when I started trying static analysis, which was just yelling about a bunch of my old code not adhering to stylistic standards or because it couldn't infer what I was doing with certain variables, at that point I might as well strongly type and get useful comments from the linting. I haven't really looked at Mojo, but Rust has some very tasty generics and meta-programming, which has the potential to let you get a lot more done with less code, which is what I've always loved.

[@vatanak8146]

Python has type hints you know?

[@johanngambolputty5351]

@@vatanak8146 I know, but when I tried it, it was hit and miss. It's funny though, because if you don't want random warnings (from rufflsp I think) everywhere you end up having to explicitly annotate more variables than in rust.

[@joe5head]

1:10 thousands of machines each worth several millions of dollars

[@enkiimuto1041]

This was the weirdest watch mojo I saw.

[@earx23]

SIMD done in intrinsics in Rust will probably beat the pants off of that implementation. The beauty of Rust in this case is, even if it's just a kind of assembler without the explicit register bookkeeping, that its typing system makes you more aware of float to int type conversions, which are very expensive. Porting my intrinsics from C over to Rust yielded a nice speed boost.

[@VivBrodock]

Prime: "idk what a tensor is" Me, a math major currently learning tensors: "idk what a tensor is either"

[@0xnika]

Dude, you are breaking the green screen with your hair!

[@tajkris]

1:55 Write your critical path in a way that mostly uses primitives and you're good to forget about GC. In fact, most popular jvms have escape analysis implemented to allocate objects on the stack instead of heap, so if you're careful enough you can use classes too. Not that I am a fan of Java, but if they can write low latency algorithmic trading systems (tens of microseconds or lower to deserialize a price tick, make a decision, prepare an order, serialize and push it out to the network card), high throughput message processing system (Kafka), or highly optimized low latency, concurrent, lock-free queue (LMAX disruptor) then I'm sure it can handle bioinformatics too.

[@elgalas]

Mojo looks fun. Been doing Aoc with it, but it is still way too early for it! I ran into multiple bugs when using parallelism

[@9SMTM6]

hyperfine, which he used as benchmark tool, actually does a few runs under the hood, and calculates the standard deviation etc. for it. So it's not 'just one run'. Still, as others highlighted, there are a few other things where at the very least he did not prove that he did it right. Such as whether he used SIMD in Rust (likely not, and SIMD can easily be responsible for more than a 50% speedup). Whether SIMD in Rust is in an usable state is another question. I've never tried it myself (in Rust), that that could be a good motivation. But it's a less catchy title. Honestly Mojo as a language is very tempting to me. I love Rust, but really, getting others to use it, when it does take a decent bit of time to do properly, is difficult, and must be justified. Mojo promises me the ability to write similar code to Rust, while still being at least somewhat editable for others. The big issue with Mojo is licensing (and, underlying, the VC funding of Mojo). Frankly I don't see how they intend to make back their money without eventually doing things I'm not going to be happy with.

[@bravethomasyt]

This code has been heavily criticised in the Rust community, and it's expected that, done properly, rust will be faster. It's a clickbait article.

[@dixaba]

You can almost always write a faster version if you make some assumptions: "No, that format is outdated", "Nah, surely there will be no right-to-left languages used", "Of course every file will end with an empty line" and so on. And even if you write code in accordance to specifications, other widely used tools almost always will have quite a bit of QoL features, which can easily become dealbreakers for end users. As an example, GNU grep does support Perl-compatible regular expressions (using -P flag), while POSIX grep does not. If you write your blazingly 🔥fast 🔥Mojo 🔥grep 🔥that is only POSIX-compliant, it will work for some users, while many other users (including myself) won't even consider it.

[@J0R1AN]

9:08 Average VIM experience

[@boccobadz]

I call it BS, exactly like the guy from Reddit. As someone with MSc in Electronics & Computer Science in Medicine, I've done some stuff with bioinformatics algos in Cpp (even though it wasn't my main field of expertise) and I doubt that this mojo code can outperform highly optimized and battle-tested Cpp parsers (written by much smarter and better-paid people than this article's author). I feel it's the same as their example with mojo magic being faster than their hand-written Python code for matrix multiplication instead of benchmarking it against numpy (which has nothing to do with python because it's a wrapper on 40 yo Fortran lib). Again, it's an advertisement full of BS - if it was so great and magical, it would be open source already.

[@Exilum]

0:45 This actually brought back a core memory. Back when I was in highschool, I used "learnt" a lot because it was how English was supposed to be. But I eventually figured out that few English speakers actually knew that, and used learned instead. Now, I intentionally use the incorrect learned form because it's just how the language evolved. Learn just isn't treated as the irregular verb it is.

[@NibbleMeTwice]

Good on you for having learned a second language.

[@samarrowsmith2723]

Start calling people "my learned friend" where you voice the last 'e' and we can start a movement

[@apaz-cli]

I work as a researcher, and I'm building these kinds of tooling and data pipelines, but have literally never heard of anyone using Mojo. The general consensus is that it's not even a contender until they open source it. I haven't even heard anybody talk about it for at least a few months, which in the machine learning world is an eternity. I legitimately forgot that they existed. Even if Modular does open source it, I doubt their ability to beat the Huggingface model serving ecosystem, which is all in Rust. I hope that Modular pivots before they burn the whole hundred million dollars they raised. I don't think they actually understand the problem they're trying to solve.

[@abinavravi1063]

Mojo seems like a movement towards rust while retaining python syntax to an extent, they have structs and traits over classes and OOP world.

[@mattythebatty1]

Why don't they use a binary file format for such massive datasets?

[@ErazerPT]

Was wondering the same because especially field 2 has just 10 possibilities, ie, you could pack each element into a nibble and make it 2el/byte. Just that would shave 50% of field size (~25% of the file size)... field 4 is only 7bit (if my math didn't fail me) so, could also shave another 14% by packing 8char>7bytes (of the field), ~7% of file size. All in all, you could definitely gain a lot from just going binary, as just reading such huge files is a lot of I/O time. But truth be said, the whole thing is so repetitive it just screams COMPRESSION!!!!! :P

[@minerscale]

the real crime is reading in 4x the data than is required due to using plaintext...

[@MI08SK]

Right! It doesn't make sense Each letter could be represented in 2 bits! since the only possible letters are A,C,G,T They could reduce memory usage by 4x by switching from one byte letter representation to 2 bit letter representation

[@VudrokWolf]

@@ErazerPTwhile applying for a DNA sequencing company they only seek for differences from a normalized DNA sequence is kind of misleading think they sequence the whole DNA it takes 7 days to make the comparison and find differences. Maybe is faster now this was 6 months ago I did not make it as an bioinformatician. 😢

[@ErazerPT]

@@minerscale 4x is a bit hopeful, but credible. Just tried plain old lzma2 and it was 56>20MB (2.8x), and that's a compressor that knows NOTHING about the format. A proper binary representation could probably arrange things in a way that bitstream compression could exploit to at least 3x+. But yeah, s**t format. Just seeing stuff like start_time=2020-02-26T02:02:24Z makes me wanna scream.

[@TurtleKwitty]

My guess is that people will favor mojo heavily when doing initial parsing and tesintgo ut theories and when it gets cemented then it'll bee pushed voer to whoever was doing the super optimized versions befroe but now they can work on larger data sets while testing theories

[@sweiscool]

"Everybody I know who does Julia loves Julia" - Prime, 2024

[@STChaosman]

Bro, i’m no a native speaker, you’re the only KZbinr for which I put videos @ 0.75 speed

[@nitsanbh]

0:39 Hey Prime, ya can’t have GREEN HAIR and a GREEN SCREEN at the same time

[@RazgrizDuTTA]

I switch from Python to Julia to do my PhD and it's amazing! I have a bad feeling Mojo will kill Julia and waste all that effort just for non-CS devs to avoid learning a new syntax.

[@abdulmuhaimin346]

i just saw this blog, and just looked up , here it is 😂

[@steffahn]

1:07 no, you got that all wrong, it's "thousands of [...] machines"! The "thousands" is the number of machines, and "multi-million dollar" the price of each machine.

[@yakocal]

Which mounts up to billions of dollars worth of machines, and it's what he said...

[@steffahn]

​​@@yakocal No he said "most people say 'billions'" suggesting that the phrase could be simply re-worded to use the shorter "billon" somehow. I disagree with that statement and assume it has only come about by misunderstanding of the sentence structure. I mean, tell me, how WOULD you re-word this? You say "billions of dollars worth of machines". But that sounds weird, too, and loses informations, as in "billions of dollars worth of DNA-sequencing machines are working non-stop ...". Arguably the "thousands of machines" is the CORE information here, given the sentences around it focus not on economics ("how many dollars") but on scale ("how much data processed").

[@karter_devolidad]

​​@@steffahnso we conclude that it's subjective...

[@annoorange123]

Go is an awful name, not search friendly at all. If we're talking about good names, Haskell comes to mind or Elixir.

[@haniffaris8917]

You would expect a google-able name from a language developed by Google, but nope.

[@AggressivesnowmaN]

Prime nailed this take regarding likelihood of adoption. Most in that field would find more use in a fast simple language. I’d be more curious how Mojo compares to things like GO and Cython than Rust. Just because they seem to be after a similar niche

[@uzbekistanplaystaion4BIOScrek]

the more stuff i see from prime about new languages, the more i think c might just be the best tool for the job.

[@AgainPsychoX]

When I heard "Java" in context of "highly optimized tools" I had to take break and walk around to feel better...

[@thedelanyo]

"Biggest takeaway" this keeps me coming back

[@_tsu_]

For such small programs, the progress bar is the thing that slows down the program the most. Looks pretty, very cool for writing heavy duty stuff, but unless your benchmark runs a minute or longer, you should disable the bar and then do it for fair results.

[@griof]

The truth is, Data scientist and researchers will use python... Nobody in this side of tech cares about perf. Or safety. You can always rent more cpu on the cloud. Also, Data scientist don't like to program, and we are very bad programmers actually.

[@_MrKekovich]

The truth is, new tools for python will be written in mojo instead of C/C++. Mojo does not aim to replace python.

[@notoriouslycuriouswombat]

feel you on the idiomatic

[@cbbcbb6803]

Wasn't there a MoJo something used to create the WebOS software for the Palm phone?

[@binary_gaming113]

I used SIMD and it was faster than not using SIMD: The article

[@tobene]

IMO mojo seems really promising, lets hope it will get open sourced soon. It seems like a great alternative to python or matlab for research

[@mytechnotalent]

I live for Prime's thoughts. It is interesting such a claim to be faster than Rust. Single algorithms can't be taken in a vacuum. I would love to see a larger set of benchmarks.

[@thekwoka4707]

Or even the Rust code used...

[@SaHaRaSquad]

@@thekwoka4707 And the Rust compiler flags. In the end Rust also uses LLVM as compiler backend so this 50% claim is difficult to take serious without more details.

[@juancarlospizarromendez3954]

In Rust: A value of type char is a Unicode scalar value, represented as a 32-bit unsigned word ...; In C and probably in the propietary Mojo: 1 char = 1 byte unless another encodings are used. It's why, for 4 letters, ACGT, Rust is worst in speed managing pure ASCII characters.

[@Turalcar]

3:08 The most amusing to me is that there exists a class called "Wirth languages"

[@74mada]

Mojo is like a tiny pebble in Rust's boot. 👌 Video was cool, though! 👏

[@johanngambolputty5351]

I've always hated how the word tensor is used in ML to just describe a ndarray, but I guess you can't blame people being confused when the real definition often is "a tensor is something that transforms like a tensor".

[@michaelhildebrand-faust4039]

Python:Mojo :: JavaScript:Typescript. Look how Typescript has taken over from JS. Same thing will happen with Python -> Mojo.

[@InfiniteQuest86]

This already existed. It's called Julia. You'd have to get all those people to move over. It's too late.

[@GamesmotionTV]

Just wondering if the Rust Community could come up with an equally fast solution. Unfortunately the article did not show any code.

[@thekwoka4707]

Zero2Prod is a great book for sure.

[@melodyogonna]

Those writing Mojo off are very funny. Mojo is just a user interface for MLIR; Chris Lattner and his team wrote MLIR by hand and validated it can be just as fast as Assembly and so performant enough to handle workloads they intended to take. Mojo is just a user interface so they wouldn't have to write MLIR by hand anymore, they could have made it look like anything, they chose Python because that's what the ML community is familiar with. Speaking of Chris Lattner ... That is the same person that started LLVM, Clang, Swift, and MLIR. This isn't some random compiler guy claiming some things, there are track records.

[@anonymousalexander6005]

That’s great… but that just makes me think it will never be an actual Python superset and they only said that for marketing.

[@melodyogonna]

@@anonymousalexander6005 Python isn't hard to implement, there are just 36 keywords, and straightforward semantics. The part that makes it a superset is what they're currently building, and that is the low-level parts Python doesn't have. Also, being a superset is a long-term goal.

[@monad_tcp]

I thought automatic vectorization was a solved problem. Turns out it isn't when you have heterogeneous architectures.

[@lmnts556]

This is true, Chris is a beast that cant be underestimated.

[@UnidimensionalPropheticCatgirl]

I mean LLVM succeeded despite being mismanaged mess, not because of it, swift didn’t get good until he got booted of the project and MLIR hasn’t been widely used yet, so as far I am concerned everything lattner touches is vapor ware until proven otherwise.

[@Beryesa.]

Mojo jojo

[@amansawhney3318]

The problem is that mojo is just using python as a front end for portable simd instrincs. You still need to understand cache coherence and vectorized instructions. Changing the syntax doesn’t just make the barrier to entry lower. I personal use Rust for all my ML and research work.

[@ruroruro]

As a CV/ML Python developer, I despise Mojo's marketing. It's an interesting project with some good potential (especially if they end up opensourcing it), but their marketing is full of borderline lies and clickbait. If they think that this kind of publicity will help their project, they are sorely mistaken. All that they have done is train their potential users not to trust a single word coming out of their mouths. smh

[@diegogasco8923]

Luca Palmieri has a new admirer 🇮🇹

[@KyleHarrisonRedacted]

Java, ya dude, big data infrastructure is all jvm’s. Hadoop is Java, Spark is Scala, Elastic is Java, etc etc Being honest when Machine Learning was all the rage I was surprised to see that the big language of choice was.. python.. Of all things, and not Java.

[@nevokrien95]

The reason for python is 2 things. 1 array are nicer to handle in python because list comprehension is useful. U would not belive how many times I print data that I list comprehend to get a picture kf what's going on. 2 Ai reaserch isn't production code its all dev which means it's VERY hacky. Like I would go and read private vars left and right just to get a grasp of what's going on. Or I would also overwrite forward with my_log(forward) to get an idea of what's actually happening under these abstructions In java such a thing would be impossible, which means some tasks I could solve in a hack way in python r unsovlble in java... Also python has better c integration and u gota remember that ai used to be done In c++ so porting that into python Is a much easier task. Also python code for ai tends to be more framework independent since u don't have static typing and TENSORs are the same thing of they r np array tensorfloe or pytorch for the most part

[@vatanak8146]

Is it worth it to learn Scala as an aspirant to Data engineering and Big data field? Or just stick to Python and SQL?

[@doigt6590]

I'm surprised you never saw it before, I've heard and seen pythonic many times when talking about languages that are pythonic like nim, lobster and mojo (and boo and genie, in days of yore)

[@useruser-tc7xx]

I don't think I can say Mojo in anything other than Mojo Jojo's voice. Maybe Dr. Evil's voice if I try hard enough :D

[@k98killer]

Wild idea: ThePrimeagen may one day say "the name is or at least somewhat resembles ________". Not sure in what context, but it's theoretically plausible.

[@gustavojambersi9569]

A lot of of people were already not changing from python to better performing languages. They DEFINITELY will not change if Mojo performs somewhat close to rust.

[@PhilipAlexanderHassialis]

The real takeaway of course is the fact that "having to learn just a bit more and achieve something much better will always beat having to learn something totally new". Which is, for me at least, why Next won the React SSR wars: it was React as you know it, with one opinionated thing (routing) and an extra function to have server processing before delivering the finished rendered stuff to the browser. You could literally take an existing small but actually in production React application and convert it to SSR within an afternoon. Remember: developers are users too. And when we get into "user" mode, woe and behold we are *far worst* than the users of the applications we create.

[@nevokrien95]

Mojo is still a buggy mess... I tested it on their cloud it broke with very small changes to what they did It dosent boot on my machine at all like just crashes on install in very nasty ways Basically if it works it can be fast but it just breaks all the time

[@theaifam5]

It feels like Actix and „unsafe“ drama.

[@MrAlanCristhian]

11:25 I agree 100%

[@isodoubIet]

It's nuts how python (and now mojo) with heavy type annotations looks about as verbose and cryptic as template-heavy C++, except that templated C++ is better because templates are structurally typed, which ironically would fit better with the python usual duck typing. Like just use C++ at that point, you're not really gaining anything by deleting the braces.

[@chigozie123]

I'm pretty sure Julia was created to do exactly what Mojo 🔥 is now struggling to do. Julia syntax is intuitive and familiar to Python programmers. It has a thriving ecosystem of libraries and has seen massive adoption. It has an excellent C/C++ interop. Why do we keep reinventing Python?

[@yldrmcs]

because data scientists are so stupid that they can’t write code in languages other than python. fact.

[@kinomonogatari]

Julia just failed to find a company to invest in it

[@RazgrizDuTTA]

Mojo will kill Julia and waste all that effort just for lazy devs not to learn a new syntax. I hope time proves me wrong :(

[@kinomonogatari]

@@RazgrizDuTTA Well I quite like Julia as a language but at the end of the day I really do not care as a physicist who wins in between Julia and Mojo. I just want a performant modern language using which I can get my work done.

[@RazgrizDuTTA]

@@kinomonogatari I understand your point of vue. I wish I was that pragmatic. In my case, I do linear algebra for computational mechanics. I absolutely despise the Python Numpy and Scipy design and syntaxe so I hope Julia will survive along with all the great linear algebra packages developed by the Julia community.

[@user-jm9rc8kf4u]

Can you make a comparison between rust and qbasic in which qbasic wins?

[@martijn3151]

If anything is fast it’s me moving away from a language when it’s called Pythonic.

[@MesoCarib]

Interesting topic … and one I can understand. 🙂One of our senior bioinformaticians at work recently used Rust to do some DNA analyses and he shared the code with the NGS data analysis group. Rust has chance. lol.

[@TonyAlvesDev]

I'm always skeptical of these statements for speed. Especially from a closed source solution. Be very aware that the processor can only go so fast and memory access is only as fast as the hardware limitations. Mojo is a great idea. Rust is a fantastic language. Both will have their pros and cons. I like where it's all going!

[@stewartli5395]

In the data world, C and C++ are always winner.

[@nikolamar]

You are 100% right about Mojo!

[@hipsterJoe1]

+1 to "Zero to production in Rust" is one of the best Rust books!

[@jerrygreenest]

So, what should I use now? Rust? Zig? Odin? Mojo? Write my own language with OCaml?

[@Mouradif]

"Thousands of multimillion dollar machines" is not the same as "one billion dollar machine". Each machine is a multimillion dollar machine, and there are thousands of them

[@ifstatementifstatement2704]

Mojo-jojo

[@freeideas]

I would switch to Rust if it didn't plunge me into async/await hell for almost everything. Some kind of coroutine (python generators for example, but lots of other languages have an answer for this) makes certain kinds of code dead easy compared to the async/await or blocking-queue or iterator alternative. If I am not being clear enough, think of a python generator for fibonacci sequence, where you can just "yield" the next number. To do the same thing in Rust you would have to make a blocking queue with two threads or invoke the dreaded async/await, or maybe make an iterator that has to remember its state across calls, right? And, YES, this kind of problem comes up ALL THE TIME in my work. Best example is parsing something complex that comes to me as a stream, and I have to give the caller a stream with the decoded data. With some type of coroutine I can just do, "parse A, yield some results (or not), parse B, yield some results, then parse C, etc.". Without a coroutine, I have to either 1) when someone calls for a read, then I remember the state of the parsing (am I an A or B or C?) then resume, parse until I have some results, save the state, and return; or 2) create some kind of blocking queue and parse the easy way into that queue; or 3) break the parsing into a bunch of async/await functions and force my user to also use async/await -- this is the WORST of the 3, btw. Am I missing something? Please correct me, someone.