Yes, it is a “capital F” Framework. Meaning, at least using the go sdk, I felt like a lot of my existing go knowledge (was developing go professionally for about 6 years before my first temporal project) wasn’t as much of a help when learning temporal as I thought it would be. Mainly I was very comfortable using things like go routines and channels, but picking up the temporal versions of these in order to avoid non-determinism took a while. So there were a number of situations where another dev would ask me “how do I do X in go”, and frequently I knew the answer but had to figure out how to make it work in a temporal workflow. This wasn’t helped by the fact that, at least as of recently, their documentation was incredibly lackluster (the sdk is well commented though).

Additionally error handling is significantly more difficult in temporal than in normal go code in my experience, and I ended up needing to toss a lot of patterns around returning errors to avoid making handling on the caller side incredibly verbose. And I mean verbose by go error handling standards.

I will say that the overall product is really good, and I would definitely recommend it for use cases where you have long running workflows. We have workflows running for several months and being able to do things like call ‘time.sleep(10 days)’ in normal code, without having to think about the internals of scheduling resumption ourselves, is huge. I’ve just heard other teams in my org wanting to use temporal when there isn’t the same time (or “temporal”) component to the problem they’re trying to solve, usually just because they heard about auto retries, and I’m not convinced it’s worth it in those cases