Видео

Hi there! We appreciate the feedback. This video is a recording of a live 1-hour meeting, so we unfortunately have to enforce a time limit. We don't like cutting people off either, though!

@@modularinc Thanks for your answer! And thanks for your work and for doing these great community presentations! But I think, even in the live stream, no one would have died, if the presentation would have lasted a minute or two longer. If in doubt, everyone could have just left the stream. But as youtube content, the presentations are just more valuable than the questions afterwards. It is a pity to cut down on the presentations for the sake of having more questions.

​@@hansdietrich1496 Very fair point! We'll try that next time. Again, thanks for the feedback - we appreciate you taking the time to share suggestions.

You are lucky to have a moderator. Moderation is a way of signalling that time is _important for everyone._ RUclips is laced with listless jaded discussions where one wished they had someone to rein in the palaver

Our Discord server is the best place to keep up with progress and ask questions: modul.ar/discord

@@modularinc Thanks!

They have the “alias”, a compile time constant. Also, if you want a variable to be inmutable you can “borrow” the variable to functions, it’s kind of read only

Please share this question in our Discord server: modul.ar/discord

@@modularinc your discord link keeps expiring!

@@boywithacoin Thank you for the heads up! The link seems to be valid, though - are you still seeing an issue?

The Mojo standard library's license is Apache 2 with LLVM Exceptions and you can access the code here: github.com/modularml/mojo. The broader MAX and Mojo SDK has a modified Business Source License called the MAX & Mojo Community License (www.modular.com/legal/max-mojo-license). We really appreciate all the feedback, and there is also a license FAQ page here: www.modular.com/pricing

@@modularinc Are you planning to move the Mojo SDK to Apache 2 and publish its code in Github eventually? If so, do you have a timeline for that?

​@@ooxxoo-z7w We're committed to progressively making the source code of Mojo fully available over time, but unfortunately can't share a timeline at this point.

We appreciate you taking the time to share your thoughts and we understand that the difference in licenses between the SDK and standard library can be frustrating. Our intention is to enable as many people as possible to build on MAX and Mojo and for them to have as high-quality an experience as possible. We believe the new license is the best way to do this, but we hear you on the confusion and frustration. Our pricing page ( www.modular.com/pricing ) also offers more details on the different licenses. To clarify, if you intend on using “Mojo for CPU in general apps and compute, and GPU for graphics and games” to build something not commercially competitive with MAX Enterprise, you’re still 100% empowered to do so. We’re here to work with you - feel free to reach out about your use case if you have any concerns.

@@modularinc I dont' think with this sort of "muddy" license terms, the ecosystem will ever take off and third-party packages will increase over time, which defeat the goal of wider adaption, even language design and ergonomics is better then other languages. It's hard sell for large project that required major investment and organisation buy-in, it will be disqualify from potential tech stack even before reach legal department. Between mojo and zig, most developer would likely choose zig purely because of license, open source nature and community support, even mojo is more high level. Mojo can be a better, more clean design and modern version of "rust" with pythonic syntax. But without clear licences term and communication, what's open source and what's close source under commercial terms, the ecosystem will not flourish, "non-compete" clause is very vague definitions and doesn't inspire confidence with open source community. For the samme purpose avoid "free riding" FSL license is much better.

​@@MW-mn1el We really appreciate the feedback! We've updated the license and FAQ page to be clearer, and we'll continue iterating based on community feedback.

Thank you for sharing this feedback. You're right - that is what we mean, and we’ll be clearer about this going forward.

It’s nothing like Matlab since you can’t use Matlab for free. It’s closer to Wolfram engine if anything.

For real, this is what I would want to avoid lol

So much this. I have no problem with them making their managed cloud stuff source-available, but Mojo itself has to be fully open-source under an OSI license before I invest any time or effort into using it. No start-up intends to rug pull, but if they start running out of money.. And, for the case of them closing down, we need to have the Mojo language tooling be open-source and with a sufficient built-up contributor pool to maintain a community fork. It's no good saying "we'll do this in future" or "we'll do it if it comes to that" because it doesn't guarantee that whoever comes out the other side owning the IP will follow through.

pixi uses uv. poetry's problem is that is really only good for pure python projects. With pixi, you can add system library dependencies or other programming languages like rust or C++, like if you want to build out a pyo3 wrapper around a rust crate. They mention pixi is like git, but I see it more like docker, without needing containers.

mojo/max is very young. Just a bit over a year since they first announced it. In contrast, rust was developed in-house for at least 3 years at Mozilla before going open source. And I believe Graydon was working on it over a year before he even released it within Mozilla. I for one think Modular talked about mojo too early, precisely because people now have this expectation that you have. I worked at Red Hat on Openstack, and I saw what happens when you have too many cooks in the kitchen. I'd rather they get feedback first, but still control the process in-house to have it more fully baked until fully open sourcing it.

The "we're not geared up to accept community contributions to the core language tooling, so we'll open source it down the road" reasoning seemed iffy from the start, but I was giving them the benefit of the doubt - it does indeed make little sense to expend effort to onboard compiler engineers at an early stage and the (unstated) idea they wanted to get a head-start in semi-stealth mode made sense. I was happy to wait until the open source release happened, providing guarantees that the language itself will outlive the next funding round, to jump in. At this point, I'm ready to give up on waiting. They've had plenty of opportunity to release the core while keeping the cloud platform value-add that they intend to monetise proprietary or source-available under something like the BSL. And they haven't. It's 2024: people won't accept developing on top of a proprietary language, especially from a start-up. .NET Core went open-source some time ago. CFML has been EOL'ed because no one cares. There is literally no single proprietary dev platform with any sort of adoption or mindshare. Time for a reality check and some action, or at least a clearly communicated plan of action (eg "we're going to be preparing for an open source release of the core language under X license over the next Y months"). They're also neutering the potential of a community ecosystem that makes languages successful by dragging their feet. This is a massive misstep strategically.

agree

Strong agree

It's likely a bug, and we'd love to fix it! :) Please create an issue here github.com/modularml/mojo/issues. You can read our prior posts here: www.modular.com/blog/mojo-a-journey-to-68-000x-speedup-over-python-part-3

Yeah, you're not wrong. It's a bug that they just fixed with dictionaries. It's about the same speed now or slightly slower than Python. Yes, it's odd, and I think it's good you're bringing it to the attention of Mojo, but be aware that Mojo is still developing - so benchmarks aren't always everything.

except that maybe we will need to write a lot of code to analyze the safety and correctness of the generated code! let alone the usage of newer and better APIs, that are not yet in the models!

😁

Compilers are “automagic” and everyone uses a compiler. And Chris built the best compiler in history

Appreciate Brians efforts and slides are amazing work but context matters. This isn't a place to share best practice ideas, it is Mojo community meeting. So, it is natural for Modular team to interrupt him because he was taking a lot of time in community meeting out of context. I advise Brian to instead start making online blog, his research skills are pretty good, but he should present his work on a place where it makes more sense to do so.

I used to run events like this. 2 ideas here. (1) tell the speaker a hard time limit and hold them to it. (2) If you have the resources, have them do a dry run, and give them feedback on timing, delivery, and clarity prior to the event. That increases quality a lot, and speakers really appreciate it and come more prepared

Hey, Brian here. Two things: 1) I was keeping my stopwatch running during my talk. Most other talks went on for 15 mins, so I thought that's how much time I had. Turns out I only had 10 because time was running short. 2) Whatever concurrency model Mojo adopts will not get much adoption if ordinary application programmers find it too complicated. Concurrency is generally considered to be super complicated and for experts, with lots of opportunity for bugs. Those who don't have much experience with it end up using a lot of workarounds like Arc<Mutex<T>> which go against the whole point of concurrency and are massive performance footguns. There are a bunch of things programmers need to know to write concurrent code that is actually efficient. You can build the most theoretically beautiful thing that experts will admire for hours but get very little adoption. Mojo is meant to be learnable by Python programmers, so they need to be kept in mind while designing APIs. My talk was about what the community could do to make sure concurrency is widely adopted by Mojo programmers, many of whom will surely come from a Python background. I wanted to start it off by stating my opinions on what Mojo's concurrent APIs should look like so that people find them easy and simple to use while getting good performance out of their code. The reason why I also mentioned libraries and learning materials in the beginning is that humans are creatures of habit. From the beginning, we're taught bad habits (think time.sleep()) which we have to unlearn when we want to improve the code we write. This creates a lot of friction and hesitancy to dedicate time to learning how to write properly concurrent code. There's a lot the community can do here to make sure that programmers learn better habits from the beginning. I thought a talk on these topics was relevant for the Mojo community, so I made it. Tatiana didn't think so. Doesn't mean I'm gonna stop being involved with the community. And yes, clearly I'm a better writer than I am a speaker.

Hey, Brian here. Two things: 1) I was keeping my stopwatch running during my talk. Most other talks went on for 15 mins, so I thought that's how much time I had. Turns out I only had 10 because time was running short. 2) Whatever concurrency model Mojo adopts will not get much adoption if ordinary application programmers find it too complicated. Concurrency is generally considered to be super complicated and for experts, with lots of opportunity for bugs. Those who don't have much experience with it end up using a lot of workarounds like Arc<Mutex<T>> which go against the whole point of concurrency and are massive performance footguns. There are a bunch of things programmers need to know to write concurrent code that is actually efficient. You can build the most theoretically beautiful thing that experts will admire for hours but get very little adoption. Mojo is meant to be learnable by Python programmers, so they need to be kept in mind while designing APIs. My talk was about what the community could do to make sure concurrency is widely adopted by Mojo programmers, many of whom will surely come from a Python background. I wanted to start it off by stating my opinions on what Mojo's concurrent APIs should look like so that people find them easy and simple to use while getting good performance out of their code. The reason why I also mentioned libraries and learning materials in the beginning is that humans are creatures of habit. From the beginning, we're taught bad habits (think time.sleep()) which we have to unlearn when we want to improve the code we write. This creates a lot of friction and hesitancy to dedicate time to learning how to write properly concurrent code. There's a lot the community can do here to make sure that programmers learn better habits from the beginning. I thought a talk on these topics was relevant for the Mojo community, so I made it. Tatiana didn't think so. Doesn't mean I'm gonna stop being involved with the community. And yes, clearly I'm a better writer than I am a speaker.

Hey, Brian here. Two things: 1) I was keeping my stopwatch running during my talk. Most other talks went on for 15 mins, so I thought that's how much time I had. Turns out I only had 10 because time was running short. 2) Whatever concurrency model Mojo adopts will not get much adoption if ordinary application programmers find it too complicated. Concurrency is generally considered to be super complicated and for experts, with lots of opportunity for bugs. Those who don't have much experience with it end up using a lot of workarounds like Arc<Mutex<T>> which go against the whole point of concurrency and are massive performance footguns. There are a bunch of things programmers need to know to write concurrent code that is actually efficient. You can build the most theoretically beautiful thing that experts will admire for hours but get very little adoption. Mojo is meant to be learnable by Python programmers, so they need to be kept in mind while designing APIs. My talk was about what the community could do to make sure concurrency is widely adopted by Mojo programmers, many of whom will surely come from a Python background. I wanted to start it off by stating my opinions on what Mojo's concurrent APIs should look like so that people find them easy and simple to use while getting good performance out of their code. The reason why I also mentioned libraries and learning materials in the beginning is that humans are creatures of habit. From the beginning, we're taught bad habits (think time.sleep()) which we have to unlearn when we want to improve the code we write. This creates a lot of friction and hesitancy to dedicate time to learning how to write properly concurrent code. There's a lot the community can do here to make sure that programmers learn better habits from the beginning. I thought a talk on these topics was relevant for the Mojo community, so I made it. Tatiana didn't think so. Doesn't mean I'm gonna stop being involved with the community. And yes, clearly I'm a better writer than I am a speaker.

There's no immediate plan for windows support but MAX works on WSL2.

Thank you very much to incentivize to do that, I would otherwise not have noticed it ever.

Yes, if you're in jupyter notebook environment