el_bhs

6 ms·

1.
The Mirage of Career Inertia in the AI Era: Questions to Ask and Answer Today(foggyfuture.substack.com)
1 points by el_bhs 6mo ago|0 comments
2.
The "giddy nothingness" of AI coding (from creator of Dapper, OTel, etc.)(foggyfuture.substack.com)
3 points by el_bhs 7mo ago|0 comments
3.
by el_bhs 7y ago
the customers spending billions on the big cloud providers are entitled to much more rigorous and detailed reporting (incl historical data) for end-user-visible performance... I would much rather see the graphs in the article than a green c
4.
by el_bhs 9y ago
(disclaimer: I am one of the people who started opentracing) Someone sent me this HN thread – nice to see the questions here! OpenTracing has had a big end-of-2017 with support landing for various service mesh(es), bindings announced from s
5.
by el_bhs 9y ago
"OpenTracing-compatible" is strict API compatibility in any supported language. The cross-language spec is "terminology-based" since it's, well, cross-language. There is an open issue about Envoy/linkerd/I
6.
by el_bhs 12y ago
what a lovely design!
7.
by el_bhs 13y ago
I don't think that doing manual memory management doubles dev time for experienced devs, no... I just mean that, if you're trying to eliminate GC hiccups by, say, writing a custom allocator in C++ (i.e., exactly what we had to do
8.
by el_bhs 13y ago
This is a lazy answer, but it needs to be said: it depends on the context and the number of roundtrips to the cache. If we're talking about a vanilla object cache, I think that it probably only costs 50% or so to make the extra copies
9.
by el_bhs 13y ago
It really did take twitter many years to rearchitect and break their most problematic dependencies on Rails, yes... my understanding is that it was a 4-year process.
10.
by el_bhs 13y ago
For my own project, the GC tradeoff with Go (or Java) is acceptable given the relative ease of development w.r.t. C++. Since there are better structures in place to explicitly control the layout of memory, you can do things with freepools,
11.
by el_bhs 13y ago
Sure. So, for any black-box service endpoint, the latency for any given request is obviously just the time it takes for that operation to complete. Ideally one measures both end-to-end latency from the client and server-side latency in orde
12.
by el_bhs 13y ago
I can't resist (this is the OP): you are missing the point. It's not just throughput, it's high-percentile latency. Latency is critical if you have 1 billion users or 100 users, and it is difficult to bring the high percentil
13.
by el_bhs 13y ago
JRuby is of course incompatible with C extensions to Rails; the place I used Rails had such dependencies, and so JRuby was not an option. I agree that JRuby is otherwise preferable to cRuby, though. I'd be curious to hear how Square ha
14.
by el_bhs 13y ago
I don't think anyone is arguing that companies fail to grow because of these languages. It's merely that they would grow more quickly once at scale if they didn't have to spend several years rearchitecting while adding few in
15.
by el_bhs 13y ago
(I wrote TFA -- didn't expect it up on HN!) I agree that the post would be more compelling if I wrote a benchmark to demonstrate how much faster an in-memory cache is than an off-process or off-machine cache. From first principles, tho
16.
by el_bhs 13y ago
Ah, I hadn't seen that, thanks! For what it's worth, "Go" as a language is not really implicated in that, it's more like the `go` cmdline suite that was causing trouble. I would also contend that the devs were being
17.
by el_bhs 13y ago
Exactly. With proper discipline and true 100% test coverage, dynamic languages work well. But over time, that ideal is a challenge for most software organizations to actually live by. Or that's been my experience... it's one of th
18.
by el_bhs 13y ago
@dvt, this is the OP here. I was hoping that those who already agree with me about dynamic languages would come to understand that Go is different in this respect. I did a lousy (i.e., nonexistent) job making a case to those who don't