sdk-java | rr | |
---|---|---|
47 | 102 | |
193 | 8,665 | |
1.6% | 1.1% | |
8.6 | 9.6 | |
6 days ago | 6 days ago | |
Java | C++ | |
Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
sdk-java
-
Show HN: Hatchet – Open-source distributed task queue
How does this compare against Temporal/Cadence/Conductor? Does hatchet also support durable execution?
https://temporal.io/
-
When "letting it crash" is not enough
Flawless sounds a lot like https://temporal.io/ .
I'm wondering if it has the same scalability concerns - sticking everything in Postgres is fine at small-ish scale, but what happens when you outgrow Postgres, either because you have higher availability requirements (can't handle primary DB restarts) or because of the sheer volume of the workload?
-
How To Collect Temporal.io Logs Using Axiom And Pino
Temporal is a scalable and reliable runtime for durable Workflow Executions. It enables you to develop as if failures don't even exist. I started exploring it over the Christmas holiday and using it for a recently open-sourced project.
-
Ask HN: How have you implemented human-in-the-loop workflows?
I have my eyes on https://temporal.io/ for similar purposes.
-
Which queue System you prefer for ecommerce and PS
Check out temporal.io open source project for a much cleaner solution using Durable Execution abstraction.
-
StackStorm – IFTTT for Ops
Interesting to see Netflix featured both on StackStorm & https://temporal.io/ frontpages.
- Open source durable execution platform
-
Leveraging Temporal for resilient remote procedure calls (RPC)
Our stack at Escape is written in multiple languages because each team has specific needs. We use TypeScript for its vibrant ecosystem, Python for cybersecurity research and Go for performance-sensitive tasks. To orchestrate cross-language task orchestration, we first developed a simple request-response protocol over HTTP, but it wasn't sustainable as the Escape codebase grew rapidly. We evaluated several technologies to replace our homegrown protocol, and two emerged as the most promising options: Connect and Temporal. The title gives it away, but the reason is far from obvious
-
Ask HN: In which areas have you compared 3+ tools and formed strong preferences?
I've put a lot of time into Airflow and feel similarly that it's a huge pain and a risk to rely on it. I've replaced it with Temporal (https://temporal.io/) and while I don't have the breadth of experience with the frameworks you listed, I do think Temporal is a great replacement for Airflow.
-
Inngest raises $3M seed to build the reliable workflow platform for every dev
Just to confirm my understanding; would you consider at least part of your product offering to be similar to temporal.io [1]? Your examples are reminiscent of theirs.
[1] https://temporal.io/
rr
- rr: Lightweight Recording and Deterministic Debugging
-
Hermit is a hermetic and reproducible sandbox for running programs
I think this tool must share a lot techniques and use cases with rr. I wonder how it compares in various aspects.
https://rr-project.org/
rr "sells" as a "reversible debugger", but it obviously needs the determinism for its record and replay to work, and AFAIK it employs similar techniques regarding system call interception and serializing on a single CPU. The reversible debugger aspect is built on periodic snapshotting on top of it and replaying from those snapshots, AFAIK. They package it in a gdb compatible interface.
Hermit also lists record/replay as a motivation, although it doesn't list reversible debugging in general.
- Rr: Lightweight Recording and Deterministic Debugging
-
Deep Bug
Interesting. Perhaps you can inspect the disassembly of the function in question when using Graal and HotSpot. It is likely related to that.
Another debugging technique we use for heisenbugs is to see if `rr` [1] can reproduce it. If it can then that's great as it allows you to go back in time to debug what may have caused the bug. But `rr` is often not great for concurrency bugs since it emulates a single-core machine. Though debugging a VM is generally a nightmare. What we desperately need is a debugger that can debug both the VM and the language running on top of it. Usually it's one or the other.
> In general I’d argue you haven’t fixed a bug unless you understand why it happened and why your fix worked, which makes this frustrating, since every indication is that the bug exists within proprietary code that is out of my reach.
Were you using Oracle GraalVM? GraalVM community edition is open source, so maybe it's worth checking if it is reproducible in that.
[1]: https://github.com/rr-debugger/rr
-
So you think you want to write a deterministic hypervisor?
https://rr-project.org/ had the same problem. They use the retired conditional branch counter instead of instruction counter, and then instruction steeping until at the correct address.
-
Is Something Bugging You?
That'll work great for your Distributed QSort Incorporated startup, where the only product is a sorting algorithm.
Formal software verification is very useful. But what can be usefully formalized is rather limited, and what can be formalized correctly in practice is even more limited. That means you need to restrict your scope to something sane and useful. As a result, in the real world running thousands of tests is practically useful. (Well, it depends on what those tests are; it's easy to write 1000s of tests that either test the same thing, or only test the things that will pass and not the things that would fail.) They are especially useful if running in a mode where the unexpected happens often, as it sounds like this system can do. (It's reminiscent of rr's chaos mode -- https://rr-project.org/ linking to https://robert.ocallahan.org/2016/02/introducing-rr-chaos-mo... )
-
When "letting it crash" is not enough
The approach of check-pointing computation such that it is resumable and restartable sounds similar to a time-traveling debugger, like rr or WinDbg:
https://rr-project.org/
https://learn.microsoft.com/windows-hardware/drivers/debugge...
- When I got started I debugged using printf() today I debug with print()
- Rr: Record and Replay Debugger – Reverse Debugger
-
OpenBSD KDE Plasma Desktop
https://github.com/rr-debugger/rr?tab=readme-ov-file#system-...
What are some alternatives?
sdk-python - Temporal Python SDK
CodeLLDB - A native debugger extension for VSCode based on LLDB
trigger.dev - Trigger.dev is the open source background jobs platform for TypeScript.
rrweb - record and replay the web
sdk-python - Python library for Modzy Machine Learning Operations (MLOps) Platform
gef - GEF (GDB Enhanced Features) - a modern experience for GDB with advanced debugging capabilities for exploit devs & reverse engineers on Linux
windmill - Open-source developer platform to turn scripts into workflows and UIs. Fastest workflow engine (5x vs Airflow). Open-source alternative to Airplane and Retool.
Module Linker - browse modules by clicking directly on "import" statements on GitHub
inngestgo - Golang SDK for Inngest
nbdev - Create delightful software with Jupyter Notebooks
litestream - Streaming replication for SQLite.
clog-cli - Generate beautiful changelogs from your Git commit history