_bpo

A better question would be, why do you think you did not succeed.

Is that a different question than "why you failed?" from the GP?

Nice & succinct problem definition for why ACLs are so important for everyone:

Let me show you an example. You have a Redis instance and you plan to use the instance to do a new thing: delayed jobs processing. You get a library from the internet, and it looks to work well. Now why on the earth such library, that you don’t know line by line, should be able to call “FLUSHALL” and flush away your database instantly? Maybe the library test will have such command inside and you realize it when it’s too late. Or maybe you just hired a junior developer that is keeping calling “KEYS *” on the Redis instance, while your company Redis policy is “No KEYS command”.

Without ACLs we need to rely on command renaming or completely isolating databases to guard against errors. ACLs sound complicated but they're actually a solid user experience improvement.

The tldr here is that this is a nice recounting of personal experience interviewing with Uber and being frustrated by it, pointing out the many warning signs seen in the interview about a toxic work culture.

The post was prompted by the phenomenal writeup by Susan Fowler on her year working with Uber. If you can read only one, certainly read hers. If you can read only two, consider reading Susan's twice as it's exceptionally good writing. This is a nice (not exceptionally original) personal account of a bad interview experience.

even for a small company, $8k/year is admittedly a small fraction of one engineer

This is certainly true, but overlooks the fact that many major products start out as experimental projects, and $8k/year is a significant investment for an experiment.

If there's a reasonable upgrade path from traditional databases like MySQL and Postgres this shouldn't be a big deal, but if the answer is "rewrite your app" it will probably be a friction point for adoption.

Capital expenditures might shed some light on this. I don't think there's enough public data to be clear but in 2015 Amazon (4.8B), Google (9.9B) and Microsoft (5.9B) were at least on the same order of magnitude in terms of CapEx, whereas other major "datacenter" companies like Rackspace (475M) are much smaller.

I don't think you can draw any definitive conclusions from this, but calling it a class of size 1 or 2 is probably an overstatement of Google (+/- Amazon)'s advantage over Microsoft at least.

Lots of downvotes here – any explanation? The GP uses the phrase "the phenomenon itself" referring to the Kantian term "Ding an sich", which (as applied to phenomena) is just a logical error...

"Entitlement programs" is politicized as a term, certainly. "Cost disease", though... possibly in search for a new keyword?

I'm referring to the phenomenon itself.

From your example, Elizabeth Warren and Tom Price are looking at the same appearances (phenomena) and deriving different "noumena".

"cost disease" has become politicized

Citation needed. Where is this term common and where is it broadly discussed?

Tangential, but why do people write things like "even after adjusting for inflation" when discussing long timespans (40 years in this case)?

Is there any reason to not adjust for inflation? The "even..." in the sentence suggests that the author is being liberal with potential critics when it would seem only rudimentary to acknowledge inflation when discussing a 40-year timespan. A typical (new) car cost ~$4.5k in 1977 in the US....

Author here. I completely agree. Embedded gists didn't have this annoyance when I wrote the article. I figured GitHub could be relied on to not change things up too much, but that's what I get for depending on an external service...

Lots of useful, successful things appear to be magic (especially in their selling points). Early Heroku is a great example in this space.

I didn't see anything in the initial premise of otto that was technically untenable. We could speculate about the "challenges" - the scope was too wide/unbounded, it was open source, it was a distraction from other company goals, it didn't gain enough early traction - but that's simply speculation without details from the creators.

It's too bad (and uncharacteristic of mitchellh) that this post is so light on specifics. Were the "previously unknown challenges" simply that not enough people adopted Otto? Or were there actual technical hurdles?

The premise of Otto isn't clearly flawed, so it would be interesting to see specific challenges - even if it's just "the problem space is way too big and not enough people wanted it"

Languages are faster, development times are shorter, and chips are WAY faster.

This is due to Moore's law, not the software design choices that the article bemoans. Those $30k/month Sun servers were many times faster and cheaper than the earlier machines they replaced as well.

It doesn't need to be compared to anything to be called a mess. dpkg/rpm have been widely useful, but package and dependency management is still a PITA.

Even if you are genuinely curious, such inquiries from a boss/"authority figure" can easily come off as threatening, so tread very carefully with advice like that.

Looks like your blog is down at the moment

You get lockin issues with any vendor - even server colocation :)

AppEngine is a great tool for a great price. It scales smoothly with an affordable increase in pricing.

Heroku is sort of famous for getting too expensive at large scale. Their advantages are their ecosystem (most of the additional services listed in the OP can be installed quickly, and you're still only billed by Heroku), and their UIs which tend to be easy to understand and operate.

Their total costs between Heroku and Redis infrastructure are less than $3000. I don't think you'd be able to hire a devops engineer for less than $30k, anywhere.

It's surprising to me that people think they're spending a lot on infrastructure when they spend $800 on fonts, etc. When you drop the payment processor charges (which are per transaction) they're at $7k to run a site with a lot of functionality for a year. Seems pretty reasonable.

"Planning Tool for Resource Integration, Synchronization, and Management"

There are many non-state actors who can threaten life/personal-freedom.

Perhaps the problem was that I didn't travel by bus :)

Or perhaps I was just consistently ID'd as a foreigner and mark. Either way, fifteen euros to get across that border seemed reasonably sufficient to all.

It's entirely possible that things have changed - I haven't been to Transnistria in several years.

No idea why this is near the top of hackernews, but I've been there. One time when I was there, there was a huge billboard in front of the old ministry of culture with the (then) presidents of Abkhazia, South Ossetia and Transnistria smiling together. The local gag at the time was that this was the "Commonwealth of Unrecognized States" - meanwhile Putin was meeting the Commonwealth of Independent States in Chisnau. [1]

Far be it from me to attempt to summarize a nation in a few sentences, but one would be remiss without following up that article by saying the obvious.... Transnistria is a place run by gangsters. The hammer and sickle are printed on their money to appeal to the old folks who long for the days of Soviet protection, meanwhile everything is for sale - including people. This is a hub for the trafficking of everything.

I don't say this out of love for the state it broke away from, Moldova, the poorest country in Europe, the last communist country in Europe, which has all of the same problems at a different scale.

p.s. no need for endless paperwork - fifteen euros to the border guards will secure your entry no matter where you come from.

[1] http://imgur.com/8wf688Y

edited to change: I wrote "fifty" euros when I meant "fifteen" - I probably overpaid, but not by that much!!

You're certainly correct, but if you compare this:

  http://linux.die.net/man/1/indent

  https://golang.org/cmd/gofmt/

I didn't mean to imply Go invented automatic formatting :) It's unique among the popular language that I know in that the formatter is built into the standard toolkit. It also goes well beyond indentation. I've never seen a discussion of the format of go code outside the discussion of how `go fmt` should work - this I consider a benefit.

A big problem in large-scale systems is dependency management. One of the significant decisions that Go makes in its design is its approach to package management. Its approach isn't perfect, but is simple, making it a breath of fresh air compared to C++ or JVM-based languages... e.g. how many hours have been spent tweaking Maven or debugging discrepancies between classpaths referencing different copies of commons-logging?

Speaking of Maven - `go build` normalizes build systems so there is less time twiddling builds. It's not a silver bullet, but it's specifically intended for large systems.

Go's strong decisions around formatting (`go fmt`) are another example of planning for enterprise-size. There is no need for a style guide for go programs - it's built into the language, and with an approach that feels less pedantic than Python.

Go isn't perfect, but it's certainly designed for large-scale systems.

I agree with you that the JVM languages have better large-scale system support currently (20 years does give you something) -- but Go's goal is not dissimilar to the one Java eventually settled on after the applet craze.

Contrary to what you've seen, Go seems (to me) to be a go-to language for new companies principally concerned with distributed systems / cloud infrastructure (particularly those that once might have hired a hybrid of C and scripting language devs). One of the trends in those communities is toward microservices / SOA / etc, but the total codebases managed are certainly enterprise-scale.

All that said I have absolutely no significant opinions on Go vs Rust :) Just had to take issue with the "go is not enterprise scale" idea.

There can be fast differences in fork times between different virtualization schemes, even if your code is CoW-friendly (and Redis's is).

I worked for years on systems built on top of MTurk (building trust systems, scaling tasks, etc)

The hardest thing is always task design, as the author discusses. It's quite challenging to create a task that will work in all browsers, across cultural and language boundaries, and to pay enough to incentivize the worker (while simultaneously little enough to make all the effort worthwhile).

The final effect is a bit dehumanizing on both ends. The workers feel alienated and mistrusted by the people requesting the tasks. The people requesting the tasks feel that the workers are lazy / "scammers" trying to cheat them.

We don't fully even know how to think about this kind of work yet - ideas like "hourly wage" don't seem to fit for someone working completely independently, at their own pace, possibly distracted or impaired.

Still, despite the trouble, it seems like one of the most promising fields for interaction design. There's the possibility to really improve peoples' lives (or make them worse).

The reality is that there is no good time for a large-scale platform to go down. I'd speculate that 8am PDT would be worse for Heroku, as their business seems largely split between the US and Europe, so downtime then would upset everyone... but that's just speculation.

You can't build a company of developers selling products to developers while fleeing the working hours of developers.

The scheduled maintenance notice said:

    During this time, Heroku command line tools and web interface actions to create and restart dynos can be delayed.

The idea that maintenance should not be done during the day is a bit antiquarian. Scheduled maintenance should take place during their company's workday when they have as many people as possible available, feeling awake, well-rested and not distracted by the things they might prefer to do with their evenings and weekends off work.

Of course, scheduled downtime should be done in off-hours, but modern services like Heroku don't have scheduled downtime.