Microsoft Surface Duo – Dual-screen Android phone - <AUTHOR> https://www.theverge.com/2020/8/12/21364633/microsoft-surface-duo-release-date-pricing-features-specs <comment><USER2> Kinda like it. Looks like a Nintendo DS to me :) Could be a productivity power house in a nice compact form factor. I'm not the guy that checks his phone every 15 mins. but when I"m on a train for a bit, something like this would be amazing. My question would be if it houses the stylus somewhere? Wouldn't want to carry that around separately. Price is pretty steep, but about the same as an iPhone 11 Pro Max with storage option, still one hell of a luxury purchase, not sure how reasonable this will be these days. Has to be top build quality and pretty much flawless though.

<comment><USER3> I like it too, but with that price, I'm definitely not a target group. It's a nerdy device with a luxury price.

</comment></comment><comment><USER4> Not sure if The Verge have just screwed up the gif, but this looks painfully slow here: [https://cdn.vox- cdn.com/thumbor/wJ90NeII7udsc85i4mlHznodfmQ=...](https://cdn.vox- cdn.com/thumbor/wJ90NeII7udsc85i4mlHznodfmQ=/1200x0/filters:no_upscale\(\)/cdn.vox- cdn.com/uploads/chorus_asset/file/21729328/surfaceduoandroidapps.gif)

<comment><USER5> Even with so low FPS count and quality it's size is 5MB. People should stop using GIF for videos.

</comment></comment><comment><USER6> I love the looks of this phone and I think I could make use of the features, but I'm not $1400-curious. I guess I'm cheap, but I'll be fine with a Pixel 4a at $350.

<comment><USER7> I have a Pixel 2 XL and until the battery starts failing or they stop updating the software it's hard to see much reason to upgrade. It used to be really noticeable every time you got a new phone how much faster it was but I think that's kind of plateaued if you don't use your phone for anything too exotic.

<comment><USER8> I'm on the same phone and if I wouldn't have kids I'd agree, but the dropped frames on video recording and lack of optical zoom make me eyeing the new Xiaomi Mi 10 Ultra if they decide to make it available in Europe.

<comment><USER7> I don't doubt that Xiaomi makes good stuff, but with the current political situation I'd be hesitant to buy any Chinese Android phone because I'd be afraid of them getting cut off from the Google ecosystem like Huawei (who also made great phones and the only smartwatch I actually liked using) did.

<comment><USER8> I'm also considering the Samsung Note 20 Ultra for this very reason, but I really loathe Samsung Software so I'm hesitant.

<comment><USER7> Samsung is all over the place; some stuff they make is great and others I rue having bought.

</comment></comment></comment></comment></comment></comment><comment><USER9> Another expensive android?

Why don't they just sell a phone with desktop windows on it? That could actually compete.

<comment><USER10> Microsoft abandoned their Windows Mobile OS years ago.

<comment><USER11> Yes, but that wasn't desktop Windows. In fact it inflicted some brand damage on desktop windows, back in the Win8 era, by moving all the new stuff to Metro.

(I'm not sure there's ever been a proper decent portable/handheld that ran Real Windows; there's tiny laptops from the Libretto to the GPD Pockect, which is a nice machine. Or there were handhelds that ran Windows CE back in the PDA era. And I've seen very cheap 8" tablets. But a phone-size form factor? Not quite. I suspect the never completely fixed UI scaling is a problem there.)

<comment><USER7> Trying to press controls intended for desktop Windows on that tiny screen would be an exercise in frustration. Trying using RDP software on your phone and see how productive it is.

<comment><USER12> If I have to make two remote desktop connections lasting ten minutes each per workday from the beach, which machine am I bringing: my phone/this? Or a full laptop?

Not as obvious a decision for some.

<comment><USER7> OK, so coming back to the original point, are you going to want a hotter, more power-hungry phone for 10 minutes of non-mobile Excel on it?

</comment></comment></comment></comment></comment></comment><comment><USER13> The _Microsoft Courier_ concept finally after more than a decade.

[https://www.youtube.com/watch?v=UmIgNfp- MdI](https://www.youtube.com/watch?v=UmIgNfp-MdI)

</comment><comment> tedk-42 Wow the pricing is ridiculous. It's using last year's flagship CPU and has two screens with a hinge. Be interesting to see how it sells but I'm not convinced it's a good buy.

</comment><comment><USER14> Man, I'd love to get this but that price is steep. I just hate how small smartphone displays are in general and how constrained multitasking is. Say I'm chatting with somebody and I nerd a source for something I'm arguing. I need to switch from the chat app, browse for a while, copy, switch, paste, keep typing. And if I need more than one, that's a whole lot of switching back and forth which is fairly slow and tedious and breaks the context I'm in every single time. Doesn't just go for chatting. Sometimes I'm writing something and need a reference. Switching back and forth every couple of seconds is unbearable. If I can get away with it, I'd rather pull out my tablet, but I also don't always have it with me.

</comment><comment><USER15> The physical size is close to the much-loved 1990s PDA, Psion Series 5: [https://en.m.wikipedia.org/wiki/Psion_Series_5](https://en.m.wikipedia.org/wiki/Psion_Series_5)

Of course this device is dual touchscreen, so it doesn't have the tactile keyboard that made the Psion so popular with writers on the road.

Still, it's interesting to see a big tech company make another attempt at the "pocket laptop" form factor.

<comment><USER16> The spiritual successor to the Psion Series 5 is the Cosmo Communicator: [https://www.www3.planetcom.co.uk/cosmo- communicator](https://www.www3.planetcom.co.uk/cosmo-communicator)

Similar size, but has the classic Psion keyboard (it was designed by the same guy, Martin Riddiford) and runs Android or Linux. As a phone, it has an external 2.5" touchscreen.

I've got to say that the software lacks polish -- Planet Computers are a very small firm -- and while the design is an improvement over their earlier Gemini PDA, it's not a great phone. I have higher hopes for next year's model, the Astro Slide, which seems to combine the best of the "pocket laptop" and touchscreen worlds (assuming they get it to work properly):

[https://www.indiegogo.com/projects/astro- slide-5g-transforme...](https://www.indiegogo.com/projects/astro- slide-5g-transformer/)

... Oh, and it's about half the price of the Surface Duo (which looks vastly more polished but also rather expensive).

</comment></comment><comment><USER10> Just curious, is a user supposed to put the device up to their ear to make a phone call? Or is the expectation to use a bluetooth headset?

<comment><USER17> Good questions. I was looking for a "phone side". To make, or receive a call you have to use two hands to open that thing up and use it? Is anti-ergonomic a design? How can you see who's calling? Even something as simple as the time we've all had since the 90's? Missed messages? Voicemail waiting? Any type of control, or info, requires you to open up the tiny laptop? Or you have to basically wear a Bluetooth headset at all times? Wow, that would be awful. Even the flip-phones of yore allowed you to see who was calling without opening the phone and, opening just required a flick of the thumb. Perhaps there are some indicators under the front/back of the closed body that we just don't know about?

I'm not being anti-microsoft, but it looks like someone just brought back the netbook.

</comment></comment><comment><USER11> So .. is this the first Microsoft Android phone? Or is it something weird that happens to run Android apps?

<comment><USER18> Full Android. They have a simulator for public already for the past few months.

</comment></comment><comment><USER7> LG makes one like this already, the G8X.

<comment><USER19> Yeah, and the specs are basically identical at $400 less.

</comment></comment><comment><USER20> Pathetic. I've never once thought "oh I know what this phone needs, a second screen, that forces me to 'open' it and makes one handed use impossible."

I should add I've nothing against Microsoft and used Windows Phone / Windows 10 Mobile until the end of 2018. But dual screen devices are dead in the water I think.

</comment><comment><USER21> Has anyone ever released a two-sided phone, with a screen on each side (so the opposite idea of one that closes like this, no hinges)? Bonus points if they're two independent phones but sharing the same battery, e.g. for company phone and personal phone

<comment><USER22> Why would you want a device with two screens where you can only look at one of them at a time? It'd make _a lot_ more sense to have a single screen and a switch (maybe in hardware?) to toggle between "screen 1" and "screen 2".

<comment> T-A A low power e-ink screen on one side for reading e-books and the like, an ordinary screen on the other for video, games and other things which need low latency and full color. It's been tried a few times but never really took off:

[https://www.eink.com/mobile- wearables.html?type=application&...](https://www.eink.com/mobile- wearables.html?type=application&id=3)

</comment></comment></comment><comment><USER23> I love the concept and how things flow between the two screens, but it looks really weird when held to the ear for a call. I don't like large screens and this one just seems too large to be called a "phone"..."phablet" seems a more appropriate term.

</comment><comment><USER24> Much like the new IMac 27" look at those bezels. Compare it to the Surface Pro X, it looks like its from the 2000's

</comment><comment><USER25> A single camera seems like a drawback.

<comment><USER5> Why would you need more than one camera?

<comment><USER26> Multiple sensors behind multiple lenses with different focal ranges being able to take multiple images simultaneously and then stitch them together is how the back camera works on most modern high end smart phones. Or using each camera individually for the best photo.

Bonus points for those that employ ML to optimise the result.

</comment></comment></comment><comment><USER27> Looks useful for Office work on the go but the price is steep.

<comment><USER28> Or you could just get any other Android or iPhone and run Office on it.

</comment></comment><comment><USER29> The Samsung Fold and Huawei Mate X makes this thing an anachronism. It reminds me of a BlackBerry Playbook vs an iPad. How embarrassing.

<comment> the-dude No wireless. Less space than a Nomad. Lame.

[https://en.wikiquote.org/wiki/IPod](https://en.wikiquote.org/wiki/IPod)

<comment><USER29> Underpowered CPU, laggy interface, poor battery life. Fail.

Quote me in a year.

</comment></comment></comment><comment><USER30> They'll sell dozens!

<comment><USER31> Well, there's a few possibilities:

* They'll sell dozens, and everyone will give up.

* They'll sell dozens, iterate a few times, and I'll have a nice device.

* They'll sell dozens, someone else will iterate, and I'll have a nice device.

I think you're right that it will be the first (Microsoft doesn't have much stick-to-it-ness), but I'm really hoping for the second or third. I really want a device like this.

I'm definitely not buying a V1 Microsoft device to become a beta tester for $1400, though. Microsoft devices don't tend to work well until V2 or V3.

<comment><USER30> The only people who will buy this device are folks with disposable income who want a status symbol.

International exchange students from the UAE and HK come to mind.

<comment><USER31> To the extent that wearable computers in the nineties, large graphic calculators, or calculator watches became a status symbol.....

This is big, bulky, ugly, but incredibly practical for people who want to get stuff done.

</comment></comment></comment></comment><comment><USER32> "Microsoft is also using algorithms to predict how to open apps on different displays. 'There is an algorithm in there that's very smart and trying to be predictive,' explains Panay. "If you're on one screen and you're invoking a link, it will fill the other screen."

That's if/then statements. You invented if/then statements.

<comment><USER33> It reminds me when I was at a user group at Microsoft for the launch of the new Windows Phone OS...

... The guy gave a long marketing speech about how "beautiful" it was, how they did so much user research on what people wanted and spent a fortune developing and using a brand new font for the interface(s).

Then, someone stuck their hand up and said "Is it true that you don't have copy/paste features yet?"

Why can't people learn... things may be important, but no one cares about the technicalities... I don't care if this is algorithm, AI, ML... neural network processing or some other fancy new term...

... just give the user a setting for what screen something should pop up on and everyone will be happy!

<comment><USER7> The iPhone also didn't have copy and paste for a while. And the trade-off with more options is they're work to maintain and users are confused by them.

<comment><USER33> Yep - but, the iPhone came from nowhere, and, "no copy and paste" was put out by Microsoft to say how bad it was...

Microsoft basically took a backwards step from Windows CE and then did the same years after it was the norm in other systems.</comment></comment></comment></comment>


A Drop-In Solution for Replacing Human Labor? Kawada's Nextage Robot - <AUTHOR> http://singularityhub.com/2011/12/09/a-drop-in-solution-for-replacing-human-labor-kawadas-nextage-robot/ <comment><USER3> This seems to be a transition stage for fine motor skill robots with advanced object recognition capabilities. A few more iterations will surely make the human counterparts obsolete, as demonstrated by the rapid automation of manufacturing giants such as FOXCONN.

<comment><AUTHOR> The most exciting part is that once a few large companies like FOXCONN make a commitment to robotic manufacturing, we may be able to see the exponential decreases in robot costs we have been waiting for as they want cheaper sensors and actuators in larger quantities. Robotics have been (and are) incredibly expensive, but but we are reaching a point where the price will begin to plummet.

<comment><USER4> This doesn't excite me, it scares me. A rapid transition to robotic manufacturing could mean a very rough time for an entire generation of human workers.

<comment><USER5> Very cheap robotics will decimate China's low skilled labor force.

<comment><USER6> And who will supposedly buy all these good those factories make? The 1%ers?

Those factories only exists if they have a market for the goods they produce.

<comment><USER7> > And who will supposedly buy all these good those factories make? The 1%ers?

Yeah, pretty much. Human wants are unlimited. (To quote Boethius, "If free- handed Plenty should dispense riches from her cornucopia as plentiful as the sands cast up by the storm-wracked sea, or as the stars that shine in heaven - men still would not stop their miserable complaints.")

Have you read Chase's 'Plutonomy' papers from a few years ago? Fearsome reading.

<comment><USER8> You mean Citigroup's Plutonomy investor Memo:

[http://www.principiadiscordia.com/forum/index.php?topic=2512...](http://www.principiadiscordia.com/forum/index.php?topic=25129.0)

It's not that fearsome.

Over time it becomes easier to give more value to more people thanks to progress in technology and greater amounts of money/economic wealth sloshing around.

The people who do something of value, or capture it, derive a huge surplus from the leverage provided by what's out there right now ( billions of people, trillions of dollars )

You can see the difference between Nikola Tesla - an absolute genius - <USER2> created the basis for all modern technology/progress and Google.

Even with all the value he created, he couldn't really derive that much personal benefit, as the utility of his inventions were low before network effects set in and there were fewer people with less disposable income to spend money on his inventions. He also got screwed but that's another story.

Compared to Google ( very smart guys yes, geniuses perhaps ) which started less than 14 years ago and has become one of the largest and most profitable companies in the world.

Lady Gaga ( 4 years ) vs. Madonna ( 40 years ) for huge success.

Avatar ( 3 billion ) vs. Jaws ( .5 billion )

You catch my drift. Feedback loops are getting larger and faster - it's like nothing stands still anymore.

But society is getting better.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> At ~$100,000 USD this will simply not replace dirt cheap labor in developing countries for decades to come.

<comment><USER10> Maybe not, but it could replace low-wage jobs in developed countries.

Imagine a 24-hour fast-food restaurant that employs several people at minimum wage. A robot could work all 3 shifts around the clock nonstop, not require much space, and be "trained" in new types of food preparation with an instantaneous software upgrade.

My economics professor once said he'd heard that if minimum wage got up to $20/hour, it would be cheaper for McD's to use robots. This is changing the other side of the equation.

<comment><USER11> Minimum wage in Australia is $15.51/hour + 9% superannuation contribution. This comes out to $16.91/hour or USD17.23/hour. If these things can work 24/7 with the same productivity of a worker on minimum wage they'll pay themselves off in eight months (plus/minus other costs associated with employees and these machines).

</comment></comment></comment><comment><USER12> is this something we should worry about? If we, as a civilisation (forget countries for a second) hypothetically replace all labourers by robots, then what? Is it any different from using cheap overseas labour? Will we be able to find something else to do for these people? Should we turn to communism in the long term, if the only 'working' people are software&robotics engineers? We obviously can't all be tech workers, can we? And would that even be useful?

<comment><USER13> There will always be unknown things and things to achieve! There is still nuclear fusion, computer brain interface, genetic engineering, inhabiting other planets. Figuring out how universe works, if there are other realities, etc.

My personal thoughts are that communism is merely the next step after capitalism (after discovering fusion and fabricating nanotechnology), however I don't think/hope it will play out as it had before in Russia.

<comment><USER14> Why do you think that?

</comment></comment></comment><comment><USER15> _Automation poses a real threat to the factory worker_

Correction: Automation poses a real threat to everyone

<comment><USER16> Correction: automation possess a threat to those who do not work principally with their mind. Knowledge workers won't be in danger of marginalization in the near future

<comment><USER13> Correction: automation can replace doctors and researchers (which principally work with their mind).

[http://news.nationalgeographic.com/news/2009/04/090402-robot...](http://news.nationalgeographic.com/news/2009/04/090402-robot- scientists.html) <http://news.bbc.co.uk/2/hi/health/131697.stm></comment></comment></comment>


O₂ Engine – HTML5 Visual Novel Engine - <AUTHOR> http://o2engine.org/

<comment><USER2> This looks interesting, but it appears to be completely tied to this "NovelSphere" site, which severely limits its potential uses.

There exist a variety of other visual novel engines that are more open, including the HTML5-based MIT-licensed TyranoScript[1] and the Japanese-only not-quite-as-open Almight.jp[2]. If you're not in need of HTML5, Ren'Py is probably the most popular VN-engine outside of Japan, and is also available under the MIT-license[3].

[1] [http://www.evanburchard.com/tyranoscript/](http://www.evanburchard.com/tyranoscript/)

[2] [http://almight.jp/](http://almight.jp/)

[2] [https://github.com/renpy/renpy](https://github.com/renpy/renpy)

<comment><USER3> Yeah, Ren'Py is the entrenched contender here. It can now generate iOS and Android apps along with desktop ones, it has Steam API support built in for commercial releases using the engine, and the engine using a domain-specific language on top of Python makes it flexible enough that people have put in turn-based strategy, RPGs, etc inside Ren'Py games.

<comment><USER4> People do amazing things with Ren'Py. Given that it now has some mobile reach, I have to say that I don't see what a fairly limited proprietary HTML5 engine could offer if I were to make a VN, though maybe I'd have some reasons if I did it as a business rather than a hobby.

edit: I hope this didn't come across as too negative, changed a bit to clarify.

</comment></comment></comment><comment><USER5> I could see them running into problems with the Telefónica owned phone company O2. The branding used by both is very similar as well as the name.

<comment><USER6> Doubtful, as O2 is first and foremost a chemical compound and as such it seems hard to claim any trademark outside of very specific trade areas. Since this engine has no ties to the telecommunications industry, I highly doubt it will be a problem.

In fact, they lost a court battle recently to Hutchinson 3G over a 'bubbles' trademark that O2 holds.

[http://news.bbc.co.uk/1/hi/business/7450513.stm](http://news.bbc.co.uk/1/hi/business/7450513.stm)

The relevant portion of the trademark ([https://inventively.com/search/trademarks/78618164](https://inventively.com/search/trademarks/78618164)) is as follows:

      interactive entertainment services, namely, providing online electronic games services by means of any communications network;

</comment></comment><comment><USER7> Hi, I'm a leader of the O₂ Engine developer team. Please let me know if you have any problems or questions!

<comment><USER8> Nice project, I love visual novels and I toyed around with my own engine a few years ago.

I'd put a full KAG3 code example somewhere on the page (rather than the tiny picture). I hadn't heard about KAG3 and I have no idea how to write it.

Good luck!

<comment><USER9> KAG3 is the scripting language of an existing popular (native) engine Kirikiri; from skimming the O2 site it seems to be implementing an alternative interpreter, similar to how ScummVM implements the LucasArts engine. Unfortunately I can't seem to actually see the SDK to confirm this without figuring out enough Japanese to sign up on novelsphere.

There's some old English documentation on [http://kirikirikag.sourceforge.net/contents/index.html](http://kirikirikag.sourceforge.net/contents/index.html) (which seems to be a translation of the original upstream Japanese version).</comment></comment></comment>


Luminoth 0.1: SSD model and pre-trained checkpoints - <AUTHOR> https://tryolabs.com/blog/2018/04/17/announcing-luminoth-0-1/? <comment><USER2> Your site would be much nicer if you didn't hijack the title bar and add a little fake chat window with "Esther".</comment>


Self-flying planes are now a marketing issue more than a technical one - <AUTHOR> https://jonathannen.com/captain-ai.html <comment><USER2> I am only about 20 hrs into my flight training, so take what I say with a grain of salt.

I still have yet to hear anyone offer up an explanation how AI will integrate with our current air traffic control system and other aircraft. Right now if I want to fly through certain kinds of airspace (basically any airspace around a medium sized airport, civilian or military) I have to talk to air traffic control, and they tell me what do to. As a pilot in command, I have final authority to deviate from these clearances for safety reasons, mainly because it is my ass on the line.

So if a drone flight is flying an instrument flight plan from point A to point B, how does an air traffic controller command them? Part of the advantage of verbal commands being given to aircraft over a common frequency is that other pilots know what aircraft are doing around them. If a drone is being silently told to avoid for traffic, that doesnt help me if I am the aircraft being avoided. If a drone is told to hold but doesnt have enough fuel, or to divert due to weather, can it recognize a command that would create a state of emergency and over rule the air traffic controllers directions? Since air traffic controllers have need to communicate with aircraft in their airspace, how will these comms be authenticated so someone doesnt spoof ATC to make a drone do something stupid?

I know NASA is working on these problems with the FAA, but I havent heard anything yet. However, aviation isnt a "move fast and break things" area. Regulations are written in blood, and I dont really want to be the guy who gets sacrificed so that the FAA can retroactively fix an issue that someone dismissed as "psychological".

<comment><USER3> >As a pilot in command, I have final authority to deviate from these clearances for safety reasons, mainly because it is my ass on the line.

I think this is the most crucial aspect. Machines are excellent at executing patterns and adhering to constraints. Improvisation, not so much. And really, in emergency situations when things go awry and off script, it's that "clutch" factor that makes all the difference.

<comment><USER4> And that, in a nutshell, is my concern about fully autonomous cars, and the enthusiasm some express for removing all manual control because "computers are better than people".

<comment><USER5> A computer will have notified ATC and all local traffic of intent, and received acknowledgement of the distress call from all affected parties, while the human is still half way through the first "Mayday, …"

One brand's autonomous pilot will only have to be taught about handling unusual conditions once, while humans have to be trained from scratch each iteration. 20 human pilots, about 22 iterations of the same training program.

Come up with a new failure scenario and a strategy for mitigating it? Train the computer once. Train every human pilot independently. The lead time is atrocious for getting software updates out to wetware, so good luck getting every commercial human pilot to be familiar with a new procedure inside ten years, by which time you have new humans to train because some of the old ones died and taken all their training and experience with them.

</comment></comment></comment></comment><comment><USER6> I don't think commercial jets are an especially favourable target for complete automation, compared to cars.

\- Slow iteration, each mistake that you could learn from potentially costs a hundred lives

\- No graceful shutdown possible most of the time – if automation fails in a car, you just stop or pull over, you probably won't die. A plane can't just land itself if automation fails unless the comm link works

\- Comm link might not always work, it can be damaged from light mid air collisions, bird strikes, drone strikes, other damage, improper maintenance, possibly bad weather, hacking, jamming, over-saturation due to mass automation failures etc.

To me it seems that it's easier to deal with road chaos than acquire an extra couple 9s of uptime in this problem.

<comment><USER7> You don't remove pilots overnight, you can keep them on board for as long as needed for safety reasons

Meanwhile flights have been almost completely automated for years already

<comment><USER6> No one has any doubt that the planes can fly themselves in 99% cases even with todays technology, but bringing this up to a higher uptime while still being fully automated will be very hard I think.

</comment></comment></comment><comment><USER8> As commercial aircraft incidents are well-documented, it might be possible to make some rough estimate of the change in accident rate if current airliner control systems were used as the basis of full automation. Off the top of my head, I would suggest relatively recent incidents that might well have ended in fatal crashes without pilot intervention include the Qantas flight 32 engine disintegration and fire, Qantas QF72 uncommanded pitch-down incident, and the British Airways flight 38 fuel icing non-fatal crash. On the other hand, crashes that might have been avoided include those of Asiana flight 214 at San Francisco (power mismanagement on approach) and Coglan Air flight 3507 at Buffalo (mishandling of icing and the resulting stall.)

</comment><comment><USER9> I'm going to have to disagree with the conclusion that 'self flying aircraft may be well ahead' of self driving cars. I think automation of cars is a necessary precursor to automation of air travel.

Many people have issues flying due the feeling of not being in control; I expect we will first need the automation of cars to acclimatise people to the concept of trusting in an AI driver/pilot, before automated flights will be accepted.

Cargo flights strike me as the much clearer entry point for the technology.

<comment><USER10> > _Many people have issues flying due the feeling of not being in control_

If there's one consistent view Americans have expressed about flying, it's that they'll choose the cheapest flight over almost anything else. Bring a cheap self-flying route to market. People will get over their qualms.

> _Cargo flights strike me as the much clearer entry point for the technology_

Agree. That said, a helicopter seat from Manhattan to the Hamptons costs about $700. If you cut that to $200 or 300 the demand would be massive, pilot or not.

<comment><USER11> I don't think that's true, about low priced tickets. What you actually mean is that once companies collude to create a situation where it's virtually impossible to compare one flight to another, or one airline to another, by any criteria other than cost then cost is what drives customer decisions.

I'm sick to death of this meme that Americans are only interested in low prices. The fact is airlines were one of the first of many industries to use fees, line by line cost breakdown, obscure deals and a baffling purchase process to strand customers on an island of price comparison and nothing else. See also: cell phones plans.

If you knew what you were getting and could hold airlines accountable when they didn't deliver on what was purchased I promise you price would no longer be the only factor. This is not a truism about Americans you've found, it's a truism about distorted and manipulated markets lacking sufficient regulation.

<comment><USER10> > _airlines were one of the first of many industries to use fees, line by line > cost breakdown, obscure deals and a baffling purchase process to strand > customers on an island of price comparison and nothing else_

I'm one of those Americans who doesn't buy the cheapest ticket. I buy comfortable seats at convenient times with airlines I'm loyal to. Guess what I see none of? Any of those things! My bags are free, my drinks are free, I get to go to the front of the check-in line and, many times, security line. On occasions where I've been charged a change fee, a quick phone call gets it reversed. I board a 6:30AM flight tomorrow and am honestly looking forward to a few hours of cool views, relaxing reading and maybe a touch of alcohol.

Airlines tried competing on pitch and leg room. Their behinds got handed to them by travellers switching to budget airlines. If you want better service, there are business class tickets available at prices cheaper than pre- deregulation fares.

Note that this effect isn't constrained to Americans. European non-business passengers' demand for air travel is also extremely elastic with respect to price [1].

[1] [http://dare.ubvu.vu.nl/bitstream/handle/1871/48303/140307.pd...](http://dare.ubvu.vu.nl/bitstream/handle/1871/48303/140307.pdf?sequence=1)

<comment><USER12> What domestic airlines do you fly most? Do you regularly fly business?

</comment></comment></comment></comment></comment><comment><USER13> Some quick math suggests to me that pilot pay is likely a small part of what you're paying for with your ticket.

United Airlines employs 12712 pilots. [[http://www.airlinepilotcentral.com/airlines/legacy/united_ai...](http://www.airlinepilotcentral.com/airlines/legacy/united_airlines)]

United has 143 million passengers. [[http://newsroom.united.com/corporate- fact-sheet](http://newsroom.united.com/corporate-fact-sheet)]

If we say that United has a cost per pilot of $200,000 (likely high) then the cost per pilot per passenger is $17.77

<comment><USER14> 12712 pilots * 200K average salary w/ overhead = $2.5B

That is not a small number.

$354 average domestic fair x 143M passengers = $50.6B in total fairs.

So $2.5B pilot cost is roughly 5% of their total costs. You can not lower gas costs nor airport costs nor plane costs much, but if you could eliminate $2.5B in salary, and add more flexibility, then yeah, I'd say there is massive incentive if the marketing and safety issues can be overcome.

<comment><USER15> Pilots also need (I would guess pretty frequent) (re-)training, hotels, lounges, long term parking, time off, health insurance, etc. They're not just $200K salary, they're probably more like $500K each/year in total cost once you get to 747 level, though they may only see $200k in salary themselves.

</comment></comment></comment><comment><USER16> Generally speaking, I would say that the difference in safety between a commercial aircraft and a common car is essentially the quality of who is driving.

The first is driven by a professional pilot, someone who belongs to an elite, that has spent many long hours in studying and training, that has passed several (I believe not at all easy) licensing tests, subject to continuous checks (medical, drugs, alcohol, etc.) periodical exams and ability tests, continuous update and that is never or almost never left alone in the cockpit, with a colleague ready to intervene or to assist him/her if/when needed.

The second can be driven by anyone, including almost inexperienced kids, elderly people, drivers under the effect of this or that drug, of alcohol, having distractions (think about phones, pets or children in the car), the licensing and medical tests are either extremely easy to pass or very rare, like one every 5-10 years, etc.

Still, there are not as many car crashes as there could be (i.e., if you prefer, even sub-standard car drivers can often drive good enough as to not cause too many accidents).

We don't have right now the techology to fully replace a single average car driver, and we plan to replace _two_ much higher standard aircraft pilots?

</comment><comment><USER17> Makes sense. Apart from the ground, it's harder to collide with other objects in 3 dimensions than it is in 2 dimensions.

</comment><comment><USER18> Before we get too excited about self-flying planes, watch the following video, which is the NTSB's animation of US Airways 1549 landing in the Hudson River after having both engines knocked out by geese:

[https://www.youtube.com/watch?v=5S5hRRio-E8](https://www.youtube.com/watch?v=5S5hRRio-E8)

If this happened to a self-flying plane, would someone on the ground be able to remotely take the controls in a matter of seconds and land it safely (or at least avoid crashing it into a densely populated area)?

<comment><USER19> This is a good example of why anecdotal evidence is a bad way to make decisions (also - why the entire world is making the humongous mistakes of ditching nuclear right now because of a couple examples of things going wrong; despite nuclear having saved millions of lives vs. the few it has cost).

For every example like this, there are many more you can point to where NOT having self-flying planes cost everybody on board their life. From hijackings like 9/11, to rogue pilots like MH370 or the Germanwings crash, to simply human error like the SFO Asiana crash, the SFO Air Canada almost-crash, or the Tenerife collision, or the Air France Atlantic crash, or many many more…

</comment></comment><comment> King-Aaron As long as they have an inflatable Otto in the pilots seat, I can't see it being a problem.

</comment><comment><USER20> The most interesting change that self-flying planes could enable is making small planes & helicopter transportation viable for everyone.

Assuming automation progresses to the point where safety is solved (i.e. at least as safe as in a car), and that noise is also solved, you could imagine a large quadcopter style drone that will pick you up and drop you off anywhere. Once it converts to electricity, the cost of operation would be very low.

</comment><comment><USER21> The reason why humans are needed in the cockpit is not about handling the perfectly automatable day-to-day routine. It's about that one-in-a-million case when several things go wrong at once in a way nobody thought of before and a pilot's judgement call could save lives while an elaborately programmed AI would get totally and completely stuck.

<comment><USER22> I don't want to pay $17 (high fake number from a poster above) for a one in a million chance of saving my life. Might as well play the lottery at those odds.

</comment></comment><comment><USER14> I think cargo planes will be the first to be automated rather than passenger jets. Less marketing problem.

</comment><comment><USER23> If I had to try and solve the marketing problem, I would try and focus on the security angle. "This plane can't be hijacked by a terrorist", "this plane would have stopped 9/11". Although, flying a plane remotely like a drone would present a huge hacking risk and would be hard to trust in a major cyber war. I'd prefer an entirely AI based solution with a remote piloting fallback.

<comment><USER24> A remote pilot on call for emergencies? Interesting. I'm picturing a room full of people who are on alert, as a service for near-instant, on-demand remote vehicle control; avoid car/plane crashes, land planes, sort of navigating the edge cases where human contol is still needed to bridge the gap

</comment></comment><comment><USER19> Planes are already pretty much fully automated. Humans make mistakes far more often than computers. Pretty much every airplane crash in the history was caused by simple human error. The more we automate, the better.

As someone who also flies >150k miles a year, I'm happy about this.

</comment><comment><USER25> "Air traffic controllers can issue changes directly to the autopilot, usually altitude adjustments."

Let's hope no one learns to hack that system.

</comment><comment><USER26> Interesting they see the pattern as going -> one pilot -> full automation. I would prefer to go from 2 pilots to no pilots if it happened. I don't like a single person being in complete control over the aircraft due to mental health etc. That said, I like full automation even less.

</comment><comment><USER27> Beyond the marketing there's the issue of who to blame when things go bad. These days the airline will always say "pilot error" is to blame. Once the pilot is gone that excuse obviously won't fly.

<comment><USER28> That's a problem for the insurance companies not the airlines.

The reputation damage for the airline is more or less the same.

Also note that while pilot error is the conclusion of about 60% of all aircraft accidents it's not the case for major airlines flying big passenger jets.

That statistic is inflated quite a bit by smaller chartered flights since it counts all accidents with 5 or more passengers onboard.

Also note that that statistic also shows that the majority of accidents happen on taxing, landing or take off. You'll be surprised by how many taxing accidents there are that cause fatalities which are deemed as pilot error despite that no passenger have been killed but rather ground crew.

There are more taxi accidents than there are accidents at cruising altitude.

So yes pilot error is a big factor, it's smaller for hull loss accidents for large commercial jets but it's still the case.

I should also note that a fatal accident can also still be pilot error despite it having a different root cause like a bird strike or a mechanical problem if the pilot did not perform correctly.

</comment></comment><comment><USER29> Market them as hijacker-proof.

<comment><USER30> Aircraft have more mechanical failures then hijacking attempts. The labor savings are not significant enough to warrant autonomous passenger/cargo jets.

> In the meantime, it seems unlikely that we'll see mass unemployment of > pilots. Mandatory retirement will see 42% of US pilots retire in the next > ten years. If anything, this shortfall will push the automation case forward > faster than ever.

This is a misnomer. There is no pilot shortage. Next time you fly a commuter flight, ask your pilot how much they make (it's about $20k-50k/year). There are an overwhelming number of available pilots in the training pipeline.

Just as with truck drivers, its not a labor cost problem. Its a corporate disdain for cutting into profit margins.

[https://www.bloomberg.com/news/articles/2017-08-17/-smokey-a...](https://www.bloomberg.com/news/articles/2017-08-17/-smokey- and-the-bandit-charm-fades-as-truck-driver-hiring-lags)

"The annualized driver turnover rate at large truckload fleets was 74 percent in the first quarter and the industry was short about 48,000 drivers at the end of 2015. That shortage is expected to balloon to almost 175,000 by 2024, according to the American Trucking Associations."

"Raising salaries is another option, but it would cut into profit margins. The University of Pennsylvania's Viscelli said companies would have to double driver pay -- now about $41,000 -- to reduce turnover. About 30 percent of new drivers quit in the first three months, according to Stay Metrics."

<comment><USER31> My wife is an Airline executive and I just showed her your post, she had a good laugh about your comment on labor and wages. Labor is the 2nd greatest cost after fuel. There are a lot of pilots making well over 100k - 250k+ a year. The problem is not cost. They can pass that along to the customer. It's union contracts.

<comment><USER30> The top 25 legacy airline executives make, cumulatively, a bit under $90 million/year. The average annual wage per airline employee is about $60k/year. The median pilot wage is ~$120k/year (the average is ~$80k/year).

EDIT: (crew is the lowest component of per hour flight time)

B757-200 FOC

Costs per block-hour of operations (avg. 186 seats):

CREW $ 489

FUEL $ 548

MAINTENANCE $ 590

OWNERSHIP $ 923

TOTAL FOC $ 2550 per block-hr

Ref: [https://www.icao.int/MID/Documents/2017/Aviation%20Data%20an...](https://www.icao.int/MID/Documents/2017/Aviation%20Data%20and%20Analysis%20Seminar/PPT3%20-%20Airlines%20Operating%20costs%20and%20productivity.pdf)

<comment><USER31> This information maybe accurate for Iran but I highly doubt it is accurate for US Airlines.

</comment></comment></comment></comment></comment><comment><USER32> No, since drones have a crash rate that's multiple-times higher than manned airplanes.</comment>


Google to Android Hardware Manufacturers: Be Generic - <AUTHOR> http://thesmallwave.com/google-to-hardware-manufacturers-be-generic

<comment><USER2> Started out with potential and then the author quickly put Steve Jobs' junk in their mouth. The notion that you can only manufacture successful products by controlling both the software and the hardware is not just silly, it's empirically denied.

What a waste of a good submission headline.</comment>


Why the Google Chrome Comic Rocked - Scott McCloud's "Invisible Art" - <AUTHOR> http://www.krisjordan.com/2008/09/09/why-the-google-chrome-comic-rocked-scott-mcclouds-invisible-art/

<comment><USER2> Buy the books. Understanding comics is just plain interesting. A good story, well told. Haven't read the follow-ups. Guys like McCloud break open the perception of what graphic storytelling can look like. More money to him = a good thing in my book.

<comment><USER3> Reinventing Comics is just about as awesome.

Making Comics is good, but only if you're interested in, you know, making comics. The others are fun and enlightening for most anyone who reads comics.

<comment><USER4> I want to read a zomplet run of Zot!

Shoot... the entire run of Comico books would be great.

(I miss the black and white independent comics fad of the 80's. Adolescent Radioactive Blackbelt Hamsters? Anybody?)

</comment></comment></comment><comment><USER5> The comics were good to me because they explained why Chrome should be exciting, as opposed to just being told "Chrome is fast."

<comment><USER6> Having the priorites behind the project (improving the general body of freely available libraries for future browsers, encouraging sandboxed processes for each separate tab, etc.) makes it seem far more significant than just a new, fast browser. (If I want a fast browser, I use w3m or dillo. That's not the point.)

</comment></comment><comment><USER7> A comicbook? Maybe Joel Silver, film producer, will make it into his next movie...

</comment><comment><USER8> There's a sequel to the McCloud book, too. Don't remember the name, but it was good, too.

<comment><USER9> There are two sequels, _Reinventing Comics_ and _Making Comics_.

<comment><USER10> _"... There are two sequels, Reinventing Comics and Making Comics ..."_

There is another out his anthology of Zot ~ <http://www.scottmccloud.com/zot/index.html></comment></comment></comment>


Sync vs. Async Python: What Is the Difference? - <AUTHOR> https://blog.miguelgrinberg.com/post/sync-vs-async-python-what-is-the-difference <comment><USER2> > If these hundred tasks make heavy use of the CPU, then the sync and async > solutions would have similar performance, since the speed at which the CPU > runs is fixed, Python's speed of executing code is always the same and the > work to be done by the application is also equal.

I think one of the things the author has not discussed is that if you have high CPU then you are going to get starvation as async does not have a fairness mechanism - timesharing is co-operative and based on FIFO in all the implementations I've seen.

If you start to saturate CPU (even a bit) you get uneven distribution of cpu time between your various async threads. This translates into chronic timeouts. For async to be applicable you really need to have a) high io load and b) lowish cpu load.

<comment><USER3> > ... you are going to get starvation as async does not have a fairness > mechanism - timesharing is co-operative and based on FIFO in all the > implementations I've seen.

If it's FIFO based, why would you get starvation?

<comment><USER2> FIFO systems can have starvation when dealing with time bound things like web requests - slow request handlers can cause other (waiting) requests to timeout.

In a thread-per-request or process-per-request model where you run say 4 * cpu workers the operating system scheduler is able to interrupt stuff that's hogging the CPU but that isn't the case in a typical 1 * cpu worker async model.

When there's little cpu load this is not a real threat but when there is material load you can easily run into problems.

<comment><USER3> I see; it sounds like latency would become very unpredictable under that model. I can imagine that's a serious problem in practice, but it's not typically what's meant by starvation.

[https://en.wikipedia.org/wiki/Starvation_(computer_science)](https://en.wikipedia.org/wiki/Starvation_\(computer_science\))

<comment><USER4> "Task does not receive resources to advance within the required time interval" is exactly starvation. A "task" here is responding to a request. The required time interval is the timeout.

<comment><USER5> "Starvation" is being denied the necessary resource indefinitely. What you describe is "soft real-time failure".

<comment><USER4> I think these are equivalent when applicable, because starving a task long enough of a resource for either the resource to expire or the task's deadline to expire has the same effect as starving the task of the resource indefinitely: task fails to progress.

<comment><USER5> That's called "firm real-time failure". Again, the standard definitions of starvation/liveness only use "eventually" and "never" without mentioning actual physical time IIRC, and the real-time systems use a whole another bunch of concepts to deal with actual, physical time.

And it doesn't really fail to progress if it's cancelled on deadline expiration, it progresses to a non-successful completion. If it instead hanged indefinitely, yes, that'd be a problem.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> If you're curious about this topic then I would love to link you to [https://techspot.zzzeek.org/2015/02/15/asynchronous- python-a...](https://techspot.zzzeek.org/2015/02/15/asynchronous-python-and- databases) written by Mike Bayer (author of SQLAlchemy) -- it's an article that I keep referring to as a must-read, incredibly well written and all about real-world implications (totally transferable to other non-Python ecosystems).

If you like to, maybe also have a read into [https://gehrcke.de/gipc/background.html](https://gehrcke.de/gipc/background.html). This is where I tried to put into words what I learned a couple of years ago when I wrote a library for the gevent ecosystem. You'll find some paragraphs about "Cooperative scheduling vs. preemptive scheduling", about "Asynchronous vs. synchronous", and about a few more simple and yet important topics in the world of event-driven architectures.

</comment><comment><USER7> Not mentioned in TFA, but I'm utterly convinced that the only compelling reason for async is to avoid the per-thread stack memory allocation of 8MB per thread or whatever it is, in order to be able to scale to an extremely large number of concurrent threads/coroutines. You can't do this with threads.

Async lets you do this whilst still storing the state of unfinished things in a stack, i.e. not having to make a million callbacks. Making it look like you're using threads even though you're not.

The better async code and interfaces become, the more it looks like regular old multithreaded code, except there aren't actual threads underlying it. You still need to make sure you serialise access to shared resources, don't share data that shouldn't be shared, etc. All the same considerations as multithreaded code.

Almost ends up looking like the underlying mechanism: threads with a GIL vs async ought to be an implementation detail that doesn't require you to modify your entire programming model.

Extension code not holding the GIL can still run in true parallel with real threads, so that's a meaningful difference but is usually not relevant for IO where async is usually used.

<comment><USER8> > avoid the per-thread stack memory allocation of 8MB per thread or whatever > it is, in order to be able to scale to an extremely large number of > concurrent threads/coroutines. You can't do this with threads.

It's 8 _K_ B per thread, so you can scale a thousand times further than you thought. One dark secret of the async movement is that if your goal is C10K (10,000 concurrent clients) then actually bog standard threading will handle that fine these days.

> The better async code and interfaces become, the more it looks like regular > old multithreaded code, except there aren't actual threads underlying it. > You still need to make sure you serialise access to shared resources, don't > share data that shouldn't be shared, etc. All the same considerations as > multithreaded code.

Depends what approach you're using. I prefer making an explicit distinction between sync and async functions ( [https://glyph.twistedmatrix.com/2014/02/unyielding.html](https://glyph.twistedmatrix.com/2014/02/unyielding.html) ), so you effectively invert the notion of a "critical section" \- instead of marking which sections can't yield, you mark which sections can yield, so your code is safe by default and you can introduce concurrency explicitly as and when you need it for performance, rather than your code being fast-but-unsafe by default and you're expected to fix a bunch of rare nondeterministic bugs with minimal support from your tools, which is how it works in a multithreading world.

<comment><USER9> > It's 8 K B per thread, so you can scale a thousand times further than you > thought. One dark secret of the async movement is that if your goal is C10K > (10,000 concurrent clients) then actually bog standard threading will handle > that fine these days.

Default virtual memory allocation for threads on Linux distributions tends to be 8 megabytes. Actual memory used is the peak stack depth used, rounded up a bit. It'd be pretty unusual to only use as little as 8 kilobytes per thread; just the standard per-thread libc context information for concurrency is a few kilobytes, plus at least one page of stack, plus the kernel's information about the thread (which isn't counted against the process)...

Yes, you can spawn thousands of threads on relatively modest hardware; I was spawning thousands of threads a decade ago.

Spawning 5000 bare-minimal python threads that do nil seems to use about 300 megs of ram on my system; real threads that do anything substantial will use a whole lot more, even if their use of the stack depth is intermittent.

Not to mention allocators that cache part of freed heap per-thread, etc.

<comment><USER10> I believe 8k is the size of the per thread stack on the kernel side. This is non-pageable memory, so it will consume physical memory whether it is needed or not, while of course the 8 megabytes is paged in on demand.

<comment><USER9> Yah, I'm ignoring the kernel stack and all kernel data structures. User space memory used will be at least a page of stack (reaching up to the maximum amount used in the thread), plus the libc reentrancy data structures, plus per-thread heap caches, etc. It's can all get paged out, but we hardly want that these days.

The key distinction is that the 8MB of stack VM doesn't have a backing until the memory is used in the thread, but afterwards it does forever.

<comment><USER8> Well, it's forever if you assume that the threads live forever; for a web server it's perfectly practical to have threads that only live for a single request, or to reuse them for multiple requests but not allow a single thread to live longer than say 10 minutes.

<comment><USER9> Decent nits, but...

Short-lived threads (for one request) are a performance and scalability disaster; tens of microseconds or worse to spawn and join, contention on important locks, bad for caches, etc. There's not much concurrency when it comes to _spawning_ threads, too.

If you have long-lived threads in a pool, yes, they may not live forever, but you generally have to assume that each thread will end up with a resident stack size equal to the largest stack use: each will get a turn to run the stack-intensive functions.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> All this async stuff should die as soon as possible. It exposes the limitations of the underlying tech and forces the application developer to deal with things that the systems level people couldn't bother with.

Look at the Erlang eco-system to see how this is done the right way.

Threads, asynchronicity, locks and so on should be dealt with at the OS or the framework level, _not_ at the application level.

Javascript also suffers from this and it makes JS ugly and hard to read. Callback hell will be yours or you end up with crutches such as promises.

At the application level things should be as deterministic as possible and the default should be that statements executed in sequence will have their side effects updated in sequence as well.

<comment><USER12> Thanks to the async/await keywords, modern javascript is not a callback hell anymore.

<comment><USER11> No, now you get it all mixed up. One library will use callback functions you supply, another will use callbacks but inline them and yet another will use async/await. And you, the application developer are left somewhere in the middle.

Oh, and you can't use 'await' in the main thread of your JS, you can only use it from within another async function, so when you need it most - for instance during application start-up - it isn't available.

<comment><USER12> You can use promisify for the first one. For the second one I think these libraries doing that but still not supporting promises are not that common anymore but nothing you can't do with promises yourself.

Javascript has a single thread, but I see what you mean and it has been fixed recently. To support older versions you can simply declare an anonymous async function and execute it immediately.

</comment></comment></comment></comment><comment><USER13> > _Greenlets are similar to coroutines [...] the async ecosystem in Python is > fractured in two big groups._

Async in software development in general is fractured in two big groups. On the one hand languages like C#, C++ and Dart support (stackless) coroutines like Python's - and on the other hand, Go, Java and Lua support stackful coroutines that are more like Python's greenlets.

There are pros and cons to each approach. I wonder if one or the other will eventually become dominant.

<comment><USER14> What is Java's support for "stackful coroutines"?

<comment><USER13> Project Loom: [https://wiki.openjdk.java.net/display/loom/Main](https://wiki.openjdk.java.net/display/loom/Main)

<comment><USER15> You used the present tense. Loom is not available yet.

</comment></comment></comment></comment><comment><USER16> I just want to rep Trio, mentioned in the article. I'm using it to prototype a system in a different language before doing another iteration of said system and it's is quite nice to use, at least compared to what I remember asyncio being like.

<comment><USER17> > it's is quite nice to use, at least compared to what I remember asyncio > being like.

Yes, I agree. Fairly recently there's been anyio [0], which brings ideas from trio to other async libraries, in particular asyncio. E.g. it has equivalent of trio nurseries (what anyio calls "task groups") for implementing structured concurrency ideas in asyncio environments (saving you from headaches due to having to deal with tasks manually). Very neat way to use trio ideas when stuck on asyncio (e.g. for web apps). :)

anyio was also discussed in the latest Python Bytes episode [1].

[0]: [https://github.com/agronholm/anyio](https://github.com/agronholm/anyio)

[1]: [https://pythonbytes.fm/episodes/show/197/structured- concurre...](https://pythonbytes.fm/episodes/show/197/structured-concurrency- in-pythonB)

</comment></comment><comment><USER18> I absolutely love async Python.

It lets me do stuff that would be hard with ordinary Python.

No doubt it takes some effort and practice to grasp, but once you have it worked out you'll find it's a powerful tool in the toolbelt.

Many languages now have async and await - it's not exclusive to Python. The reason so many languages have gopne this way is that so far it's the easiest and most sensible solution to writing concurrent code in a way that won't become incomprehensible.

And if you are trying to get your head around it, the easiest analogy is the web browser and JavaScript. If you have grasped JavaScript and the event loop then essentially you have grasped async Python, or not far from it.

Some people misunderstand async Python - they think the point is to make Python faster - it isn't. The point is to enable concurrent programming.

I do understand the haters - at first, until you grasp it, async Python so incredibly foreign and so different from ordinary synchronous Python that you might think "AAAARGH why did they do this and make it so hard"? But really it's not hard once you grasp the mental model of what is going on.

<comment><USER19> I had so much trouble getting the python tcp client to work like I wanted it to. Then I tried my hand on the async tcp client and was pleasantly surprised how simple it was.

        reader, writer = await asyncio.wait_for(asyncio.open_connection(), connect_timeout)
        line = ""
        while True:
            line = await asyncio.wait_for(reader.readline(), read_timeout)
            if line == b"":
                break
            yield line

<comment><USER18> I've written a bunch of things that were really well suited to async Python including an mpjeg server, a queueing server and a process management server that monitors the stdout and stderr of various processes and reads them in real time and acts upon the messages it reads.

Each one of those applications was made possible comprehensible and even easy by async Python.

<comment><USER19> I made a python clone of multitail in just under a day thanks to being able to read multiple files simultaneously with async. It really is overpowered.

</comment></comment></comment></comment><comment><USER20> I'm very uninformed when it comes to async in Python so please bear with me.

Given a "web API type" python app, where about 30% of the APIs also reach out to other, external APIs, before responds to the incoming requests...

Is that _the_ classic example where async would provide a solid benefit?

Is that why Node has become so popular = it's all json + non blocking API responses?

<comment><USER21> That's where it _could_ provide a solid benefit (though you could probably usually do better by instantiating an appropriately sized thread pool and avoiding async entirely), but that's missing the real power of async which is that it makes concurrency easier to reason about. Except at an await the application behaves serially; you can't get interrupted in between lines or in the middle of an operation that it turns out isn't atomic.

<comment><USER22> "it makes concurrency easier to reason about"

Doesn't it do that by not really having concurrency? There is only a single locus of control so a whole class of problems should simply cease to exist.

<comment><USER21> We might be nit-picking definitions, but I don't think that's a fair characterization. From the perspective of the user programming with async, when you gather the results of two coroutines you don't care at all the order used for each stack frame. The mental model is one of concurrent operations which might suspend at yield points.

</comment></comment></comment></comment><comment><USER23> What this really highlights is that you need to learn the basics to make the right decision for your application and platform. There's no one solution for everyone but if you don't take the time to understand context switching and the role of your OS then you will be doomed to tilting at windmills.

</comment><comment><USER24> Didn't know that about Flask. One learns something new every day, even with tools one's been using for years.

Actually, I gotta take a closer look to greenlets in general.

</comment><comment><USER25> tangentially, I'd like to give thanks to Miguel Grinberg for getting me started on flask and sockets in python via his posts.

</comment><comment><USER26> Any emacs users know of a linter that will tell me when I forget to await a coroutine?

<comment><USER27> Pretty sure I added a lint rule to pylint the other day that will do just that. I imagine emacs has a pylint plugin.

Basically you add a linter that overrides `visit_callfunc()` and make sure it's not an async function being called.

<comment><USER26> Cheers.</comment></comment></comment>


Show HN: Bright, a metric and visualizer of how inspirational a GitHub repo is - <AUTHOR> https://github.com/Hellisotherpeople/Bright <comment><AUTHOR> Bright searches through all of the people who starred a particular repo, then looks at how many stars each of their repos have. It sums the total number of stars from each user to compute a "Brightness" score for a repo. It also creates a tree for visualizing what repos that your stargazers have made and which of those repos have a lot of stars.

The intuition behind this is that a user who has a cumulative 1000 github stars is likely more experienced and knowledgable than a user with 0 github stars. Repositories which have thousands of stars from fake bot accounts (whose accounts would have 0 cumulative stars) would have a brightness score of zero, but a repository which seems unimportant but had a highly experienced developer star it would have a high brightness score.

<comment><USER2> Neat! Have you found anything strange with it? Bot-star-rings or similar?</comment></comment>


Ask HN: Is GitHub's download server down in Europe? - <AUTHOR> Since yesterday I've been trying to download things hosted on github and the loading times are infinite! Most of the times I get an error after a few seconds of downloading that file. I also tried using my 3G and a proxy but it is the same. Is it happening to you? I'm in Germany right now. <comment><USER2> Don't know but here in Germany it's slow as hell.

<comment><USER2> And a the download of bootstrap (for example) doesn't work at all.

<comment><USER3> I don't have problems.

In the case of bootstrap, [https://github.com/twbs/bootstrap/releases/download/v4.0.0-b...](https://github.com/twbs/bootstrap/releases/download/v4.0.0-beta/bootstrap-4.0.0-beta- dist.zip) works fine for me.

Also the status page works fine ([https://status.github.com/messages](https://status.github.com/messages)).

<comment><USER2> Status page is loaded very slow. Thx for the link :)</comment></comment></comment></comment>


Jobs, Obama, Zuckerberg, Schmidt, Ellison, Hastings Dinner Pic Feb. 17, 2011 - <AUTHOR> http://www.textually.org/textually/archives/2011/02/21/Obama%20Dinner%20Who%27s%20Who%20Photo.jpeg

<comment><AUTHOR> Dinner was held at Doerr's home. Doerr supporting Apple: <http://www.kpcb.com/initiatives/ifund/index.html> Doerr supporting Facebook, Zynga, Amazon: <http://www.kpcb.com/initiatives/sfund/> Doerr supporting green initiative: <http://www.kpcb.com/initiatives/greentech/index.html> Westly supporting clean/green initiative: <http://westlygroup.com/portfolio/>

Was this an attempt to get the tech giants of Silicon Valley to work with the green companies for energy programs that Obama was pushing at the time?</comment>


My sabbatical research pivot - <AUTHOR> https://blogs.uw.edu/ajko/2016/05/13/my-sabbatical-research-pivot/ <comment><AUTHOR> > _In my experience, faster development didn't matter much. Developers' speed > mattered somewhat, but only to the extent that we made effective product > design choices based on the valid understanding of customer, user, and > stakeholder needs._

Lately I've been thinking that most of the value a good engineer provides is in making a vague specification concrete. Building something that works is easy; deciding _what it is_ that you are building is the hard part. You can think of the process of writing software as the process of deciding exactly how every unspecified edge case and detail in a specification will be resolved.

I wish there were more and better tools for declarative programming. Most of the time imperative programming produces overly specific solutions that are brittle and difficult to understand. It's really hard to infer the original intent of such code. A lot of solutions don't even require a Turing-complete language in the first place! For example, a library for mutating a datastore and keeping it consistent can be entirely specified using SQL-like expressions. Yet there are all these frameworks and ORMs for writing such libraries by hand using Turing-complete languages. It baffles me. /rant</comment>


The Electric Leaf's True Believers Won't Leave Well Enough Alone - <AUTHOR> http://www.nytimes.com/2011/10/16/automobiles/nissan-leafs-true-believers-wont-leave-well-enough-alone.html?pagewanted=all

<comment><USER2> Since the car has a lithium-ion battery, it really doesn't deal well with being depleted for medium periods of time. The gauge is probably done like that to lengthen the life of the battery.

</comment><comment><USER3> Can anyone parse that title? I'm failing.

<comment><USER4> Electric leaf -> Nissans' new electric car

leaving well enough alone -> keep your hands of

Rough translation: Nissan Leaf owners open up the hood to see if they can improve performance and/or charge time or other stuff.

An EV can be hacked on by electronics types in much the same way that a regular car used to be the domain of gearheads. Regular cars now need knowledge from both domains but EVs are much more accessible to EE types and other people with knowledge about the way electrons make our lives easier.

<comment><USER3> Ah, it's an idiom, thanks. I couldn't figure out the subject of "leave".</comment></comment></comment>