You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Instantly share code, notes, and snippets.
Evan Schwartz
emschwartz
Inventor & Rust / TypeScript engineer. Building Scour, a personalized content feed: scour.ing -- give it a try!
This is an OPML version of the HN Popularity Contest results for 2025, for importing into RSS feed readers.
Plug: if you want to find content related to your interests from thousands of obscure blogs and noisy sources like HN Newest, check out Scour. It's a free, personalized content feed I work on where you define your interests in your own words and it ranks content based on how closely related it is to those topics.
This is a very rough outline of the things that need to be done to implement autometrics in another language:
Research auto-instrumentation libraries for the language
How do they work? This is mostly to serve as a potential source of inspiration (or maybe we can just use one of those libraries with a little configuration?)
How does code generation work in the language? Are there macros, decorators, or some other method for generating code?
Autometrics needs to be able to insert metrics-collection code at the beginning and end of any instrumented function
Rust does this with an attribute macro
TypeScript does this at runtime with a wrapper function
Can this also modify the doc comments of the given function?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
server generated ILP address (test.amundsen.bmp.btp18q1xrp.tPcfTiM2_-stOLrODMIQbFX7BLln60TC8qy2BefdDsQ.local.X22YdPW64RhBKHCHYYjVDnpz7x83I76gbWq6_JY4Ngs.PNOMQrElaGRlc5VK2uKIFSug) and shared secret (e945dd40aecfe9191e83e8dce2ab81d1fe4760c9ef5a0f71b227adc9308ca173) for client
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Draft 1 of PSK2 attempts to support both streaming and chunked payments. However, it includes some features that are only useful for chunked payments and does not include some others that would be needed for a proper chunked payments implementation.
Based on a conversation with @sharafian, this proposes narrowing the scope of PSK2 while making it easier to build use cases like streaming and chunked payments on top.
For context, @justmoon had the idea to use PSK2 for "payment sockets", which I started implementing yesterday. However, @sharafian made the point that for many receiver use cases, it's better for the PSK2 receiver not to keep state but to simply call a callback for every chunk it gets. Applications will figure out their own logic for which chunks to accept and how to track the balance for different users or interactions. Therefore, PSK2 doesn't need the fields that are specifically fo