zellyn

70 ms·

901.
by zellyn 10y ago
On the parallel Reddit discussion, someone mentioned that the gain is less when rendering CJK scripts, since there are so many different glyphs.
902.
by zellyn 10y ago
Raph really, really knows his stuff. His interview on the New Rustacean podcast starts with a summary of his background: Gimp, Ghostview, android font rendering.
903.
by zellyn 10y ago
I think faking a phone call to your lawyer is pretty unforgivable…
904.
by zellyn 10y ago
I should mention that we use Ruby, Java, and Go. So protobufs are also the "lingua franca" for cross-language communication.
905.
by zellyn 10y ago
True. But when using them, it feels like every field is "present" and you don't have to worry about the "optional, missing" case.
906.
by zellyn 10y ago
We use them internally at Square for our RPC mechanism ("Sake", similar to "Stubby", Google's internal RPC mechanism), for our Kafka-based logging/metrics/queue infrastructure, and for defining external JS
907.
by zellyn 10y ago
- removing optional values is actually quite nice. In practice, I end up checking for "missing or empty string" anyway. - the "well-known types" boxed primitive types essentially add optional values back in. And dependin
908.
by zellyn 10y ago
btw, I also wrote up a brief "State of Go Packaging" doc you might be interested in reading: https://docs.google.com/document/d/1M4Ldgtxr9vC8wpyTldQe5oUy...
909.
by zellyn 10y ago
In fact, here's Sam and wycats (of Cargo) talking about how a generic library (obviously Go is not the best choice for that) would be nice: https://twitter.com/sdboyer/status/755036174016806912
910.
by zellyn 10y ago
Heh. Thanks for the warning. I just changed my document (mentioned at the bottom) to comment-only too.
911.
by zellyn 10y ago
I read/skimmed the whole article, and still don't understand why this is better than Dropbox. Also, aside from mentioning Middle Out compression, this was indistinguishable from Pied Piper… :-p
912.
by zellyn 10y ago
Unfortunately, the discussion took place on the "Hack Day", and wasn't recorded (I think they're going to try to change that for next year). Chris Broadfoot took pretty comprehensive notes, though: https://doc
913.
by zellyn 10y ago
It's not enough. `go get` understands only how to pull the latest version of the master branch of things.
914.
by zellyn 10y ago
Being willing to change `go get` is forgetting reverse compatibility.
915.
by zellyn 10y ago
And some of the Google tools are way better than their clones.
916.
by zellyn 10y ago
Yes. It's a terrible mess. But as of GopherCon a couple of weeks ago, the way forward is becoming clear. Most important, the Go Team is now in direct communication with the authors of the most widely used vendoring tools, and it seemed
917.
by zellyn 10y ago
Came here to type this comment. Man, did they ever bury that one. I finally went back to ctrl-f "dig", and it was in fact in the intro, but just in passing…
918.
by zellyn 10y ago
From the article, three months shouldn't be enough to see this trend…
919.
by zellyn 10y ago
Curious that they don't mention actual performance numbers in this blog post…
920.
Baseline JIT and inline caches(blog.pyston.org)
53 points by zellyn 10y ago|12 comments
921.
by zellyn 10y ago
I know Perl6 and Python3 have shown the dangers of changing things in disruptive ways. But I still appreciate your willingness to change things carefully to make them better. The length of time your software will be used in the future almos
922.
by zellyn 10y ago
Our Go monorepo has 1,325,332 lines of non-comment code, according to `cloc`, although about half of that is generated protobuf code. I'm still waiting for `cloc` to finish on the Java repo…
923.
by zellyn 10y ago
One thing to consider is that monorepo tooling is (outside of Google) still pretty immature. At Square, we have one main Java "monorepo", one Go "monorepo", and a bunch of Ruby repos. The Java repo is the largest, by a h
924.
by zellyn 10y ago
That would be great if people always used versioning correctly. I deal frequently with breaks caused by simple things like renaming, removing, or re-ordering protobuf fields in one repo, and not updating code in another. At least in a monor
925.
by zellyn 10y ago
Disagree. Typically, in this scenario, you're using some kind of protocol to communicate. In our case, it's protobufs: they are in fact one of the prime sources of breakages between repos, and one of the main reasons I wish we had
926.
by zellyn 10y ago
Out of curiosity: how do you launch 20 satellites like this without danger of collisions? I guess you accelerate between deploying each satellite to slightly change the orbit?
927.
by zellyn 10y ago
I wasn't arguing that a code of conduct solves all problems, especially those of abuse of power. Just that it would help a lot. Sounds like you had a bad experience: I'm sorry to hear that. Imbalance of power is never fun… :-(
928.
by zellyn 10y ago
Publicizing a way of reporting behavior would have ensured that there was a central, cumulative record of bad behavior, instead of anecdotal and diffuse understanding of the problem.
929.
by zellyn 10y ago
Most codes of conduct I've seen would have helped by: - making it explicit up-front that the behavior described is considered unacceptable by the community, which would help victims know that they have the support of the community - pu
930.
by zellyn 10y ago
I bought one of the old, accidentally incorrect kits that sell for much less, and then brought it up to parity by buying individual components.

More ›