Having the same concurrency advantages as Golang in the future？

[yingjie52]

Will Mojo also have the ability to support a large amount of concurrency in the future。

[lattner]

Mojo already has full concurrency support and a high performance runtime, it just isn't fully exposed through the APIs yet.

[ego]

Will Mojo also have the ability to support a large amount of concurrency in the future。

Golang's go is awesome. What about software transactional memory system (STM) (like in Clojure)? Chanels/Agents/Atoms any other primitives? Or it will be something simple like in rust, zig (thread/spawn)?

[samuell]

As someone who wrote a tool that is heavily dependent on the concurrency primitives in Go to provide an extremely small codebase for what it does, I wanted to chime in with the components I think are important here, as it seems one or more of these are often left out in many discussions:

• Light-weight threads (aka go-routines)
• Automatic multiplexing of those threads onto OS threads and thus physical cores (aka M:N multiplexing)
• Channels with the choice of 0...* (zero to many) items of buffer, to provide synchronization points, which can be used for automatic backpressure
• Kind of implicit from the above, but anyway: Ability for the lightweight threads to stop and being paused at a blocking channel, until it gets unblocked again.
• Language support to effectively selectively read from channels, such as Go:s select() statement.

The only language I know of that supports all of these currently is Crystal (see this comparison with Go if interested).

I think Python/Mojo could come close with asyncio with asyncio.Queue() for the channels etc. But not sure how much work it would require to also make use of proper threading.

Given the more powerful backend in Mojo, it would be extremely cool with a version of asyncio that is based on true Go-like M:N multiplexed lightweight threads (so in effect running on multiple cores when available!).

I see a ton of potential if the support here gets close to the Go concurrency primitives, once Mojo also comes out with an open source, locally runnable toolchain (important in scientific/academic domains).

[lattner]

Mojo already supports 1,2,4. We support the low level runtime for 3,5 already but need to build out those APIs. The very recent Swift concurrency features provide support for all of these FWIW, and I expect Mojo to take a step further.

[samuell]

Mojo already supports 1,2,4. We support the low level runtime for 3,5 already but need to build out those APIs. The very recent Swift concurrency features provide support for all of these FWIW, and I expect Mojo to take a step further.

Cool, that's great to hear, and great info! Many thanks!

[yingjie52]

Mojo should improve concurrency while maintaining concise Python syntax, and not increase syntax difficulty to improve performance. I believe that Mojo's development goal is to improve concurrency while maintaining concise syntax. If you increase grammar difficulty to improve performance, then Golang and other grammars can do it. The magic of Mojo is that its performance is so powerful despite its simple syntax. I hope the organizers can develop a breakthrough way to achieve it, in order to maintain their advantages over Python and Golang

[samuell]

While I'm not very worried, as Mojo seems to be going in a great direction here, I agree about that.

It is also clear that these concurrency primitives can be combined with much easier syntax than in Go, as demonstrated by the Crystal language (see e.g. this comparison).