4 ms·

https://temporal.io/ https://temporal.io/

swyx 6y ago
what do you like about it? (disclaimer, i work at temporal, but just genuinely interested in how you'd describe it in your words, good or bad lets hear it)
- poletopole 6y ago
  I may be able to answer your question. I only watched the video on the landing page and glanced at the docs, but it reminds me of what a saga system would do (like redux-saga perhaps), meaning that much of the side effects, such as networking, are abstracted away from the business logic, and there is the concept of compensation when things don't go as planned. Very neat!
  - swyx 6y ago
    yeah, "saga for the backend" is an appealing angle to some folks (eg our Coinbase testimonial has that) but i'm not sure how many developers know about sagas so I've been hesitant to push that too hard (bc then we'd have to teach people an extra concept before they get to us). i'd say something that is maybe hard to appreciate until you really get into it is just how much goes into making this ultra scalable with distributed transactions. If you have ~20 mins for it, I wrote this up recently: https://docs.temporal.io/blog/workflow-engine-principles https://docs.temporal.io/blog/workflow-engine-principles
    - poletopole 6y ago
      Not hard at all to appreciate. I know the consistency woes of juggling thousands of message queues with millions of messages and containers with enormous databases. The problem though, as I found out ironically, is that most dilbert bosses don't appreciate solutions like temporal, unless a tech "guru" tells them about it. For example, I get laughed at when I tell other developers that databases are an antiquated idea and should be avoided in general. What I've been working on in recent years is actually not too far off in terms of how to approach making truly simple code, but is far off in the sense that it'll take me (alone) years to make a pragmatic implementation, probably as a language in its own right. Rather than attempt to make a system partition tolerant I started thinking what if network partitions were assumed as the default? To answer that question you have to do things like measure the information entropy of data, use knot theory, representation theory such as young lattices, symmetric group mapping, character groups, prime number theory, among other goodies, to represent event-states, workflows, etc. Most of all (this is where things get weird) is rather than code programs, the emphasis becomes how to easily declaratively code and build "homotopic" multiplexed protocols instead (while keeping the business logic familiar), that way SDKs and integrations are a thing of the past. All this has of course has to use existing web standards like HTTP, otherwise it won't be adopted. My friend always laughs at me when I try to explain it to him, so I apologize, ha. But that's all the more reason to appreciate technology like temporal because it's something a developer can use today.
      - swyx 6y ago
        jeez, you had me until knot theory lol. sounds good, you get it. if you are interested in working with us... we're hiring haha. or happy to help promote if you want to write up your thoughts
        poletopole 6y ago
        I'll check out your hiring page.
- joshlemer 6y ago
  I would say that it allows one to write statefu, long lasting workflows or processes in a durable and persistent way using all the niceties of regular programming languages such as Go/Java, like control structures, abstraction, etc. In a similar way that generators in Python/JS allow one to write even complicated iterators much more easily than manually keeping track of state yourself, Temporal allows one to easily define long-lived stateful processes (on order of years even) with the simplicity of roughly: while(true) { Thread.sleep(1, MONTH); sendReminderEmail(user); } ...which would normally require one to manually keep track of state in queues and key-value stores and idempotent updates, but with temporal the developer can just focus on the simple business rules. The runtime of Temporal takes care of compiling that down into proper state-machine logic.
  - swyx 6y ago
    yeah nice, exactly. i like calling Temporal a "framework" for that reason - you'd have to code + provision all this stuff anyway if you're doing anything async, and you're probably not testing it properly/thinking through scalability needs or lacking debugging tools to investigate issues. I'll volunteer that we don't have Python or JS SDKs right now but are working on it (https://github.com/temporalio/sdk-node https://github.com/temporalio/sdk-node). i think `Thread.sleep(1, MONTH);` is a profound paradigm change in programming that I have been struggling to find the words to describe. It's like, where you used to need to write "multiuser" code, you can now write code as if you simply have one machine per user and it idled or did work as long as your user's activity is still going, whether we're talking the end-to-end journey of a food delivery startup or machine learning data pipelines or infrastructure provisioning at a cloud startup (you can even run a workflow for forever, with some careful segmentation https://docs.temporal.io/docs/concept-workflows#faq https://docs.temporal.io/docs/concept-workflows#faq). this is useful market research for us, thank you for taking up the suggestion :)

swyx 6y ago

what do you like about it? (disclaimer, i work at temporal, but just genuinely interested in how you'd describe it in your words, good or bad lets hear it)

poletopole 6y ago
I may be able to answer your question. I only watched the video on the landing page and glanced at the docs, but it reminds me of what a saga system would do (like redux-saga perhaps), meaning that much of the side effects, such as networking, are abstracted away from the business logic, and there is the concept of compensation when things don't go as planned. Very neat!
- swyx 6y ago
  yeah, "saga for the backend" is an appealing angle to some folks (eg our Coinbase testimonial has that) but i'm not sure how many developers know about sagas so I've been hesitant to push that too hard (bc then we'd have to teach people an extra concept before they get to us). i'd say something that is maybe hard to appreciate until you really get into it is just how much goes into making this ultra scalable with distributed transactions. If you have ~20 mins for it, I wrote this up recently: https://docs.temporal.io/blog/workflow-engine-principles https://docs.temporal.io/blog/workflow-engine-principles
  - poletopole 6y ago
    Not hard at all to appreciate. I know the consistency woes of juggling thousands of message queues with millions of messages and containers with enormous databases. The problem though, as I found out ironically, is that most dilbert bosses don't appreciate solutions like temporal, unless a tech "guru" tells them about it. For example, I get laughed at when I tell other developers that databases are an antiquated idea and should be avoided in general. What I've been working on in recent years is actually not too far off in terms of how to approach making truly simple code, but is far off in the sense that it'll take me (alone) years to make a pragmatic implementation, probably as a language in its own right. Rather than attempt to make a system partition tolerant I started thinking what if network partitions were assumed as the default? To answer that question you have to do things like measure the information entropy of data, use knot theory, representation theory such as young lattices, symmetric group mapping, character groups, prime number theory, among other goodies, to represent event-states, workflows, etc. Most of all (this is where things get weird) is rather than code programs, the emphasis becomes how to easily declaratively code and build "homotopic" multiplexed protocols instead (while keeping the business logic familiar), that way SDKs and integrations are a thing of the past. All this has of course has to use existing web standards like HTTP, otherwise it won't be adopted. My friend always laughs at me when I try to explain it to him, so I apologize, ha. But that's all the more reason to appreciate technology like temporal because it's something a developer can use today.
    - swyx 6y ago
      jeez, you had me until knot theory lol. sounds good, you get it. if you are interested in working with us... we're hiring haha. or happy to help promote if you want to write up your thoughts
      - poletopole 6y ago
        I'll check out your hiring page.
joshlemer 6y ago
I would say that it allows one to write statefu, long lasting workflows or processes in a durable and persistent way using all the niceties of regular programming languages such as Go/Java, like control structures, abstraction, etc. In a similar way that generators in Python/JS allow one to write even complicated iterators much more easily than manually keeping track of state yourself, Temporal allows one to easily define long-lived stateful processes (on order of years even) with the simplicity of roughly: while(true) { Thread.sleep(1, MONTH); sendReminderEmail(user); } ...which would normally require one to manually keep track of state in queues and key-value stores and idempotent updates, but with temporal the developer can just focus on the simple business rules. The runtime of Temporal takes care of compiling that down into proper state-machine logic.
- swyx 6y ago
  yeah nice, exactly. i like calling Temporal a "framework" for that reason - you'd have to code + provision all this stuff anyway if you're doing anything async, and you're probably not testing it properly/thinking through scalability needs or lacking debugging tools to investigate issues. I'll volunteer that we don't have Python or JS SDKs right now but are working on it (https://github.com/temporalio/sdk-node https://github.com/temporalio/sdk-node). i think `Thread.sleep(1, MONTH);` is a profound paradigm change in programming that I have been struggling to find the words to describe. It's like, where you used to need to write "multiuser" code, you can now write code as if you simply have one machine per user and it idled or did work as long as your user's activity is still going, whether we're talking the end-to-end journey of a food delivery startup or machine learning data pipelines or infrastructure provisioning at a cloud startup (you can even run a workflow for forever, with some careful segmentation https://docs.temporal.io/docs/concept-workflows#faq https://docs.temporal.io/docs/concept-workflows#faq). this is useful market research for us, thank you for taking up the suggestion :)