But I am someone who loves Elixir and would like this to not be released under a commercial license.
I also thing that this person should be rewarded for their efforts, it ain’t easy to build this.. so I’m trying to tip the hat to Temporal to incentives this person to make this SDK more open source friendly.
I can guess that many don’t know what temporal is, or why they should care about it for Elixir.. BUT….
On the surface it’s not an easy sell as this language gives us all the foundations for distributed computing. All I can say is that it gets harder the more you go beyond the basics and Temporal solves a lot of the “beyond the basics”, without feeling any harder than the basics.
I’m not a shill, but I am a fan of Temporal so I’m happy to answer any questions.
My goal is completely transparent…I would love for both this guy to be paid and for this SDK to be opened up more.
I heard of it many times over my career but never found it doing anything that Oban on multiple nodes can’t do as well – and we’re not even talking Oban Pro, just the free Oban.
I have rarely worked for a long time on projects that require such a scale – but I remain skeptical of the paid offering.
Admittedly though, I never sat to compare it with Oban, feature by feature, side by side. Have you? What does Temporal offer that’s making it indispensable?
Hey @dimitarvp I’ve been in non elixir world for some time so I’m probably way off.
Last time I looked at Oban, it was the best of the many worker queue implementation in elixir.
To create durable workflows required building your own external state. Im very, very very happy to be wrong. I know Oban Pro had some workflow equivalent but it seemed more expensive and clunky that temporal at the time.
Does it have the equivalent of signals and queries and support mutil day workflow?
Honestly my main thing is that I don’t get to work with Elixir on a daily basis, and anything that can add Elixir as a possibility is good for me.
Can you say specifically what Oban did I might be able to do a half ass job of explaining the differences
I don’t think Oban is more expensive. Oban pro doesn’t charge on the amount of jobs you execute, Temporal does.
You don’t own the infrastructure where Temporal execute, that’s why included in their pricing is storage.
Oban you pay to have access to the code, it gonna run on your own infrastructure, and it can run as many jobs as you want, the price won’t change. I’ve worked in places where what we run daily on oban would consume all the jobs available on temporal basic plan(the only one that is “cheaper” than oban)
So, to reproduce exactly what temporal does you would need more than just Oban or Oban Pro, but there is a big trade-off being done there. Temporal abstraction “encapsulate” and save state of the world to execute, but if that state becomes stale it can byte you, Oban Workflows from Pro is not as powerfull as Temporal but with a good experience on how to properly build the job to give you the guarantees that you need to a paritcular use case you wont need something as powerfull as Temporal.
Temporal is very appealing to runtimes that doesn’t have the safety, resiliency and isolation that the beam does. temporal deal with more then that, but the biggest appeal is exactly what we already get with using the beam itself, the extra stuff is only additional and can be engineered depending on your real needs.
I’m in SE Asia, so it’s late here and I’m tired. I’ll respond tomorrow…
Tonight I’ll just say that I never intended an Oban vs Temporal debate. I actually have more questions than answers about that…
That said, from my little knowledge, I already know that there’s are more than a few “apples to oranges” comparison here, which I’ll respond to tomorrow.
Either way my point is that the standard “BEAM can do everything” conversation doesn’t help Eixir get more adoption… and I want more adoption!.
IMO this is a good product and we should support a BEAM based SDKs for it.
Like I said I’ll give a good shot at responding tomorrow, but not for comparison against Oban, just to get more traction for something I think it’s worth highlighting.
Nobody is saying that. But as @cevado pointed out, Temporal’s pricing can be viewed as predatory – I sure don’t want to get billed on tiers of amount of work processed.
That I think we all agree with.
This is a dev forum. But maybe “getting traction” will find sympathetic ears. I don’t speak for the whole community, obviously.
To me Temporal is a relic from other times. The world has changed. That’s my surface-level evaluation of it.
Damn, man! I was on the verge of sleep and saw you typing so thought I’d wait for the response.. and man was it worth it. I can’t resist but to respond that post was too hilarious!
Relic!!! Hahaha, let me sleep man you’re cracking me up too much!
You know how old the BEAM is? Even Elixir is older I think.
As for preditory, what? Their Cloud offering is cheap, literally everything in our org costs more than this.
Tbh we were self hosting the open source version for ages but it’s cheaper and easier for us to use the SaaS than maintain ourself.
I am simply being honest about what I would buy and would not buy. As a dev I don’t want tiered pricing. To me that’s predatory. Feel free to disagree but you’ll not change my mind.
My question: so how do you use Temporal today, roll your own Elixir wrapper or use another fully supported language? If it is the second case, do you think there is any practical limitation of writing a port server in eg Python to interface with Temporal, other than being inelegant?
