Parsing: a timeline - <AUTHOR> https://jeffreykegler.github.io/personal/timeline_v3 <comment><USER3> I get the quest for more elegant and powerful parsing techniques, but it seems that some very interesting real-world problems - mostly arising in code editors - don't get enough academic love:

* Fast re-parsing when part of the input changes;

* Parsing of incomplete input, and enumerating possible ways to continue the input.

These can be very useful for code editors, for syntax highlighting and code completion. Some editors work around this by using a more restricted lexical syntax and avoiding to build a complete parse tree (Vim); newer editors - JetBrain and VS Code AFAIK - do have some pretty good techniques, but they don't seem to get a lot of academic treatise.

<comment><USER4> Fast re-parsing is tricky. I'm building a JS IDE for a simple language, and it needs to only re-parse the part of the syntax tree that an edit affects (and only update the minimal number of affected DOM nodes). Writing the (recursive descent) lexer/parser by hand was easy. Being able to stream text diffs to the lexer/parser and have it rebuild only the appropriate part of the AST took... a bit of work. Writing unit tests might kill me.

<comment><USER5> You will probably be interested in this explanation of how xi-editor does it: [https://google.github.io/xi- editor/docs/rope_science_11.html](https://google.github.io/xi- editor/docs/rope_science_11.html)

<comment><USER3> Thanks! The entire site is very interesting.

</comment></comment></comment></comment><comment><USER6> This was a good article! It's (reasonably) missing one of my favorite parsing algorithms, though, which is Might's "Parsing with Derivatives" [0, 1]. It's not very efficient compared to some other algorithms, but I think it is very elegant conceptually.

[0] Blog post: [http://matt.might.net/articles/parsing-with- derivatives/](http://matt.might.net/articles/parsing-with-derivatives/)

[1] Paper: [http://matt.might.net/papers/might2011derivatives.pdf](http://matt.might.net/papers/might2011derivatives.pdf)

[2] Improvements: [https://michaeldadams.org/papers/derivatives2/derivatives2.p...](https://michaeldadams.org/papers/derivatives2/derivatives2.pdf)

<comment><USER7> The author, according to my understanding, says that parsing with derivatives does not improve the state of the art either in terms of complexity or in terms of elegance.

My personal opinion is that Matt Might uses a different avenue to derive the state of the art and even though the original algorithm can be trapped to exponential complexity, the improved analysis and amendments in the 2012 paper save the situation.

I think it is quite an achievement to fight against so many experts who believed that the flaws could not be worked around and re-derive the state of art complexity. At least in the field of pure mathematics this has a very big value.

<comment><USER6> You bring up good points! I think the efficiency in real-world applications is still not as good as alternative solutions, but what I really like about PWD is that it's a general parsing algorithm that's incredibly simple to understand (if you have a working knowledge of regular languages). The implementation can be a little more tricky (e.g. if you've never written a fix-point before[0]), but the actual concepts just seem so simple. PWD was actually one of the first parsing algorithms I learned about (odd, I know), and even without much prior knowledge of the field of parsing I was able to grasp the gist of it in a single sitting.

[0] You can also just skip over establishing a fix-point if you guarantee that your language is not left-recursive.

</comment></comment></comment><comment><USER8> The author has assembled an interesting timeline. It leaves a lot out (this is inevitable; the theoretical research around parsing is unbelievably vast). But ultimately the goal of the article appears to be placing their project Marpa in its historical context.

Marpa is one of many attempts to "solve" the problem of parsing. Other notable attempts are PEG (Parsing Expression Grammars), the ALL(*) algorithm from ANTLR ([http://www.antlr.org/papers/allstar- techreport.pdf](http://www.antlr.org/papers/allstar-techreport.pdf)) and GLR. I wrote an article about what makes this such a difficult problem: [http://blog.reverberate.org/2013/09/ll-and-lr-in-context- why...](http://blog.reverberate.org/2013/09/ll-and-lr-in-context-why-parsing- tools.html)

</comment><comment><USER9> My professor-of-sanskrit friend chimes in:

The Germans were deep into Pannini in the 1800s, and the Russians were as well.

So it's possible the first point overstates the degree of ignorance of Pannini, at least on Markov's part =)

<comment><USER10> Thanks for this pointer.

[https://en.wikipedia.org/wiki/P%C4%81%E1%B9%87ini](https://en.wikipedia.org/wiki/P%C4%81%E1%B9%87ini)

"Pāṇini's work became known in 19th-century Europe, where it influenced modern linguistics initially through Franz Bopp, who mainly looked at Pāṇini. Subsequently, a wider body of work influenced Sanskrit scholars such as Ferdinand de Saussure, Leonard Bloomfield, and Roman Jakobson."

</comment></comment><comment><USER11> I like ANTLR 4's innovations, which are missing from the article.

      This paper introduces the ALL(*) parsing strategy that
      combines the simplicity, efficiency, and predictability of
      conventional top-down LL(k) parsers with the power of a GLR-
      like mechanism to make parsing decisions. The critical
      innovation is to move grammar analysis to parse-time, which
      lets ALL(*) handle any non-left-recursive context-free
      grammar.

[https://dl.acm.org/citation.cfm?id=2660202](https://dl.acm.org/citation.cfm?id=2660202)

<comment><USER12> Non-paywalled: [http://www.antlr.org/papers/allstar- techreport.pdf](http://www.antlr.org/papers/allstar-techreport.pdf)

</comment></comment><comment><USER13> Also, for a very comprehensive survey on parsing techniques, I can recommend "Parsing Techniques" by Grune and Jacobs: [https://dickgrune.com/Books/PTAPG_2nd_Edition/](https://dickgrune.com/Books/PTAPG_2nd_Edition/)

</comment><comment><USER14> How have you totally missed GLL and GLR parsing?!

[http://dotat.at/tmp/gll.pdf](http://dotat.at/tmp/gll.pdf)

<comment><USER15> Who uses them? I know someone who wrote a GLR parser generator, but I've never seen the algorithm used in production.

I've heard of one C++ front end that uses it -- Elkhound -- but the only context I've heard of Elkhound is in GLR parsing! As far as I can tell Clang is now the state of the art. (i.e. Clang probably does everything Elkhound does, but better and faster.)

I have looked at least 30+ parsers for programming languages. I see:

        - hand-written recursive descent (with operator precedence for expressions)
        - yacc (Ruby, R, awk, etc.)
        - <USER2>
        - Bespoke parser generators
          - Python's pgen.c - LL(1) with some tricks
          - sqlite's Lemon - similar to Yacc except you push tokens

That's about it. I've never encountered notable usages of Earley or GLL or GLR parsing.

<comment><USER16> Tangentially related, the author of this timeline has developed an Earley parsing framework called Marpa. [http://savage.net.au/Marpa.html](http://savage.net.au/Marpa.html) .

It's used in other projects (eg, [https://github.com/jddurand/MarpaX- Languages-C-AST](https://github.com/jddurand/MarpaX-Languages-C-AST) ) but the only ones I found which look production ready, in a cursory search, also involved the author.

<comment><USER15> Thanks, this is what I'm getting at. A lot of parsing techniques seem to fall into the category of "only people who care about parsing use them."

That's not to say they will never jump the chasm. I'm just a bit conservative in my design choices and I look for algorithms that have been "battle-tested".

<comment><USER16> As a minor commentary, back around 2000 I used Aycock's SPARK parser for Python, which was based on the Earley algorithm. I first learned about the Earley algorithm from Aycock's presentation at the Python conference IPC7. (His use of docstrings to annotate the grammar went on to influence Beazley's PLY parser, which is LALR(1))

Aycock's work with SPARK was one of the influences of Kegler's Marpa. I was surprised to see Aycock mentioned on this timeline as it was the only name were I could say "I met him".

Thus, I can say that for my work, I used the Earley algorithm. However, I don't think it was essential for the parsing I needed, only that it was available.

<comment><USER15> Ah that's interesting. I recognize SPARK because it used to be part of the Python distribution, used to parse the DSL that describes Python's AST:

[https://eli.thegreenplace.net/2014/06/04/using-asdl-to- descr...](https://eli.thegreenplace.net/2014/06/04/using-asdl-to-describe- asts-in-compilers)

In other words it was DSL used to implement a DSL used to implement Python -- how meta! But that post describes replacing it with a simple recursive descent parser in Python.

I used ASDL itself (not SPARK) extensively in my shell:

[http://www.oilshell.org/blog/tags.html?tag=ASDL#ASDL](http://www.oilshell.org/blog/tags.html?tag=ASDL#ASDL)

But still I would say that counts as a production usage of Earley parsing! Interesting. I don't know of any others.

(On the other hand, the fact that it was replaced with a few hundred lines of Python code means it probably wasn't needed in the first place.)

</comment></comment></comment></comment></comment></comment><comment><USER17> Misses the subplot of Lambek's categorial grammar and the way it frames parsing as proof search. Pretty cool idea, perhaps underexplored.

<comment><USER18> I have some older books and heavy papers on the subject. Any recent lightweight treatments you can link to? Thanks.

<comment><USER17> This paper is fresh in my mind since I recently read it. I liked it: [https://www.eecs.harvard.edu/shieber/Biblio/Papers/infer.pdf](https://www.eecs.harvard.edu/shieber/Biblio/Papers/infer.pdf)

 _We present a system for generating parsers based directly on the metaphor of parsing as deduction. Parsing algorithms can be represented directly as deduction systems, and a single deduction engine can interpret such deduction systems so as to implement the corresponding parser. The method generalizes easily to parsers for augmented phrase structure formalisms, such as definite- clause grammars and other logic grammar formalisms, and has been used for rapid prototyping of parsing algorithms for a variety of formalisms including variants of tree-adjoining grammars, categorial grammars, and lexicalized context-free grammars._

<comment><USER19> I knew Earley parsing before I read this paper. Now I know things about logic and theorem proving. Cool paper, would read again.

</comment></comment></comment></comment><comment><USER20> The PEG comments seems to be a bit bitter and I would like to hear the story behind the frustration.

<comment><USER21> The article says that PEG handles non-deterministic grammars by becoming non- deterministic itself. I don't know about PEG, but if that's true, it sure sounds like a recipe for disaster.

<comment><USER22> Thanks for reading my article. I _don 't_ say that, though the distinction is tricky. PEG is relentlessly deterministic, but that does not mean that the _user_ can determine, in practice, what choice PEG will make.

It's the difference between my being able to tell you that Jimmy Hoffa is definitely in a specific place, and my being able to tell you where that place is.

<comment><USER23> Are you saying that the user "can not" determine? Who's the user? the source code writer?

<comment><USER22> The author of the PEG script cannot in general know what language it actually describes -- it's just too hard. For more, see [https://jeffreykegler.github.io/Ocean-of-Awareness- blog/indi...](https://jeffreykegler.github.io/Ocean-of-Awareness- blog/individual/2015/03/peg.html). It has references, which you can follow up on.

You're safe if the grammar is LL(1) -- what you sees is what you get. After that it gets mysterious fast.

<comment><USER23> The language definition is pre-existent to the PEG parser you can write for it. PEG has a lot of advantages as a tool, and its a nice experience to write by hand. You do not author a PEG script, you author a language definition first. You're saying that _if_ the lang definition is lost, then is _hard_ to recover it from the PEG script or the parser code. Yes, but it is not a normal situation.

</comment></comment></comment></comment></comment></comment><comment><USER24> Impressive. Half the breakthroughs involve Chomsky.

<comment><USER25> Noam is on the short list of the most intellectually impactful human beings of the period since Descartes: Newton, Darwin, Smith, maybe Ricardo, Marx, maybe Frege or Russell, Einstein, Turing, Keynes, Chomsky, and a scant few more.

His politics may motivate people to disregard him, but mostly he's just come to the devastating conclusion (for solid reasons) that people working on language outside the Chomskyan tradition are not doing science; semantics, linguistic anthropology, and some areas of psychology are just wind. People who do such work will not understand his criticism because their academic standing depends on their not understanding it. There is thus a supply of motivated PhDs ready to dismiss and de-emphasize his contributions. Some of the same applies to philosophers who work on language.

<comment><USER26> Within linguistics there's plenty of politics associated with Chomsky but it's mostly politics within the field, it has nothing to do with politics writ large. He is cited more than any other linguist I expect. I haven't paid attention in about 15 years now, but back in the day there were plenty of linguists who liked his politics plenty but were sore that lines of inquiry they found fruitful -- reasoning about how linguistic form relates to function in particular -- had been banished from the influential journals and conferences by Chomsky and his acolytes. Semantics is plenty formal, by the way. Lambda calculus and other formalisms get lots of print.

<comment><USER25> Yes, as I said above, politics (re American policy) may have some role, but mostly, he has argued forcefully against a whole range of approaches to studying language. And many people (most prominently those in the Barbara Partee/Montague tradition) don't like that.

Oh, and at last look he was not just the most cited linguist. He was the most cited living human being.

(And FWIW, I came to linguistics from philosophy via formal semantics; I once held negative opinions of Chomsky myself. It took time to see that he was right.)

<comment><USER26> I wouldn't say that I ever came to the view that his anti-functionalist views were right. In other fields of science, biology, for example, it's taken as given that one can and should reason from function to form and vice versa. I got my PhD and left to program computers, in large part because I'd soured on the politics within the field. I was interested in semantics myself.

</comment></comment></comment></comment></comment><comment> Al-Khwarizmi The first entry seemed to imply that the post would be about (or at least include) natural language parsing, but it only focuses on the formal language parsing used in compilers.

<comment><USER4> This is because the two subjects were largely indistinguishable until fairly recently. Most of the theory for language parsing came from efforts to describe natural languages in terms of formal grammars, and until ALGOL, most programming languages didn't have especially complex grammars. So until recently, the study of formal languages was a linguistics thing - it's since become much more popular in the CS world.

<comment> Al-Khwarizmi Certainly they share a common root, but "largely indistinguishable until fairly recently" is quite an overstatement. They have had distinct goals and methods for at least 50 years, and for the last 20 years the overlap has been minimal.

CKY is from the 60s. Inside-outside from the 70s. Mild context sensitivity, tree adjoining grammars and other similar formalisms from the 70s-80s. Chart parsers that actually work for natural language in real life scenarios from the 90s (Collins, Charniak, Eisner). All that is seminal work in natural language parsing and mostly useless for compilers, just like LR is mostly useless for natural language.

<comment><USER4> Sorry, I'm from a philosophy background so I think of anything published in the last ~100 years as "fairly recent" ;)

All I meant was that that many ideas and methods developed originally for linguistics were taken up and expanded upon in programming language research, so that they had a great deal of overlap until about half way through the timeline in the link.

<comment><USER27> Programming languages didn't exist in any meaningful sense until the 1950s, and the theoretical framework didn't really exist until the 1960s. There's very little cross-pollination between compiler and natural language theory, both before and after the time. Strip out the notion of the CFG (a one-way development), and there's not really any overlap.

</comment></comment></comment></comment></comment><comment><USER21> Somewhat related: Marpa is a fantastic piece of software. I used it once for implementing a custom query language for a DCIM I was working on. If I'd still be using Perl, I'm sure I would've put it to good use again.

<comment><USER16> The Marpa FAQ at [http://savage.net.au/Perl- modules/html/marpa.faq/faq.html#q1...](http://savage.net.au/Perl- modules/html/marpa.faq/faq.html#q131) asks "Are there C/Lua/Python/etc bindings for libmarpa?" and answers that there are "Various language bindings for libmarpa" at [https://github.com/rns/libmarpa- bindings](https://github.com/rns/libmarpa-bindings) .

<comment><USER28> > there are "Various language bindings for libmarpa"

The C libmarpa is regrettably only the core of the larger parser[1], written in Perl. And at least as of several years ago, it had not been used elsewhere. Though it looks like there was some unmerged ruby activity in 2016.

[1] [https://metacpan.org/source/JKEGL/Marpa-R2-4.000000/lib/Marp...](https://metacpan.org/source/JKEGL/Marpa-R2-4.000000/lib/Marpa)

</comment></comment></comment><comment><USER29> Missing important details concerning why LLVM is taking over the world.

</comment><comment><USER30> Don Knuth is a genius</comment>


Natural History Museums Are Teeming with Undiscovered Species - <AUTHOR> http://www.theatlantic.com/science/archive/2016/02/the-unexplored-marvels-locked-away-in-our-natural-history-museums/459306/?single_page=true <comment><USER2> In response to the inevitable "No wonder they're extinct; those biologists in the 19th century were collecting them all indiscriminately". When they were collecting, these creatures were common as dust. And now these collections are the only way we know that some of these species existed at all.

</comment><comment><USER3> In the excellent Bill Bryson book "A Short history of nearly everything", a well known researcher was supposed to have opened a case drawer in the London Natural History Museum and exclaimed "oh fuck not another phylum".

The issue is that there are simply not enough trained scientists to study all that can be studied.

Perhaps there is hope for us all once the robots take our jobs:-)

<comment><USER4> A friend of mine works as a beetle curator. Telling species apart is actually surprisingly difficult. He shot down a lot of my technical solution suggestions with ease. Genetic sequencing might work some day but it's not there yet (and they have a lot of specimens, like 10-20 million).

E.g. there is a species where each specimen looks very different (e.g. size between mm and cm) depending on how much food they consume. The best way to differentiate is often to extract the genitalia.

One thing the article doesn't explicitly mention but alludes to is that a lot of species we _think_ we know may actually be different species, or just the same species with a different look. A lot of the descriptions are 50 years old and read "black body with six legs and a head". So all those need to be re- done at some point.</comment></comment>


California rated worst for business by Chief Executive Mag; Texas was the best - <AUTHOR> http://blogs.forbes.com/joelkotkin/2010/11/15/california-suggests-suicide-texas-asks-can-i-lend-you-a-knife/

<comment><AUTHOR> Opening paragraphs:

In the future, historians may likely mark the 2010 midterm elections as the end of the California era and the beginning of the Texas one. In one stunning stroke, amid a national conservative tide, California voters essentially ratified a political and regulatory regime that has left much of the state unemployed and many others looking for the exits.

California has drifted far away from the place that John Gunther described in 1946 as "the most spectacular and most diversified American state...so ripe, golden." Instead of a role model, California has become a cautionary tale of mismanagement of what by all rights should be the country's most prosperous big state. Its poverty rate is at least two points above the national average; its unemployment rate nearly three points above the national average.

       Chief Exec Mag Rankings:
       Top 5: TX, NC, TN, VA, NV
       Bottom 5: MA, NJ, MI, NY, CA

<comment><USER2> Though I don't disagree with all of that, "its poverty rate is at least two points above the national average" is an odd statistic to cite in a pro-Texas article, since Texas's poverty rate is even higher (TX 17%, CA 16%, national average 14%).

<comment><USER3> It's not odd nor is a comparison with Texas necessary if the #1 question is "Why is the 'Golden State' doing so badly?"

Plus we understand why a lot of Texas has been historically poor; the question of why California has gotten a lot worse is probably more interesting.

(I'm not sure how much worse, how or when, my Google fu wasn't good enough in 1-2 minutes to find anything beyond "In 1969, California's poverty rate was more than three points below the rest of the nation (9.1 percent compared to 12.5 percent)" in the summary of this: www.wsws.org/articles/2002/jul2002/cali-j13.shtml.)</comment></comment></comment>


Netflix Worth More Than Disney After Streamer's Stock Hits All-Time High - <AUTHOR> https://variety.com/2020/digital/news/netflix-shares-all-time-highs-disney-market-cap-1234581167/ <comment><USER2> "You just won the Super Bowl, what are you going to do next?!"

"I'm going to watch Netflix!"

</comment><comment><USER3> As an aside, I have been unable to register for disney+ in Germany. Both my and my partner's payment methods are always rejected with an unknown error. We tried 2 cards each, we even tried using paypal and even that still didn't work. After reaching out to their support on twitter we're still unable to register. The support chat implied that this is a common problem in Germany for some reason.

<comment><USER4> Google pay worked fot me.

</comment></comment><comment><USER5> Many things can impact can impact how a company might be valued. Enterprise Value (EV) is a commonly used valuation metric that subtracts cash and adds debt to the market cap as calculated by share price. Netflix has an EV of $183b and Disney has an EV $228b. Then there's other assets and liabilities, revenue and expenses, and ratios, trends, and speculation to go with that.

</comment><comment><USER6> And yet Netflix's offerings seem more slim than ever. I am scrolling past endless thumbnails of The Shape of Water and I can find nothing to watch.

<comment><USER7> Broaden your horizons!

[http://www.bbc.com/culture/story/20200415-the-best-tv- series...](http://www.bbc.com/culture/story/20200415-the-best-tv-series-to- watch-in-lockdown)

</comment></comment><comment><USER8> I find this statement hard to believe - to say the least. Not sure where you took your info from, but Disney isn't some firm that has recently hit the headlines. No matter what sources you quote from, the sort of info suggests that Disney has no assets at all.

<comment><USER9> It just means the market cap is higher, nothing else.

<comment><USER10> It means the stock is over-priced. In a rational world the investment decisions would be trivial.

<comment><USER11> It's not overpriced if people are willing to trade it for that amount

<comment><USER10> That was my point. People are not rational.</comment></comment></comment></comment></comment>


Two guys has just put an X-Wing into Earth's orbit - <AUTHOR> https://twitter.com/ProjectHeT/status/591371799209840640 <comment><USER2> No, it's not in orbit, and the link item doesn't claim so. It's at high altitude suspended from a balloon - it's not the same thing at all.

<comment><AUTHOR> Thanks for the heads up. They had apparently put the balloon into stratosphere. Source: [http://www.bbc.com/news/technology-32384570](http://www.bbc.com/news/technology-32384570)</comment></comment>


The Amazon Premium - <AUTHOR> http://calpaterson.com/amazon-premium.html <comment><USER2> The comparison on the Google compute instances is a bit iffy.

First, why are we looking at Google's N2 instances rather than N1 instances? The N1 instance would be $52 rather than $61, but the author hasn't talked about why they selected the more expensive N2 instances. Given that competitors don't talk about the CPUs they're using, it seems weird to select the more expensive CPUs for Google.

Second, Google offers dedicated hyper-threads. The author says that cloud providers (like Google) are more expensive, but they've compared dedicated hyper-threads on Google with shared hyper-threads on Digital Ocean. DO offers an 8GB 2 vCPU (2 dedicated hyper-thread) instance for $60/mo, but the author is using the 8GB instance with shared CPU for $40/mo.

So, with storage, Google costs about $52 while DO costs $60 for an equivalent instance. Linode's $60 8GB dedicated vCPU instance does come with 4 cores so it seems like a better value. One can also argue that the included transfer on Digital Ocean offers $8 in value. However, the premium for the instances alone isn't as big for Google. In fact, google seems cheaper.

Now, it's probably a fair comparison for Amazon's instance which only gives you CPU credits for around a third of the time.

Google's automatic sustained-use discounts and dedicated hyper-threads make it really competitive with Digital Ocean (if you don't need a lot of bandwidth) as long as you're doing an apples-to-apples comparison. DO's over-sold CPU instances will be cheaper because you're getting less. If DO didn't offer dedicated hyper-thread instances, maybe you could claim that they were equivalent. But DO literally sells something more equivalent for $60 rather than $40.

EDIT: Also, OVH is a bad comparison. OVH is cheap, but inconsistent in their product offerings. The author notes that they offer hosted DB services, but that's only in France. Their US, Canada, Singapore, Germany, Poland, and Australia locations don't offer that. Their US website is missing pricing on many of the things they seem to offer. Plus, at a certain point, when you're trusting someone with your datastore, you want a high level of certainty. OVH's website doesn't inspire confidence given how much seems like someone didn't even check it. It's certainly cheap, but it seems cheap for a reason.

One final thought: I'm surprised the author hasn't talked about transfer pricing. Cloud providers usually charge a bundle while others charge a lot less. 1 cent per GB at Digital Ocean is a lot less than the 9 cents per GB at AWS. AWS even charges 1 cent per GB for data transfer between AZs in the same region. If you're running a compute and Kafka cluster in 2 AZs, then writing 1GB to a quorum of 3 servers means paying 1.5 cents per GB written (assuming that half the time you're writing to 2 servers outside your AZ and half the time you're writing to one server outside your AZ). Likewise, when you go to read it, if half the time you're not reading from a local AZ, you're paying half-a-cent per GB to read the data. So processing 1GB costs 2 cents. That adds up fast. Everyone compares things like compute instances and seems to ignore data transfer costs. Frankly, Google is competitive on storage and compute costs with places like DO. However, if you are trying to create the next Imgur, you probably care more about transfer costs than compute or storage costs.

<comment><USER3> Hi, author here.

The reason I chose the n2-standard-2 over the n1-standard-2 was because the N1 instance in question has only 7.5GB of memory rather than 8GB. I let OVH slip on this one because they didn't have any other instances in the same ballpark but Google did. One of the eggs you have to crack when doing such a comparison I'm afraid.

With respect to the discussion of what really is a fair comparison to 1 unit of Google's proprietary vCPU units: that is of course open to speculation. One of the tremendous problems of cloud computing pricing is that the big three suppliers like to a) take a proprietary unit like "vCPU" which is not in common parlance and b) then repeatedly quote the cost for it in a tiny unit like hours. An n2-standard-4 is 0.0517 USD per hour - great. And let me really get the boot in: I hate that google's pricing page continuously defaults to the this useless unit on every page load. That company is probably the largest producer of web cookies worldwide but to remember that one, essential, UI slider was too much apparently. I broadly file this under the objection of "This is a naive navigation of the pricing schemes of $BIG_TECH" that I cover in the article

Transfer pricing is a real issue and arguably where $BIG_TECH really come and rip your face off. Egress bandwidth is priced at an unreal level precisely because people like me doing comparisons forget about it. In this respect $BIG_TECH are like the chinese restaurants where the dish is £5 but a 250ml bottle of coke to go with it is £6. I should have included it and if I did the comparison again I would model a small defined application rather than a small specific spec size. Mea culpa.

I still think the view I express in the article is right: $BIG_TECH cost a chunk more.

<comment><USER2> Given that google tells you what CPUs they use and that a vCPU is one hyper thread on that CPU, it doesn't seem proprietary at all. Digital Ocean's shared CPU plans seem like the ones where you're unsure what you're buying. Your thesis might still be valid, but you've definitely misled readers about Google's offering. You're comparing dedicated resources to shared resources when DO and Linode show you that they have higher prices than what you've used for equivalent instances.

Edit: also, you can create custom sized instances so you could have created an 8GB 2 CPU N1 instance for $49.63/mo.

<comment><USER4> DO also comes with free guaranteed bandwidth.

</comment></comment></comment></comment><comment><USER5> I often see these comparisons done to try to discredit the use of cloud computing resources, often comparing single cloud entities to bare metal one- for-one comparisons.

But that's now how compute is delivered in projects any more. The value isn't on the box, it's on _the platform_.

I'm personally about to bolt together a solution that will need to scale significantly, that uses complex message queuing, enormous amounts of object storage, expose set of APIs, and require a highly available distributed document store. And I'm going to personally do it _by myself_ without having to hire 14 SMEs across each of the domains.

The value isn't in a cheaper linux server, or less expensive bandwidth. The value is me being able to develop a solution from the ground up by bolting together Web services, Amazon S3, SNS/SQS, Lambda and DynamoDB from a menu of integrated services all by myself. Period.

<comment><USER6> And to not have to worry about the infrastructure gatekeepers.

<comment><USER7> Yup. Lots of tin-huggers don't appreciate that it isn't the _hardware_ that people are trying to get away from, it's _them_.

<comment><USER6> Speaking of which. My last job I was the dev lead and we were doing everything on prem. Then we hired "consultants" to help us "move to the cloud". I didn't know the first thing about AWS when the migration started.

I didn't know at the time that the consultants were a bunch of old school netops folks who took one AWS exam and all they knew was how to duplicate an on prem infrastructure in AWS.

Of course as always, if you take your on prem thinking and processes to the cloud, you now have the worse of both worlds. All of the process and people overhead of being on prem and you're spending more for the privilege.

I started studying for the AWS architect associate exam just so I could talk the talk and I realized how much unnecessary work we were doing instead of using managed services. I presented my entire plan to the consultants and they didn't tell me once that there was a better way.

For phase 2, I wanted to be more "cloud native" there was so much push back from the netops people who could tell they were losing their grip.

Not long after, I changed companies to work for a company where the new CTO - a smart guy who is definitely not young - always prefers managed services.

I've worked for small companies and everything I do in AWS, I've had to do on prem in the last 20 years. Never again.

</comment></comment></comment></comment><comment><USER8> There's really no controversy that AWS, Azure, and GCP are substantially more expensive than bare metal providers, if you're simply comparing machine specs.

So if all you're doing is setting up root access and handling everything yourself, then yes, you're throwing huge wads of cash down the toilet with those platforms versus renting a VPS on Linode, Digital Ocean, etc.

The economic disparity can flip, though, if you use these services as they're intended. i.e., take advantage of features that are charged incrementally and optimise to reduce how much they're activated per user transaction, where "user transaction" is a key user action such as a page serve or a reported being emailed.

The costs can be much lower when you're only using what you need, and not paying for large capacity to be sitting around in case of a peak usage moment. And even more so when you consider there are automatic upgrades and ops to ensure high availability.

<comment><USER9> Easier said than done. To implement that I will probably need to hire a DevOps guy, and now we have all this cloud formation (or whatever your infra as code choice is) code to manage now. So in reality it probably costs more (devops and more code to manage) than if I just went with a couple cheaper bare metal servers.

If you are running in the cloud then you still need a devops guy same as you would if you where bare metal. In fact you will probably need _more_ devops people the deeper you get into the AWS ecosystem.

<comment><USER10> Datapoint: We have 2 "DevOps guys" supporting a significant AWS infrastructure. We autoscale from 200 ec2 instances at night to 700 ec2 instances during the day. We run 60+ microservices, each of which has multiple processes that run, each of which is autoscaled (we use ECS). We use Aurora (with autoscaled readers) and DynamoDB (autoscaled IOPS). We manage all of that with 2 "Devops Guys".

Granted, we're a mature startup and have put a few years of investment (at the cost of 2-3 "Devops Guys") into our infra, but ultimately it doesn't take much to manage a ton of AWS infra once the tooling is in place.

<comment><USER11> just for back of the envelope, who many customers are you able to support per ec2 instance?

<comment><USER12> WhatsApp used to be hosted on ~15 bare metal servers serving 100 million concurrent users...

<comment><USER13> They were also acquired at a price which would value each employee at ~350M.

They were capable of scaling in a way that is certainly an anomaly, and not indicative of the costs of an ordinary team.

It speaks volumes about what the right talent and architecture/technology choices can do if leveraged successfully, but is more of an interesting anecdote than a realistic infrastructure budget.

<comment><USER14> > They were also acquired at a price which would value each employee at ~350M.

That's a pointless calculation. The acquisition wasn't for the employees. As with all network-effects products, the acquisition was for the active user base. They could have acquired WhatsApp, fired the engineering team, rewrote it with an architecture that required 100x the servers and still been happy.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> The reason I use AWS is because I can be fairly certain, that their uptime is quite high (not 100%, but it's more than I can probably guarantee if I were to run on an own server), that their eco-system is huge and they connect to each other.

Being a "solo hacker" developing multiple websites, I need to prioritize where I put my time in. Thus my "default" choice is using Elastic Beanstalk to deploy websites, be it PHP, Python or something else. I can easily add environment variables, let it connect to RDS (database), scale it up (more servers or bigger servers), I can add SSL certificates, I can add a CDN (Cloudfront), I can add separate data storage (S3) all with a few clicks and from one (albeit super-huge and need-to-get-used-to) dashboard.

Alternatives: I don't trust Google services for anything critical (they tend to shut down easily or they might just change their pricing drastically - e.g. in Google Maps), Azure might be an alternative, just never had the time to check it out intensively.

For "fixed ceiling" projects, I use Digital Ocean (because unfortunately AWS mostly doesn't offer a budget ceiling, just alarms).

<comment><USER16> Checkout Lightsail, been using it past 6 months. Power and freedom of digital ocean in AWS ecosystem.

<comment><USER17> To be clear, Lightsail is only "sorta" in the AWS ecosystem.

It is in the ecosystem in the sense that it ultimate boots up an EC2 instance. It is essentially a simplified skin on top of EC2 where AWS makes most of the decisions for you in regards to server setup, with simplified pricing. And it shows up as AWS on your bill, and can be billed along side other AWS services you use.

However, it isn't really in the ecosystem as I would argue. You can't connect it to networks and subnets you create. You don't have control over availability zones, so essentially everything (like talking to S3) is considered egress traffic. It is like a sandboxed AWS service, that sits out there on its own. It really isn't any different than using Linode or Digitial Ocean for your compute resource and using AWS for block storage, queuing, DNS, etc.. Other AWS services can't "see" your Lightsail instance, like they can see your EC2 instances. You can't connect EBS volumes to it, you can't take advantage of elastic IPs, or anything of that sort. It really is a separate service that sits on its' own, under the comfort of the AWS name.

If I remember right, even tags don't carry over between Lightsail and the rest of your AWS account. Again, Lightsail is fine as a service, but it is only "sort of" in the AWS ecosystem. It mostly sits on its own as an isolated service, backed by AWS.

</comment></comment></comment><comment><USER18> I suspect some of the premium is because "nobody ever got fired for buying AWS"

If you chose AWS and there's a security incident or hours-long outage, well, some of the best in the industry experienced the same thing, what can you do? Whereas if you chose Linode and they had _exactly the same incident_ justly or otherwise, people might question your choice of a cut price $10/month provider.

<comment><USER17> This is why a company i worked at about 3 years ago switched to AWS. I suggested using Digital Ocean and argued that we didn't need the complexity of AWS. But the CEO (who is so tech-illiterate that he struggles to send basic email, I am not even joking) has heard that everyone else uses AWS, so he wanted to use it too. Nobody was going to stop this guy from switching over to AWS. He wanted his company to rank among the cool kids that was built on AWS. He had heard of AWS and he trusts Amazon. He has never heard of Digital Ocean. His un-warranted opinion on switching to AWS was not worth fighting, so I let him switch as he desired. If any problem had ever come up with Digital Ocean, he would have pointed fingers at me and said "this wouldn't have happened with AWS, because they are AMAZON!".

And thus is why one small company dumps $1,000 a month into AWS when it could dump about $250 a month into Digital Ocean for comparable results. I know these are small numbers for many people on here, but it is a good illustration.

For what its worth. I was able to justify getting an AWS Certification because of this, which has been surprisingly helpful to have on my resume, even with companies that don't use AWS. It seems to be a fairly respected certification that demonstrates knowledge of cloud computing in general.

<comment><USER19> Dude, even for a small company the difference between $1000/mo and $250/mo is peanuts.

<comment><USER20> Maybe. But the decision heuristic here, which is "we pay 4x more for things because the CEO doesn't trust his people and like to micromanage things" can easily be fatal.

<comment><USER19> The company paid $1 instead of a quarter. Why the original poster even put up a fight about saving 750 dollars.... can't tell you. They probably spent more on keeping the kitchen stocked with coffee and soda each month.

<comment><USER20> The company is paying an extra $9000/year. With a boss like this, it's perfectly possible that they _don 't_ stock the kitchen with coffee and soda, because the CEO is already having somebody bring him his caramel macchiatos, so he doesn't care, and money's tight, because his people just do what the boss says instead of him trusting them to do the right thing.

</comment></comment></comment></comment></comment></comment><comment><USER21> As someone who's worked at many startups and look at this from that point of view.

Here are my key points:

\- What makes aws great is NOT ec2... it's the ALB, route53, ecs/eks/fargate, redshift, rds, lambda, SQS, Kinesis, cloudwatch, cloudfront... ect. The last startup I was at our production MySql got corrupted... glad I paid for RDS and had their 5 minute interval backups to s3 that required 1 click.

\- Nearly everyone is on aws, if aws is down the internet is down. The down time from aws is often hand waved away.

\- With aws I have access to 3rd party services like snowflake and databricks. Hiring and training talent is more expensive then ease of use services.

\- The cost to performance ratio had always been worth it for every startup* I worked at (double given aws gives baiscly a free year when you raise a round of vc funding). Its costly to dedicate staff/time to infrastructure. I had a real time data pipeline up in under 2 hrs using kensis and imply. Just having to set up somthing like kafka alone will take a multiplitude longer. *The exception being the startup that did billions of requests a day... I doubt they regretting paying aws to get to that point after 6ish years.

<comment><USER14> > Nearly everyone is on aws, if aws is down the internet is down. The down > time from aws is often hand waved away.

This is not even close to true. The 3rd answer has some numbers for you: [https://www.quora.com/How-essential-is-AWS-to-the- internet](https://www.quora.com/How-essential-is-AWS-to-the-internet)

You'll notice that the most dramatic responses come from other AWS devs like yourself (the first answer in the quora link). This is because as an AWS devotee you end up in an echo chamber.

<comment><USER21> In my experience its true. When S3 went down my companies systems started malfunctioning, as well as many other vendors/system all over the internet including things like slack. Our customers were experiencing pain from multiple vendor failures. When our customers cant order lunch, run trello, or sent chat messages on slack they blame "the internet".

Note:I take offence to being called an AWS devotee, I have been in this space professionally for going on 13 years with nearly all of it in the startup space. The early years had to rely on collocation. To see startups struggle from things like hardware failure and delaying sales because they need more hardware is something I do not fondly remember.

<comment><USER14> Apparently "the internet" to you is just hip startups if your name call outs are things like slack, trello, and lunch ordering. The startup echo chamber and the AWS echo chamber have a lot of overlap due to the elasticity you highlighted. That still doesn't mean it's representative of internet services.

When an AWS outage stops wire transfers, airline reservations, robot surgeons, etc, then it really will be "everyone". Until then, try to give yourself some perspective so you can recognize when a product is mature enough that it's time to start moving away from AWS.

> I have been in this space professionally for going on 13 years with nearly > all of it in the startup space

This is why the siren call of instant infrastructure is so alluring to you. While your depth of knowledge for startup infra requirements is there, it does not transfer to large enterprises/campuses/etc where demand is very predictable and involving another company (Amazon) in your operations is nothing more than a liability.

Before you bemoan on-prem competing with Amazon's world-class engineering org, consider that their priorities are spread across thousands of products all interacting with millions of customers. An outage that could destroy your business means nothing to them other than some reduced KPIs that month. While an on-prem solution might be worse in throughput, global latency, etc, the fate is in control of the org that can make sacrifices Amazon can't (e.g. planned nightly outages).

<comment><USER6> * This is why the siren call of instant infrastructure is so alluring to you. While your depth of knowledge for startup infra requirements is there, it does not transfer to large enterprises/campuses/etc where demand is very predictable and involving another company (Amazon) in your operations is nothing more than a liability.*

Every large company has dozens of vendors that they "involve their operations".

</comment></comment></comment></comment></comment><comment><USER22> I'm no AWS fanboy, and sure its not the cheapest out there, but this is assuming that all cloud providers provide the same level of services for their machines, which is a complete joke. There are OS, Software, security, ease of tools, even speed of scale considerations that have more to do with why 90% of the internet is on AWS lol. There's a reason the only approved government cloud for years has been AWS. Also, heads up, AWS also offers far more services than ALL of those other providers you mentioned. So when you actually start running a real ONLINE business, and need ETL, MUTLI-AZ, WHAREHOUSEING, AUTOSCALE, S3, ETC, all those things talk to each other out of the box and your vendor list doesn't go from 1 to 50.

<comment><USER23> I think the point is that many AWS customers aren't doing all of that and still assume they are saving money.

I would finger in the wind guess that a majority of AWS customers are just renting servers and storage and not even scratching the surface of the usefulness of the platform. Just my guess.

<comment><USER24> Sure they aren't, but they don't want it to be a big hassle when it turns out a few years later, they actually need those features.

My employer is okay with paying an extra $10k/mo for stability and predictability.

</comment></comment></comment><comment><USER25> Yes OVH and DO are much cheaper, I have used both.

I retired this year, last job was engineering manager at Capital One (managed deep learning team, I had little to do with infrastructure). At large scale, AWS is a good choice because of the capable security roles that they support. Not a perfect system, but when a large corporation wants to go all in on cloud deployment, AWS is a reasonable choice.

Personally, I really appreciate getting a free GCP micro instance that usually hosts two semi permanent web demos. Before I bought a good at-home GPU system, GCP was a good option for spinning up instances for machine learning runs, but Azure and AWS is also good for this.

If I were trying to spin up a startup business, I probably would use DO or OVH with a hot smaller backup always running that I could switch DNS settings for rollover - but not nearly as robust as multiple availability zones with one of the expensive cloud providers.

</comment><comment><USER26> It is true that AWS is expensive considering cost of raw hardware resources. However, it is also true that it is very easy to create many kinds of apps and their support is not bad. For example using their "serverless" stuff (lambda, api gateway, static hosting in S3 and cloudfront) it is very easy to make apps with hosting cost almost perfectly matching the number of users so the only upfront capital expenditure is dev time. Another thing that is very easy on AWS is micro service apps (geographically distributed or not) consuming their managed services such as elasticache etc. Finally, automated deployments (allowing for continuous development/continuous integration if one wishes to use it) are also easy to implement quickly...

The price one pays for it is vendor lock in. I wrote many mini-non-mission- critical apps to run on AWS, but I would think twice about putting my main business app in AWS without (costly)backup.

I imagine that for startups it might make sense to create their initial product on AWS and when the product takes off spend some of first revenue making it cloud agnostic.

The benefit of AWS is that a startup can implement a proof of concept quickly without having to worry about managing their own elastic search for example, and once it proves viable effort can be added to escape vendor-lock-in.

<comment><USER6> You're always locked into your infrastructure at a certain scale. All the time you waste trying to avoid lock in, you could be using to actually deliver value to customers.

Even if you are just running a bunch of EC2 instances the pain of transitioning your workload and data usually isn't worth it.

</comment></comment><comment><USER27> I don't agree with the pricing comparison, it is factually incorrect. For instance the digital ocean equivalent in AWS would not be an EC2 but a similarly sized light sail instance which is $40/monthly flat. There are also other factors like region, on demand vs reservations that are ignored.

</comment><comment><USER28> Sometimes it's all about priority. I can't speak for the author and I don't know what the author needs, but my experience tells me, again and again, using cloud services is all about productivity, and people tend to underestimate the cost of lost productivity and missing opportunities.

I'll give two examples.

Netflix focused on productivity. They even popularized the phrase "undifferentiated heavy lifting". They were able to build a metric system, in less than a year, that supported full OLAP query with practically arbitrary number of dimensions. The system ingested > 20 billion data points per minute, ran on more than a thousand machines, and did not set quota to any team or service. The entire system was built and operated by merely three engineers. This was simply not possible without AWS. Similarly, Netflix's data pipeline, Elasticsearch cluster, and Druid clusters were developed and operated by two engineers. They were oncall 24x7, yet they rarely got waken up in the middle of a night. You think this was possible if Netflix tried to build its own infrastructure?

The counter example is Uber. Uber was ambitious and wanted to build everything. The results? More than 200 alerts got fired within 2 hours -- the poor oncall engineer couldn't do anything but to keep ack'ing the alerts. Wanted to use Cassandra? 10-page forms that were more tedious than applying for the Ivy schools, weeks of waits, lots of angry emails, countless meetings, and still no Cassandra instances. Wanted to add 50 machines to your ES cluster? PPTs, meetings, escalation all the way to CTO, and weeks of planning. Want to try out Apache Kudu? No way, because our container-based EC2-like system did not support persistent volume, let alone something similar to EBS or EFS. Wanted to use container for your ES cluster? Same answer. Wanted to create your bespoke cluster topology? Same answer because apparently custom network configuration was not supported. After waiting for more than three years? Same answer. If this was not expensive, I don't know what was.

So, you asked if you should save a few thousand bucks a month for your fast- growing company?

</comment><comment><USER29> When comparing virtual machine and ephemeral block storage you're kind of missing the point of AWS "value" for me. It's the deep integration to other services. So yeah DO are perfectly fine if I just need that VPS and a few S3 buckets, but if I need managed Redis? Or something like SSM for managing secrets? Or a managed Elastic search instance?

<comment><USER30> Redis themselves offer a managed service. There's [https://www.envkey.com/](https://www.envkey.com/) and several alternatives. Elasticsearch offers 3 completely different tiers of support and offerings.

Everyone going to AWS is going there for an AWS-like experience. As someone who runs pretty big workloads on AWS, you still very much need the help when you get to a certain scale, and there is a ton of value in just buying a support contract from Elastic or Redislabs, even when using their managed services or running it on an ec2.

</comment></comment><comment><USER31> Given that AWS operates at an unprecedented scale yet still seems to charge a premium over smaller operators, can someone explain why their operating margin[0] of ~25% seems relatively small in comparison to what one might expect? Is this simply because they reinvest a lot of their revenue into product development, or are they much less efficient than they might be able to be?

[0] [https://ir.aboutamazon.com/news-releases/news-release- detail...](https://ir.aboutamazon.com/news-releases/news-release- details/amazoncom-announces-third-quarter-sales-24-700-billion)

<comment><USER32> > their operating margin[0] of ~25% seems relatively small in comparison to > what one might expect?

Your setup premise is too constrained, you only provide two possible answers. One, they reinvest a lot; two, they're much less efficient than someone (who?) expects.

The third one is that you're wrong about how much margin is in the business to begin with. The smaller operators are barely surviving at break-even or worse. Companies like Linode and DigitalOcean are not printing large profit margins. DigitalOcean has been a money losing operation (growing via hundreds of millions of dollars in venture capital and debt, plausibly self-sustaining some day when they decide to pull back on spending expansion vs growth... maybe). So the premium that Amazon is charging is precisely what is responsible for them comparatively printing money with a ~25% operating margin. It's not the other way around, such that their margin should be up at 50% if they were run properly as a business. It's something close to remarkable that they have a 25% operating profit margin (and are consistently so profitable), it's the envy of the entire cloud industry.

<comment><USER33> Also why they can safely drop prices if someone else eats their lunch.

</comment></comment></comment><comment><USER34> The effective monthly price for that t3a.large (excluding storage) can vary from $55 to $25 depending on how much you're willing to commit in advance.

See the chart at [https://ibb.co/M7nnMvL](https://ibb.co/M7nnMvL) for some different scenarios.

</comment><comment> kube-system Ignoring that this really isn't an accurate comparison of TCO or performance, this really isn't surprising to anyone who has experience working with enterprise sales. Specs alone will rarely win a sale. Intangibles still have a lot of worth in the b2b space.

</comment><comment><USER35> Meanwhile I have a 64GB DDR5, 512SSD and 4 TB 7200 RPM hard drive, Ryzen ( 2700 - 8 core @3,2Ghz) for 900$ as a docker host kicking cloud butt.

Indeed, I don't need global-wide services though. But it's more than enough for my localized SAAS.

I'll probably add some PI4's in a cluster and experiment with that ( eg. Hosting 2 message brokers instead of one) or the elastic search that requires 1,5 GB RAM ( I'm not sure yet), since I don't want that in the same server.

<comment><USER36> This is an apples and oranges comparison.

You are using commercial-grade hardware, with no ECC RAM and other server- grade features.

You are also missing RAID, the UPS power supply and generator backup, as well as redundant Internet connections to different Tier-1 providers.

<comment><USER35> I don't care about ECC [https://blog.codinghorror.com/to-ecc-or-not-to- ecc/](https://blog.codinghorror.com/to-ecc-or-not-to-ecc/)

I had hardware raid 5 before and it failed, because I used similar hard drives ( 3 drives failed within a month, wasn't expecting that).

Working on redundant deployment though ;)

\-- My quote still stands as I said it

<comment><USER36> > _I don 't care about ECC_ [https://blog.codinghorror.com/to-ecc-or-not-to- > ecc/](https://blog.codinghorror.com/to-ecc-or-not-to-ecc/)

And that's fine. Though as a counterpoint:

[https://louwrentius.com/please-use-zfs-with-ecc- memory.html](https://louwrentius.com/please-use-zfs-with-ecc-memory.html)

> _I had hardware raid 5 before and it failed, because I used similar hard > drives ( 3 drives failed within a month, wasn 't expecting that)._

Which goes back to _my_ point. You're comparing your home system, with something like one-9's uptime (90% availability over an entire year) with a cloud provider that is going to give you five-9's or better.

These are not the same things. And you are going to pay more for each additional 9 of uptime.

For your own stuff, yes, of course it can make perfect sense to host it yourself. I've got a personal server running on positively _ancient_ hardware that still manages two-9's availability, and that's fine for my use case. But I wouldn't directly compare that to a cloud provider either.

<comment><USER35> I said my hardware raid failed, I'm still checking georedundancy / failover at sperate locations.

</comment></comment></comment></comment></comment><comment><USER37> While I appreciate the analysis, the perspective this whole blog post takes misses the mark on how AWS provides value. You can't look at it simply as providing commodity computation and storage.

As a solo SAAS founder, I use AWS because of all the other services that surround those offerings (Cognito for user management, DynamoDB for database, Serverless stack for API, SES, SQS, Route53, ECS, I could go on for a while) provide a huge amount of value for me in terms of not having to fully set up and maintain that functionality myself. I pay next to nothing for these services and the developer and devops hours saved is worth many thousands of $ to me. However, because of this reliance, I then end up _knowingly_ overpaying for storage, computation, and bandwidth (the latter is by far the biggest concern, the former 2 are fairly minor, so I'm looking at alternative CDN providers). However, other than that, even though my AWS bill is the biggest my SAAS has, I happily pay it. There would be almost no way for me to run this thing solo without it (I'm not saying someone else couldn't, just for me).

</comment><comment><USER38> This is not an ultra fair comparaison since Amazon has huge discount when you signed up for a year for example. Not to mention spot instances...

But yes OVH has a lot to offer and got my preference too. But I am French and it is a French success!

<comment><USER39> Yeah this is an extremely limited use case with very few data points. It doesn't take into account corporate discounts, spot instances, reserved instances, savings gained from replatforming/rearchitecting to *aaS options. The author here must have very limited enterprise cloud experience.

<comment><USER40> Part of this point is that Amazon / Google / Microsoft pricing is intentionally complex, which at the end of the day leads to surprise / higher costs

</comment></comment></comment><comment><USER41> The premium, and highly profitable, market leader is more expensive than other offerings that are trying to play catch-up on market share. This is not exactly a groundbreaking or unknown finding.

BMWs also cost more then Fiat's

Also, AWS has become the new IBM and as they used to say "nobody gets fired for choosing IBM." In the current market if you choose something other than AWS people will question your decision if something goes wrong.

<comment><USER42> OVH is older than AWS and profitable as it is.

</comment></comment><comment><USER43> I think this is a nice little piece (though as others have said - not exactly breaking new ground) and I just wanted to add something to this:

> "Smaller providers cannot operate at my yottabyte scale"

I used to work at a company, now closed, that at one point was the #2 or #3 user of S3 in the world. We were not a big company and the fact that we were inexorably bound to Amazon was a harbinger of our doom. That we were too large for most solutions and that we had become trapped on one provider was a sign of our poor decisions and our inability to think laterally and, effectively, do anything other than digging _straight down_.

I raise this because I think that, if you ever find yourself thinking you're too big for a small provider, I think you should treat that fact as an existential threat to your company. Either you build your own hardware setup or you break up how you do things so you _can_ use smaller companies (even if you chose not to). All the tooling and learning you do to fragment, migrate and validate your data will be invaluable.

<comment><USER19> Or you just use a cloud provider, which will be able to scale well beyond whatever your company grows to.

> All the tooling and learning you do to fragment, migrate and validate your > data will be invaluable.

Too bad this learning has absolutely nothing to do with 99% of any business out there. It adds _zero_ value to the company. In fact, it is a net negative because the company could be doing anything _but_ learning something like that.

Opportunity cost _is_ a real cost.

</comment></comment><comment><USER44> My favorite use case for AWS is being able to spin up temporary resources for rendering, video transcoding, or lab testing, and then shut them back down after a few hours. Likewise I can see a huge win for cyclical traffic loads in only paying for what you use, and in being able to scale up on a dime. Comparing it to a monthly $x/mo provider isn't a fair comparison.

<comment><USER42> What you're doing is probably much more expensive in the long run than buying a GPU or using a dedicated rendering service.

</comment></comment><comment><USER45> This isnt a useful comparison, Normal S3 has 6 copies, whereas some of the others have only 3. The Durability of S3 standard is 11 9's

<comment><USER46> That S3 durability isn't really guaranteed by an SLA, it's just "designed" for 99.999999999% durability, but if you don't get that - too bad, I guess?

To be fair, other providers also don't really offer an SLA on their durability.

<comment><USER45> My point is that S3 is significantly more durable than the "OVH" type object storage in the posters comparison.

</comment></comment></comment><comment><USER47> This is not even talked about: One of the biggest cost of cloud is also bandwidth. Usually at about $0.10/GB of outbound transfer.

<comment><USER48> He includes a pointed link at the end to the Twitter of the AI Dungeon 2 guy - who discovered the hard way that when you have a popular app which involves downloading 6GB every time a new user shows up (or an old user, for that matter), you quickly hit $10k/day bills.

<comment><USER47> Oh wow- I had not looked at that in detail. TLDR: Guy puts free game online, and is charged $0.30 for every download, raking up a $10k bill.

</comment></comment></comment><comment><USER49> I immediately disregarded the authors opinion when they put OVH in the same league as major cloud providers. OVH is a source of nothing but spam/malware/outright malicious traffic from our perspective.

We have a job that automatically updates an AWS WAF IP blacklist with their ASN ranges from BGP. We don't want their business or their customers business.

</comment><comment><USER50> I think this argument/comparison warrants including the pricing of purchasing a hands on rack from a data center directly.

A full 1Gbps up/down cost about $200/mo, plus ~$150/mo for the managed fiber run. A full locked rack is around 800-1,200$/month. You can load up 40U worth of Dell R730xd, or R740xd (dell outlet). Throw in a few enterprise HP 10g fiber switches (refurbished).

You will quickly start to crush any cloud pricing. But you need IT/VMWare experience.

Keep in mind that a cpu/core on AWS or GCP is a fraction of an actual cpu/core. It's a spot representation of an x cpu from some arbitrary time way back when. Even if their specs say differently, try running a job on a 2x cpu machine vs 2x cpu on dedicated hardware.

<comment><USER51> Cloud computing is cheaper, not because its actually cheaper, but because of elasticity. If you dont need elasticity, then yes, colo will always be cheaper. If you are in the cloud you should be autoscaling, as that is the main premise of why the cloud took over, and why the cloud can save you money. Only pay for what you need _right now_ That being said, if you can actually plan well enough in the future for colo, you can also pay 3 years in advanced for aws reserved, and pay significantly less than these prices.

<comment><USER50> I completely agree. I only mentioned because the article included providers that don't include the same level of ecosystem benefits, which seems slightly unfair (from a CTO/board decision perspective). I think including a baseline colo option gives insight.

Also, purchasing Dell R7xx hardware, from our experience, has almost 100% uptime at scale, over the past 10+ years, confidently running a 3yr machine 5-7 yrs easily.

</comment></comment></comment><comment><USER52> In some ways you just can't compare, i.e., Cloud Formation and software defined infrastructure is a completely new way of architecting services, but if you're doing more than serving web pages, anything data heavy, the storage and egress costs are incredibly high.

Consider the costs of a rack of Supermicro thumpers (90 bays [https://www.supermicro.com/en/products/chassis/4U/946/SC946E...](https://www.supermicro.com/en/products/chassis/4U/946/SC946ED-R2KJBOD)) for long term large online storage vs AWS. Even using Glacier (which is cached tape) is expensive in comparison, especially when read/egress costs are included. Even if you use more enterprisey gear from Dell it is MUCH cheaper to DIY or pay an independent integrator than to use AWS.

AWS itself it doing this for even cheaper than what white box gear sells to retail, because of their huge scale and integration efficiencies. There is a reason AWS makes so much money.

</comment><comment><USER53> It's simplistic but there's value in having such basic comparisons as the offerings differ for more complex use cases. If anything, I imagine basic comparisons will underestimate cost differences once the ancillary charges are taken into account. I can't be the only one who's seen organisations surprised by their cloud costs after migration and then struggle to reduce costs.

</comment><comment><USER54> This couldn't have come at a better time for me. I'm trying to migrate off of Heroku and my default was to AWS, but this definitely gave me more options.

One advantage of AWS is that there seems to often be free AWS credits thrown around. It's hard to compare and quantify that, but something I'm aware of.

</comment><comment><USER55> I've run substantial systems (200+ node operations) on OVH and it was completely unreliable. The hardware kept breaking down, the internal network was terrible, and the support was terrible. Sometimes some backhoe would cut the network connection and cause a 12 hour outage (ok, over 3 years only twice). It was also was inelastic, and provisioning was slow. So if I needed new hardware there could be considerable lead time required.

We also tried Heztner, Linode and others. They were all bad in their own unique ways.

With AWS, and GCP, yes it is more expensive and also have their own set of problems but nowhere near the same scale as these other providers.

Yes if you are running a 1-2 machine setup, who cares. If you are running a professional organisation where you cannot reasonably have downtime without customers screaming, don't go for the cheap stuff.

<comment><USER56> I haven't used OVH a whole lot, but it's my go-to for small stuff because it's such a good value for the price. I have spun up a lot of instances on AWS and OVH now, and haven't noticed a speed difference. In fact OVH seem faster. Are you talking about VM instances or something else that takes a while to provision?

</comment></comment><comment><USER57> "I do appreciate the youthful incredulity of thinking you can save us a million dollars a year by pointing to a hard-drive rack . It's good to question the fundamentals! And we've done just that. Spreadsheets up the wazoo. We don't spend a million dollars with glee. But you can try to cut corners on redundancy and availability, and then you can see how much leniency your customers will show you when you lose their files and have to explain yourself. I'm the one who has to say sorry! So I have to be able to look at our setup and believe we did everything possible to keep our customer's data safe, and then some. This is that."

-DHH

[https://m.signalvnoise.com/only-15-of-the-basecamp- operation...](https://m.signalvnoise.com/only-15-of-the-basecamp-operations- budget-is-spent-on-ruby/)

</comment><comment><USER58> Ad pixel servers. Literally go from 1x to 4x at peak. If we had to pay for 4x all the time, it wouldn't be feasible. And then add in that feeding through the managed technologies allows you to build lots of product with small teams means it's a no brainer.

</comment><comment><USER59> Are there any reasons for going bare metal today? Does it lead to competitive advantage in some scenarios?

Imagine if Netflix or Twitch were founded today - two businesses with demanding media-hosting needs. Would they be better if they used Amazon infra or built out their own data centers and CDNs?

I'm really curious about this because I'd like to get into the space and I'm mulling over bare metal as a competitive advantage vs a barrier to scaling. I've seen how difficult it is to provision and upgrade machines. At the same time, if you were to make it to scale, it seems like having the bare metal and the talent to manage it puts the ball back in your court. Am I wrong?

<comment><USER60> Netflix only uses amazon for the "control plane" - ie the "web app" you're navigating when using the Netflix app. The actual delivery of media happens via their own CDN (of bare-metal servers.)

</comment></comment><comment><USER61> The nice thing about choosing Linode is you don't have to wait for a security incident: [https://news.ycombinator.com/item?id=10999397](https://news.ycombinator.com/item?id=10999397)

</comment><comment><USER62> Good luck trying to get a host with 192GB RAM on OVH. It takes days for the host to be provisioned and you have to fill out forms and provide identification.

On AWS if I want to run a model that requires a lot of RAM (or compute, or whatever) I can have it up and running in minutes without thinking too much about it.

Yes, I pay a premium, but the experience is just superior to anything the value hosting services provide. I find the same to be true for the most part in Azure as well.

I'm happy seeing this comparison, however. It gives me a good sense of just how much of a premium I'm paying. Thanks for doing this.

</comment><comment><USER63> It seems like this is assuming something like a simple webserver without HA requirements, but doesn't explicitly state that assumption. There is no mention of reliability or SLAs.

</comment><comment><USER64> Hetzner, less than €10: [https://www.hetzner.com/cloud?country=ot](https://www.hetzner.com/cloud?country=ot)

</comment><comment><USER65> One more idea: "$BIG_TECH has huge developer economies-of-scale".

Whenever I or one of our devs has a problem with AWS or configuration, there's a 99% probability that anyone had this problem before and I find high quality google search results. That's not the case for OVH, Digital Ocean, ...

With developer salaries at 350'000 USD/year, you can now calculate the massive amount of savings.

</comment><comment><USER66> Your average AWS and Digital Ocean customers have very different needs. Hence different feature sets and different pricing. Running a simple Wordpress blog on AWS is just as stupid as running a 1000 instance cluster on Digital Ocean.

Also, why don't you compare Digital Ocean to Amazon Lightsail? Or spot instances? You can often get those for 1/10 of on-demand price.

</comment><comment><USER67> To some extent, all of these things start looking even more expensive when you realize that you're buying burstable CPU that you aren't allowed to fully utilize. At least with Amazon's t3 instance class, you are assigned "burst credits" which you accumulate by not using the CPU and consume by using the CPU. So you are paying $70 per month for "2 CPUs" but you do not get 5184000 cpu seconds / month, you get significantly less. Digital Ocean, at least, is the same for those cheap instances though I'm not sure how they dole out CPU credits (I think they yolo it and you cross your fingers that you're not sharing a physical machine with the guy doing video transcoding and CI builds).

Both Amazon and Digital Ocean do have dedicated CPU instance types. The prices will make your eyes water. (I have not used the other cloud providers, so I don't know what they're up to.)

Obviously selling CPU on a time-sharing basis is a good idea; most customers aren't maxing out their CPU 24/7, and this lets them pack more customers into fewer machines. (RAM is the killer, though, and you'll see that at every cloud provider, RAM is really what you pay for.) But when you compare these prices to what a CPU costs... it starts to make you think.

My last job really warmed me up to the idea of just running my own servers. All our workloads were containers running in Kubernetes. With Kubernetes, I don't care about individual computers anymore. If one malfunctions, workloads can be easily moved to another computer. All the machine setup work is made machine readable by building containers and authoring Deployment objects, so there is no mental investment in a particular computer or disk image that you get from logging in, installing Debian, screwing around with files in /etc for an hour, etc. Basically, any sort of maintenance involved with physical computers no longer concerned me; repairing a hardware failure basically meant just repairing that hardware failure at my leisure and then moving on.

Combined with this was the fact that we were an ISP, so we had a datacenter, power, networking, and all that the floor below our office. I eventually convinced myself that for a month worth of AWS fees, we could have 10x the computing resources and 10x the bandwidth for a one-time cost. Nobody was motivated to hand over the credit card and let me build the cluster... but for me, running dedicated servers went from "thing that only Google does" to "why isn't everyone doing this!?" It's just not that expensive. And, consumer-grade hardware is really good these days. I drooled over the fast builds we got from a c5.4xlarge AWS instance. A consumer Threadripper build would blow that out of the water for about the cost of 6 months of AWS. (Amazon pays the Intel tax. You don't have to, though.)

<comment><USER68> It seems like you have a good business idea. At some point people will get off the cloud treadmill and build in house setups. If you create a company that sets up and maintains these at a lower cost than other cloud providers it would get you some business

<comment><USER69> Can you imagine how low that cost has to be? Unsure that's a worthwhile busines. AWS has the economy of scale.

<comment><USER68> Was talking about inhouse/onpremise setups. Does AWS do that?

</comment></comment></comment></comment><comment><USER70> This is a good start. What would have made this article compelling is a performance vs price comparison. cpu, iops, network, etc. extra credit for sampling a statistically significant number of vms across multiple regions and availability zones per provider.

</comment><comment><USER71> What I wish is that someone would make a blog post that shows you just how much you can realistically do while staying under the "free" tier limits and what innocent "mistakes" will take you over the line into regrettably expensive monthly bill

<comment><USER71> Also, I wonder why Amazon hasn't gotten into the ad platform business? They've gotten into everyone else's business. Isn't that the dream - to host a website on their platform and have it be self-supported via ads and possibly even profitable?

</comment></comment><comment><USER72> I'm a front end developer For work and more and more aws experience is explicitly asked for, I feel like I have no choice but to use their services for personal projects just so I can honestly say I have that experience.

</comment><comment><USER73> The top comment here rebutts this article from a business perspective: [https://news.ycombinator.com/item?id=21313816](https://news.ycombinator.com/item?id=21313816)

</comment><comment><USER74> This should include some data transfer and associated costs. Some of the services the services listed include a certain amount of bandwidth in the listed price, while others don't.

</comment><comment><USER75> News flash: elastic pricing is not optimal for static workloads.

</comment><comment><USER33> When people choose AWS, they do _not_ need only virtual machines. They need the whole range of products that AWS has to offer, and that range is _huge_.

</comment><comment><USER76> I wonder why the author is comparing AWS t3a.large to GCP n2-standard-2. It's not an apples to apples comparison as t3a runs on AMD while n2 runs on Intel silicon.

</comment><comment><USER77> You buy a shoe: $50, you buy a shoe exactly the same quality, but it's a nike: $120. Cloud is exactly the same kind of product than anything else

</comment><comment><USER78> Ironically, the per-terabyte price to _buy_ HDD storage these days is roughly equal to what Amazon charges for object storage per month.

Source: Amazon store ;)

<comment><USER79> This is not ironic as it's absolutely not relevant.

The HDD that you buy is not redundant, don't provide more than a very limited throughput, is not distributed across multiple geographic areas, is not connected to the internet, comes without any of the hardware to make it spin and is not benefiting from s3 APIs as far as I know.

You are comparing the costs of buying gas vs the costs actually associated with driving.

</comment></comment><comment><USER80> No one ever got fired for choosing IBM... i mean AWS

<comment><USER24> It might be CYA in action. However, risk has real cost. Risk of needing more than the little guys provide, risk of them disappearing or the service not keeping up with the times. For some people, the risk way outweighs the extra hosting cost.

</comment></comment><comment><USER81> Sentence 1: Amazon is probably the largest cloud services company in the world.

Probably? Back button where art thou.

</comment><comment><USER65> According to the results, shouldn't the title be "The Microsoft Premium"?

</comment><comment><USER82> There are lots of apples to oranges here. You can't compare say a Linode or Digital Ocean to an AWS/Azure. One of boxes for experimentation may make sense, I would not run prod though. Also, have you seen the network performance of the smaller providers? (obviously that comes at a cheaper cost too)

</comment><comment><USER83> In the long run you could save 50% or more if using reserved instances on AWS.

</comment><comment><USER65> One more idea: "$BIG_TECH will still exist in 10 or 20 years."

</comment><comment><USER84> There is no mention of uptime or SLA.

</comment><comment><USER85> DO is famous for randomly deleting customer data. They probably should not be included on this list.

</comment><comment><USER86> This entire article is flawed. The true value add of cloud services (AWS, etc) is that you no longer have to pay for disk jockeys to run a data center. To play games with refreshing hundreds or thousands of pieces of bare metal every 3-4 years [EDIT] is to doom your company to crushing O&M.

If you've never done Datacenter operations, then you're missing a giant point that eliminating an entire department of expensive technical people is a huge gain long term.

<comment><USER87> You didn't read the article at all, did you?

<comment><USER86> Read it enough to consider his primise was flawed and to judge the article as such. Running other "cloud" providers on-prem is not a recommended unless you're in Gov or Financial. [EDIT] Comparing the other cloud providers is totally a valid exercise. Just disagree with the wording of his/her approach

<comment><USER88> He's not suggesting doing anything on-prem.

<comment><USER86> I stand corrected.

<comment><USER89> > Read it enough to consider his primise was flawed and to judge the article > as such.

I suspect this algorithm needs tweaking, then :)</comment></comment></comment></comment></comment></comment>


All cause mortality and the case for age specific alcohol consumption guidelines - <AUTHOR> http://www.bmj.com/content/350/bmj.h384 <comment><USER2> At the bottom of the page:

~~ What is already known on this topic ~~

\- It is unclear from existing evidence whether the protective effect of moderate alcohol consumption is both real and applicable to older populations

~~ What this study adds ~~

\- When compared with self reported never drinkers, protective associations were largely limited to women drinkers aged 65 years or more

\- Little to no protection was present in other age-sex groups

 __*

I'm not a woman over 65, and I doubt the majority of people on HN are either. The study is still useful, though, since it indicates what not to do for health promotion! Drink alcohol.

Edit: not much markdown works... boo.

<comment><USER3> where does it show that moderate alcohol consumption is bad for health promotion??

</comment></comment><comment><USER3> "In summary, the study is grossly underpowered to convincingly prove a plausible protection, and they have committed the cardinal sin of saying that non-significance is the same as 'no effect' in a study lacking sufficient events, in this case, deaths in non-drinkers. Maybe epidemiological studies should include power calculations, which make sure there is a reasonable chance of detecting a plausible effect, and which became standard in clinical trials after too-small studies were being used to claim that drugs did not work."

[http://understandinguncertainty.org/misleading- conclusions-a...](http://understandinguncertainty.org/misleading-conclusions- alcohol-protection-study)

</comment><comment><USER4> Looking through this study it becomes clear that any positive effects of alcohol consumption is probably based on wishful thinking rather than statistical evidence.

They do mention one important point: most studies consider non-drinkers a homogenous group. In this study, they show that a lot of the seemingly positive effect evaporates when former drinkers are removed from the study. I wonder what would happen if they also removed people from the study who don't drink alcohol because of health reasons.

<comment><USER5> More like "the number of lifetime teetotalers they could find was so small that there was insufficient data to measure an effect"

</comment></comment><comment><USER6> I'd be interested in reading a study of drinking patterns beyond simple measurement of total consumption.

Every study I read measures volume over a time such number of units per week. But there is a difference between downing a bottle of wine in one hour every saturday night as opposed to a single glass every night. Perhaps a study based on peak blood alcohol level during the week rather than total consumption?

The OP study seems to have dealt with older people. Retirees, without jobs, might have many 'average' days resulting in a steady daily drinking pattern. Most of the younger drinkers I know go for extended periods without drinking (weekdays) only to get hammered come the weekend. Is this worse? Maybe multi- day dry periods give your system a rest and that is better than a daily pattern? I don't know.

It's all moot to me. I don't drink, which for a non-muslim non-mormon canadian means people often think I'm a recovering alcoholic. I'm not. I just don't like drinking. It;s not fun.

<comment><USER7> These total-factor mortality studies tend to be over large populations and long time-periods, so it's difficult to administer a test protocol like "check their blood alcohol many times a week and find a peak."

It seems almost certain that intensity of drinking has some effect on total- factor mortality, if only because if you get blind drunk you're more prone to accident than someone who drinks only to being buzzed or less.

<comment><USER6> That's why I am so interested. I could see how getting blind drunk once a week might actually reduce total mortality. Perhaps those who get blind drunk only occasionally under planned conditions have fewer accidents than those who drink regularly and therefore spend more time under the influence.

I agree that a measurement protocol would be difficult. But the OP was based on self-reporting. They could ask "Have you, in the last week, ever been above the legal driving limit?" or "What is the most you consumed in a single sitting this week?"

</comment></comment></comment><comment><USER8> So 20 units per week is about 0.5L of scotch. I drink about that much, or even a bit less, and most people think i am a drinker. Is that level of consumption actually safe?

<comment><USER9> This isn't medical advice: UK recommended limits are 3 to 4 units per day, with some days alcohol free and don't save the units up.

You're drinking towards the upper range of that, but still described as "reduced risk" drinking. "Increased risk" drinking is between 3 to 4 units per day (so around 28 units a week) and 50 units a week. Over that and you're at "high risk" drinking. [http://www.nhs.uk/conditions/Alcohol- misuse/Pages/Introducti...](http://www.nhs.uk/conditions/Alcohol- misuse/Pages/Introduction.aspx)

You might want to make sure you have a couple of alcohol free days spread out in the week. You might want to make sure you're not regularly drinking more than that half liter of whiskey each week.

The NHS has a huge amount of information: [http://www.nhs.uk/Livewell/alcohol/Pages/Alcoholhome.aspx](http://www.nhs.uk/Livewell/alcohol/Pages/Alcoholhome.aspx)

</comment></comment><comment><USER10> "Two samples were used, each utilising a different variable for alcohol usage: self reported average weekly consumption over the past year and self reported consumption on the heaviest day in the past week"

I started to question the study a when I saw self reported.

I would really like to get to the bottom of this is # of drinks a day and health. What is the true number of drinks/day that cause damage? I vaguely remember Checholvakia study that made the partipiciants bring back the cork, so the researchers knew they drank the alcohol, and didn't sell the bottles. But even then--they could have poured out the liquor? I gave a weird feeling no drinks/day is best? I should be dead--yes--antidotal.

</comment><comment><USER11> Direct healthcare costs estimated to account for £3.5bn by 2011-12 ($4.1bn; €3.6bn) of annual National Health Service expenditure in England.

Meanwhile :

Health problems associated with being overweight or obese cost the NHS more than £5 billion every year. [1]

[1] [https://www.gov.uk/government/policies/reducing-obesity- and-...](https://www.gov.uk/government/policies/reducing-obesity-and- improving-diet)

<comment><USER12> I suspect that alcohol consumption is a significant contributor to obesity.

</comment></comment><comment><USER13> A little off topic, but their site makes it really hard to figure out what BMJ stands for. I clicked around until I saw a picture of an old medical journal with "British Medical Journal" on the spine. On the ten or so pages I tried, that phrase never appears.

<comment><USER14> I think its a pseudo-acronym, like BP and KFC, where the mission extends the original goal so that it becomes rebranded without standing for the original name anymore.

I doubt you will find the original name of the other two on their sites either. If there is one thing that motivates marketers, its expunging an obsoleted brand from history...

</comment></comment><comment><USER15> Basically, though, it's at the point of debating positive effects (if any) of drinking alcohol. Because there is no evidence of a negative effect.

For most Americans, I believe this concept: that drinking probably is not bad for you, would be considered pretty radical.

<comment><USER16> What? It's radical because it's not true. Every large-sample longitudinal study into alcohol consumption has found an inverse correlation with mortality. Ignoring all questions about liver and cardio risks or benefits, alcohol is carcinogenic in a dose-dependent way. [http://www.medscape.com/viewarticle/824237](http://www.medscape.com/viewarticle/824237)

</comment></comment><comment><USER17> So the TLDR is if youre >= 65, decrease alcohol consumption. If you're <65 optimal range is 15-20 units per week, better if it's even consumption per day.

"One unit of alcohol is about equal to: half a pint of ordinary strength beer, lager or cider (3-4% alcohol by volume); or. a small pub measure (25 ml) of spirits (40% alcohol by volume); or. a standard pub measure (50 ml) of fortified wine such as sherry or port (20% alcohol by volume)"[1]

So in short: have 2 weak pints of beer xor 1 strong pint of beer xor 150ml of 13% wine.

Can someone confirm,refute this understanding of the text.

[1]:[http://www.patient.co.uk/health/Recommended-Safe-Limits- of-A...](http://www.patient.co.uk/health/Recommended-Safe-Limits-of- Alcohol.htm)

<comment><USER18> Did you read the article? The whole point seems to be the opposite of this. There was some small benefit to drinking alcohol to women over 65, none in other groups.

<comment><USER19> Not none

"Among younger men, the range of protective effects was minimal, with a significant reduction in hazards present only among those who reported consuming 15.1-20.0 units/average week (hazard ratio 0.49, 95% confidence interval 0.26 to 0.91) or 0.1-1.5 units on the heaviest day (0.43, 0.21 to 0.87)"

A hazard ratio of 0.49 means your chance of dying is _halved_. That seems like a very significant benefit to me. As a comparison in this study the hazard ratio for all-cause mortality for engaging in a very high volume of exercise is 0.65 [http://www.hivdent.org/_nutrition_/2011/PIIS0140673611607496...](http://www.hivdent.org/_nutrition_/2011/PIIS01406736116074962.pdf)

(the 95% confidence interval for the exercise study is much narrower though)

</comment></comment></comment><comment><USER20> I'm sorry, but this is one research result I won't drink to.</comment>


Machine Learning and Node.js, is this a match? [video] - <AUTHOR> https://youtu.be/SF8sluhCQTY <comment><AUTHOR> Personally, when using node.js i am a little bit envious on python, for pandas, sklearn, keras.</comment>


Pypants (Django Dash 2009) - <AUTHOR> http://pypants.org/ <comment><USER2> It was part of the Django Dash so the guys only had 2 days to build it, hence the scaling issues :D. AFAIK they are continuing work on it (add support for SVN/HG etc.) so stability should improve pretty fast.

</comment><comment><USER3> Site should be working again. To get an idea of what it does, check out this page:

<http://pypants.org/projects/amqplib/0.6/evaluations/226/>

</comment><comment><USER3> Sorry about the 500 issues. I'm working on fixing it at the moment. It's running on a 256MB slice with 2 other sites.

It only works for python packages currently. You can point it at any git repository that has a python package in it (watch the screencast).

</comment><comment><USER4> Grading on what though?

Number of lines of code? Size of methods? Number of commits? How much you like them?

An about page with the grading methodology should probably be the next thing you publish. Also, in my mind the historical breakdown is irrelevant. I couldn't care less if the project sucked two weeks ago if they re-factored and are now "a" quality. Of course, that's if I knew what "A" quality meant. :-)

Other than that, not a bad effort for a dash project. It's a neat idea and something that could prove very useful.

<comment><USER2> Well I'd be more likely to use a piece of code if I see that people have constant commits that are raising the quality of the code base. At least this way you aren't just going by commits/releases, you get to see how they changed the quality of the product.

</comment></comment><comment><USER5> What does it do besides give 500 errors?

</comment><comment><USER6> I'm getting a lot of 500 errors thrown here, but the project looks fairly interesting.

</comment><comment><USER7> While the site is down, take a look at the demonstration video: [http://vimeo.com/4936426?pg=embed&sec=](http://vimeo.com/4936426?pg=embed&sec=)

</comment><comment><USER8> I'm a little disappointed that Pypants hasn't graded itself. Got something to hide, hmm?

<comment><USER3> <http://pypants.org/projects/pypants/> There ya go :)

</comment></comment><comment><USER9> What about code hosted on bitbucket / hg ?

<comment><USER3> Supporting svn and hg is in the works, just didn't have time.

</comment></comment><comment><USER10> Pypants is awesome!</comment>


Show HN: Intelligent Domain Name Generator - <AUTHOR> http://DomainMongrel.com

<comment><USER2> Checked my personal domain... $9.00

Checked the same domain sans a hyphen... $23.06

Someone squatted on it to sell it for a markup, asked for something like $150, I laughed at him over the phone. Joke's on me, I guess.

</comment><comment><AUTHOR> You need to add a single keyword in the domain name generator tool. If you try to add multiple keywords, it does not work.

</comment><comment><USER3> It doesn't work for me: I entered "Screenshot", no results

<comment><AUTHOR> Domain Generation is pretty resource intensive. It has to be less than 9 characters. Can you try with a smaller keyword length.</comment></comment>