Recent submissions

Comment · 5 years ago
Comment · 9 years ago
How about when they were buying those DCs?
Comment · 9 years ago
> modern C++

This library is old enough to drive...

Comment · 10 years ago
Comment · 10 years ago
>Many of Rust's safety guarantees come from compile-time checks that then do not have any runtime penalty.

But not bounds checks, which are unfortunately what you need with respect to buffer overflows.

Comment · 10 years ago
Comment · 10 years ago
Comment · 11 years ago
> And I can think of more than one well-regarded unicorn where everyone still has access to basically everything, even after their first or second bad security breach.

Which companies? That's pretty scary.

Comment · 11 years ago
>A rotating disk is roughly able to saturate a 1Gb ethernet link.

Locality is key there. Read randomly and you won't saturate a 100Mb link.

Comment · 11 years ago
It's good to have competition in this area. Influx is giving me whiplash (it's on its third database engine in six months!)

The circular buffer approach is fine, but it does have the drawback of being unable to represent variable-length data (like key-value pairs). It's also harder to compress the data.

Can a GROUP-BY do windowed aggregations? Like, take an average over ten-minute windows? My SQL knowledge is not great.

Comment · 11 years ago
Yeah, but...

Need replication? Gotta write your own sharding logic or set up pg_shard.

Need aggregations? Gotta write your own logic. Will you do them on the fly? Use triggers? On demand?

Need to remove old data? Gotta set up a cron job. But wait, what if I want to age different series at different rates? Now you need a policy system. Sigh.

Not saying Postgres can't be the storage engine, but there's a lot of work to do on top of that.

Comment · 11 years ago
Yeah, I'm not brave enough for embedded.

I'm still pretty excited about what's happening in this space though. Thanks for your thoughts.

Comment · 11 years ago
I apologize if I gave the impression I was claiming otherwise. It's just context for the discussion.
Comment · 11 years ago
The author also points out that some of the benchmarks poorly represent real workloads:

"Bottom up (since the worst offenders are now first),

binary-trees is silly since it measures allocation speed for a case that simply doesn't exist in real code;

thread-ring is basically insane, since nobody ever bottlenecks like that;

chameneos-redux's C++ implementation is ridiculous. The C is not so ridiculous, but you still have the problem that basically every language in the top few spots does something completely different;

pidigits tests whether you have bindings to GMP;

regex-dna tests a regex engine on a small subset of cases (arguably the first half-acceptable benchmark);

k-nucleotide tests who has the best hash table for this particular silly scheme, and they don't all even do the same thing (eg. Scala precompacts, like my new Rust version);

mandelbrot is kind'a OK;

reverse-complement would be kind'a OK if not for a few hacky implementations (like the Rust);

spectral-norm is kind'a OK;

Haskell basically cheats fasta (which is why I copied it);

meteor-contest is too short to mean anything at all;

fannkuch-redux is probably kind'a OK,

n-body is kind'a OK.

So maybe 5/13 are acceptable, and I'd still only use 4 of those. I think if looking at mandelbrot, spectral-norm, fannkuch-redux and n-body you can argue the benches are a reasonable measure of peak performance. However, these cases are also all too small and simple to really be convincing either, nor is it particularly fair (where's NumPy for Python?)."

https://users.rust-lang.org/t/blog-rust-faster/3117/12?u=acc...

Comment · 11 years ago
Ah, so Rust does represent thread semantics through types? It's curious that the authors don't mention that in their proposal.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton