HNHacker News
TopNewBestAskShowJobs

sgmansfield

178 karma · joined May 25, 2016

[ my public key: https://keybase.io/paintballbob; my proof: https://keybase.io/paintballbob/sigs/8dngTxemmp2BUW3l6lOcEGUuxSbLxo-Fmy5qD8M3-gI ]
submissionscomments
sgmansfield··on Ask HN: What are best tools for web scraping?
I would hazard a guess that nearly all large scale use cases are negotiating those prices down quite a bit.
sgmansfield··on Redis on Acid: 0.5M ops/sec, 1ms latency and ACID compliance
It's worth noting that they're running this benchmark on an absolutely enormous (and expensive) instance: https://aws.amazon.com/ec2/instance-types/x1/
sgmansfield··on Locked out of Facebook with a campaign running and my credit card being charged
Call the credit card company and dispute the charges. Also, block any further charges if you can. Nothing gets people's attention like messing with their cash flow.
sgmansfield··on Elf Hello World
Fantastic article. I noticed a couple of TODO's around, though. Does this hint at a second installment? :)
sgmansfield··on A Foray into Go Assembly Programming
Sure, but that ruins the fun :)
sgmansfield··on A Foray into Go Assembly Programming
Thanks for letting me know, I'll see if I can fix it. If I could trouble you to do so, can you provide a screenshot?
sgmansfield··on A Foray into Go Assembly Programming
This was probably not explained well. The compilation failed with an error saying that I was basically trying to do something that was not allowed.

For your second question: I don't believe there is a way to use a separate assembler.

sgmansfield··on Caching at Reddit
client-side compression works out better for a couple of reasons:

1. You use less bandwidth in/out of the box. This matters in AWS because your bandwidth is (relatively) limited.

2. Your CPU usage to (de)compress is distributed over a larger fleet. The clients spend the CPU time, not the cache servers.

sgmansfield··on Caching at Reddit
Yeah it absolutely is. In fact, there's been tons of large improvements as of late, with more coming.
sgmansfield··on How Much Are Your Words Worth – Literally?
Somewhat disappointing. It's just a long ad for nested.
sgmansfield··on Show HN: Accelerating SHA256 by 100x in Golang on ARM
Do you have a source for the 1% number?

Also I'd like to know what you would consider an appropriate amount of assembly code.

sgmansfield··on Iris framework author exposed for license violations
He is not the sole contributor, actually. He squashes master every once in a while to a single commit, which removes other authors. If you peruse the travis builds page[1] you can see commits by other people

[1] https://travis-ci.org/kataras/iris/builds

sgmansfield··on Iris framework author exposed for license violations
More specific to the license violations is this issue on httprouter:

https://github.com/julienschmidt/httprouter/issues/148

sgmansfield··on Writing an OS in Rust: Catching CPU Exceptions
I was just about to post this exact same thing. Now there's an introduction of ranges and another API that is necessary to understand in order to grok this code. Bit twiddling, ANDing, and ORing are specific and absolute.

For example, what happens when I specify a range of 0..100 for a 32 bit int? what if the value is too big for the range? APIs around small operations like this introduce ambiguity that wasn't present before.

sgmansfield··on Application data caching using SSDs
Author here (of both Rend and the post).

We really are looking for raw performance, but not at any cost. I spent a bunch of time, and continue to do so, to eliminate extra work, indirection, and garbage.

Efficiency of runtime and development is a careful balance that Go fits well. Rust is immature. C is difficult for people who haven't been writing it professionally. Java (less Zing or other special cases) is too latent, even if it's very fast when it's running because of HotSpot optimizations. The list goes on, but I didn't see a reason to choose the others over Go, nor have I found something yet that beats it for our use case.

Really, Java just wasn't the language for the job. Go has a lower level and simpler interface, simpler runtime (with less indirection), and better model for concurrency. Yes, it's a new language for us, but it was the right tool for the job. Our garbage collection pauses are mostly under a millisecond, so they aren't really an issue.

Zing never really was on my radar. Looking at it now I shudder to think of the licensing costs, especially since we run tens of thousands of cache instances. We already pay enough just to run these servers. It's also a new Java runtime which very few people know about, and probably nobody at Netflix has used. I would have had to learn it all independently and continue to be on my own from then on. The Go slack team and community in general are very helpful and supportive, and I would speculate that the same level of support isn't available for Zing without paying.

sgmansfield··on Application data caching using SSDs
OK, I can reproduce. I'll forward, something seems wrong (obviously). Thanks for reporting this.

edit: No SSL on blogger custom domains. Sorry =/

sgmansfield··on Application data caching using SSDs
Sorry, not sure what's wrong. I tested in the latest firefox, safari, opera, and chrome and it works for me.

Edit: blogger doesn't do SSL on custom domains. Sorry =/