Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Instead of the current “generic over asyncness” I informally proposed something using the where clause, at least for function bounds
In fact, you've actually been a huge source of inspiration for building keyword-generics into the programming language I've been working on in private for the past 2 years! The language is called "Claro" and if you're interested, please take a look at the blocking-generics syntax that your initiative has inspired.
Open issue, Must a const fn behave exactly the same at runtime as at compile-time?
On the contrary, we're actually looking at potentially removing the restriction that const fn are pure at runtime: RFC#3352 Relax const-eval restrictions.
I think it's fairer to say the language got so much more powerful that there wasn't any point making actors a language feature when they can be built from existing orthogonal language features. You're probably looking for actix (not actix-web, just actix). There's also Lunatic built in Rust but supporting any actors compiled to WebAssembly.
I think it's fairer to say the language got so much more powerful that there wasn't any point making actors a language feature when they can be built from existing orthogonal language features. You're probably looking for actix (not actix-web, just actix). There's also Lunatic built in Rust but supporting any actors compiled to WebAssembly.
The remaining gap is remote actors, since you still need some kind of serialization between them, and take your pick of standards for that one such as gRPC using Tonic.