All-in-one C++, Rust, AND Python Successor? Mojo
Вставка
- Опубліковано 20 тра 2023
- A look at the new, potentially revolutionary Mojo programming language from Modular.
Camera: Canon EOS R5 amzn.to/3CCrxzl
Monitor: Dell U4914DW 49in amzn.to/3MJV1jx
SSD for Video Editing: VectoTech Rapid 8TB amzn.to/3hXz9TM
Microphone 1: Rode NT1-A amzn.to/3vWM4gL
Microphone 2: Seinheiser 416 amzn.to/3Fkti60
Microphone Interface: Focusrite Clarett+ 2Pre amzn.to/3J5dy7S
Tripod: JOBY GorillaPod 5K amzn.to/3JaPxMA
Mouse: Razer DeathAdder amzn.to/3J9fYCf
Keyboard (sometimes): Keychron Q1 amzn.to/3YkJNrB
Keycaps (sometimes): amzn.to/3UZq93f
Computer: 2021 Macbook Pro amzn.to/3J7FXtW
Lens: Canon RF24mm F1.8 Macro is STM Lens amzn.to/3UUs1bB
Caffeine: High Brew Cold Brew Coffee amzn.to/3hXyx0q
More Caffeine: Monster Energy Juice, Pipeline Punch amzn.to/3Czmfox
Building A Second Brain book: amzn.to/3cIShWf - Наука та технологія
I always find "compared to Python" when talking about speed a little bit useless. Python is always slower than anything, except when you're using a C lib, so compared to what Python exactly?
I think it has a bit more utility in this context because it seems like the long term vision is to be able to migrate your existing Python codebase to Mojo with few or no code changes
What I find most important is that this language aims to be a superset of Python.
Same as Kotlin and Java, or Typescript and Javascript.
Or C and C++.
That way migrating old codebases can happen by simply changing the file endings.
I'm excited about that, and will probably start using it in a project when it's possible to do that.
TypeScript & Kotlin did it right. This is the way.
I don't think Kotlin is a superset of Java is it? Just has really good interop capabilities. In any case I agree with the importance of being able to migrate a codebase simply by changing the file extensions - if we get there, it seems like Mojo will get incredible adoption
java is still better than kotlin
@@mister-ace nice joke
@@mister-ace Hahahaha, I'm laughing at your joke.
Python easiness and syntax with features and performance as C++ and Rust. Mojo is going to be a massive game changer whenever it officially releases to the public as stable release. I love the new research and development into modern programming language development and design. Making newer better programming languages to replace all the old ones that have been the status quo for decades is what we need to do more of.
I agree 💯!
IMHO, language features win many times over syntax in the long run, and from this demo, it looks like mojo has taken some ideas from Rust and made them worse by adding some of the most annoying "features" of C++ (move constructors.. rules of x comint up?). Not a winning recipe in my book.
When you started wondering why that print call wasn't giving an ownership error, I envisioned a bunch of early adopters spitting out their coffee hoping they don't fix that "bug" and bork their prototype codebases.
hah - yeah some folks on the Mojo Discord are saying that the borrow checker hasn't been fully implemented yet, so that may be the culprit. Get away with unchecked borrowing while you can fi guess :)
@Code to the Moon Lol yeah those folks would have some memory problems if they don't end up with dependency problems.
Thank for wonderful presentation! In their doc(roadmap) it's mentioned that ownership is only partially implemented, no proper lifetime support right now.
It's wonderful to see how Mojo incorporate c/c++ freedom, rust safety and python dynamic feature in same language.
Thanks for watching! yeah, some folks on the Mojo Discord mentioned this as well - that's likely why I wasn't getting the error I was expecting
Thank you! Impressive first look, and agree with your ending: can't imagine building anything with it just yet.
glad you got something out of it!
8:12 I'm probably wrong because I'm not familiar with the ownership concept that seems to be from Rust, but I think it's because
- first you created rocky
- then you changed its mass value using inout
- then you ran the cell again, but giving the ownership to the function
- so when calling print(), you might be referring to the first one you created, or the location in memory of the first rocky.mass
So to investigate, you could try starting clean and running again
yeah I was thinking this initially as well, however I refreshed the kernel after doing the video, rearranged the code a bit and still got the same result
@@codetothemoon I'm not sure, but seems to me that it won't give an error since the print function in Python is probably not "ready" for handling ownership, or maybe the creators decided that the print function won't be handling it at all, for compatibility. Rust, for example has different approach for dbg! and println! macros. Since, Mojo is a Superset of Python, hence not having a strong type system as Rust, it's not mandatory to add borrow checking everywhere. That's what I think. If you ever confirm that, please let us know.
Great content, BTW!
@@wands84 Thanks for the kind words! From chatting about it on the Mojo Discord server, the consensus seems to be that the reasons I didn't get an error is because the borrow checker is currently incomplete.
@@codetothemoon sry to use this a a question board but this point is highly interesting, if u got the information, is the final version basically gonna have a borrow checking system like rust
@@Erick-zd3gbI remember seeing somewhere that the answer is yes, but not exactly the same.
Thanks for sharing your exploration of Mojo. I'm guessing all the extra details, e.g., "register passable" are a good thing, but from this first tour of the language, it seems quite cumbersome. I think I'll wait till 2.0.
Yeah - wouldn't fault anyone for waiting until more of the basics are implemented before diving in
Finally, a python that I can use without scratching my hair off my head
I think there will be many who share this sentiment!
pattern matching and rust-like enums are a must for me now :/
python has pattern matching
yeah those are nice, haven't actually looked into either yet in Mojo context
It is often said that Julia solves Python's "2-language problem" (using Python for general coding and another for routines that need speed). But soon we can say Julia solves Python's "10-language" problem!
Julia is fast, but I always hated this ridiculous matlab-leaning syntax.
I can't live without curly brackets
I can't live without porridge
We have the same way if thinking. I just love curly braces so much
I was just about to write that! 😢
interesting how many folks are saying this! If you already dislike using indentation to denote scopes, I don't think Mojo is going to do anything to win you over. I personally find not having curly braces nice, but that's just me 😎
>>> from ___future___ import braces
it would be interesting to know if its possible to make DSP Programming with Mojo
Seems like a hotch potch. Can't imagine auditing a codebase with fn functions and def functions coexisting simultaneously.
Also, I use Rust for its borrow checker guarantees. In such a language it seems like it would be impossible to ensure that GC has to do a lot less work than necessary which will impact performance.
Although it can't replace systems languages, it has the potential to become a de-facto replacement of Python at some point.
mostly agree. The need for backwards compatibility with Python syntax will become a bit of an anchor at some point
Mojo will smoke CPython.
No more interpreter and GIL BS.
Personally I'm slightly interested in Mojo for just making "better python scripts". I'll most likely still use C or C++ for normal programs
make_larger is a function that’s done at the time of the print
Mojo is very promising to make it really compelling for rust devs they have to add features like Enum and match, it would be actually insane if they manage to take those features from rust with better defaults and making it easier to use. So excited for Mojo and thank you for the high quality videos as always!
agree 💯! One of the benefits of having a public beta in the early stages like this is that the community has an opportunity to provide feedback like this - and I know we're not the only ones that want such features! Also thanks for the kind words!
I imagine the priority is to get to the full superset of Python first and then add desirable features to it. But despite the provocative video title Mojo's primary focus is the Python and AI domain, not C++ and Rust as such. But it would look to obviate the need to write AI and Python scientific computing components in C++.
Given who’s leading its development I’d be pretty confident it will. Chris Latner packed all that good stuff into Swift and he’s talked at length about the reasoning.
Python already has match by default
I use VSC, which one are you using?
you forget the compile time evaluation inspired by Zig lang, which will be a major feature for Mojo
Mojo taking the best features from every language out there and implementing it into their language to make the best language ever is pretty awesome. I cant wait to use it when it officially is released.
lets wait for the final release
indeed, final judgement will be reserved until then 😎
Wow time flies. Mojo is already 7 months old.
I was hoping for Option, Result and Error Handling like Rust do. I personally use Python or Rust and Mojo just doesn't fit anywhere for me right now.
I'd like Option as well - not sure about Result, as it seems like Mojo is following Python in being an exception-centric language (for better or worse)
@@codetothemoon maybe they will be able to extend the syntax with something that makes exceptions (raising) more explicit.
If only Nim was more known. Basically Python like syntax but compiled and C like performance
love nim from what I've seen so far! Been really eager to spend a bit more time with it.
@@codetothemoon Awaiting your video on it
I’d like to watch a critique of Nim too. Looks nice to me!
Could your perform some your own benchmarks?
Does this get compiled or it is interpreted?
compiled. It uses MLIR which is an alternative to LLVM - both of which Chris Lattner (the cofounder of Modular) has contributed to
@@codetothemoon Thanks!
To me it seems like two languages combined to a Frankenstein hybrid
I can see how it might appear that way!
If anybody from Mojo/Modular is reading this, please make the error messages less technical. Try to make them so any average programmer can understand what went wrong.
agree - that's one thing Rust does a fantastic job of, and something that is often overlooked but can make or break a language's adoption
Being a superset of python can make it easy for people to adopt Mojo, but it will inevitably become a mess like JavaScript and typescript
time will tell - hopefully not having a need to "compile to Python" (ala TS->JS) will prevent Python from becoming an anchor
Kotlin is a superset of Java just like Mojo is a superset of Python and Kotlin is not a mess. C++ as a superset of C and TypeScript as a superset of JavaScript arent bad either. I think Mojo will be fine.
@@vectoralphaAI I think he meant that being a superset will bring people in. However, the problem is elsewhere - more clueless people will come and use Mojo for what it isn't intended to be used for.
Sounds promising, but i doubt it will be used in any way other than python replacement. Python has a bunch of serious desigh flaws which Mojo had no choice but to inherit in order to keep compatibility. I'd really love if people just migrated from python to nim instead of writing dosens of tools for python, destroying it's ecosystem consistency even further
which are the most egregious design flaws inherited by Mojo? I've personally been really impressed with nim in the little time that I've used it
I am also wondering: which “serious design flaws” of Python do you refer to?
I think that this error related to using object after passing ownership is fixed
nice! I plan to check in on Mojo every few months or so, I'm almost due for another look...
@@codetothemoonalmost every week brings very significant changes. Its development is really rapid :) There are also a lot of its unique features (SIMD instructions, vectorizing, autotuning, tiling etc.) which could be covered in yt. As of my research, your video is one of the best introduction in yt, so imagine level of other content 🙃
I hope also that this another look will result in another video :D
I do want to build a large project within the next months to years. We have a product on sale that we bought that needs to be re-written due to bad code, and we want to shift to a different direction with the product after the sales have begun. I am the lead developer, who is still carrying the product on my own. I will decide on the tech stack and we need optimal performance that scales well. Mojo could change everything for us. I'm not ready for a C++ project and I think those times are over nowadays, I also think Rust is great, but I will have trouble to find people and they will be expensive. I do think it's easy to find many Python developers who could quickly adapt to Mojo, those programmers would just lack to program the Mojo way to get the most performance out of it. A lot of stuff could be enforced with linting though, and a lot can be teached and shared, abstracted and re-used. Our project is not related with AI, but the option for using a borrow checker without enforcing this way of programming is a selling point for me. As long as I, as the dev lead, can enforce practices on the project level, I'd want to consider Mojo for it.
I always did like python, its been my main language for a good 10 years now, but this seems like it's trying too much, there's too many different keywords and it doesn't feel consistent, all I really want is rust with maybe some optionally relaxed safety rules (maybe some of the behind the scenes inference of lobster when you leave some details out). Or just an easier way to do dynamic memory, but then again I haven't messed around in unsafe too much, I don't mind raw pointers so maybe that's the way. Seems like a potential case of making things worse for the sake of backward compatibility (except to multiple languages).
maybe you're right! will be really interesting to see how they incorporate feedback like this from the community - I suspect many others share your opinion.
What is that environment you were coding in?
it's a Jupyter notebook, as of the time of this comment it's currently the only way to have access to a Mojo build environment
I think it seems like a great language for games
interesting - maybe - why do you think so?
@@codetothemoon not the deepest of analysis, but if it pick up enough steam and the libraries start coming and it’s easier than rust, then I think that it would be the c++ killer. Also Python being used in scripting in games, I’m hoping that it will be way easier to write the python bindings in mojo than it is in other languages
is this faster then C++ and saver then Rust ??
I'm not sure it's aiming to be faster than C++ necessarily - I think being in the same ballpark as C++ performance-wise would be a huge achievement. Similarly, I don't think it's aiming to be safer than Rust - just on par with it. Though it is aiming to give you a bit more control than Rust in terms of whether your types can be moved, copied, etc.
thank you for a great first look at this weird language.
you're welcome, glad you got something out of it!
Its a cool language if numpy didn't exist, python wasn't an actively developed language with a strong foundation, and integrating C/Rust modules into python wasn't a piece of cake. However, having Mojo concepts migrated into python 3.14/3.15 is something i wouldn't be surprised to see
I disagree that numpy (or any package that invokes functionality written in a lower level language) is a viable substitute for everything that Mojo is aiming to offer, assuming the long term vision comes to fruition. re: Mojo concepts being migrated into Python - that would be really interesting, but my guess is that there might be some technical barriers that preclude it.
@@codetothemoon there are definitely technical issues with migrating those concepts into python which is exactly why the python software foundation is working relentlessly to integrate those concepts into python. on the other hand concepts such as type annotations are implemented differently in mojo which means annotated python code wouldn't work on mojo, or at least it seems so from the demos.
my high hopes for Mojo ruined in 17 minutes 19 seconds.
More mojo
will definitely be checking on the project periodically, maybe making a video here and there when significant progress has been made
borrowed not being default in rust is probably my biggest issue with it, to a level I could not imagine I could get annoyed with a fact.
so mojo got me there straight.
this used to bother me too, but the more I'm using rust the more it makes sense to me. When I want to semantically give a value to a variable, then I want to give the actual memory, and not a clone or reference to the value. It requires a change in thinking about data that maybe is less mathematically convenient, but lets you intuitively think about data as memory, atleast from the allocation-viewpoint.
I was most familiar with c# and syntactically simpler languages like js/python before I learnt (the basics of) rust, and in c# the way you think about this stuff is in terms of learnt approximate guesstimates & profiling. Data not copying by default means smaller memory footprint by default, and I think that's way neater than trying to refactor yourself into it.
I feel the same way - was always curious why Rust chose "move as default" since, at least for me, borrowing seems to be needed much more frequently
Just code in Julia for your high performance computing needs. Has all you'll need, speed and ease. What's the point in reinventing the wheel. 😏
Julia does seem to sit within the niche that Mojo is aiming to occupy, but Mojo aims to provide several features that Julia does not - no GC and borrow checking being among them
While it's interesting to follow your train of thought, I still feel this video could have used a bit more background research/preparation before recording.
thanks for the feedback! the challenge I ran into in making this video was that I'd have some goal in mind - ie implement a TSP Solver, then I'd run face first into the limitations of the current state of the language. What specifically do you think I left out that would have been good to include? Or are you referring to the part where I'm trying to figure out why the borrow checker isn't giving me an error?
@@codetothemoon Yes, the borrow checker stuff. It was kinda confusing to watch, especially with the non-instant feedback of Jupyter. I felt like I ended up knowing less about how it works than I did before. (And just to be clear, it's still a good video, just not on par with your usual quality.)
It’s quite honestly infuriating that a language in this early stage with so much *design* still to do, let alone implementing and fixing basic stuff, gets soooo much attention just because they plastered the label “A.I.” on it. Yes, it can do very fast matrix multiplication, but that could have gone into a Python extension.
There is definitely still quite a bit of ground to cover, but they have a pretty substantial financial backing that is conceivably sufficient to bring the long term vision to fruition. Will be fun to see what happens.
@@codetothemoon I also think so. And I was in no way critizing that you made a video about it. Quite the opposite.
But to get this much attention everywhere for something that is in its very early stages ...
It is in the early stages, but its premise is insanely good. I am currently unhappy with python due to its lack of performance, unhappy with Rust because you can't do fast prototyping because everything has to be verbose and unhappy with julia because it doesn't have any interface guarantees, enables namespace Pollution has one based indexing and is column major. But for the lack of a better option I still use julia
Rust would be perfect since it has multiple ffis for python libs , unfortunately the foundation is cringe
@@codetothemoon do you know who is financing it and why?
i32 > Int
I like first type naming much more than latter ..
I wonder why this over Julia: they seem to have the same objectives or very very close.
Simply, no. I am interested to see how it plays out though.
Yeah, not for everyone. We'll see if they can execute on the vision...
more Mojo please)
would love to do more once the language is further along!
Mojo is a mojón
how so?
It's more technical than Python. I had to pay attention to a lot more details.
definitely - being a superset of Python, it aims to add lots of bells and whistles that Python doesn't have. whether the overhead of learning how all those work is worth the ROI remains to be seen 😎
Are people that obtuse to Nim? Like it already is what Mojo is trying to become.
Dabbled in nim a bit myself, and have been really impressed so far. I'm planning on doing a deeper dive when I have a bit of time!
@@codetothemoon I love Nim, its such a elegant and expressive language, you can use it for web development, and system programming, it wouldnt be heard to do machine learning with it, when the proper libraries are created, there are already a few that are on the level of something l ike numpy. Its as fast as C, compiles to a single binary. Compiles to C, C++, Obj-C and javascript. The GC is optional and swappable. The Meta programming is other worldly. Just a big fan of this language and interop with C is native, so you can use existing C libraries.
I feel like when a language trying to pump the hype then it will end up like vlang 🤔
I'd be somewhat surprised if that happened, Modular currently has 30M in funding led by Google Ventures. That's a lot of runway and firepower 😎
@@codetothemoon Having a big bag of cash guarantees NOTHING. In fact, if you look at all kinds of projects, too much available money can do more to wreck a project than too little, paradoxically. Simply put: "necessity is the mother of invention" leads to far greater motivation to find clever solutions but cash-in-pocket often makes one too comfortable.
There will be a lot of push back from this, sadly. Look at what happend at the early stages of typescript
totally agree. but if they are able to execute on the vision I think the naysayers will be silenced
Really similar to Scala to me
really how so?
@@codetothemoon The types in square brackets. This really make it feel like Scala to me.
@@grindarius661 ahh yes good point!
looks interesting, but it's another one of those languages that treats windows as a 2nd class citizen, so it's probably going to end up being a niche language.
do you primarily use Windows for software development? recently I've sort of been under the impression that it's lost a bit of popularity amongst developers. irrespective of that, definitely agree that they need to support all major platforms to be a serious contender!
@@codetothemoon I always use windows. I just don't like Linux as an OS. I don't care about what's popular. I just care that my work environment is supported fully.
I need curly braces., I just don't like python's indentation only style, so Mojo isn't going to work for me either. I do indent blocks, but that's not enough to me on its own.
I think many will share this sentiment! if you already dislike using indentation to denote scopes, Mojo probably isn't going to win you over
The Python community really doesn’t need any more fragmentation.
Then don't use it, how is its extra compatibility a problem? If it's a problem for you, treat it as a different language.
And python fragmentation isn't that bad.
Why does that matter at all? It’s also a superset. All the python code will be valid mojo code (if the team keeps its promises). You want to keep the bad performance and lack of type safety in python just for “the python community”? Seems very odd to me
@@playea123 mojo will come with its own set of bugs and problems, also i think it will take a long time before they add everything from python since the project is still not open source
@@maevwat I totally agree. I would be happily surprised if it was fully ready to go in less than 5 years.
@@anonymousalexander6005 I have no issue with python as is and where it is mainly used. It’s a supremely productive tool that, on its own ,is not safe or performant. I just don’t get criticism of Mojo from this standpoint. It’s a superset. Your python code is valid as is. If you put in more effort, you will be rewarded with better performance and safety. Those two allow you to take the python syntax you are already familiar with and use it in areas where Python is currently not a logical tool to use. Nim is very close to that as is. Mojo just takes all of that to the next level.
Still 100% on paper. Sure its GA now its still need to be in peoples hands to fiddle and see how good it really is. Overall, I don't really like Python except for simple things.
yeah it doesn't seem anywhere near ready for actually actually building things with yet. But if you're not totally averse to Python, it seems very promising
I also mainly just use Python for simple scripts and I won't complain about a better Python. And I am happy people who really use Python can get something better as well. But for "real programs" I probably won't use it
A Python killer for sure. But I doubt it will compete with Rust for low level system programming.
I am not sure either. It could be interesting to do a comparison (syntax, benchmark, community) to be able to do a good comparison. It could be interesting if it can manage pointers explicitely
@@fabricehategekimana5350 the fact that it going to be a superset of Python means it will probably end up being a non-sequitur for most if not all of the use cases of Rust anyways. It’s going to end up being more of a competitor with Go, Kotlin, C# and the like, although it’d be awesome if they provided the std modules as low-level libraries to Rust/C-level languages, but I’d doubt that because pythonc never ended up that way either.
It will be used heavily for low level programming in AI where parallel processing across GPUs is a must. They’re using MLIR, which makes it easier to do that for code that runs on differing hardware
yeah - I'm wondering how much the need for compatibility with Python will prevent it from gaining ground in the systems programming space
Thanks for the video!
This one is not for me, for the fact it has many of the things I dislike about Python.
What do you dislike about python ?
For me, it's the lack of pipe and a sound type system
@@fabricehategekimana5350 it just deviates too far from my old school preference of curly braces, semi-colons etc.
The most hideous thing of all is the “__something__” naming convention though.
It’s just not my thing, personal preference only.
Yeah if you dislike Python for any reason other than the performance, Mojo probably isn't going to do much to win you over 😎
agree that __something__ is the worst part of Python. I actually like using indentation to denote scopes, but the double underscores just look so off-putting
@@codetothemoon I’m sure the ‘perfect’ language will come along soon & I will live happily ever after.. 😂
On a serious note, the closest I have found to what I would consider the best syntax, is Grain.
It’s really cool on many levels & were it not for the lack of a viable http client at this stage, I would be using it already. Definitely check it out, if you haven’t already 😊
Closed source = argument is invalid
"Get started today" by giving us all your personal details and we _might_ let you learn more ... 🤦♂
I don't remember giving much more than my email address
If it doesn't have a GOTO command I'm not using it.
totally, GOTO has been around since the mid 20th century, how can languages without it be taken seriously in the 21st century??
@@codetothemoon Yes indeed. I believe GOTO is called the Observer pattern in OOP, oversimplifying a bit, which I have found very useful and is the basis for the way Windows works every time you click on a button.
Finally!!! I'll be adopting it as soon as it's usable. And promises to keep adding modern programming techniques. The most important thing for Mojo designers to take note is to be pragmatic (like Python, Kotlin), not evangelistic (I say this is right, and you must follow it) like Rust or C++. Do most of the work in the compiler.
What do you mean?
I'll likely be taking a much closer look once more of the basics are implemented as well!
"orders of magnitude faster than python"
doing it yourself is faster than python most of the time
lol - pen and paper ftw!
What does the presenter mean, "it's looking pretty pythonesque?"
This language is a SUPERSET of python. Does he know set theory, or at least, the meaning of the word superset?
He's got that up-speak accent, too, that he was using in the beginning, like everything is a question, but it wasn't.
By Pythonesque I mean it looks like Python. I'm aware that it's a superset of Python - I'm not sure where the inference to the contrary is coming from.
Same ol'OOP 💩...
the OOP specific aspects of Mojo are pretty standard, I think the innovation here largely exists out side of that
@@codetothemoon that's a good thing! I've always wanted a compiler + types for python...
I find it funny that to make a language like Python faster you have to create a whole new language on top of it, it’s very interesting yea, but it kind of defeats the purpose of using Python entirely. (yes there’s PyPy but it’s still meh)
I think you could cover some ground without making any syntactic changes to the language - but the unfortunate reality is that some performance improvement opportunities rely on input from the developer, which needs to be exposed in the form of language syntax. I don't think being a superset of Python defeats the purpose, as it makes it compelling for those with a Python background and/or those that are interested in migrating an existing Python codebase. There were so many compile-to-JS languages before TS came around, yet TS "won" handily despite being late to the party. I think that's a testament to how superset languages have an advantage when it comes to getting buy-in from communities
It looks nice, but no thanks. Good video anyway👍.
thanks, glad you were able to rule it out based on the video!
From the github repo it doesn‘t look serious at all
It’s a superset of Python, and Python isn’t serious, so how can you expect this to be?
@@anonymousalexander6005 sure but 2 people contribute to the repo it will take long until mojo is serious, published and used. I‘m willing to try it sounds amaaazing
@@anonymousalexander6005 nvm I was a bit off. Didn‘t knew who develops it in the first place 🥵
it hasn't been open sourced yet so I wouldn't use GitHub activity as a vital sign yet. They have 30M in funding from Google Ventures
Seems like demoware at the moment. Got complicated AI stuff working at the expense of the basics
I agree. But imo it was the right choice - no point in spending time building out the basics if you can't show the value add over existing solutions
looks muck simpler than Rust, C++, but I'll die without curly brackets 🥲
Yeah, definitely seems to be quite a bit of aversion to using indentation to denote scopes :)
This is legit awful. I've been waiting for a Python-like language that can do stuff like this, but why change totally basic idiomatic things about Python just in Mojo? Like for example why the hell does Int and Bool have to be upper case, when they aren't in Python? Also all this fuss with inout and owned is just hella confusing. If I want a borrow checker or want to manage my own memory I would much rather use Rust, Zig or just plain C. I already have a problem with Python having a lot of implied and hidden behaviour, this just feels like putting on yet another layer of that. Also what exactly does this give us beyond what you can already get with Numba or Cython? I get that matrix multiplication go brrrrr, but we already have all these other amazing options, some of which (JAX) also run on GPU and TPU. To me this whole thing just looks like the C -> C++ transition. Just add a lot of shit to a language without any seriously thought out concept, keep patching it, until it becomes 5 languages at once, and call it a day. I sincerely hope this will not actually start being a thing.
I think many may share these sentiments, should be interesting to see what happens!
Int and Bool need to be capitalized because it's a superset of Python and int and bool already have a meaning in Python. I might write a function in Python and annotate an argument as int but then occasionally pass strings to it as long as those string can be converted to an int. High profile Python libraries do this kind of thing all the time so Mojo can't break that if it wasn't to be a true superset. The result is that you can write int and bool in Mojo but they don't do anything; they're just suggestions/documentation like they are in Python. If you want to actually tell the compiler that something is 100% actually an integer or boolean then you write Int or Bool. It's a necessary evil.
still prefer nim
I've dabbled in nim a little, and have been impressed by what I've seen so far. Looking forward to diving into it a bit deeper...
@@codetothemoon nim 2.0 on its way
The hype train?
all aboard! 🚂
Someone thought "Would not it be nice if rust had python syntax?"
They don't understand the point of python. Python is for people who don't want to code, but have to. They want to get away with doing the minimum and are happy with a slow running program as long as they can move on and start doing something else.
@Katter is he wrong? Python as a whole is not for building production and usable applications or systems. It is misused in that sense the same way that JavaScript is. Just because it can easily be used to do those things, doesn’t mean it should be. Something like Go or maybe even Kotlin if you want to, Rust if you can, and C/C++/Zig/assembly/etc… if it’s absolutely necessary. Reserve Python/JS/Bash/etc… for scripting, proofs of concept, and prototypes like it should be.
do you think Guido van Rossum would agree that "Python is for people who don't want to code, but have to"?
Really?
😂
Sounds a bit backwards. More Python developer who wants Rust performance I'd guess
Mojo, if you can replace c++ than Ai will replace you and we will be replaced by promote engineers and those will eventually be replaced by the autoGpt and world will crashed..so plz don't try to replace c++ plz
I really don't think we need any more programming languages. What does this do that others can't?
Edit: reminds me of xkcd 927
leverage a very large community and libraries for pretty much everything
It's being developed by the guy who made LLVM, which is what all these languages are based on
It's a better option for datasciences and machine learning. Until now we have languages like R and Julia that are good at it. But the community like more python because of the simplicity of it's syntax. But to do so we need to use python + many external API.
With mojo, we have everything all in place. But with his features, it can be used in domains where python failed (like software developpement or Web app)
it aims to have a Python compatible syntax (which many, especially in the ML/Data science realms, prefer) while being as performant as Rust or C - and because it uses MLIR under the hood, it may even have some low level advantages over those languages as well (the details of which I don't fully understand yet)
Mojo was recently caught lying about their benchmarks. This did it for me. Lost all credibility.
Chris Lattner is still salty about his failure from Swift + Tensorflow. This is just yet another pathetic attempt to divide the python community.
I think many will share this sentiment! Will be interesting to see how things develop...
I don't see mojo going very far. The only advantage of mojo is the backwards-compatibility to python.
If you subtract the backwards-compatibility to python from mojo, there is nothing left but a strange raggle-taggle of other languages mix.
I think Rust got a much wider spectrum (from bare metal to frontend) and concise way of doing things. Maybe Rust is missing the ecosystem python got, but Rust got a pretty strong base, which Mojo is lacking as an unreleased language.
PS.: I mean Python is only a strange way to bind c-packages together. Using Mojo for using python to bind c-packages together doesnt make it better.
definitely agree that Mojo has quite a bit of ground to cover to even begin to think about taking market share from Rust, which as you say is incredibly well established at this point. I personally find the Mojo syntax nice even irrespective of the backwards compatibility with Python, but that's just me. If we somehow got to a point where both Mojo and Rust had a similar level of maturity and comparable ecosystems, I suspect that I'd prefer Mojo. But it's definitely not yet clear whether that's a realistic scenario.
The rationale for Mojo is to address specific issues in the AI community. It’s best to read the Modular site for why. You can’t get that just from watching this video. The title is misleading imo.
Hahahaha, lmao.
You can't be serious with all this hype for Mojo, really. You want a fast language that can call Python with zero overhead? Well, there's Julia for that. It is also a language focused on being at least partial python replacement. Why not Julia? The only actual reason i can think of is Julia being garbage collected, but you can even work around that with manual memory management.
the long term vision for Mojo includes things that Julia is not capable of, one of which you point out. re: manual memory management, you wouldn't have a borrow checker to ensure safety then right?
@@codetothemoon Isn't one of Python's main features its speed of code-writing? I don't think battles with borrow checker will make development times faster. Mixing low-level language focused on memory safety with a half-scripting language with focus on simplicity is never a good idea, seems counterintuitive.
7 Behold, he cometh with clouds; and every eye shall see him, and they also which pierced him: and all kindreds of the earth shall wail because of him. Even so, Amen.
(Rev.1:7)
12 And I beheld when he had opened the sixth seal, and, lo, there was a great earthquake; and the sun became black as sackcloth of hair, and the moon became as blood;
13 And the stars of heaven fell unto the earth, even as a fig tree casteth her untimely figs, when she is shaken of a mighty wind.
14 And the heaven departed as a scroll when it is rolled together; and every mountain and island were moved out of their places.
15 And the kings of the earth, and the great men, and the rich men, and the chief captains, and the mighty men, and every bondman, and every free man, hid themselves in the dens and in the rocks of the mountains;
16 And said to the mountains and rocks, Fall on us, and hide us from the face of him that sitteth on the throne, and from the wrath of the Lamb:
17 For the great day of his wrath is come; and who shall be able to stand?
(Rev.6:12-17)
First!
you got it!
This is just a py replacer
Without many of the downsides of Python!
I can't stand Python's 'dunder' syntax but it doesn't look like Mojo offers any alternative to it. I mean, this is just the ugliest thing in Python. Wasted opportunity!
Warning: horrible pedantry incoming...
The word voilà (from French, literally "see there") has a v in front /vwäˈlä/
Mojo looks really cool though. Rust and Python are my favorite languages.
in spoken french it's pretty common with voiced fricative consonants to be partially muted when they start a word as long as there is air exhalation, which is what CttM did
(disclaimer: I'm native french)
@@qexat Today I Learned
But... if you don't pronounce the back half, and you don't pronounce the front, what is left to pronounce? 😂
@@Kiaulen LMAO true
thanks for pointing this out, didn't realize I was saying it wrong 😎