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.

Do you have a source for their blockchain being launched EOY?

I've been following their blockchain project since the whitepaper, and they've been quietly missing their launch goals by many quarters...

I think Telegram has a unique position to combat Facebook's Libra.

Bisqwit?

If you need flashcards to remember syntax, you're probably not writing/reading enough code.

I think you're underestimating the cryptocurrency "hodl" hysteria...

> It certainly didn’t help that the crypto community was choke-full of conspiracy theorists, libertarians that never read anything else after falling in love with Ayn Rand as teenagers, and get-rich-quick schemers.

I agree. Because of the nature of cryptocurrency, the industry has always just been wrought with fraud.

It has something to do with Telegram chats, the "wild west" feeling, semi-anonymous currency transactions, and the feeling most people have that there is (or was) a real possibility that they could gamble and win big with little effort.

The entire industry can almost be seen as a giant, anonymous slot machine.

I'm curious how people still consider BCH a viable currency after the 51% attack done "in good faith" by a major mining pools BTC.top and BTC.com [1]. What's to stop them from doing it again the next time it's convenient?

[1]: https://twitter.com/TheCryptoconomy/status/11319624478232780...

Luke 19:26 repeats the line but within the context of money. It certainly isn't an "endorsement of the 1 percent", but more a statement of truth observed in virtually every human domain.

You're right about that specific verse but that line is repeated throughout the Bible - some within the specific context of compounding money (Luke 19:26).

It applies to the article because the Pareto principle (also known as the Matthew effect [1]) explains why there's so many open source projects with low revenue and only a few with six figure revenues.

[1]: https://en.wikipedia.org/wiki/Matthew_effect

Thanks for writing this.

I'd love to hear your input on a possible application for this. I'm not sure if you're aware, but Counting Bloom Filters are useful as space efficient counters in LFU cache admission/eviction [1].

I'm wondering if bloom clocks would be a good data structure for a space efficient LRU admission/eviction. Full LRU uses a linked list and sampled LRU just uses random sampling, but my intuition is that bloom clocks might perform similarly or better than sampled LRU...

The difficult part will be dealing with concurrency. I suppose it'd be easy to treat threads as "nodes", but not all languages have the luxury of thread-local storage (Go), so I'll cross that bridge when I get there.

Anyways, I'm going to test it out later - thought you might be interested in my thoughts on a possible use.

[1]: https://arxiv.org/abs/1512.00727

This reminds me of recent talk by Jonathan Blow [1], where he talks about how we've made very little progress in the field of software and anything that appears to be progress is just software leveraging better hardware.

It's quite scary how low our standards have gotten.

[1]: https://www.youtube.com/watch?v=pW-SOdj4Kkk

I (and others [1]) have found that the act of logging itself helps you build and maintain momentum. For some people not wanting to "break the chain" of visible squares/X's/dots is enough motivation to continue.

[1]: https://www.reddit.com/r/theXeffect/

You're basically describing the black swan problem [1], but I'm not sure what your argument has to do with the premise of the article, which I understood as "tracking your life in a mechanical manner allows you to make better, more objective decisions."

Are you saying we shouldn't track aspects of our lives because that could lead to essentially "overfitting" decisions based on personal data? I don't think the data or the collection of the data is the problem - it's ignoring black swans.

I'd argue that our decisions are always influenced by our personal, recent past. If it's not explicitly written down in a spreadsheet, it's imprinted on our subconscious and associated with related emotions.

At least spreadsheets/journals allow us insight into details that we're likely to forget in our day-to-day lives. I think personal tracking is a net positive for anyone.

[1]: https://en.wikipedia.org/wiki/The_Black_Swan:_The_Impact_of_...

I found it ironic how unreadable this article was.

Not only is Durov's net worth $2.7B, but Telegram just raised $1.7B in an ICO for their cryptocurrency they're launching off of Telegram.

We should get Telegram to censor them too, that would definitely not make things worse.