What kind of concurrency models are being considered?

[nashaad]

Are go like coroutines (Communicating sequential processes), task oriented async patterns or actor model being considered for carbon?

[yarcowang]

Yes, I'm also curious about this question~ Because a lot of modern programming languages try to solve the problem, and I didn't read it in carbon's document.

[xuanswe]

This is one of the most important features I want to check in each language.
Currently, this is one big issue in Rust, therefore most people prefer Go for distributed systems.
I hope there will be a single mordern language that can be used not only for system programing, embedded but also for distributed systems.

There's one example regarding this problem is TiKV and TiDB.
TiKV uses Rust to avoid GC.
TiDB uses Go because of concurrency support.

Maybe in the future, this kind of issue is solved by using Carbon ;).

[dellwatson]

@xuan-nguyen-swe it's not really big issue in rust. it is already in built thread in rust too. tokio-rust is also have same vision with golang. it is just more easy to implement in golang alongside the simplicity in their language too

[jwtowner]

Are go like coroutines (Communicating sequential processes)

From what I can tell, it has support for something close to C++20 coroutines with the __await, __run and __continuation keywords. See https://github.com/carbon-language/carbon-lang/tree/trunk/explorer#experimental-feature-delimited-continuations

Anything higher level, such as tasks, executors, actors, etc. I imagine would likely be implemented as libraries. Carbon also implements the C++ memory model for atomics.

[jonmeow]

The coroutines are really an early experiment. The __ prefix is because we haven't really discussed them much. We definitely think something needs to exist in the area but don't know for sure what the shape will be. We're hoping we'll get the interest of experts in the area to help us design a good solution.

[geoffromer]

I'd say they're not even an early experiment; their only purpose was to make sure that Explorer's internal design is capable of expressing suspend/resume-style computation. There's no expectation that Carbon's eventual concurrency features will look anything like what's currently in Explorer.

[smallstepforman]

I've been using a C++ based Actor library for the last 5 years, and the biggest issue with a language which doesn't fundamentally support Actors is that there is no mechanism to prevent a client from manually invoking the "Behaviour" function instead of using the async messaging framework. Also, sharing data amongst Actors is problematic - a non Actor language will happily share a pointer. To safely use an Actor framework, the compiler really needs to understand that it is dealing with an Actor object which restricts how others interact with the Actor. I have written an Actor library for C++, but I wouldn't recommend inexperienced developers use the Actor model without language support. Pony showed promise, and would have been great without GC. Sadly, that language is gone.