andrewvc

This is a long-standing debate over who should allocate capital. I don't think there's one exact answer. Clearly some companies, like AOL were terrible at reinvesting money, they tried and tried but wound up blowing tons of cash on worthless companies.

Other companies, like say Facebook were able to make smart investments like buying Instagram.

Clearly investors price stock based on whether the company can make smart investments in its own future, which is why AOL nosedived and Facebook rose. The market isn't always right but I'm not convinced that an alternative would be better

Additionally, companies guarding mountains of cash is problematic. Sometimes companies can invest cash more wisely than the market. Often times however this is not the case.

I agree short termism is a problem, but I'm not convinced of any particular solution here.

I'll also point out that sometimes when the market is too short termist private equity can come in and revalue the company to free it from those constraints as in the case of Dell.

Not really a surprise. Before sanitation massive quantities of people had them too. Parasites are still a problem in much of the world for humans and animals alike.

IMHO HN conversations tend too much toward solving problems at google scale. We often forget here that there are tons of high-value business critical systems that generate mere 10s, hundreds, or a few thousand background jobs a day. Given the numbers quoted in the article, DB backed queue systems scale quite far. I've successfully used them to handle tens of thousands of events per day with no problem over a timespan of years. It's clear that this is a great approach for some situations, and that one size fits all doesn't make sense here.

1. https://en.wikipedia.org/wiki/Insula_(building)

Instead of complaining about this thing point by point I'll just ask a question. Has anyone taken this self-serious pseudo-quantified thing and tried to actually put it into practice? Have you found any quantifiable results?

This, TBH, seems like an arbitrary yardstick for insecure people to measure themselves by IMHO.

At the very least they need to add a failsafe that checks all outgoing logs for any secure tokens and replaces them with '*' or something.

If you sign up to play a game of whack-a-mole you will lose eventually.

The secret is that you need to be fully committed to remote. If you do this you force yourself to actually find workflows that work remotely. If you just work two days a week remote you wind up isolated for two days and don't collaborate during that time.

A lot of companies that fail at remote work also fail because they have a mix of office and remote workers. This only works if you force every conversation to happen online. Otherwise you have the inner circle in the office and the outer circle that is remote.

The point is that a lot of remote work failures are simply companies that had remote workers but didn't have a workflow that was amenable to remote work.

I don't think most people are responsible enough to deal with more secure MFA. Most people don't know how to keep custody of stuff like that.

I'll just say that I love working with smart, motivated OSS developers from across the world in a culture where we implicitly trust people to do the right thing. That lets us avoid a lot of stifling process that I've seen in other jobs.

While you may know a lot about what the language is, how it works, and accepted ways of using it, your opinions on how to do things will always be evolving (hopefully).

Sometimes all the experts who use a language will be behind the times. For a long time experts championed strong OO design. Now all the experts champion hybrid OO/FP style things (witness Java 8!).

This too shall pass, and we should have the humility to realize that no-one knows for certain what will be the next evolution of software development.

Additionally there's an argument to be made that people who don't spend those years having their life structured and defined by a university learn other important lessons.

There's particular irony to making the point that college is where you learn to think on HN. Many founders, like Bill gates dropped out of college to be hyper focused on their mission.

Rather than thinking of college as a blanket solution for everybody I wish people viewed it as a tool. Some people need it, some people flat out don't.

There's an argument to be made that people who don't spend those years having their life structured and defined by a university learn other important lessons.

There's particular irony to making the point that college is where you learn to think on HN. Many founders, like Bill Gates, dropped out of college to be hyper focused on their mission.

Rather than thinking of college as a blanket solution for everybody I wish people viewed it as a tool. Some people need it, some people flat out don't.

Why are you so sure that college is causative here?

I don't doubt that college is where many people grow up more intellectually, but I have yet to see proof that it is the cause of that growth.

I'm not arguing that most problems need a custom database, only a minority do. I'd say that this problem is borderline on which direction to go.

Databases are very leaky abstractions as you all discovered. The nice thing about custom code is that you don't have leaky abstractions. The bad thing about custom code is that you have a large new untested surface area.

In the case of your application the requirements are so minimal, a bitfield plus a log, I'd say its a wash.

Programmers today forget that things like flat files exist and are useful. It's a shame, because you wind up with situations where people just assume they need a giant distributed datastore for everything.

What you're doing in that case is trading architectural complexity for code complexity. Now, if its the case that all data in your org goes in one data store to keep things consistent, great, that makes sense. But for a one off app I just don't buy it.

The crux of the problem is that they need to mutate a relatively tiny amount of memory and have a rolling log of events for which only the last 5 minutes needs fast access. Also, if you can put all your state on one machine its far less likely that the one machine will die, than it is that at least one will die in a cluster of machines. Given the nature of the problem keeping all state on one machine seems pretty rational to me, so long as you have the ability to switch to a hot spare within a few minutes or so.

If I were to architect this for speed I would have two tiers: a websocket tier, and secondly a 'database' tier. The database would be a custom program that would:

0. Provide a simple Websocket API that would receive a write request and return either success if the user's write timer allowed it to write or failure if it didn't. This would also broadcast the state + deltas. 1. Keep the image in memory as a bitmap 2. Use rocksdb for tracking last user writes to enforce the 5m constraint. You could use an in memory map, but the nice thing about rocksdb is that it shouldn't blow up your heap. 3. Periodically flush the bitmap out to disk to timestamped files for snapshots 4. Keep the hashmap size small by evicting any keys past their time limit 5. Write rotating log files rotated every 5m or so to record the history of events for DR and also later analysis

Backing this sort of thing up is very simple. You just replicate the files using rsync or something like it. You may have some corruption on files that are partially written, but since we're opening and closing new files often you can choose how much data-loss you want to tolerate.

Restoration is as simple as re-reading the bitmap and reading the log files in reverse up to 5 minutes ago to see who still isn't allowed to write yet (thus reconstituting the hashmap). Let's remember, redis replication is async, so this has the same tradeoffs.

Please refrain from making statements like this unless you have a reproducible quantifiable analysis.

If you really wanted to demonstrate the effect you describe you'd need to have the same team rewrite the application twice, once Java->Java, once Java->go, making sure to align the program structure as much as possible (making exceptions to take advantage of lang specific features of course).

If you were to do that, then that would be interesting! No one does that of course because it's expensive and wasteful from a business perspective, but it's the only way to determine anything useful.

I'm sorry, but the truth here is that DuPont knew for decades and hid those results from the public. https://www.bloomberg.com/news/articles/2016-07-06/dupont-lo...

I haven't used them in years, so I'm not sure if they are still the low cost leader, but they are definitely the kind of thing where you get what you pay for. Their lack of investment in product and infrastructure showed for the years I used them, and their slowness in delivering updates was incredibly frustrating.