laudspeaker
hatchet
laudspeaker | hatchet | |
---|---|---|
34 | 16 | |
1,397 | 3,167 | |
2.5% | 18.7% | |
9.8 | 9.7 | |
2 days ago | 5 days ago | |
TypeScript | Go | |
GNU General Public License v3.0 or later | MIT License |
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.
laudspeaker
-
Ask HN: Who is hiring? (April 2024)
https://news.ycombinator.com/item?id=39836316
Laudspeaker | Remote| Full Time | Senior Software Eng / Founding Eng
We posted on hacker news a few days ago - you can see the whole post here (https://news.ycombinator.com/item?id=39836316)
Summary below:
We are building a new, open source suite of software tools to completely handle the "customer journey". You can see our repo here: https://github.com/laudspeaker/laudspeaker
We are a small team of 3, had a successful launch on HN a year ago, are backed by YC, and and are now starting to close large companies deploying our software to touch millions of users.
Who You Are:
-
Laudspeaker hiring senior engineer to build open source customer engagement
Our mission is to build a new, open source suite of software tools to completely handle the "customer journey". You can see our repo here: https://github.com/laudspeaker/laudspeaker and our site here: https://app.laudspeaker.com/login
We had a successful launch on HN a year ago, and have moved quickly since and are now starting to close large companies deploying our software to touch millions of users.
We continue to have an ambitious roadmap and are looking for a founding senior engineer to radically improve the product (take it from a 1->10, we have already built the 0->1) and help "level-up" the founders. We need our product to scale to tens of millions of messages sent an hour, handle millions of incoming api requests, add introduce engineering best practices, and tooling for our product to maintain SLAs
The right engineer will be excited to join a small team, excited to work on open source software, works well autonomously, can deal with ambiguity, and wants to work remotely (with minimum 4 hours of overlap sometime between 8am - 8pm pst)
Some more details:
- We work in Typescript with Nest.js for the backend and react for the frontend
-
How would you go about building your own email marketing system like Mailchimp?
laudspeaker: https://github.com/laudspeaker/laudspeaker
-
Launch HN: Dittofeed (YC S22) – open-source customer engagement platform
c) We can be self-hosted (A few users are self hosting today)
For others checking this out there are also older projects like Mautic [5]. And customer engagement is a large enough category that it includes projects like Chatwoot [6] that focuses more on customer support.
[1] https://github.com/laudspeaker/laudspeaker
- Laudspeaker hiring engineer to build open source customer journey software
-
i'm building an open source visual drag and drop editor for designing user messaging flows (like onboarding) for websites and apps
Play around with our cloud option : https://laudspeaker.com/ / https://app.laudspeaker.com/
-
Laudspeaker v1.3.0 - an open source marketing automation platform
Check out our GitHub (Licensed MIT + Apache 2.0): https://github.com/laudspeaker/laudspeaker
- An open source marketing automation platform
- Hey folks we built an open source marketing platform, check us out!
hatchet
-
Ask HN: Who is hiring? (April 2024)
Hatchet (https://hatchet.run) | New York City | Full-time
We're hiring a founding engineer to help us with development on our open-source, distributed task queue: https://github.com/hatchet-dev/hatchet.
We recently launched on HN, you can check out our launch here: https://news.ycombinator.com/item?id=39643136. We're two second-time YC founders in this for the long haul and we are just wrapping up the YC W24 batch.
As a founding engineer, you'll be responsible for contributing across the entire codebase. We'll compensate accordingly and with high equity. It's currently just the two founders + a part-time contractor. We're all technical and contribute code.
Stack: Typescript/React, Go and PostgreSQL.
To apply, email alexander [at] hatchet [dot] run, and include the following:
1. Tell us about something impressive you've built.
2. Ask a question or write a comment about the state of the project. For example: a file that stood out to you in the codebase, a Github issue or discussion that piqued your interest, a general comment on distributed systems/task queues, or why our code is bad and how you could improve it.
-
Show HN: Hatchet – Open-source distributed task queue
Can you explain why you chose every function to take in context? https://github.com/hatchet-dev/hatchet/blob/main/python-sdk/...
This seems like a lot of boiler plate to write functions with to me (context I created http://github.com/DAGWorks-Inc/hamilton).
Hello HN, we're Gabe and Alexander from Hatchet (https://hatchet.run), we're working on an open-source, distributed task queue. It's an alternative to tools like Celery for Python and BullMQ for Node.js, primarily focused on reliability and observability. It uses Postgres for the underlying queue.
Why build another managed queue? We wanted to build something with the benefits of full transactional enqueueing - particularly for dependent, DAG-style execution - and felt strongly that Postgres solves for 99.9% of queueing use-cases better than most alternatives (Celery uses Redis or RabbitMQ as a broker, BullMQ uses Redis). Since the introduction of SKIP LOCKED and the milestones of recent PG releases (like active-active replication), it's becoming more feasible to horizontally scale Postgres across multiple regions and vertically scale to 10k TPS or more. Many queues (like BullMQ) are built on Redis and data loss can occur when suffering OOM if you're not careful, and using PG helps avoid an entire class of problems.
We also wanted something that was significantly easier to use and debug for application developers. A lot of times the burden of building task observability falls on the infra/platform team (for example, asking the infra team to build a Grafana view for their tasks based on exported prom metrics). We're building this type of observability directly into Hatchet.
What do we mean by "distributed"? You can run workers (the instances which run tasks) across multiple VMs, clusters and regions - they are remotely invoked via a long-lived gRPC connection with the Hatchet queue. We've attempted to optimize our latency to get our task start times down to 25-50ms and much more optimization is on the roadmap.
We also support a number of extra features that you'd expect, like retries, timeouts, cron schedules, dependent tasks. A few things we're currently working on - we use RabbitMQ (confusing, yes) for pub/sub between engine components and would prefer to just use Postgres, but didn't want to spend additional time on the exchange logic until we built a stable underlying queue. We are also considering the use of NATS for engine-engine and engine-worker connections.
We'd greatly appreciate any feedback you have and hope you get the chance to try out Hatchet.
-
Show HN: R2R – Open-source framework for production-grade RAG
This is a great question, thanks for asking.
We are testing workflows internally that use orchestration software like Hatchet/Temporal to allow the framework to robustly handle 100s of GBs of upload data from parsing to chunking to embedding to storing [1][2]. The goal is to build durable execution at each step, because even steps like PDF extraction can be expensive / time consuming. We are targeting an prelim. release of these features in < 1 month.
Logging is built natively into the framework with postgres or sqlite options. We ship a GUI that leverages these logs and the application flow to allow developers to see queries, search results, and RAG completions in realtime.
We are planning on adding more features here to help with evaluation / insight as we get further feedback.
On the A/B, slow rollout, and analytics side, we are still early but suspect there is a lot of value to be had here, particularly because human feedback is pretty crucial in optimizing any RAG system. Developer feedback will be particularly important here since there are a lot of paths to choose between.
[1] https://hatchet.run/
- Show HN: Hatchet – open-source, event-based workflow engine
- Hatchet – open-source workflow engine for Go applications
-
Hatchet — yet another TFC/TFE open-source alternative
Absolutely -- just created an issue if you'd like to follow along or provide feedback!
What are some alternatives?
roomGPT - Upload a photo of your room to generate your dream room with AI.
otf - An open source alternative to terraform enterprise.
gptcli - ChatGPT in command line with OpenAI API (gpt-3.5-turbo/gpt-4/gpt-4-32k)
hn-search - Hacker News Search
dittofeed - Automate messages across email, SMS, webhooks, & native mobile push 📨 💬 📧
conductor - Conductor is an event driven orchestration platform
tailchat - Next generation noIM application in your own workspace, not only another Slack/Discord/Rocket.chat
terrakube - Open source IaC Automation and Collaboration Software.
frontman - Frontman is an open-source API gateway written in Go that allows you to manage your microservices and expose them as a single API endpoint. It acts as a reverse proxy and handles requests from clients, routing them to the appropriate backend service.
wakaq-ts - Background task queue for TypeScript backed by Redis, a super minimal Celery
turnly - The next modern Queuing Solution (QMS)
gue - Golang queue on top of PostgreSQL