Recent submissions

Comment · 9 years ago
I bought a license simply beacuse Sublime Text was the only editor that could open a wikipedia json data dump. I installed many editors before I more than willingly paid for Sublime.
Comment · 9 years ago
Comment · 9 years ago
Stolen!
Comment · 9 years ago
Now there are too many rules. I'll just go back to writing crap code.
Comment · 9 years ago
Summarize how it changed my belief system (or gave it a dent)? Or summarize the video? Ok, here's a summary: the video is just one of the most watchable things I've come across.
Comment · 9 years ago
What you said made me want to write surpisingly terse and concise code. It's what I shall try to do from hereon.
Comment · 9 years ago
I'm scrolling up to see where you hit a nerve with me (or is it the other way around?). Anyway, sorry about that.
Comment · 9 years ago
I'm glad I posted here because one point is maybe finally clear to me about speed. It's not a good word for performance. It's the wrong word to use.

The great folks at Elasticsearch would _love_ for Lucene to be more performant. It would make life so much easier for them.

The Lucene team spend a good buck on their nightly performance tests. It's astonishing how well-tested Lucene is.

I wonder why I'm faster at writing and reading. Maybe it's because I have been benchmarking against an older version (4.8). But still. I wonder if my tests are all wrong or if I just got lucky in my design. ResinDB has flaws. It puts massive pressure on GC at writing time, if your batches are huge. I'm working hard at optimizing that achilees heel away. Before I have completely done so, writing speed is achieved through lots of memory allocations. It's surprisingly easy though to move away from using GC as a service.

But performance is not a feature anymore?

Edit:typos and tried to clarify things

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton