Hacker News: srijs

New comment by srijs in "Solving for faster SHA-1 collision detection"

srijs — Thu, 24 Sep 2026 09:36:16 +0000

Hi, author here. FWIW the blog is fully hand-written. I used Claude to help me generate the visuals.

What goes into head vs. tail is actually fully deterministically decided by the solver based on a P(tail) gradient, so expressions that are more effective in filtering out blocks before they can hit the (slower) tail are preferred in the prefix.

Solving for faster SHA-1 collision detection

srijs — Mon, 21 Sep 2026 18:46:17 +0000

Article URL: https://sam.dev/blog/faster-sha1-collision-detection

Comments URL: https://news.ycombinator.com/item?id=49791558

Points: 58

# Comments: 10

Speeding up gearhash on ARM64 (2× faster)

srijs — Sun, 06 Sep 2026 18:50:23 +0000

Article URL: https://sam.dev/blog/gearhash-on-arm64

Comments URL: https://news.ycombinator.com/item?id=49589584

Points: 2

# Comments: 0

New comment by srijs in "Simple, Fast, and Scalable Reverse Image Search"

srijs — Wed, 19 Oct 2022 18:53:35 +0000

1x RCU gives you 1 strongly consistent read of up to 4KB _per second_. So 8000 reads per second require 8000 RCUs, which at list pricing comes to $1 per hour. And that's assuming reads do need to be strongly consistent (otherwise half the price) and no discounts are applied.

New comment by srijs in "Plumbum: A lazy, constant-memory streaming data Rust library"

srijs — Mon, 12 Oct 2015 00:51:09 +0000

Author here. Slightly simplifying, a Kleisli arrow is just a function from `A` to `M`, and which is composable, similar to function composition:

    Kleisli + Kleisli = Kleisli

Although it is an important part of how the conduits work, it is not strictly necessary for using the library.
Would it help if I clarified that somewhere, or would you rather not read "Kleisli" anywhere in the docs?

New comment by srijs in "JSON Lines"

srijs — Sat, 26 Sep 2015 06:00:33 +0000

There is also NDJSON (aka Newline-delimited JSON): http://ndjson.org/
(disclosure: I'm the author of the Haskell ndjson-conduit library)

New comment by srijs in "Download Atom editor without an invite"

srijs — Sun, 02 Mar 2014 13:19:27 +0000

From the official update:
$ shasum -a 256 atom-mac.zip 4614ec62feaea32392ad7f6b3a80534c8ad0c758ed210cabafcc86c5c49a49a1 atom-mac.zip
$ md5sum atom-mac.zip 5454bd3a8271c93f5225cd2b57cdab81 atom-mac.zip

Show HN: Open Source Node.js Interpreter for iOS

srijs — Mon, 13 Jan 2014 18:13:31 +0000

Article URL: https://itunes.apple.com/app/id793774475

Comments URL: https://news.ycombinator.com/item?id=7052256

Points: 15

# Comments: 0

Show HN: Node.app - Node.js for iOS (supports timers, events, fs, utils, ...)

srijs — Sat, 30 Nov 2013 15:54:37 +0000

Article URL: http://nodeapp.org/

Comments URL: https://news.ycombinator.com/item?id=6823437

Points: 3

# Comments: 1

New comment by srijs in "Show HN: Proof-of-concept Node.JS-like interface with iOS 7 JavaScriptCore"

srijs — Tue, 15 Oct 2013 20:25:59 +0000

Very happy about your input! :)
I think you got a very good point there regarding the impedance mismatch between native and js apis.
Really enjoying the uvbook, this got me sold on the libuv api. After skimming through the source and being happy that libuv is indeed just a very thin wrapper around posix, I just integrated libuv with my project and will base all bindings upon that.
Thank you very much!

New comment by srijs in "Show HN: Proof-of-concept Node.JS-like interface with iOS 7 JavaScriptCore"

srijs — Tue, 15 Oct 2013 07:21:28 +0000

Thanks a bunch for your feedback :)
My initial plan was to provide the node features using Foundation.framework features only. Now, this could turn out to be more boilerplate code than I intended to write and if it does, I'm now pretty sure I'd go with libuv.
I'm not quite sure about using libuv from the start, though. My consideration was that a) this is not targeted at server applications, so you don't necessarily need very high performance and b) libuv is a cross-platform library, while I'm targeting darwin only, so it might be a bit overkill.
Do you have experience with libuv? If so, do you have experience regarding footprint / conciseness? Can you confirm/deny my presumptions?

New comment by srijs in "Show HN: Proof-of-concept Node.JS-like interface with iOS 7 JavaScriptCore"

srijs — Mon, 14 Oct 2013 16:50:59 +0000

I did some evaluation a while ago about bundling a Javascript engine with mobile apps on iOS and concluded JSC was way easier to compile and integrate. This is in fact what e.g. Appcelerator Titanium does currently. However, this bundling results in huge binaries, which is not very nice for mobile platforms.
The thing that got me into hacking the prototype was the release of JSC as a public system framework on iOS7, eliminating the need to separately bundle JSC. So its not really a platform preference, I'm just trying to work with what's currently there...

New comment by srijs in "Show HN: Proof-of-concept Node.JS-like interface with iOS 7 JavaScriptCore"

srijs — Mon, 14 Oct 2013 15:23:19 +0000

Thanks :)

New comment by srijs in "Show HN: Proof-of-concept Node.JS-like interface with iOS 7 JavaScriptCore"

srijs — Mon, 14 Oct 2013 12:23:55 +0000

JavaScriptCore is a cross-platform javascript engine on it's own that is used by default in WebKit browsers (Safari, Mobile Safari, Konqueror, etc.).
The new thing on iOS 7 is that this framework is exposed as a public API you can code against. So you don't have to initialize a heavy-weight WebView just to execute Javascript.

New comment by srijs in "Show HN: Proof-of-concept Node.JS-like interface with iOS 7 JavaScriptCore"

srijs — Mon, 14 Oct 2013 11:29:07 +0000

This is very rough and no IO is supported yet. However, I think it serves well as a proof-of-concept that a lightweight node-compatible interface can be done for mobile apps using javascript.
Tell me what you think! :)

Show HN: Proof-of-concept Node.JS-like interface with iOS 7 JavaScriptCore

srijs — Mon, 14 Oct 2013 11:28:20 +0000

Article URL: https://github.com/srijs/NodelikeDemo

Comments URL: https://news.ycombinator.com/item?id=6546608

Points: 30

# Comments: 14

Add Support for 80+ Filetypes to your iPhone

srijs — Mon, 26 Aug 2013 13:54:50 +0000

Article URL: http://www.doctapeviewer.com

Comments URL: https://news.ycombinator.com/item?id=6277016

Points: 14

# Comments: 4

New comment by srijs in "Compiling LLJS to asm.js"

srijs — Tue, 26 Mar 2013 08:59:23 +0000

Typed arrays do deliver a lot of speedup, and in fact, the above example is slightly faster in Chrome than in Firefox Nightly for me. However, if your algorithm does crunch a lot of data in a low-level way, there is definitely even more performance you can get by using asm.js.
See my link in the comment below for benchmarks of a sha1 algorithm that shows a good speedup in Chrome by using TypedArrays, but an even greater one in OdinMonkey.

New comment by srijs in "Compiling LLJS to asm.js"

srijs — Mon, 25 Mar 2013 23:45:51 +0000

Thank you. I just updated my code and it's really within half of native speed now... (benchmarks in the README, if any of you are interested)
asm.js is very exciting technology!

New comment by srijs in "Compiling LLJS to asm.js"

srijs — Mon, 25 Mar 2013 20:38:57 +0000

Cool. I recently wrote a low-level sha1 implementation in pure javascript, trying to leverage asm.js (http://github.com/srijs/rusha).
Can you tell me, how did you confirm you wrote valid asm.js and there was no fallback-mechanism kicking in?
I benchmarked my implementation, of course, and noticed a 2x speedup. However, this seems quite less for the this type of low-level algorithm...