TBH I am yet to encounter an "automagic" system that simply works as expected. They tend to fail in catastrophic ways and result in a lot of dev time wasted just to understand & fix the performance issues. At this point all I'm interested is good primitives combined with extensive API's and libraries for me to build my own systems.
Brian did too much efforts to do this and present it. It is good that before the meeting you saw his slides or his ideas or his experience that will be present it and you told him comments offline or reject him politely offline. I know that your time is important too, but stopping him like this and telling him this is basic information for you, specially he told you he just stated computer science. He did too much research and efforts to create this, he wanted to help but now I am sure he is not happy and do not want to do any thing related to mojo, part 2 will not be happening. He was excited. You could show him some support he would be a great contributor to the ecosystem.
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 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 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 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.
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!
Mojo community meeting? I'm here for it.
When will mojo v1.0.0 release?
TBH I am yet to encounter an "automagic" system that simply works as expected. They tend to fail in catastrophic ways and result in a lot of dev time wasted just to understand & fix the performance issues. At this point all I'm interested is good primitives combined with extensive API's and libraries for me to build my own systems.
Compilers are “automagic” and everyone uses a compiler. And Chris built the best compiler in history
16:30 - story of my life with most higher level languages, even ignoring the GPU
Cute mascot made me click the video 🗿
Brian did too much efforts to do this and present it. It is good that before the meeting you saw his slides or his ideas or his experience that will be present it and you told him comments offline or reject him politely offline. I know that your time is important too, but stopping him like this and telling him this is basic information for you, specially he told you he just stated computer science. He did too much research and efforts to create this, he wanted to help but now I am sure he is not happy and do not want to do any thing related to mojo, part 2 will not be happening. He was excited. You could show him some support he would be a great contributor to the ecosystem.
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 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 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 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.
Just get into ai ecosystem. No one will type out code manually in 2 years
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!