Steve Jobs, LSD and Drug Freedom - <AUTHOR> http://politics.salon.com/2011/10/08/steve_jobs_and_drug_policy/singleton/ <comment><USER2> Incidentally, despite the oft quoted, "Bill Gates would be a broader guy if he had dropped acid once", Bill Gates basically did admit to taking LSD in a 1994 interview:

 _PLAYBOY: Ever take LSD?

GATES: My errant youth ended a long time ago.

PLAYBOY: What does that mean?

GATES: That means there were things I did under the age of 25 that I ended up not doing subsequently.

PLAYBOY: One LSD story involved you staring at a table and thinking the corner was going to plunge into your eye.

GATES: [Smiles]

PLAYBOY: Ah, a glimmer of recognition.

GATES: That was on the other side of that boundary. The young mind can deal with certain kinds of gooping around that I don't think at this age I could. I don't think you're as capable of handling lack of sleep or whatever challenges you throw at your body as you get older. However, I never missed a day of work._

[http://beginnersinvest.about.com/od/billgates/l/blbillgatesi...](http://beginnersinvest.about.com/od/billgates/l/blbillgatesint5.htm)

<comment><USER3> _Incidentally, despite the oft quoted, "Bill Gates would be a broader guy if he had dropped acid once", Bill Gates basically did admit to taking LSD in a 1994 interview:_

As with most drugs, those who don't wear the uniform of the subculture associated the drug (or at least strongly show the personality traits their users like to attribute to the drug) are assumed to never have done them.

<comment><USER4> The reverse is true, as well. My favorite 'after work' pullover in cool weather is a Baja hoodie.

Found out a few days ago this is garb that is associated with stoners at the high school: it's nickname is 'drug rug'.

I now understand the stink eye the school cop used to give me. And why a guy at a truck stop assumed that I - a middle-aged white guy with three kids in tow - might have something illegal he needed to see him through his overnight run.

</comment></comment></comment><comment><USER5> I've taken LSD and 'shrooms a few times, and while I can understand what Jobs is saying, I think he was wrong. I had mystical experiences where I thought I understood that the whole world was connected together, and I was connected to the world, and other deep insights. I think this was just brain-addled delusion, not any insight into how things really are.

That said, I fully support these things being legal, and (for people who aren't naturally anxious) trying them with a good "set" and "setting".

<comment><USER6> I too have taken LSD. Microdots were prevalent circa 1995 in South Yorkshire, which were strong to the point of not being funny. However, I did manage to get my grubby little junkie mitts on a few paper trips which were a lot more pleasant.

My own personal view that it did change the way I look at the world in some strange and indescribable ways and the experiences made a large contribution to the person I am today, for better and for worse. I never had any grand epiphanies though, but I had some really good times.

I also had some truly horrible times which resulted in some pretty strange phobias that I'm only just starting to get over, but I wouldn't say they've had any noticeable affect on my life.

The moral of the story? There is no moral to this story.

<comment><USER7> You really put it accurately. When I came to psychedelics I had expectations and excitement and stuff. It didn't turned out exactly as expected.

</comment></comment></comment><comment><USER8> I've never used illegal drugs, and I've never had a desire. However, the one problem we do have by keeping certain drugs illegal is that Americans are destroying countries, like Mexico, where a week doesn't by where a drug gang hasn't killed someone. Illegal drug money is used to finance so much corruption and killing, that there seems to be little value in keeping them illegal, especially considering that everyone who wants to take drugs still does. If certain drugs do have harmful effects then at least the effects will be mostly limited to the people who take them.

<comment><USER9> "Illegal drug money is used to finance so much corruption and killing, that there seems to be little value in keeping them illegal, especially considering that everyone who wants to take drugs still does. If certain drugs do have harmful effects then at least the effects will be mostly limited to the people who take them."

Mexico is already corrupt without the drugs. Making them legal will give the cartels even more power because they will now be able to legally sell drugs in the US.

They already have (and know how to run) multi-million dollar operations, you don't think they won't think about legally partnering up with companies in the US?

"If certain drugs do have harmful effects then at least the effects will be mostly limited to the people who take them."

Many people want government-run health care in the US. Legalizing illegal drugs will add to the already large amount of addicts. Do we really want more addicts in our hospitals? I also don't feel like I should be forced to pay for your poor life choices. Regular Drug users should immediately get a huge increase in healthcare costs.

We still have tons of people suing the cigarette companies because they cause cancer. I can only imagine how many lawsuits will be in our court systems if there is a company selling heroin.

<comment><USER10> Not to pile on, but:

> Many people want government-run health care in the US. Legalizing illegal > drugs will add to the already large amount of addicts. Do we really want > more addicts in our hospitals? I also don't feel like I should be forced to > pay for your poor life choices. Regular Drug users should immediately get a > huge increase in healthcare costs.

First, the fact that drugs are illegal has done nothing to make them difficult to get - I think most university students would agree they are about 3 text messages away from any drug they might want. People don't avoid drugs because they are illegal, they avoid them because they are concerned about addiction & health effects.

Second, addiction _is_ a public health issue, not a law and order issue. Do you know how expensive it is to imprison someone vs sending them to a rehab program? Take a look at Portugal - treating addiction like the health issue it is works and it's cheaper.

> We still have tons of people suing the cigarette companies because they > cause cancer. I can only imagine how many lawsuits will be in our court > systems if there is a company selling heroin.

I won't argue the premise but surely you would agree that a backed up court system beats DEA agents getting their heads blown off on a regular basis.

<comment><USER9> "Second, addiction is a public health issue, not a law and order issue. Do you know how expensive it is to imprison someone vs sending them to a rehab program? Take a look at Portugal - treating addiction like the health issue it is works and it's cheaper"

I looked, and I'm not surprised by the results:

[http://www.npr.org/2011/01/20/133086356/Mixed-Results-For- Po...](http://www.npr.org/2011/01/20/133086356/Mixed-Results-For-Portugals- Great-Drug-Experiment)

"Today, more users are in rehab, but drug use is on the rise, and reporter Keith O'Brien says the policy has made the problem worse."

"personal drug use over the course of their lifetime has gone up about 40 to 50 percent in the last decade."

Drug use is actually up...because there is no legal risk.

More from the article:

"They would meet with the person who had been picked up in possession of whatever drug it was and discuss the issue. These CDTs would then hand down various, sort of, not punishments, but treatments. Some people would, you know, be asked to enter counseling. Some people would be banned from, say, going to raves, if that's where they were doing their drugs; or banned from attending certain concerts or bars, if that's where they were doing drugs. And, you know, this is very controversial, even in Portugal, as you can imagine."

Do you really want the government telling you you can't go to a concert or rave?

I would really like to see the long-term numbers for Portugal. I predict they will be bankrupt within 15 years.

"I won't argue the premise but surely you would agree that a backed up court system beats DEA agents getting their heads blown off on a regular basis"

They still get their heads blown off for things like Vicodin (a legal form of heroin), so how will legalizing all drugs be any different?

"Take a look at Portugal - treating addiction like the health issue it is works and it's cheaper."

</comment></comment></comment></comment><comment><USER11> I wish that his article had delved more into the long term effects (benefits or otherwise) of taking psychedelic drugs rather than going off into a complaint about US drug policy.

Anyone got interesting, concrete data to share rather than anecdotes about Steve Jobs?

<comment><USER12> "Anyone got interesting, concrete data to share rather than anecdotes about Steve Jobs?"

Here are all of the Johns Hopkins studies on psilocybin:

<http://csp.org/psilocybin/>

You might also be interested in going to Horizons if you're going to be in NYC this coming weekend:

<http://www.horizonsnyc.org>

It's all of the talks on the latest scientific research on psychedelics for therapeutic use. You can also watch many of their previous talks here:

<http://vimeo.com/horizons>

As well as many of the talks from the huge MAPS conference that took place last April:

<http://www.maps.org/media/videos/>

If you're looking to read any books on this, a couple I'd recommend would be:

<http://www.amazon.com/exec/obidos/ASIN/1594774021/erowid-20>

<http://www.amazon.com/exec/obidos/ASIN/1594772509/erowid-20>

<http://www.amazon.com/exec/obidos/ASIN/0892819278/erowid-20>

I have an entire page with many more links to this stuff, but it's on Squidoo so if I linked to it then my comment would be auto-deleted. Heh.

edit: Changed Amazon links to donate affiliate fees to Erowid

<comment><USER13> All the studies I've seen either have to do with safety, perceived benefit (self-evaluated), or effect on attitude (openness) as measured by a survey. Do you know of any studies which identify an objectively measurable positive benefit to the subjets? For example: decreased risk of suicide, decreased risk of divorce, increased likelihood of solving a long-standing problem, increased success at work, etc.

<comment><USER12> "Do you know of any studies which identify an objectively measurable positive benefit to the subjets?"

Deciding whether something is objectively measurable or not has thousands of years worth of philosophical baggage, so I can't really say whether any of these will meet your definition, but for what it's worth:

\- Using LSD to treat alcoholism

\- Using ibogaine to treat opiate addiction: <http://vimeo.com/20118700>

\- Using psilocybin to treat smoking: <http://vimeo.com/15913255>

\- Self-evaluated life quality in psychedelic drug users vs. non-users: <http://www.maps.org/videos/source4/video12.html>

\- Using MDMA for PTSD: [http://www.oprah.com/health/PTSD-and-MDMA-Therapy- Medical-Us...](http://www.oprah.com/health/PTSD-and-MDMA-Therapy-Medical-Uses- of-Ecstasy/print/1)

\- Using LSD / Psilocybin for cluster headaches: <http://vimeo.com/10918637>

\- Using LSD for solving long-standing problems. (James Fadiman discusses this in his book that I linked to, and I think also here: <http://www.maps.org/videos/source4/video5.html.>)

<comment><USER13> Thank you for the response. Philosophical discussion aside, I think most of us can agree that there is a huge difference in reliability between self-reported results, and the more objective examples I mentioned.

I appreciate the videos, but I'm really looking for controlled studies. (In principle, I'm very open to the idea of using drugs like LSD for the treatment of things like alcoholism or cluster headaches. And I think it's a shame that, given the _relative_ degree of safety associated with these drugs, it's nearly impossible to legally runs such studies. But at the end of the day, there looks like a huge lack of evidence and I'm very skeptical.)

Thanks again.

<comment><USER12> "I appreciate the videos, but I'm really looking for controlled studies."

Here is the first of probably many controlled studies with 2-bromo-LSD for cluster headaches:

[http://news.sciencemag.org/sciencenow/2011/06/lsd- alleviates...](http://news.sciencemag.org/sciencenow/2011/06/lsd-alleviates- suicide-headaches.html)

The MDMA research on PTSD also has placebo controls. There are several different studies on this, you can probably find them via maps.org.

And James Fadiman writes about actual research done on problem solving in his book, although it isn't really possible to control since each person's long- standing problem is different.

<comment><USER13> Awesome, thanks!

> Cluster headache attack cessation and remission extension of months or > longer in six treatment-refractory patients administered only 3 doses of > BOL-148

> Five male patients with treatment-refractory chronic cluster headache and > one female patient with treatment-refractory mixed cluster/migrainous > headache were administered 2-bromo-LSD (BOL-148) (20mcg/kg) at five-day > intervals for a total of three treatments. Sixteen-week outcome data on the > five male patients revealed a robust treatment response, with three of the > five having no attacks for more than one month, thereby shifting their > diagnosis back to the episodic form of cluster headache. Similarly, the > female patient reported quiescence of cluster attacks for greater than one > month and "significant" improvement in migraine in the following weeks from > last dose of BOL-148. This poster presents longterm outcome data on all 6 > patients who received BOL-148. In follow-up with these patients, BOL-148 > provided significant headache relief that lasted for several months to more > than one-year. Data suggests that BOL-148 may function as an important new > treatment, though, at present, there is no explanation for such long-term > prophylactic effects with no later drug re-administrations. There is some > evidence that BOL-148 is affecting epigenetic mechanisms and may open the > possibility for a near-cure-like treatment for patients afflicted with > vascular headaches.

Incidentally, this is apparently a non-hallucinogenic analog of LSD.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> As a young man, I took psychedelics several times under the pretense of mind expansion. Looking back, I think the things I've read (and internalized), relationships I've had, and just generally "getting out of my comfort zone" had a more formative effect on my outlook than any chemicals.

If you want to use them, that's fine. But I would hate to think a young hacker reading this stuff felt like he _needed_ to use psychedelics.

The notion that dropping acid was one of the two or three most important things Steve Jobs had done in his life seems a bit...reality distorting.

</comment><comment><USER15> The apple logo itself could be taken as a symbol of accepting psychedelic insight. A bite of the forbidden apple.

When talking about Steve Jobs and LSD, we should consider the work of Myron Stolaroff and his associates. LSD can be used in anything from satanic orgies to mystical new age woo to CIA mind control experiments to creative technical problem solving. The branch of the psychedelic family tree SJ plucked his apple from is related to Myron Stolaroff's work on creative and technical problem solving.

Article by Myron Stolaroff on using psychedelics wisely: [http://www.erowid.org/psychoactives/writings/stolaroff_using...](http://www.erowid.org/psychoactives/writings/stolaroff_using.shtml)

Podcast featuring early psychedelic researcher James Fadiman "Using Psychedelics to solve technical and scientific problems" [http://beemp3.com/download.php?file=3226003&song=042-Fad...](http://beemp3.com/download.php?file=3226003&song=042-Fadiman+Using+Psychedelics+to+Solve+Technical+and+Scientific+Problems)

Article mostly about Al Hubbard (fascinating reading in it's own right), which connects Steve Jobs to Myron Stolaroff's advocacy of LSD among engineers and technologists: [http://kikoshouse.blogspot.com/2009/10/alfred-captain-al- hub...](http://kikoshouse.blogspot.com/2009/10/alfred-captain-al-hubbard- appreciation.html)

And finally, a 1960s study about LSD and creative problem solving (by Stolaroff, Fadiman, et al) "Psychedelic Agents in Creative Problem Solving: A pilot study" <http://www.erowid.org/references/texts/show/7609docid6734>

</comment><comment><USER16> Jobs was one of a kind, and to attribute his achievements even in part, to hallucinogens is a fallacy. If it was true, there would be more people like Steve Jobs in the world today.

I think Steve was wrong on this, as he was wrong on other things, i.e. that pancreatic cancer could be treated with a special diet. Maybe if Steve sought medical attention earlier he would still be with us today changing the world.

<comment><USER17> My dad died nine months after being diagnosed with Pancreatic Cancer, which was three months longer than expected. Steve Jobs died years later, after the Whipple Surgery and a liver transplant.

<comment><USER16> I'm sorry for you loss. Jobs had a rare type of pancreatic cancer, islet cell neuroendocrine tumour, which accounts for ~1.3% of cases. With early enough treatment, the prognosis for this type of cancer is much better than other types of pancreatic cancer.

<comment><USER17> Ah, didn't know that. Thanks.

</comment></comment></comment></comment><comment><USER18> Tim Ferris does a high dose of mushrooms (psilocybin) once a year. He says that each trip has had a major positive impact for several months and solved a major problem in his life.

<http://www.ustream.tv/recorded/17192634> @ 0:33:42

</comment><comment><USER19> Sam Harris on LSD:

[http://www.samharris.org/blog/item/drugs-and-the-meaning- of-...](http://www.samharris.org/blog/item/drugs-and-the-meaning-of-life/)

<comment><USER20> Great article. I've gone back to that thought "Everything we do is to alter our consciousness" since my first highs.

I went to a church for a concert recently and I was struck with the lengths these people went to in order to alter their consciousness without "drugs". Highly emotionally charged speakers work everyone up. Food and coffee are practically fetishized. There's a nice (albeit kind of unnatural/forced) sense of community that hits certain primal emotional triggers. So yeah, everyone's trying to altering their consciousness.

</comment></comment><comment><USER21> There might be some truth to Steve Jobs' view of LSD.

There have been studies that link psychedelics and aesthetics: [http://yourlife.usatoday.com/health/story/2011-09-29/Magic-m...](http://yourlife.usatoday.com/health/story/2011-09-29/Magic- mushroom-drug-may-improve-personality-long-term/50602264/1)

I'd say LSD is like steroids for artists/designers/creative people or Adderall/Ritalin for students. Sure it won't make you creative overnight but it will reaaalllly help, and it's kind of dangerous. Most of the danger comes from illegality, of course :)

It is just a lot easier to come up with new ideas when your mind is open and sketchbook seems to be a direct extension of your brain, where you can just 'think' ideas with pencil.

</comment><comment><USER4> _It's fascinating to juxtapose America's reverence for Steve Jobs' accomplishments and its draconian drug policy_

The author confuses American government policy with American citizens.

</comment><comment><USER22> Since this article brings up an LSD anecdote from Steve Jobs, I'll add one from someone who is not famous at all, but which I think is no less useful.

A few weeks ago, I spotted two men fighting outside of a bar. The older man got violently pushed to the ground, and I went up to him to see if he was okay, and ask him what had happened.

He rambled on for a while, telling me that dropping acid in the early 1970s was one of the most important experiences he had ever had. It put him in touch with a higher dimension, and he would sometimes receive messages from there. The reason people beat him up sometimes, he explained, was that he spoke the truth, directly as God sent it to him, and that people didn't like hearing the truth.

Make up your own mind about LSD, but try to take into account more than one data point!

</comment><comment><USER23> For anyone who is interested in the article, I strongly recommend reading "What the Dormouse Said" by John Markoff: <http://en.wikipedia.org/wiki/What_the_Dormouse_Said>

It's about how the counter-culture attitude of the 60s helped inspire the PC wave of innovation. Drug use is one of the core topics, but it is not romanticized. The book is very "matter of fact" in its analysis of how drugs were involved in the evolution of the PC.

</comment><comment><USER24> <http://homepage.mac.com/mseffie/handouts/hindsight.html>

<comment><USER25> and the relevance to this article is?

</comment></comment><comment><USER26> So is this the pattern we can expect for the coming months? HN posts titled "Steve Jobs and [insert my agenda here]"?

I realize when you want publicity for your cause, startup, whatever you tie it to something else that's in the news anyway but all these "Steve Jobs and X" posts are bordering on tacky or tasteless.

Although at least this isn't as bad as Stallman's truly tasteless rant.

</comment><comment><USER27> [edit because absurdity is apparently not obvious] By the author's logic,[/edit] perhaps people should consider putting their children up for adoption, too.

However, I suspect that moving to Silicon Valley would be more likely to provide them with opportunities for success.

<comment><USER28> The author's logic isn't "Steve Jobs took LSD, you should too", it's "Steve Jobs took LSD and credits it as a crucially important intellectual experience in his life, so maybe you should too." I'm pretty sure Jobs didn't say the same thing about being adopted.

<comment><USER27> The author's argument is more along the lines of:

      P1 = Steve Jobs was a success.
      P2 = Steve Jobs took LSD.
      </comment></comment></comment><comment>-
      Therefore US drug policy is bad.

</comment><comment><USER29> The article is all over the place and somewhat poorly written, but I generally agree with the overall premise before I even clicked the link: America's drug policy of prohibition is a waste of time, money and resources.

</comment><comment><USER30> Reminds me of Carl Sagan's musings on marijuana usage.

</comment><comment><USER25> Okay, so the article has some valid arguments. But why use Steve Jobs to make a point about drugs?

</comment><comment><USER31> Godwins law is tranforming to Jobs law. All discussions will lead to Steve Jobs.

<comment><USER11> Not really. This is little more than the media using Steve Jobs' death as a hook for whatever particular story they are writing or comment they wish to make. It too will pass.

</comment></comment><comment><USER32> I will never understand how HN manages to be so (maybe relatively) anti-drug, even in a latent fashion on this topic. I do, not, understand this sentiment. For all of the things that HN does not take at face value, there is a blind acceptance of the "drugs are evil" viewpoint espoused (often _exclusively_ in the face of _their own studies, dozens of times, over 20 years_ ) by the United States Government.

Downvote within 3 minutes, immediate comments touting how evil and unhealthy they are (which for the majority of lower level drugs are simply untrue, but you wouldn't know that unless you thought for yourself and read the literature).

Maybe I should clarify, there is an unusually large amount of effort that seems to be exuded in terms of keeping others from taking drugs, either through culture, pressure or laws than I am used to expecting on HN.

<comment><USER33> They may not be evil, but they aren't particularly good for you either

<comment><USER34> You could say the same about chocolate cake.

<comment><USER35> Sugar, you're right. Natural organic unsweetened dark chocolate "in moderation"? No concerns, antioxidant, aphrodisiac etc. pp.

</comment></comment></comment></comment><comment><USER36> RUMOUR: Apple to start selling iLSD.</comment>


Bitcore – A pure JavaScript Bitcoin API - <AUTHOR> http://bitcore.io

<comment><USER2> It's an exciting time to be a JavaScript developer for Bitcoin. There are a number of JavaScript libraries for Bitcoin. Here is a comprehensive list of alternatives to Bitcore:

\- [https://github.com/bitcoinjs/bitcoinjs- lib](https://github.com/bitcoinjs/bitcoinjs-lib) (one of the best)

\- [https://github.com/indutny/bcoin](https://github.com/indutny/bcoin) (Indutny's work is found throughout Node.js and is the basis of elliptic curve cryptography in Bitcore)

\- [https://github.com/ryanxcharles/fullnode](https://github.com/ryanxcharles/fullnode) (ex-developer of Bitcore and now engineer at Reddit behind Reddit's crypto currency initiative)

\- [http://cryptocoinjs.com/](http://cryptocoinjs.com/) (disclosure: I started this one)

Here is an older article that I wrote about understanding how an Address is created (still valid, but using an older version of bitcoinjs-lib): [http://procbits.com/2013/08/27/generating-a-bitcoin- address-...](http://procbits.com/2013/08/27/generating-a-bitcoin-address-with- javascript)

The cool thing is that you can use test Bitcoins without any risk to learn how to program for Bitcoin. Use these faucets: [http://tpfaucet.appspot.com/](http://tpfaucet.appspot.com/) and [http://faucet.xeno-genesis.com/](http://faucet.xeno-genesis.com/)

Here is a very simple wallet that I built to demonstrate how easy it is to build one: [https://github.com/coinbolt/simple- wallet](https://github.com/coinbolt/simple-wallet)

Finally, an open source app to test the purchasing experience of Bitcoin: [https://github.com/coinbolt/catshop](https://github.com/coinbolt/catshop)

<comment><USER3> Since you'd be the most likely person to know here, what javascript VM's will give you known-secure PRNG's, and which won't?

I think that's a pretty important thing to clarify if you're creating/signing transactions via JS.

<comment><USER4> A deterministic K is used in many of these libraries, so randomness isn't needed at the time of signing transactions. window.crypto and the Node.js crypto library are often used for private key generation.

</comment></comment></comment><comment><USER5> Looks awesome. Cryptocurrency development has seemed pretty intimidating to me but this is probably the going to be the push that gets me started supporting tip sharing features on my site.

<comment><USER6> Look into Coinbase's tip service: [https://www.coinbase.com/tip](https://www.coinbase.com/tip)

As well as ChangeTip: [https://www.changetip.com/](https://www.changetip.com/)

It might be what you're looking for, unless you want to custom build something. In that case also give Chain.com a look as well as Blockcypher.com.

Coinbase also has some nice developer products, their api: coinbase.com/docs/api/overview

and if you want to do anything relating to raw bitcoin data (the blockchain and all transactions) i.e., run a node, I'd recommend Toshi.io, an open-source node that is very easy to query. Quite a few people run this thing on an AWS tier.

Hope that helps if you want to dabble with a bitcoin project for your site :)

</comment></comment><comment><USER7> I am wondering if anyone has some thoughts on the security of this in a web- application? Storing the private keys in a database connected to one's web-app is just a bad idea right? So than it just becomes a proxy to the Bitcoind installation via JSON-RPC? Would it be considered safe to encrypt user's private keys via their password+hash+salt the same way I'm storing their passwords?

<comment><AUTHOR> Yep, storing your bitcoins in a plain web app is definitely a bad idea. The current trend in the bitcoin space is a mixture of:

* Discouraging the use of the webapp (if any available) in favor of a browser application (chrome app, firefox app, etc)

* 2 factor auth to login

* Bitcoin "multisig" transactions: require at least N out of M valid private keys (allowing the storage of these keys to be on different devices/services/media) before releasing funds

And of course encryption before storage.

</comment></comment><comment><USER8> Core Bitcoin: [https://github.com/oleganza/CoreBitcoin](https://github.com/oleganza/CoreBitcoin)

Bitcoin Core: [https://github.com/bitcoin/bitcoin](https://github.com/bitcoin/bitcoin)

Now it is Bitcore. Project names are hardly distinguishable, feels kind of messy.

</comment><comment><USER9> Awesome project. Hopefully nobody makes anything serious using it in the browser.

</comment><comment><USER10> This looks very well done! Starred on github :)

</comment><comment><USER11> This looks more like a library than an API. I wonder why the decision was made to market it this way.

<comment><USER12> All libraries expose an API, which is its set of public functions.

<comment><USER11> Sure but it seems strange way to discuss it. Unless it's an API that wraps some existing library.

<comment><USER10> I believe haakon is correct on this one, unless I'm missing something. We just got into an argument at my work over the correct usage of the term "api", but found this post to back up my arguments - [http://stackoverflow.com/questions/8772746/difference- betwee...](http://stackoverflow.com/questions/8772746/difference-between- framework-vs-library-vs-ide-vs-api-vs-sdk-vs-toolkits)

Anyway, I'm not trying to nitpick or keep this side-discussion alive. But I'm genuinely curious how most people classify the difference between api and library.

Also on a sidenote, who's downvoting all the comments and the thread itself? This seems like a really cool project and it doesn't look like anyone's posted anything completely irrelevant here.

<comment><USER13> > Also on a sidenote, who's downvoting all the comments and the thread itself? > This seems like a really cool project and it doesn't look like anyone's > posted anything completely irrelevant here.

Who else? Bitcoin haters and deniers like patio11. Such kinds of irrational and emotional people are everywhere, including HN. Keep in mind they can be good and logical at other things, but get emotional on one particular subject. Bitcoin shakes some of the foundations everyone on Earth has or has had at some point (like the concept of money, the justifications for inflation, etc.), and a lot of people don't like change.

<comment><USER14> > Bitcoin shakes some of the foundations everyone on Earth has or has had at > some point

really now...

> like the concept of money

Bitcoin is still money (which I would describe as a proxy for value with latency built in).

> the justifications for inflation

Other than eventually running out and deflating (probably a problem in it's own way), bitcoin doesn't address this problem.

What is bitcoin going to do to address fractional reserve banking, debt slavery, information asymmetry (insider trading), financial chicanery (selling debt-based products/toxic assets), which I would argue are bigger problems built into money as we know it. Nada that I'm aware of.

Why is bitcoin even less anonymous than traditional currency?

Why is it even more inequal (who has bitcoin? wealthy, technologically literate citizens of the first world) than traditional currency?

I agree that money sucks but bitcoin is hardly the solution we need.

</comment></comment></comment></comment></comment></comment><comment><USER15> Looks like they built their NSA spy module out of coffeescript, neato

<comment><USER16> Huh?

<comment><USER15> In today's climate I would be extremely weary of npm installing any core bitcoin tech without a serious line by line audit of the source.

<comment><USER17> Why would this be more true of npm than any other package manager for any scripting language?

<comment><USER18> I would guess his paranoia is more general than directed at npm directly. However, it's a fair point that NPM allows anyone to push projects with no oversight, whereas many other package manager inventories are maintained and curated.

</comment></comment></comment></comment></comment><comment><USER19> I have a question about bitcoin in general - how do transactions on the network get verified? Does it mostly happen through miners? If so, what happens when mining reaches the point where it becomes economically worthless to everyone except a few electricity thieves? Will there just be a massive backlog of unprocessed transactions?

Unless I'm wrong somehow, I could see this becoming especially problematic as bitcoin becomes more popular and the daily transaction volume grows. How does the bitcoin foundation/community plan to tackle this issue?

<comment><USER20> This is clearly not the place to ask this question about mining. This is a thread about a software development on a whole different side of Bitcoin. If you are genuinely curious about the theme of your question, and not just interested in derailing threads, you are very welcome to educate yourself at bitcointalk, the main Bitcoin forum. There have been thousands -if not millions- of man hours in thinking, development, research and debate about the topics you enquire about. Head there and find the answers, and if still in doubt don't be afraid to ask (on an appropriate thread).</comment></comment>


Callbacks as our Generation's Goto Statement - <AUTHOR> http://tirania.org/blog/archive/2013/Aug-15.html <comment><USER5> "Await" is fantastic, and having using it for JavaScript (via TameJS and then IcedCoffeeScript), it makes things a lot easier and clearer.

That being said, I don't think the comparison between callbacks and goto is valid.

"Goto" allows you to create horrible spaghetti-code programs, and getting rid of it forces you to structure your programs better.

"Await", fundamentally, isn't really anything more than syntactic sugar (except for exception handling, which is a good thing). "Await" doesn't change how your program is structured at all, it just changes the _visual_ representation of your code -- from indentations in a non-linear order, to vertical and linear order. It's definitely a nice improvement, and makes code easier to understand (and allows for better exception handling), but it's not actually changing the way your program is fundamentally structured.

And finally, "await" is only applicable when a single callback gets called once at the end. If you're passing a callback that gets used repeatedly (a sorting function, for example), then normal-style callbacks are still necessary, and not harmful at all. Sometimes they can be short lambdas, sometimes they're necessarily much larger.

In sum: "await" is great, but there's nothing inherently harmful about callbacks, the way "goto" is. To the contrary -- callbacks are amazingly useful, and amazingly powerful in languages like JavaScript. "Await" just makes them nicer.

<comment><USER6> You're missing the point of `await`.

Await _does_ change how your program is structured, unless we're talking about most trivial cases.

You can use `await` inside a `for` loop—can you do the same with callbacks without significantly re-structuring your code?

What is the "callback analog" of placing something in a `finally` block that executes no matter which callback in a nested chain fails? You'd have to repeat that code.

Await has a potential of simplifying the structure a lot, because it befriends asynchronous operations with control flow.

>And finally, "await" is only applicable when a single callback gets called once at the end. If you're passing a callback that gets used repeatedly (a sorting function, for example), then normal-style callbacks are still necessary, and not harmful at all.

Indeed, await is only for the cases when we abuse functions (because we don't know what we'll call, and we have to bend our minds). Passing the sorting comparator is the primary _use_ of first-class functions.

<comment><USER5> I'm not disagreeing with you at all.

I guess we're using "structured" in different ways. Libraries like TameJS _do_ wind up creating structures to deal with for loops, in the same way you'd otherwise manually have to deal with. Likewise with exceptions (which I said are the main actual benefit to await, that can't be reproduced in normal callback routines).

You obviously have to write a bunch of "plumbing" code to do with "raw" callbacks, in complicated situations (like loops), which "await" does on its own -- and writing that plumbing is annoying, although there are libraries to help.

My only point is, the fundamental structure of your program, on a _conceptual_ level, is still the same. Everything's still running the same way, in the same order. It's just more concise, with less plumbing of your own, using "await". So the _micro_ structure is different with await, but the high-level structure is no different. You can't "abuse" callbacks in the way you can abuse goto. Maybe I should have made that clearer.

<comment><USER6> I see your point. Closures also don't affect structure on conceptual level, but I think they're pretty darn useful. By the way, async _can_ affect things on conceptual level if you embrace[1] it (I posted this link somewhere below as well, but just in case you haven't seen it).

[1]: [http://praeclarum.org/post/45277337108/await-in-the-land- of-...](http://praeclarum.org/post/45277337108/await-in-the-land-of-ios- scripting-users)

</comment></comment></comment></comment><comment><USER7> Yes a thousand million times. This is the reason why people love golang and why there's a lot of excitement about core.async in the Clojure community, particularly for ClojureScript where we can target the last 11 years of client web browser sans callback hell:

[http://swannodette.github.io/2013/07/12/communicating- sequen...](http://swannodette.github.io/2013/07/12/communicating-sequential- processes/)

Having spent some time with ClojureScript core.async I believe the CSP model actually has a leg up on task based C# F# style async/await. We can do both Rx style event stream processing and async task coordination under the same conceptual framework.

<comment><USER8> Yeah, C# await/async is cool. But isn't Google Go's approach nicer? Keep standard lib calls blocking as is, and use the "go" statement when you want to run something async? It avoids all the extra DoWhateverAsync() API functions. See [http://stackoverflow.com/a/7480033/68707](http://stackoverflow.com/a/7480033/68707)

What's the Go equivalent of "await"? I.e., like the "go" statement but asynchronously wait for the function to return and get its value?

<comment><USER9>
      ci := make(chan int)
      go func(ci)
      <-ci

<comment><USER10> If you're using `ci` as just a semaphore, you should use a struct, since those use even less memory than an int in go.

</comment></comment></comment></comment><comment><USER11> You get a similar interface in Python's Twisted using the @inlineCallbacks decorator:

        @inlineCallbacks
        def example():
            try:
                obtain_some_lock()
                ui_status("Fetching file...")
                result = yield fetch_file_from_server(args)
                ui_status("Uploading file...")
                yield post_file_to_other_server(result)
                ui_status("Done.")
            except SomeError as e:
                ui_status("Error: %s" % e.msg)
            finally:
                release_some_lock()

I must say that this style of writing async code is much friendlier than descending into callback hell.

There is work to make a similar async interface native in Python 3, in PEP 3156 [http://www.python.org/dev/peps/pep-3156/](http://www.python.org/dev/peps/pep-3156/), so this should become more widely available even to those who don't use Twisted.

<comment><USER12> Yes! I really hope this use of yield will bubble up to the language spec and become pervasive in Python. It really strikes me as the Pythonic approach to solving callback hell.

<comment><USER13> > Yes! I really hope this use of yield will bubble up to the language spec and > become pervasive in Python.

And the time machine spaketh: [http://www.python.org/dev/peps/pep-3156/#coroutines-and- the-...](http://www.python.org/dev/peps/pep-3156/#coroutines-and-the- scheduler)

(it has no reason to "bubble up to the language spec", the language provides all the right primitives — especially with Python 3's `yield from`, it's up to the libraries to use them. That is a Good Thing.)

<comment><USER12> Good point. Bubble up to the standard library, then.

</comment></comment></comment></comment><comment><USER14> I'm not buying the c# async/await kool-aid.

Async, sure, I'm down with that, but I've used the c# async stuff now, and while it makes it the app somewhat faster, it has three major downsides (that I encountered):

\- Infects everything; suddenly your whole application has to be async.

\- Debugging becomes a massive headache, because you end up in weird situations where the request has completed before some async operation completes, the debugger gets scared and stops working.

\- It's really hard to test properly.

The only good reason for using it is that because of the infection-property back fitting async to your application is a major headache; if you might use it, you have to use it from the beginning or you get a huge backlog of refactoring and test fixes to do.

-___- 'I might use this for some performance bottleneck I don't yet know about, so better start using it now...' yeah, that's a thing: premature optimization.

<comment><USER15> But doing things by hand with callbacks is going to have all of those same issues isnt it? If you dont want to infect everything then you basically need to just write synchronous code instead...

<comment><USER16> The issue I see is that with some libraries you either go 100% async or 100% sync with no middle ground.

<comment><USER6> This is simply not true. You can use any C# library without using async (code rewriter). You'd still be using Tasks but there is nothing special about them (no compiler magic). They're just futures on which you can schedule continuations.

<comment><USER16> I'm not talking about C#, but about libraries in other languages that support async behaviour

<comment><USER17> PDFJS--the PDF reading package from Mozilla--is a gross offender in this regard; the mix of sync and async, and the somewhat arbitrary nature of which is which, is pretty annoying.

</comment></comment></comment></comment></comment></comment><comment><USER18> As someone who only recently switched to Node.js from PHP I personally haven't had any difficulty switching over to the callback frame of mind, and I haven't experienced the "callback hell" so many people complain about. At first I was hesitant to start with Node because I saw blog posts by people bemoaning the spaghetti callback code that they ended up with. But I haven't experienced any of that, although I am a relatively newbie Node programmer with only a few months of experience so far. My current project is quite non trivial as well, running into the tens of thousands of lines so far.

The key I've discovered to nicely organizing callbacks is to avoid anonymous callback functions unless absolutely necessary for a particular scope, or unless the function is going to be so trivial and short that it can be read in a single glance. By passing all longer, non trivial callback functions in by name you can break a task up into clear functional components, and then have all the asynchronous flow magic happen in one concise place where it is easy to determine the flow by looking at the async structure and the function names for each callback function.

Another major advantage to a code organization like this is that once you have your code such that each step has it's own discrete function instead of being some inception style anonymous function tucked away inside another function inside another callback it allows you to properly unit test individual functional steps to ensure that not only is your code working and bug free at the top level functions, but also that each of the individual asynchronous steps that may make up some of your more complicated logic are working properly.

Most of the bad examples of callback hell that I see have anonymous callback functions inside anonymous callback functions, often many levels deep. Of course that is going to be a nightmare to maintain and debug. Callbacks are not the problem though. Badly organized and written code is the problem. Callbacks allow you to write nightmarish code, but they also allow you to write some really beautiful and maintainable code if you use them properly.

<comment><USER19> I often write synchronous methods that include control flow that nests three deep (say try/finally, if/then/else, and a for loop). Often it's easier to read this code than it would be if everything were split out into separate named methods.

Why would the same not be true of asynchronous methods, assuming that the technology was there to enable it (as it is in C#)?

<comment><USER20> _> Often it's easier to read this code than it would be if everything were split out into separate named methods._

This might actually be a shortcoming of our code organization/reading tools.

<comment><USER15> Why should that be the case? Creating all the extra methods is going to create lots of new points of indirection, the new methods are likely to be tightly coupled anyway and breaking the nesting might mean you have to hoist a bunch of variables into an outer scope.

<comment><USER20> Exercise: list all of the implicit assumptions about how code organizing and reading tools have to work from those two sentences.

</comment></comment></comment></comment></comment><comment><USER21> Anonymous Callbacks != Callbacks

Callbacks have been around forever in C using named functions, and are not specific to either the current generation of programming languages or programmers. One can still use a _named function_ instead of a locally constructed lambda to represent a callback in a high level languages.

The primary difference is that when declaring named functions non-locally, one must explicitly share state through the parameter rather than implicitly sharing state through lexical scoping. It seems more accurate to label the problem of nesting lambdas to the point of ambiguity as "Lambda Abuse" or "Lexical Scoping Abuse" rather than "Callback Hell".

<comment><USER22> Not totally, the problem being described as "Callback Hell" is in my experience: non-locality of code. Things that relate to one another should be spatially together for a programmer to write, read, understand- and NOT split into success and error conditions around the axis of final callback.

Even with named functions, this is the problem- right? You pass in a named callback and you have to find that function later when you're debugging to figure out what's going on. Locality of code means no breaking context to find something not already on screen and therefore easier programming.

</comment></comment><comment><USER23> The problem is simply that those languages are not Lisp.

Once good patterns of use of GOTO were found, it was natural to critisize random uses, and to wrap good uses in a lisp macro. Or in a new while or for "instruction".

But then the next construct is discovered, and its bad uses considered harmful, and its good uses need to be wrapped. In lisp, mere programmers will just write the next macro to abstract away this new construct. Other programming languages need to evolve or have new language invented with new "instructions".

So now it's the callbacks. Yes, in lisp we'd just use closures, but this is only a building block for higher level constructs. If those "callbacks" are needed to represent futures, then we'd implement those futures, as a mere lisp macro.

Yes, in the other languages you're still powerless, and need to wait for the language designers to feel the pressure and implement a new "future" instruction or whatever.

Any language construct can be considered harmful eventually. Concretely, a repeative use is a hint of that: the construct becomes meaningless because it's used all the time, or apparently randomly (just like those GOTOs). But it's not that the construct is bad, it's that its usage is not abstracted away in higher level constructs. And the only way to do that is lisp macros.

So unless you're programming in lisp (a homoiconic programming language that let you write easily macros in the language itself), you will always reach a point where some construct will be able to be considered harmful for lack of a way to abstract its uses away.

<comment><USER24> Ah, but the real problem is not that these languages aren't Lisp, but that they aren't Scheme. People are being forced to write continuation-passing- style code by hand, which anyone would agree is painful. To allow _user-level code_ to abstract away the need to write CPS, you need call/cc (or something like it).

<comment><USER23> You would never use call/cc directly. Like goto, it is a building block to be used in control abtraction macros.

<comment><USER15> Yes. The point is that while the idea of continuations exists, no one should be forced to write continuation-passing-style code by hand!

</comment></comment></comment></comment><comment><USER6> There is some creative use of C# async/await in this blogpost:

[http://praeclarum.org/post/45277337108/await-in-the-land- of-...](http://praeclarum.org/post/45277337108/await-in-the-land-of-ios- scripting-users)

Basically, the author implements a "first time walkthrough" kind of interface a-la iWork very declaratively by using async:

        	async Task ShowTheUserHowToSearch ()
        	{
      		await Tutorial.EnterText (searchField, minLength: 3);
      		await Tutorial.Tap (searchButton);
      		await Tutorial.Congratulate ("Now you know how to search.");
      	}

<comment><USER25> What if you have two buttons, search and 'be lucky'? I guess you will have to await for a controller object that wakes up that if either one of the buttons is triggered, and then test what button was pressed.

Now what if you have add a search option dialog that can be invoked at any moment? I guess when the 'apply' button of the option dialog got pressed then this is still going to be a callback that sets global variables according to search option.

So, like any mechanism, this way of structuring code has its limits. If an event can happen at any stage of the flow, then this still has to be handled by a callback, otherwise you would have to check for this kind of event after each await clause.

<comment><USER26> "What if you have two buttons, search and 'be lucky'? I guess you will have to await for a controller object that wakes up that if either one of the buttons is triggered, and then test what button was pressed."

[http://msdn.microsoft.com/en- us/library/hh194796.aspx](http://msdn.microsoft.com/en- us/library/hh194796.aspx)

<comment><USER25> ... select or WaitForMultipleObjects in another form

</comment></comment></comment></comment><comment><USER27> I agree, although I think callbacks are more like COME FROM than goto. You see a function being passed somewhere as a callback, and you know the block is going to execute at some point, but most of the time you have no idea what the codepath that calls you back looks like.

There's nothing more frustrating than trying to debug why a callback isn't being called. Who calls it? How do I set a breakpoint somewhere to see why it isn't being called? etc.

The one thing that is still missing from await and other green thread approaches is cheap global contexts. Isolating every different green thread so they can't implicitly share state is the obvious next step.

<comment><USER28> Have you looked at the Erlang model? Each Erlang process (green thread) only gets the arguments initially passed in and whatever else it asks for from other running processes. The only shared state is long-running processes created for the purpose of explicitly sharing state.

<comment><USER27> Yep. The Actor model that Erlang uses is exactly what I was referring to being missing from green thread libraries for other languages (C#, python with greenlet or generators, js with generators)

</comment></comment></comment><comment><USER29> I generally agree that there are better ways to handle asynchronous control flow than callbacks, but I think this is exaggerated. As in most posts like this, the callback soup examples are difficult to follow primarily because they are horribly written, not because of callbacks.

As long as you write decent code, the main impediment to asynchronous programming is reasoning asynchronously, not syntax. If you require complex asynchronous logic and don't use an appropriate algorithm, you'll end up in the muck whether you use callbacks or await.

Taking go as an example: while I agree that the go statement is more elegant than a callback approach, I see it as quite a minor win compared to channels. The go statement is convenient syntax, but channels are what make concurrency in go feel so robust, and it's a pattern than can be applied just as well in a language that uses callbacks.

</comment><comment> ryan-allen I don't understand what the big deal is. Callbacks are OK. They're less cumbersome if the language you're using has smaller function definitions.

Callbacks 'get crazy' when you've got more than one I think, and thankfully someone smart has made a library you can use to manage them!

[https://github.com/caolan/async](https://github.com/caolan/async)

Saying that, I don't mind the way things look with the whole await/async stuff in C# and etc. However I don't think we should be waving our arms around saying callbacks are like goto, they so completely are not! I have written heaps of stuff with callbacks and it's _not that confusing or unmaintainable_. It's just different.

<comment><USER6> How do you do this with callbacks?

        foreach (var player in players) {
            while (true) {
               var name = await Ask("What's your name");
               if (IsValidName(name)) {
                   player.name = name;
                   break;
               }
            }
        }

Assuming `Ask` is an asynchronous operation and must not block the UI thread.

Note that second player is only asked _after_ the first player has given a valid name.

(And the code structure reflects that :-)

My point is of course it's _doable_ with callbacks, but I spent more time indenting this code than writing it, and I darn well know _I_ 'm not smart enough to spell out the correct callback-style code in a comment field on Hacker News. And if I suddenly had to add error handling...

<comment><USER30>
      for player in players
    	get_name_for = (player) ->
    		ask "what's your name?", (response) ->
    			if is_valid_name response
    				player.name = response
    			else get_name_for player
    	get_name_for player

<comment><USER31> This looks like it does the wrong thing. If "ask" gets to access the scheduler's task list as a queue, then entering an invalid name in the first response and only valid names thereafter will cause the first valid name to be given to the second player, the second valid name to the third player, and so on. If "ask" gets to access the scheduler's task list as a stack, then a sequence of only valid input names will cause the last player to have the first input name, the second-last player to have the second input name, and so on.

Edit: I was optimistically assuming that the consumer of the many "asks" that are created all at once would process them sequentially, dealing with one and invoking the callback before dealing with the next. If you do not assume this, my problem disappears and you get the simpler problem of spawning many prompts simultaneously.

<comment><USER30> Hmm, I wrote it so that the function closes over the player, so that shouldn't happen. The real issue is, as pointed out, that this will ask for all the names at once, rather than sequentially. Wether this is bad or not depends on how the `ask` function gets its input.

</comment></comment></comment></comment></comment><comment><USER32> Holy Baader-Meinhof, just today, in frustration, I wrote something like Haskell's sequence_ for ContT, in Javascript:

[https://gist.github.com/cscheid/6241817](https://gist.github.com/cscheid/6241817)

<comment><USER33> Why do you as an American feel the need to invoke some dead german left-wing militants in a pseudo-religious phrase that's meaningless except maybe for shock value? This seems highly inapproriate for any website and even more so on HN.

<comment><USER32> (for whatever's worth, I'm Brazilian)

<comment><USER34> Aren't you still American? ;)

As an Indian I am confused why only people of the US are called Amerians while two entire continents are called America.

And also, why we Indians are not considered Asians by the said Americans.

<comment><USER35> Because "America" is part of the nation's actual name, and the only part that isn't a modifier. What else could you call Americans? Unionized Statists?

<comment><USER36> I actually use the term "USian" quite frequently, but then I'm weird that way.

</comment></comment></comment></comment></comment></comment><comment><USER37> (C/OS developer spiel)

I'm sick of these app developers assuming that using "goto" is bad practice. The fact is that "goto" is used plenty in great production code you're probably running right now.[1] I'd like to know a cleaner way to abort a function into its cleanup phase when a function call returns an error. And "goto" statements are extremely simple to handle for even the most naive of compilers.

[1] [https://www.kernel.org/doc/Documentation/CodingStyle](https://www.kernel.org/doc/Documentation/CodingStyle) (see chapter 7)

<comment><USER38> Exceptions

<comment><USER39> Not terribly plausible in kernel code.

<comment><USER38> Not all kernels are UNIX.

<comment><USER37> I didn't know UNIX won't allow kernel exception handling. Source?

Of course exceptions are suboptimal; bad performance compared to "goto" can have unintended side effects depending upon the OS (scheduling work may be triggered off of the additional interrupt).

<comment><USER38> > I didn't know UNIX won't allow kernel exception handling. Source?

My statement was based on ideology as I doubt typical UNIX kernel coders would ever allow for exceptions, given that C does not support them and is against the UNIX way.

> Of course exceptions are suboptimal; bad performance compared to "goto" can > have unintended side effects depending upon the OS (scheduling work may be > triggered off of the additional interrupt).

Exceptions at the kernel level are possible, Windows does it for certain classes of errors, for example.

Some other commercial or research kernels might do it as well.

</comment></comment></comment></comment></comment></comment><comment><USER40> Evan Czaplicki (author of Elm lang) made the identical argument (sometime?/years ago), with the same reference to Dijkstra's quote, but with another suggested solution, Functional Reactive Programming, on which his language is oriented:

[http://elm-lang.org/learn/Escape-from-Callback-Hell.elm](http://elm- lang.org/learn/Escape-from-Callback-Hell.elm)

<comment><USER41> HN discussion of that article: [https://news.ycombinator.com/item?id=4732924](https://news.ycombinator.com/item?id=4732924)

FRP is an interesting topic (I thought so anyway, I wrote a paper on it for my MS). It doesn't seem to have caught on widely as a paradigm, with a few exceptions I'm aware of (Elm, Meteor).

<comment><USER42> Rx (for C#), RxJS (for Javascript), Bacon.js.

Definitely not 'widely' but there are a few library implementations out there.

I reckon that the reason for this is that it's most useful when the interactivity is high (i.e. there are a lot of events to react to), but most applications (desktop, web) don't have a high enough number of events to make learning a new paradigm 'worthwhile'.

</comment></comment></comment><comment><USER43> I was pleasantly suprised that catoverflow is an actual site.

</comment><comment><USER44> Anonymous callbacks are very powerful and very important. They will make you feel bad for unnecessary nesting. They will force you to learn how to abstract better, especially state changes. They will show you how nice and reliable code can be if it doesn't have shared states across multiple functions and how easy it is to understand consistent code with explicit continuations and how to write one yourself. They will make you a better programmer.

And "await" can only make it harder to visually distinguish which piece of code is executed in parallel and which is executed sequentially. Nesting makes it explicit.

</comment><comment><USER45> Why do people insist on analysing things using analogies? Analogies are useful for explaining a concept that might not be obvious. Saying callbacks are like gotos, gotos are bad, therefore callbacks are bad is ridiculous.

And he gives some sample code where the 'problem' is nothing to do with callbacks, its just nested lambdas. In fact I find that code quite easy to read, and would be very interested in seeing the same functionality implemented some other way, bearing in mind it is quite a difficult problem to synchronize multiple async operations and usually requires horrible code using multiple mutex.

<comment><USER46> I'm confused as to why you think the code presented in the blog post isn't an example of 'the same functionality implemented some other way'. The await code is almost undeniably more straightforward and the exceptional cases more obvious to handle.

He also doesn't seem to be making a weird logical leap the way you claim he is. He's not really using an analogy. He's saying callbacks are bad _the same way_ goto is bad, in that they make the logical structure of a program's execution non-obvious, particularly over time and when being modified.

<comment><USER45> I'm not saying the await syntax isn't useful or a better way to implement that problem. The title and opening of the article is comparing callbacks with gotos. It would be logical if he titled the article "C# Await syntax trumps callbacks when multiple callbacks need to be synchronised".

Any syntax can be used to create spaghetti code. Callbacks only become spaghetti like when nested / chained / abused. I've written hundreds of API methods using callbacks that I believe are very clean. I've recently written a large API which makes async service calls that follows this pattern :

void GetInvoiceHistory(int? customerId, Action<List<InvoiceItem>> callback, Action<string, Exception> exceptionCallback);

The consumer of this API does not need await, there is no need to nest callbacks, there is no need for try/catch and it is very clean to work with. So IMHO, stating that callbacks are this generation's gotos is a pile of shit.

</comment></comment></comment><comment><USER47> This definitely is a problem in Obj-C. Using GCD and callbacks is usually easier to understand than delegates and manual thread management, but it's still not great. I would love to see something like async/await in Obj-C. There are some great ideas on how to get something similar in this blogpost, but none that I would use in production code unfortunately: [http://overooped.com/post/41803252527/methods-of- concurrency](http://overooped.com/post/41803252527/methods-of-concurrency)

</comment><comment><USER48> It's right that callback model sucks, and the _task_ model is a way to go.

      Sadly, many developers when they hear the word "C# async"
      ...
      All of these statements are made by people that have yet
      to study C# async or to grasp what it does.

But it's unpleasant to see the author is talking concept of task - <USER2> threading, coroutine, or whatever - is like a patent of C# (or F#). And furthermore, treating _many developers_ are not able to understand this concept.

Maybe true for the people around him.

I understand his position as a lead developer and an evangelist of Mono/C#, but this attitude is ridiculous.

<comment><USER6> Have you read the article? It's not about tasks per se, it's about a code rewriter.

<comment><USER48> This article is about structural paradigm shift which foresaw for a long time from Actor model, Erlang, and recently to Go and Rust.

How is this just only an introduction to a new syntactic sugar?

</comment></comment></comment><comment><USER49> ES6 generators combined with promises will bring this to the javascripters: [http://taskjs.org/](http://taskjs.org/)

</comment><comment><USER50> In the right places and for the right reasons they are fine. A lot of code today devolves into what I've come to call "callback spaghetti" and, well, good luck. The toughest thing sometimes is getting your mind around what is supposed to happen and, more importantly, what is not.

I found that sometimes it helps to build a state machine to effectively run the show and try to limit callbacks to setting flags and/or navigating the state tree. State machines make following code functionality a breeze, even when dealing with really complex logic.

<comment><USER6> That's a smooth point! As you probably know, async code is translated by C# compiler to a state machine[1].

[1]: [http://stackoverflow.com/a/4047607/458193](http://stackoverflow.com/a/4047607/458193)

</comment></comment><comment><USER51> Yup yup yup. I thought I was the only one who noticed that node had reinvented the Windows 3.1 programming loop.

<comment><USER52> Windows 3.0 had it before Windows 3.1.

</comment></comment><comment><USER53> Callbacks are basically COME FROM, epecially on a platform like a cell phone where you at least in theory have limited processing resources ($40 android phones need apps, too!). They are the devil.

<comment><USER54> > Callbacks are basically COME FROM

No, they aren't even similar to COME FROM. COME FROM is "upon reaching label X, jump to this point". Callbacks have _less_ in common with COME FROM than with GOTO, and less in common with GOTO than with normal procedure/function invocation.

> epecially on a platform like a cell phone where you at least in theory have > limited processing resources

Platform is completely orthogonal to the relation between callbacks and other programming constructs.

<comment><USER53> I see your point, but they read a lot like come from when looking at code.

And platform is not orthogonal: sometimes I need to know exactly what is using how many cpu cycles, and callbacks make it hard.

Admittedly I mostly do embedded dev, but there's a reason why I have the only remote control / video app out there that still works on a HT G1 :)

</comment></comment></comment><comment><USER55> iced-coffee-script has a similar solution. [http://maxtaco.github.io/coffee- script/](http://maxtaco.github.io/coffee-script/)

<comment><USER56> Iced Coffeescript is brilliant! I think it is the closest you can get right now to sane development with callback-oriented code in Javascript.

Unfortunately it doens't solve the exception problem yet. Exceptions passed to callbacks (as `(err, value)`) are not thrown. So instead of try/catch there will be lots of `return cb(err) if err` in your code.

</comment></comment><comment><USER57> I was expecting to read something about FRP or other naturally reactive programming models that dealt with the semantic complexity of callbacks, not just their syntactic complexity. I don't think async constructs and others that depend on CPS techniques are really going to save us from complex programs that we barely understand.

</comment><comment><USER58> Meh.

Callbacks are a very limited way to do asynchronous programming. However they are a good way to create interfaces that let you call methods and insert your own functionality in the middle.

So yes. Better async is good. But don't take away callbacks. They have their uses.

</comment><comment><USER59> lthread is a coroutine library that allows you to make blocking calls inside coroutines by surrounding the blocking code with lthread_compute_begin() and lthread_compute_end(). This is equivalent to async calls but without the need to capture variables.

[http://github.com/halayli/lthread/](http://github.com/halayli/lthread/)

Disclaimer: lthread author

</comment><comment><USER60> Instead of using callbacks, golang embraces synchronous-style calls and makes them asynchronous by switching between goroutines (lightweight threads). gevent (for Python) does something similar. It's certainly an interesting approach IMO.

</comment><comment><USER61> I noticed that most of the methods awaited on had an Async suffix in their name. Is that some sort of modern hungarian notation, and is it even necessary? It also looks like you can't pass timeouts to await.

<comment><USER62> The Async suffix is here to differentiate with the synchronous version of an existing method returning T, the asynchronous return a Task<T>. With a Task<> you can do :

      int timeout = 1000;
      var task = SomeOperationAsync();
      if (await Task.WhenAny(task, Task.Delay(timeout)) == task) {
          // task completed within timeout
      } else {
          // timeout logic
      }

<comment><USER61> According to the Microsoft doc[1] it is convention for async to return a Task but not a requirement. Since the return type of Task tells you a method is expected to be used asynchronously, also encoding that in the name seems somewhat redundant. I guess you have to use a different name because of static typing so Async is as good a suffix as any.

[1] [http://msdn.microsoft.com/en- us/library/vstudio/hh156528.asp...](http://msdn.microsoft.com/en- us/library/vstudio/hh156528.aspx)

</comment></comment></comment><comment><USER63> This is all simply sugar to hide behind-the-scenes threading behind very narrow interfaces. Which isn't necessarily bad, but it's fun to see it suddenly in favour again and presented as something new.

E.g. Simula67 had Call and Detach for the basic case, and Activate(object representing async behaviour) and Wait(queue) that would both depending on need often be used for the same purpose (as well as a number of other operations). We had to write code using those methods in Simula67 in my introduction to programming class first semester at university...

<comment><USER64> That was my thought. I always get lost in these discussions because I have to translate the bizarre lingo into basic threading primitives I can understand. Once I've done that I don't understand what all the fuss is about.

<comment><USER63> I think the issue is that most programmers actually _never_ touch threading, or if they do, they get complicated threading models shoved in their faces and run away in horror (which is a reasonable reaction). But these constructs looks sort-of like they're just wrappers around callbacks.

Never mind that the only reason callbacks are all that interesting in JS is because they allow the engine to sneak in threading behind your back - <USER3> people have a very woolly idea about how JS execution happens and the fact the javascript execution itself isn't threaded.

</comment></comment></comment><comment><USER65> You can write any article like this about anything, here is the formula:

\- pick a language feature

\- write an article with the title "<language feature> as our Generation's Goto Statement"

\- write an example where you misuse <language feature> and over generalize it

\- show a workaround that doesn't really save the trouble of actually thinking before typing

The hard thing about callbacks is that you need to think about asynchronous processes which can be hard, the callbacks are not the problem so replacing them with something else won't help you too much.

</comment><comment><USER66> I am very happy that my current (PhD) code doesn't require me to deal with blocking calls to things (it's just one massive calculation essentially). I remember this nastiness from when I had a real job, and I'll no doubt have to deal with it again when I escape academia.

This article is very interesting - I enjoy articles which spell out the usefulness of a new language feature. I haven't used C# for a few years, and this is a great advert for coming back to it one day.

</comment><comment><USER67> I have a basic technical question. I work in C for embedded systems, so I'm a bit "behind the times."

How is "await" any different from a regular blocking system call? A regular system call does exactly what is being described: The system call happens, and then when it is finished, execution resumes where it left off.

(Yes, this makes the thread block... which is why you have multiple threads. I think the answer will have something to do with this, though...)

<comment><USER68> I'm not a beliver, so I may be missing something important...

As far as I can see, await makes it possible to do things like:

\- UI Thread starts Thread X to do something slow; \- Thread X is processing, in the meantime the user clicks on something that requires X's result; \- Only now the UI thread stops, waiting for X.

Your program stay responsive, unless it's completely not able to do so.

As I said, I still don't think it's a so important feature. It is quite rare that one needs such kind of coordination in UI programs, and there are better mechanisms for no-interactive software (that optimize for throughput, not responsiveness)... As a second thought, it may be very relevant for games, I don't know.

I also don't get why the node.js people consider it so important to have concurrence at a web server. For me, it only makes sense for sites that have less concurrent requests than server cores, AKA: nobody.

<comment><USER6> No, you got it wrong. Await _never blocks_ the UI thread.

Instead, the compiler rewrites your sequential code into a state machine. When you await on a task, the compiler turns this into scheduling a continuation. No blocking.

<comment><USER68> Yep, I got it wrong. Thanks for pointing that.

Now I'm also wondering how I'd use something like that in an imperative language... Well, I have some studying to do.

</comment></comment></comment></comment><comment><USER69> Completely OT, but when Dijkstra says:

>My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.

He's touching on a crucial point in Immanuel Kant's philosophy. Kant theorized that though humans received their sensations as a constant stream of input in time (which is an internal condition of human beings, not a feature of bare reality), we can't actually do anything with that stream without applying concepts so as to form concrete (or abstract) objects, i.e. chairs, black holes, mothers, etc. But how would our minds know when to apply this concept or the other? Kant's reply was that our minds look for little clues called 'schematisms' which tell us what the most appropriate fundamental concept to apply to a part of the stream is, upon which others could be combined to produce objective representations we can think and act upon.

Almost a hundred years later, Nietzsche will claim (paraphrasing) that a measure of strength in a human being is the extent to which to which they can 'consume' phenomena in time, weakness being how direly one needs to apply a static idea to phenomena (like morals, stereotypes, prejudices, cause and effect, etc).

I'm just noting an interesting entry point into an old philosophical conversation. If it's understandable then I hope someone finds it interesting.

</comment><comment><USER70> The only thing I've encountered in modern day programming which is really as evil as goto is aspect oriented programming (AOP). Maybe there are different implementations of AOP but in the one I've used you were basically able to hook into every method from everywhere and it was impossible to have any grasp on the flow of the program. That is besides using a debugger.

</comment><comment><USER71> JS gives you the tools to cope..

      function sequence(fns){
       var fn = fns.pop();
       while(fns.length) fn = fns.pop().bind(this, fn);
       fn();
      }

      sequence([
        function(k) { funcy(1, k) },
        function(k) { funcy(2, k)  },
        function(k) { funcy(3, console.log)  }
      ]);

      function funcy(v, cb){
    	console.log(v);	cb(v);
      }

      // ==> 1 2 3 3

</comment><comment><USER72> ES6 generators will be the solution for callback hell in node.js. Node 0.11 already has generators support hidden behind a flag (--harmony-generators) and eventually it will be enabled by default. Generators + libraries like this

[https://github.com/jmar777/suspend](https://github.com/jmar777/suspend)

will make node.js code more readable.

</comment><comment><USER73> Callbacks are a tool in my toolbox. General event based programming is a tool in my toolbox. Various threading models are a tool in my toolbox. Just because there are situations where a tool is not the best choice does not make the tool bad... it means you use a different tool in that case.

</comment><comment><USER74> Miguel is always fun/good to read.

</comment><comment><USER75> Can someone explain to me the difference between this and futures (specifically, futures in c++11)?

<comment><USER76> I can't comment on futures in c++11, but async/await is more like promises + coroutines, rather than just promises (as defined by Promises/A+)

</comment></comment><comment><USER77> This is what continuations are for.

<comment><USER78> Continuations don't help with the problem that the visual structure of callback-oriented programs doesn't reflect the order of execution. As a heavy JS programmer, that's the most compelling point for me in this post.

<comment><USER31> Actually, they do. C#'s await (and any similar scheme based on ES6 generators) is a feature that can be built using continuations.

<comment><USER54> So are Java/C#/everything-else exceptions. And, for that matter, pretty much every control flow construct imaginable.

OTOH, I think that the big problem with continuations is that it gets very difficult to build efficient implementations of them (and this tends to impact not just efficiency of code that _uses_ continuation, but usually efficiency of any code in a language which _supports_ them), and it is much more efficient to implement specialized weaker (but good enough for most key use cases) forms of the most important applications of continuations.

<comment><USER31> Supporting call/cc and dynamic-wind has a significant performance impact in some languages, even for code that does not use the features.

Supporting coroutine.create+coroutine.clone, shift+reset, or setcontext+getcontext+makecontext+swapcontext seems to have no performance impact on code that does not use the features.

</comment></comment></comment></comment></comment><comment><USER79> Akka adds something similar in Scala land (and Java) called Dataflow concurrency.

[http://doc.akka.io/docs/akka/snapshot/scala/dataflow.html](http://doc.akka.io/docs/akka/snapshot/scala/dataflow.html)

</comment><comment><USER80> How is this different from Fibers in Ruby? One can accomplish same thing with Fibers.

</comment><comment><USER81> To appreciate whether callbacks are Goto and what to do about them, it is probably good to read a good perspective on Goto from back in the day: [http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoT...](http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf)

When skimming it, I noticed the appeal to events and the precursors to literate programming (Knuth eventually came up with literate programming a few years after this paper was written).

</comment><comment><USER82> futures are so nice to use in scala. warping back to my planet..

<comment><USER83> Scala has both Futures and Promises which are inherently much nicer than that async call. That's what happens when you allow things to compose. Glad c# gets something.

</comment></comment><comment><USER84> I love when Node.js advocates try to convince you that promises are as good a concept as anyone would need to handle asynchronous programming

<comment><USER85> Promises were removed from node core a long time ago, and remained unpopular until very recently. They are making a comeback due to lobbying in standards committees, forward-compatibility with ES6 generators, and the jQuery effect.

<comment><USER84> Fair enough. I guess I'm confusing IRC with reality again.

</comment></comment></comment><comment><USER86> As soon as you have anything involved that's async to your process or thread, you're going to operate most efficiently with something along the lines of a callback. I don't see them as a Goto at all; they're much more like interrupt handlers or at least event handlers if you want jump ahead a generation from there.

</comment><comment><USER87> Having had the pleasure to work with node.js for the past months, I upvoted this submission on title alone.

</comment><comment><USER88> I actually believe that code should be synchronous unless instructed to operate asynchronously - just my .02

Await should not be required - it should be more like...

\--

regularWork(); //im waiting till this thing is done

driveHome();// not executed till thing one is done

background orderStatus = orderPizza();

turnOnXbox();

while(orderStatus == 'not ready') {

playXbox();

}

turnOffXbox();

eat();

\--

Like I said - just my humble opinion that the code written would become more expressive.

</comment><comment><USER89> Agreed, that's why we're using fibers and common-node ([https://github.com/olegp/common-node](https://github.com/olegp/common-node)) at [https://starthq.com](https://starthq.com)

</comment><comment><USER90> I always liked event based systems the most. I find them to be clean and flexible. Sometimes you want to run some more code after you run an async operation, or you want to run multiple operations at once and deal with them out of order. Await seems pretty linear.

</comment><comment><USER91> Does Await convert those async calls back into synchronous calls, or what does it do? Because that would be kind of defeating the purpose of doing things asynchronously?

And you don't have to nest all those callbacks and write them inline. Rearrange your code a bit.

<comment><USER6> No, it rewrites the method code into a state machine[1].

See Async/Await FAQ[2].

[1]: [http://stackoverflow.com/a/4047607/458193](http://stackoverflow.com/a/4047607/458193) [2]: [http://blogs.msdn.com/b/pfxteam/archive/2012/04/12/async- awa...](http://blogs.msdn.com/b/pfxteam/archive/2012/04/12/async-await- faq.aspx)

<comment><USER91> I'll have to look at that in the morning, thanks!

</comment></comment></comment><comment><USER92> The ease with which callbacks can be created leads people to create them carelessly and excessively. While I like what the article has to say, there are ways to write callback heavy code that do not get ugly so fast. Looking at the iOS nested block example from Marco Arment -- the first step is to not do everything inline. Then the code suddenly becomes clear and the argument becomes one of syntax sugar.

Comparing callbacks to goto is a tad unfair. They don't merely solve async issues, but also event handling and dynamic systems to name two common uses. I don't see a better solution on the table. Using callbacks to write deeply async code is the real problem. And while async/await may help with this problem, it still won't tell you why step 3 never finishes, because it's still waiting for a come from.

<comment><USER56> First: code that performs simple sequential steps should look simple. With callbacks, it always ends up looking complicated.

Second: refactorability in callback oriented code is a lot worse than linear code. Even refactoring code with a single callback can be annoying. Async code with callbacks that looks and feels like imperative synchronous code is an enormous gain.

<comment><USER92> First: you're hammering the async point, which I don't disagree with. I am just pointing out that you can write less horrible async code than the example cited with callbacks.

Second: wait until people write ludicrous numbers of async routines as if they were imperative because it's so easy. Calling one from another (and hooking them up to event handlers). You'll have the same damn problem one level removed.

</comment></comment></comment><comment><USER93> Here's a cool way to reinvert control

[http://blog.sigfpe.com/2011/10/quick-and-dirty- reinversion-o...](http://blog.sigfpe.com/2011/10/quick-and-dirty-reinversion- of-control.html)

</comment><comment><USER94> "I have just delegated the bookkeeping to the compiler."

That's not obviously a good thing. Debugging the compiler (or just figuring out why it did something, even if correct) is far more difficult than debugging application code. Given the choice between implementing behavior with application code (or a library function) or adding semantics to the language, I prefer the former because it's much easier to reason about code written in a simple language than to memorize the semantics of a complex language.

[edited to replace sarcasm]

<comment><USER6> This is a nonsensical comment, and I voted it down. The same point can be made about any time languages got a level higher. This kind of rejection of powerful in favor of complex-but-familiar is precisely what Bret Vector warns against in the Future of Programming talk[1].

If anything, `await` makes debugging easier because you don't have to untangle callbacks and jump back and forth. You're not supposed to "debug the compiler" because, well, you know, there are test suites and everything.

 _Yes_ , this is something that takes getting used to. Just like `for` loops, functions, classes, futures, first class functions, actors and many other useful concepts and their implementations.

As for your edit, I still can't agree with you.

You're saying:

>I prefer the former because it's much easier to reason about code written in a simple language than to memorize the semantics of a complex language.

The point of `async` is making the semantics _more obvious_. Is it much easier to reason about Assembler than C? I say it's not. Would it be for somebody with years of experience in ASM and none in C? Yes it would.

I think it just comes down to that. Callbacks seem simpler to you not because they _are_ simpler (try explaining them to someone just learning the language, and you'll see what I mean), but because you got used to them. Even so, error handling and explicit thread synchronization make maintaining callback-ridden code painful. I think setting `Busy` to `false` in `finally` block is a great example (in the blog post). You just _can 't do that with nested callbacks—they are not that expressive_.

Async allows you to think in structure (`for`, `if`, `while`, etc) about time, that's why it's powerful.

[1]: [http://vimeo.com/71278954](http://vimeo.com/71278954)

<comment><USER94> The sarcasm in my post was unnecessary, so I've replaced it with a better explanation.

<comment><USER6> Thanks for taking time!

I still don't agree though, I edited my post as well to explain why I think this is exactly the moment you need to tweak the language, and not the libraries. (And this is the point Miguel was trying to make when he differentiated `async` from "futures" libraries, even from the one `async` uses, because they are irrelevant to the discussion.)

</comment></comment></comment></comment><comment><USER95> callbacks are like goto in that you can create terrible code by using them badly, but also they are vital to implementing good code. if, for, while and co are all syntactic sugar for correct and standardised use of goto with hints to help the compiler make optimisation.

in both cases though we don't something universally evil or bad - <USER4> something that bad programmers can and will abuse.

</comment><comment><USER96> I love it -- another dramatic unveiling in a cutting-edge language of a feature Tcl has had for decades (google "vwait").

<comment><USER6> Oh, can we use Tcl on iOS maybe? No? How about Android? Xamarin runs on both.

</comment></comment><comment><USER97> I can see how this could be useful for Javascript and web stuff. But it isn't Async, this is in effect a blocking call.

</comment><comment><USER98> In ToffeeScript you can just do e, data = readFile! fname

Or take a look at CoffeeScript or IcedCoffeeScript or LiveScript back calls.

</comment><comment><USER99> One instant cure:

Make rules in IDE/editors, for each async/anonymous closure, undo the indent for one level.

</comment><comment><USER100> So... This article is basically saying that blocking style programming is a lot easier to read and write, and proceeds with demoing a lib which makes async calls look sync. So instead of doing this in $lang, why not invest time in making blocking style faster on the kernel level? Perhaps introduce actors or tasks in the kernel, so that every lang can benefit.

</comment><comment><USER101> I think the problem is not the callback itself, but the nested inline callback.

In any case, I prefer futures.

</comment><comment><USER102> shenanigans. Pyramids (at least in js) can be easily avoided by simply naming your functions. Treating them like the first class objects they are. Naming the function means you are no longer going to an arbitrary code block, but instead going to a concept whose name, doc string, and (through hoisting) position on the page illuminate its purpose.

Callbacks aren't bad. Pyramids are bad. Stop writing pyramids.

Nodejs also establishes a nice api for callback functions-- in particular, callbacks are defined with an `error` and a `data` argument. You handle the error if it is non-null, otherwise execute `data`.

If you want to avoid callbacks, Node also provides event emitters, and streams. Streams in particular provide a nice api for dealing with event based programming.

<comment><USER103> I disagree. Callback based programming forces you to modularize around asychronous/IO calls instead of semantic cohesion.

Naming functions doesn't solve that problem. On the contrary, you get seperate lexical units that are not separately reusable and make no sense on their own. They are simply fragments of code that's supposed to be executed before or after some IO operation inside another function.

</comment></comment><comment><USER104> await PostPicToServiceAsync(mFile.GetStream (), tagsCtrl.Tags);

Seems to be equivalent to a blocking call of old, or am I missing something?

<comment><USER6> Yes, you are :-)

The compiler rewrites your code to schedule all next lines as a _continuation_. There is no blocking.

</comment></comment><comment><USER105> At least for java, when your software library exists in the cloud, I don't see how you could avoid using callbacks.

<comment><USER106> This is possible if the language supports coroutines like python (see twisted's inline callbacks) or my port to Lua for Luvit: [https://github.com/kans/luvit-inlineCallbacks](https://github.com/kans/luvit- inlineCallbacks).

Personally, I think raw callbacks are the right thing 95% of the time. yield/async/coroutines are needed for branching async logic where otherwise you'd be forced to make a new function for each branch and deal with the spaghetti at the end.

</comment></comment><comment><USER107> I think this article misses a main point and that's the fact that all await does it take a function that used to be asynchronous and makes it synchronous. While yes, there are definitely use cases where that is nice, in general I think that if you want to use an await command, why are you making a call that was meant to be async? You are defeating the whole point of async calls.

Yes I know a lot of standard libraries have calls that are async and you may not really need for them to be async but I don't think that this is the case often enough that we should abandon callbacks and the like and go back to an age where all code must be synchronous. I know the author isn't saying it to that extreme necessarily, but his comparing callbacks to gotos is extreme as well.

<comment><USER19> That's not how async/await work at all. They let you write the code _as if_ it were synchronous, but it's still asynchronous, which is the whole point.</comment></comment>