arthursilva

25 ms·

61.
by arthursilva 11y ago
Bashing non-COMPACT storage is nonsense. non-COMPACT store by itself doesn't add any significant overhead (only 2 bytes per cell and even less after compressed). What really wastes space is using collections types. Even using that I do
62.
by arthursilva 11y ago
The truth is that rust is in its infancy its all guesses at this point. Go didn't attract c++ people as people first guessed.
63.
by arthursilva 11y ago
Nonsense, go is fine, so is rust.
64.
by arthursilva 11y ago
There should definitely be a bigger dataset version, the teste data is a very small fraction of the available memory.
65.
by arthursilva 11y ago
Benchmarketing, serious business.
66.
by arthursilva 11y ago
Possibly stupid question... Why there's _1 and _2 variants for each hash size?
67.
by arthursilva 11y ago
Great writeup! Deserve a spot on the official docs.
68.
by arthursilva 11y ago
It's Riak Core.
69.
by arthursilva 11y ago
Those are very lightweight abstractions as the compiler will generate optimized code for each variant separately. That's the entire point of Rust Trait abstractions.
70.
by arthursilva 11y ago
Hopefully this will force AWS to lower their prices as well.
71.
by arthursilva 11y ago
Do you have a unixbench score?
72.
by arthursilva 11y ago
How these ARM cores compare to Digital Ocean cores? My apps are mostly CPU bound.
73.
by arthursilva 11y ago
Hopefully this will put AMD back on the (real) map, nothing good can come from continuous Intel monopoly.
74.
by arthursilva 12y ago
HN author should probably have linked this blog post instead. https://nukep.github.io/progblog/2015/04/15/developing-llama... it's a good read.
75.
by arthursilva 12y ago
Well, once you compare both languages you can see why. Hint: inovation/complexity (not that either is a good or bad thing). Anyway, that's only one possible reason... I think Go is actually 2 years older.
76.
by arthursilva 12y ago
This could be a byproduct of what they developed for Aurora (their upcoming redesigned mysql) shared storage. Probably the other way around.
77.
by arthursilva 12y ago
Elastic Search is known to drop your data in some occasions. I think it's fair to advise against using it as your source of truth (or anything built on top of it like Crate).
78.
by arthursilva 12y ago
Seems like it's an layer over ElasticSearch using Presto SQL parser. SQL queries are translated into ES queries.
79.
by arthursilva 12y ago
While I do agree with you I don't think anyone used foundation DB sonellly for its sql layer and if they did...
80.
by arthursilva 12y ago
Their SQL layer architecture is indeed chatty. If I remember correctly they were doing/planing a lot of optimizations like: 1. delaying requests a little on purpose to take more advantage of batch requests 2. fancy techniques to improv
81.
by arthursilva 12y ago
I'm predicting Couchbase 4.0 eating a fair share of Mongodb cake.
82.
by arthursilva 12y ago
Ya, it's limited indeed. I just realized you're a pypy developer. Thanks for all the good work you guys are putting on it!
83.
by arthursilva 12y ago
Oh gosh, I remember checking out Pike a longgg time a go! Totally forgot about it since them. Checking it again today makes me realize how neat it is, the union types (now in typescript as well) are awesome.
84.
by arthursilva 12y ago
I just checked out and seems like pypy has made some good progress database driver wise! So I went ahead and installed pypy 2.5.1 to compare the json performance. It got better but ujson is just crazy fast. CPython (w/ ujson) is 70% fa
85.
by arthursilva 12y ago
That's my point, I can't use the extensions with pypy. And this stuff is usually the bottleneck.
86.
by arthursilva 12y ago
The ones I miss most frequently are a faster json parser (I use ujson), a faster msgpack parser and a faster database driver. The pure python versions (even on PyPy) don't make the cut :(
87.
by arthursilva 12y ago
Heck, I'm kinda felling bad as a Pythonista. We're lagging badly speed wise. Sure, there's PyPy but it's not compatible with the mainstream C-Extensions so pretty much a no-go for most of my projects. Hopefully Piston wi
88.
by arthursilva 12y ago
Woa, that was unexpected! So sad to see this great piece of software dragged to Apple dungeons.
89.
by arthursilva 12y ago
Probably the greatest release since 2.0.
90.
by arthursilva 12y ago
Precisely, but as of today the document model is limited (at least in comparison to Mongo). I'm following these developments for a while and I agree that they'll be killer!

More ›