Cool, congrats on launching! Could this replace Jobrunr?
Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust
91–100 of 112 posts
Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust
#92Cool, congrats on launching! Could this replace Jobrunr?
Thanks! I'm not familiar with Jobrunr, but we can definitely help with orchestrating async tasks (as well as sync rpc calls), especially if its important that they run to completion
Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust
#93Cool, congrats on launching! Could this replace Jobrunr?
From a quick glance at what JobRunr does (especially running asynchronous/delayed background tasks), it seems that Restate would be a very good fit for it as well. Restate will also handle persistence for you w/o having to deploy & operate a separate RDBMS or NoSQL store. Note that I am not a JobRunr expert, though.
Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust
#94Earlier quoted context omitted.
I think you would need to validate the response from the first call before determining it to be a success?
First call: fetch a widget Success! Your widget expires in 30 seconds Second call: use widget Failure! For some reason or another Ok, so restart the flow… First call: fetch a widget Cached! Receive the same widget again Second call: use widget Failure! widget has now expired
Ah I see what you mean. In this case the handler should complete with a terminal error - we weren't able to finish the task in time. Of course, many types of errors and timeouts are valid application-level results, not transient infrastructure issues. And sadly, tight timeouts push transient issues into application-level issues, and this is unavoidable, I think
Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust
#95I understand the need for writing this as an SDK over existing languages for adoption reasons, but in your opinion would a programming language purposely built for such a paradigm make more sense?
(Disclaimer: I work at Restate on SDKs) This is a very interesting point. I did some investigation myself, and so far I'm torn apart on whether a novel language would really make such a big difference for durable execution engines like Restate. Let me elaborate it: first of all, what would be the killer feature that justifies creating a whole new PL for durable execution? From what I can tell, the thing that IMO can…
Oh wow, thanks for the depth in your reply. well I don't know anything about programming languages but something just made me ask this question out of curiosity. I may have to play around with restate a bit
Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust
#96I'm not sure "In Rust" serve any marketing value. A product's success rarely has to do with the use of a programming language, if not at all. I understand the arguments made by Paul Graham on the effectiveness of programming languages, but specifically for a workflow manager, a user like me cares literally zero about which programming language the workflow system uses even if I have to hack into the internal of the s…
it does if it makes Hners click upvote...
Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust
#97I'm not sure "In Rust" serve any marketing value. A product's success rarely has to do with the use of a programming language, if not at all. I understand the arguments made by Paul Graham on the effectiveness of programming languages, but specifically for a workflow manager, a user like me cares literally zero about which programming language the workflow system uses even if I have to hack into the internal of the s…
Having spent a lot of time recently writing Rust it's a major negative for me.
It's a terrible language for concurrency and transitive dependencies can cause panics which you often can't recover from.
Which means the entire ecosystem is like sitting on old dynamite waiting to explode.
JVM really has proven itself to be by far the best choice for high-concurrency, back-end applications.
Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust
#98Looks really awesome. Always been looking for some easy to use async workflows + cronjobs service to use with serverless like Vercel. Also something about this area always makes me excited. I guess it must be the thought of having all these tasks just working in the background without having to explicitly manage them. One question I have is does anyone have experience for building data pipelines in this type of archi…
While Restate is not optimized for analytical workloads it should be fast enough to also use it for simpler analytical workloads. Admittedly, it currently lacks a fluent API to express a dataflow graph but this is something that can be added on top of the existing APIs. As @gvdongen mentioned a scatter-gather like pattern can be easily expressed with Restate.
Regarding whether to parallelize or to batch, I think this strongly depends on what the actual operation involves. If it involves some CPU-intensive work like model inference, for example, then running more parallel tasks will probably speed things up.
Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust
#99This seems interesting!
I couldn’t find an equivalent of the codec server in temporal that basically encrypts all data in the event log. Is there something similar?
Re: Show HN: Restate – Low-latency durable workflows for JavaScript/Java, in Rust
#100This seems interesting! I couldn’t find an equivalent of the codec server in temporal that basically encrypts all data in the event log. Is there something similar?
We haven’t built any client side encryption tools yet. I don’t think it would be particularly difficult to do an MVP. If it’s very important to your use case, come chat to us in Discord? https://discord.com/invite/skW3AZ6uGd