nelhage

6 ms·

1.
by nelhage 2y ago
(author here) > The problem is 95% about laying out the instruction dispatching code for the branch predictor to work optimally. A fun fact I learned while writing this post is that that's no longer true! Modern branch predictors ca
2.
by nelhage 2y ago
> Btw, what about some clang18.tc comparison (post author here) Oh, this is something I could have called out explicitly: The tail-calling interpreter relies on a feature (the `preserve_none` calling convention) that only landed in clang
3.
by nelhage 4y ago
(author here) I actually did a v0 writeup in Go, but I wanted a language that had a bit more powerful type system and more support for a fluent/functional style in some of the expressions. I was optimizing for what I know and felt was
4.
Building LLVM in 90 seconds using Amazon Lambda(blog.nelhage.com)
90 points by nelhage 5y ago|5 comments
5.
Papers I Love: Gg(buttondown.email)
3 points by nelhage 6y ago|0 comments
6.
by nelhage 6y ago
We used precisely this optimization in [sorbet]( https://sorbet.org ), a brand-new type checker for Ruby, which also contains a high-performance LSP server. We wrote the entire thing (and tested, using ASAN and fuzzers and other t
7.
How I Write Tests(blog.nelhage.com)
1 points by nelhage 10y ago|0 comments
8.
by nelhage 11y ago
Better yet, just run this on a t2.micro on a throwaway EC2 account. Doesn't matter if they own the box, they get literally nothing they couldn't get for free from Amazon anyways.
9.
by nelhage 11y ago
zero-width matches (and empty lines) were a huge source of stupid edge-case bugs in livegrep[1], and being rigorous about maintaining this mental model definitely helped a lot. [1] livegrep.com
10.
by nelhage 11y ago
I get into this a bit later on, but I think the exact same model applies to pointers: You're much better off in most cases thinking of pointers as pointing at the zero-width points between elements, than at elements themselves.
11.
Indices Point Between Elements(blog.nelhage.com)
133 points by nelhage 11y ago|62 comments
12.
by nelhage 11y ago
Live data, but they're stored redacted, and/or with sensitive data (e.g. credit card numbers) replaced with opaque tokens that reference an encrypted store that's carefully access-controlled.
13.
by nelhage 11y ago
This is a great question, and it's definitely a problem we have. We don't have a single answer we use for every system we work on, but we employ a few common patterns, ranging from just keeping hard-coded strings containing the ex
14.
by nelhage 11y ago
Our testing running infrastructure spins up a pool of database instances on each worker machine, one for each worker process. The test spinup and teardown code handles schema management, hooking into our DB access layer to create and clean
15.
Running three hours of Ruby tests in under three minutes(stripe.com)
287 points by nelhage 11y ago|106 comments
16.
Greg Brockman Is Joining the Stellar Board(blog.gregbrockman.com)
5 points by nelhage 11y ago|0 comments
17.
by nelhage 11y ago
Why do we think the blur is sufficient? The blur loses information, but there are presumably a small number of watermarked versions, and a lot of frames. It's almost certainly possible for HBO to reverse-engineer the blur algorithm —
18.
Regular Expression Search with Suffix Arrays(blog.nelhage.com)
17 points by nelhage 12y ago|0 comments
19.
by nelhage 13y ago
You're getting that even with a statically-compiled binary? What's the output of "file ./level0"?
20.
by nelhage 14y ago
(author here) Yeah, there are a lot of such tools, and they can be invaluable. In my experience, though, if you're working with a large, complex system, including pieces like Ruby and OpenSSL which do some grody tricks internally, they'll f
21.
Tracking down a memory leak in Ruby's EventMachine(blog.nelhage.com)
158 points by nelhage 14y ago|31 comments
22.
by nelhage 14y ago
We've been pretty happy so far. There have been a few rough edges getting it up and keeping it running, but we've been very impressed with the performance so far. I've passed your comment on to Colin, who wrote the Ruby client -- I'm sure h
23.
by nelhage 14y ago
There isn't support. It's definitely something I've pondered. If you're interested in adding support, I'd be happy to hear from you at (my username) AT stripe.com.
24.
by nelhage 14y ago
MoSQL will just throw any fields it doesn't recognize into a JSON "extra_props" field (if you ask it to). So everything will work fine, and existing SQL code (which doesn't know about those fields) will continue to be fine. If you need the
25.
by nelhage 14y ago
They each have different advantages and strengths. MongoDB is great for failover and for rapid development or prototyping. SQL is great for reporting or analytics, since you can do all kinds of aggregates and JOINs right in the database. Th
26.
by nelhage 14y ago
(I wrote MoSQL) I actually played with mongo_fdw. At this point, it's a really cute hack, and useful for some things, but it doesn't give Postgres enough information and knobs to really let the query planner work effectively, so it ends up
27.
by nelhage 14y ago
I actually prototyped our PostgreSQL solution using mongo_fdw (Incidentally, I throw together Debian packaging here, if you're interested: https://github.com/nelhage/mongo_fdw ). Our experience was that mongo_fdw doesn't (yet?) give postgr
28.
by nelhage 14y ago
To pick one, we like the fact that MongoDB lets you change your schema and add new fields to your documents without having to worry about migrations or keeping track of schema versions, or any of that. You could build something like that on
29.
by nelhage 14y ago
(I wrote MoSQL) PostgreSQL scales surprisingly well for this purpose, and is much nicer for interactive queries than Hadoop/Hive. We use Impala[1] for some larger datasets, but Impala is comparatively new, and it's nice to have something as
30.
Announcing MoSQL(stripe.com)
390 points by nelhage 14y ago|113 comments

More ›