As a long time Hatchet user, I understand why you’ve created this library, but it also disappoints me a little bit. I wish more engineering time was spent on making the core platform more stable and performant.
Readit Newszegl commented on Show HN: Pickaxe – A TypeScript library for building AI agents github.com/hatchet-dev/pi... · Posted by u/abelanger
zegl commented on Show HN: Varse – Simple remote application config github.com/varse-io/varse... · Posted by u/izakfr
Congrats on launching! What’s the difference between this and Feature Flags in PostHog?
I'm going to give you a niche idea.
An email provider / hosting / client focused on a single user owning a whole domain.
I don't care about individual email addresses. What I really want is to be able to handle asterisk@asterisk.example.com both for receiving but more importantly for sending.
Receiving is fairly easy with aliases and catch-alls. But for some reason all clients / providers make it really hard to send emails from any address you own.
I think there is money in this problem.
I recently migrated to Fastmail, and they are handling this very well.
zegl commented on Turtles, a Shelly/Zigbee home automation tool in Elixir joisig.com/2023-holiday-s... · Posted by u/joisig
I have different opinion on Home Assistant. It's surprisingly heavy compared to alternatives, the YAML configs are insanely overcomplicated, they move too fast with Python versions (phasing out 3.9 when it was still the default on the then stable Debian, etc).
My 2 cents go for Zigbee2MQTT, Mosquitton, and Domoticz. Domoticz has it's problems, but it's been a faithful workhorse for me for the past 6 or more years.
+1 for Zigbee2MQTT. I've been using it at the core of my home automation for a few years, and it's incredibly reliable.
zegl commented on 10k Bounty for Rewriting Prettier in Rust twitter.com/Vjeux/status/... · Posted by u/hardwaregeek
Many organisations have a CI step that runs a linter or formatter on all the code and fails if the tool makes changes.
The idea is to catch cases where contributors failed to run the tool on save.
On large code bases this can be time consuming.
The trick to make CI in large codebases fast, or how to make any system fast, is to only test what’s changed.
In CI you only need to lint the files that have changed, or run the tests that depend on code that has changed etc.
This way the time it takes to execute the tests scales with the amount of changes, and not with the total amount of code.