karlmcguire

Statistical Consequences of Fat Tails by Nassim Taleb.

Yea, because that's been working great thus far.

Nice, Robinhood is a publisher now!

Thanks for the pallene link! Terra was fun to play with but I've always wanted a simple compiled Lua.

I think most "master" software engineers are a bit more idealistic than that... Not saying I am a master but I occasionally write something and consider it genuinely beautiful.

It seems like with Quora you either get very bad or very good answers. The good ones tend to be significantly older, i.e. before it got big and people started to gamify the system.

Any time someone logs into your account you immediately get a notification on all devices with the IP address the attempt originated from.

The most interesting thing about Telegram to me is the development team: about 10 very good engineers who travel with Pavel and work from hotels.

It's not clear who made Telegram's crypto but it was probably Nikolai Durov who is a genius mathematician and engineer, so it's not like it's some guy in a garage.

I found it interesting that direct calls (just calling one of your contacts) can be peer-to-peer if you enable it in the settings. They even have a unique code at the top of the screen (like 5 emojis) that you can verify match on the other participant's phone.

"All systems operational"

What's the point of a status page if it doesn't reflect the real status...

It's either the status page goes down with everything else or the status page is wrong. Great.

EDIT: Looks like it's accurate now, 20 minutes later.

> So, if we can't stop the project from happening, what can we do?

> 1. Do nothing. Assume that you will be able to grow and borrow forever.

The Fed is buying individual corporate bonds now. The only thing keeping this American experiment afloat is borrowing forever.

Glad you liked it!

> does it have a distributed mode like groupcache?

Not at the moment, no. Though it could, theoretically, be used within groupcache. We'll look into that as it has been brought up a few times now.

> it would be great if there's a "safe mode" instead of the (IIUC) "start dropping Set requests when overloaded".

We could definitely look into adding a config flag for that. I'd love to know: in what situations would lossless Sets be important to you? We already have guaranteed updates, so the only Sets that are dropped are new items.

Thank you. The sync.Pool lossy ring buffers are probably my favorite innovation, especially because of how little code it is.

I was worried about type casting as well and generally avoided bare interfaces like the plague. However, in all the benchmarks I've ran for throughput, type casting was a small percentage of CPU time. I'll see if I can dig up a flamegraph.

Of course, the only reason sync.Pool performs so well is because of its internal usage of thread local storage. If the Go team exposed that, we could make our own typed sync.Pool implementations... I won't hold my breath, though.

Thank you for the kind words!

You're right about our rabbit holes. Our initial "why" for this project was essentially: "Caffeine is written in Java with excellent performance. Go should be (and usually is) competitive with Java. Why is there no Go equivalent?"

With such a high bar we were disappointed in naive, idiomatic Go solutions, but we knew there had to be some way to close the gaps.

I look forward to continuing to do so. We have a few things on the roadmap such as adaptivity (see Ben Manes' work for more info) and managing our own memory.