kodablah

Replied to another in this thread, but basically https://temporal.io/in-use lists many, AI and not.

I fear I'll come off as a shill, but I've seen dozens of company uses of AI in workflows in the real world. Agents are just orchestrating multiple AI steps basically (granted not all of them are using AI to _pick_ the step to take which is often what "agentic" is seen as). Some are listed at https://temporal.io/in-use alongside the many non-AI things, e.g. https://temporal.io/resources/case-studies/bugcrowd, https://temporal.io/resources/on-demand/arc-xp-washington-po..., https://temporal.io/resources/on-demand/practical-tactical-a..., and more and more. All those companies use AI workflows in real world cases, and there are many more. I only showed the tutorial to agree with OP that it is just workflows with fuzzier steps and that's ok.

What's wrong with an agent being a glorified workflow? At Temporal (where I work), it seems plenty natural for agentic AI to just be AI worklows. Here's a video we put out this week demonstrating it: https://youtu.be/GEXllEH2XiQ (code at https://github.com/steveandroulakis/temporal-ai-agent).

Interesting, this is very similar to some of the things we do to language runtimes at Temporal to ensure durability/resumability.

Is the persistence layer and the calls to persist/checkpoint pluggable/extensible?

Question unrelated to the game specifically - how does Netlify quantify the number of developers? How does it know/guess that it is 5 million?

This is not the case everywhere in Texas. In many places, you fill in a paper ballot at a booth and feed it into a machine at the end with nothing printed afterwards.

I have been looking for this for a while. I built a browser with Chromium Embedded Framework (CEF) a while back, but Google neutered all users of it by disallowing Google logins from it using opaque heuristics that were hard to work around.

I made a POC of using Qt to capture the FF window: https://github.com/cretz/ffembedpoc. But I fear if a browser engine becomes too easy to embed, large companies like Google will blackball it for fear of automated use, like they've done in the past.

Correct, granted it's more complicated than "clients". At least Node.js (Neon), Python (PyO3), and Ruby (rb-sys/magnus) have nice supported bridge wrappers. The .NET-to-Rust interfacing in the Temporal .NET SDK required pure C FFI and P/Invoke and being careful about GC and lifetimes during interop. Can see the bridge at https://github.com/temporalio/sdk-dotnet/tree/main/src/Tempo....

I can say with regards to panics, .NET is very nice to wrap Rust panics into `SEHException` classes (though of course we strive to be completely panic free).

> And for the transition phase, there has to be interop for async ↔ async2

For those like me who weren't clear whether `async2` was expected to be a real keyword in the final language, it's not[0].

0 - https://github.com/dotnet/runtime/issues/94620#issuecomment-...

> picking a copyleft license must mean that you care about user freedoms [...] they're giving up on their principles

This is a personal bias and disregards others' definition of true do-whatever-you-want freedom. Different project owners may think differently on what free means and alter the license to respect their principles (and may consider copyleft to be the restrictive/anti-free mistake made early on based on these same kinds of personal biases).

And many contributors don't really care what the project owner does with their code and the CLA lets them delegate responsibility.

Sure, and I think the CLA is a good signal to those that care about how their contribution is used to stay away. But for everyone else that's not concerned with that, the CLA is not inherently evil.

This is not necessarily true. Sometimes it's needed to pivot to a better/different open source license without going through the pain of contacting every contributor ever. I have seen that pain in some projects that want to go from LGPL to MIT or something.

For many contributors, they're ok giving full ownership of their contributions to a project owner on the owner's terms. Some contributors may not be ok with that of course, but it doesn't mean that every project owner has nefarious plans with said code ownership.

> Ghost / Replay

This is harder than it seems. However I have seen vscode users use `rr` recordings to even step backwards from a breakpoint. But it is gdb-based (i.e. not very platform independent) and is not displayed in a "ghost" like manner which would be neat. I think the first step is for runtimes to get better at recording replays.

My suggestion is to hit up the Social Security Administration website: https://www.ssa.gov/oact/babynames/. Go back a century (or to some era of choice), walk the list, find one that you like that isn't even in the top X these days and you'll be fairly safe. You'll end up with a reasonable, not-ridiculously-unique name that this generation mostly doesn't have (the site has recent years and names don't usually go from unlisted to popular overnight).

> the popular girl's name of the decade, apparently.

Keep in mind, in the internet era it can actually be nice to have a bad-SEO common name (though that's often dependent upon surname too).

For the longest time (up until earlier this year[0]), you couldn't even get the proto details from a gRPC error. IME GP is correct, there are so many caveats to gRPC implementations that unless it is a prioritized, canonical implementation it will be missing things. It seems there are tons of gRPC libraries out there that fell behind or were missing features that you don't know until you need them (e.g. I recently had to do a big lift to implement HTTP proxy support in Tonic for a project).

0 - https://github.com/grpc/grpc-dotnet/issues/303

It seems like the struggle here is trying to use Rust transparently/automatically from another language instead of just make bindings easier. I have found that trying to auto-FFI existing Rust types is not the best for languages because there is often an impedance mismatch with how the language treats things and how Rust does. Therefore trying an always-works transparent binding may inevitably end up with people asking for more flexibility to fit the language better (e.g. controlling lifetime semantics, type mappings/copying, etc).

I think it's clearer to take an approach like Neon and PyO3 and other FFI-to-lang helpers do where you just make it easy/safe to write these Vale functions in Rust.

That's no coincidence, Temporal is founded by the creators of Amazon Simple Workflow. See https://temporal.io/about.

We offer a full guide to help here at https://docs.temporal.io/self-hosted-guide and many users of all sizes self-host Temporal. Having said that, it has challenges as does running any high-available production system. We offer cloud to ease this burden. You still run all your code/workers and you can end-to-end encrypt all data.

Fixed, thanks! (it had undergone revisions hence the function name mismatch)

(to clarify my ambiguous disclaimer, I am the author of OP's Temporal post, not the Celery one)

The Temporal server stores events and distributes tasks. There is a cloud offering or it can be self-hosted (with support for Cassandra, Postgres, MySQL, and SQLite persistence). This post focuses more on the Temporal Python SDK and not the general platform.

Yes, it has undergone revisions since which caused function name mismatch (EDIT: fixed). The execute_activity there uses start_to_close_timeout which is per attempt and will retry forever by default (customizable).

This is more of a primer on the Python part of Temporal rather than an explanation of all Temporal concepts in depth. Definitely would recommend reading the fundamental docs at https://docs.temporal.io/encyclopedia/. For more exact samples, see https://github.com/temporalio/samples-python.

Yes, C# is faster just because it's a faster runtime, but Python does scale reasonably well for this use case.

Not necessarily "equal" but the basic premise is the same, yes, and there is a common lineage. Azure Durable Functions sits on Azure Durable Task Framework which was created by the co-founder of Temporal (https://temporal.io/about).

(disclaimer, I'm the author of the post)

Yes, that is good design and the event loop should basically be shared process-wide (asyncio objects are usually not thread safe and cannot be shared across event loops). Temporal only does custom event loops in isolated workflows.

To add to other responses here, Temporal doesn't take over the default event loop in general (and users still use it for clients and activities and such). Temporal workflows must be deterministic and durable which means they are guaranteed to run and are resumable on other machines. Therefore Temporal workflows specifically operate on a custom event loop implementation. It doesn't affect anything outside the workflow.

Many Temporal users used Celery in the past. There was a popular blog post a while back about issues with celery: https://steve.dignam.xyz/2023/05/20/many-problems-with-celer.... Here's a brief heading-by-heading listing of how Temporal addresses those issues: https://community.temporal.io/t/suggestion-for-blog-post-abo....

(disclaimer, I'm the author of the post)

We need hundreds or thousands and they need to be cheap and, in Temporal's case, the cooperative multitasking needs to be deterministic which native threads are not. Temporal's C# SDK uses .NET tasks the same way and tasks have a lot of parallels with asyncio (though they combine with threads in one static thread pool which can be confusing in itself).

> Relying on external APIs or databases within activities might lead to variability in workflow execution.

This is why they are activities. Their results are stored in history, the workflow remains deterministic.

> might need to see how it accounts for more complex scenarios where errors are transient or where a retry could be successful even for some client errors like rate limiting or temporary unavailability etc.

Temporal allows you to specify whether an error is retryable or not.

This and other similar CPU-bound operations may be unreasonable to detect at analysis time. I would encourage users to run with asyncio debug mode in tests to help catch these: https://docs.python.org/3/library/asyncio-dev.html#debug-mod.... Granted that's runtime, but there are limitations on what analysis can perform, it's just meant to help catch obvious issues.