To me, they are failing some basic requirements (partly similar to Julia): 1. No support for Windows. 2. Exclusive focus on AI.

It's not in a 1.0 state yet. Did you expect them to be able to continuously fan up the hype for a few years? They've got their name out amongst early adopters, but they need a more complete language before it will appeal to the mainstream.

Thanks for raising, it's public now

I think that something they’ll leave to developers to build themselves. Mojo is fast enough where you could implement a lot of the basic functionality of numpy on your own and since you can just import the Cpython version of numpy into your mojo project, you won’t lose any functionality by moving to mojo. It is very likely though that developers make a mojo version of numpy so the api is the same with full mojo functionality

Actually, that would be pretty nice. The only thing Flutter has going for it is its template scaffolding syntax and libraries. They just have awful performance. If mojo could adopt that idea of templating, and mix it with the performance of their dynamic scaling on hardware that MAX offers... that would be the ideal language. Let the community develop libraries to interface with iOS and Android.

They are going by a year.release versioning system. For example, 24.3 is the 3rd release in 2024.

@@MestisoHapa Thank you

Real devs also use light mode, funnily enough. Some also have difficulty reading light-on-dark text, such as those with astigmatism.

I thought I was going blind :v I love the idea though

Ghee unwatchable. Please reshoot

First out of focus screenshare I've ever seen. We truly are living in the future

The point behind Mojo is it's a superset of Python to make adoption and implementation much easier. Python devs should have very little trouble getting up to speed. It's designed to be familiar and usable out of the box without having to learn a whole new syntax. That design choice was done on purpose.

@@liquidmobius Python is such an ugly language. While it's easy to learn, it feels more like a scripting language. Its code lacks structure and feels like it will fall off the page. I yearn for Algol-like languages with English keywords like Object Pascal and Ada.

@@bobweiram6321 I actually started learning Ada a few weeks ago, with the goal being to become relatively proficient with Spark. My main interest is safe systems-level languages, and Ada/Spark fits that bill perfectly. Time will tell if I stick with it or not. I'm moving more towards embedded, so we'll see. As far as Mojo though, it's specifically targeted at the AI space, since ML is done primarily in Python. It's designed to make deployment easier, so developers don't have to rewrite their models in C++ or Rust. So in that sense, it's really targeted at a specific niche. They are planning on broadening it to more general-purpose use case. I personally really like it, but wouldn't even consider it for general-purpose systems programming.

@@bobweiram6321 Python is structured, it just does not use parentheses to distinguish code blocks (replaced by indentation), which is actually an advantage. The algo language is the predecessor of the C language, and the C language tends to use symbols to represent a block. Instead of using begin/end, in other words, your head is the same as it was decades ago. don't get me wrong, I don't hate using parentheses to represent code blocks. I just hate the { that starts the code at the end of the line and I can't find the corresponding ending. Even if the IDE can mark the ending for me, I also hate that they are not on the same X. coordinate

I have done rust for about 5 years, and I hoped that rust would catch on more, but there's a theory in economics called Network Effects, and essentially it means that the more people use something., the more other people will use that thing. It's contagious (and I suppose you could say addicting too). The simple fact is that people don't want to learn all the new syntax and rules of rust even if it has the speed of C/C++ with greater memory safety and higher level abstractions. While I'm not the biggest fan of python (not an expression oriented language, non-lexical scoping, types are optional, etc), it IS the lingua franca of machine learning and scientific computing in general. So it makes sense for Modular to "meet programmers where they are". It's also a proven strategy that worked with javascript -> typescript, and objective-c -> swift.

`__init__` requires `self` to be fully initialized before it returns. Otherwise, you will receive a compile-time error.

right, but who said Mojo is a serious programming language yet. It's still in development and find out how to do things stage. Windows support is unnecessary at this stage and might be implemented when the foundation is set up.

It is not necessarily an initialization. What is being passed in can already have a value (it is often used as `inout self` to help initialize self, but it does not have to be an initialization). "inout" is more like "mutable" and says that the value I am using can be mutated, and this change will be propagated to the caller. A lot of people seem to not like inout as a keyword, but I believe it came from the swift language

@@MestisoHapa but in _init_(inout self), then self is uninitialized, right?

@@Jowbaka In __init__ methods, yes. But inout can be used in any function or method. It's not strictly for initialization. As it says in the video, inout is basically an LValue type. It's mutable/assignable, and when the value changes, the newly set value is still there after the function has returned. In an __init__ method, if you forget to assign an initial value, the compiler will flag that as an error

@@MestisoHapa inout works well for all other functions, but to me _init_(init self) is clearer than _init_(inout self), because in a regular usage inout always requires the argument to already be initialized before calling the method or function. Another possibility is _init_(out self) (from c++ proposal, not my idea).

@@Jowbaka But then you're adding a new keyword that's only applicable in one scenario. AFAIK, you're right, in other functions the inout parameter would already need to be initialized, but I don't see that as requiring a distinction between the concepts of initialization and mutability/assignment. Initialization is always assignment but it's not mutation. And that's what an LValue is...either mutability or assignment. So instead of having to learn two keywords, you just need to learn one. Also, keywords should always be considered thoroughly, because it means you can no longer use it as a symbol elsewhere in the language (unless you make a much more complicated parser). They could have gone the route of C# also, with separate "in" and "out" parameter keywords. But since Chris Lattner made Swift, and Swift already has inout (and therefore, a lot of swift programmers are already familiar with the concept), I guess Chris decided to reuse it for Mojo. Me personally, I would have preferred 'mut' (and there was some discussion about it github.com/modularml/mojo/blob/main/proposals/lifetimes-keyword-renaming.md#inout-keyword--ref-or-mutref-)