This Is What One Half Second of High Speed Trading Looks Like - <AUTHOR> http://blogs.smithsonianmag.com/smartnews/2013/05/this-is-what-one-half-second-of-high-speed-trading-looks-like/ <comment><USER2> One time I printed out all the code--at that time ASP, HTML, CSS, and Javascript--that got executed for one page load of the homepage of my employer's primary website. I taped the pieces of paper end-to-end and hung them on my wall.

It made a great conversation piece with my coworkers. Non-technical folks (most of them) were astounded that so much text was being interpretted and executed every single time they loaded the homepage (in less than a second).

What was the point? It helped set a certain emotional tone to our conversations. Folks found it a lot harder to demand their project be done "right now, it's easy" when directly confronted with the complexity behind a single page load.

Likewise, stories that highlight the immense speed and complexity of high frequency trading help set an emotional tone of alienation and fear. It helps trigger the same reflex Frankenstein and The Terminator played off of: "maybe we're unleashing technological forces that no one can control."

But of course if you are well and truly versed in a technology, that feeling goes away. I knew that our crappy brochure website was not very complicated as websites go.

<comment><USER3> As an ops-guy (interestingly enough, at an HFT company), I used graphviz to draw out a diagram of all the network interfaces and routes that were being used when trading on a single exchange for one single instrument.

It was a huge, big, complex, ugly thing. We laughed. Good times.

<comment><USER4> That sounds cool.... I would love to see it though understand the security concerns..

</comment></comment></comment><comment><USER5> If there was a similar video showing all of the electronic sensors of a modern airliner flowing into the central flight control computer would it would engender the same sort of trepidation about air travel? Should we be afraid of something just because it's "complicated" to someone unfamiliar with the state of the art?

There are a lot of valid criticisms you can make about modern financial markets, but claiming that we are using computers to do things better than we did 10 years ago is a bad thing isn't something I'd expect to see here on HN.

<comment><USER6> I don't see any comments here critiquing HFT simply because it's complicated. Rather, they seem related to whether it's actually a net-positive for society.

<comment><USER7> Every description of an HFT algo seems to fall into one of three categories:

* Acting on public information, milliseconds before anybody else - which helps everybody else about as much as insider trading does.

* Acting on trading information gleaned from "bid stuffing" (making and canceling orders really quickly) - which helps everybody else about as much as front running does.

* Detecting the presence of large trades about to go through or going through and capitalizing on the price movements they cause - i.e. imposing a tax others making large trades in the stock market.

In return, they flood the market with liquidity when it is least needed and withdraw it suddenly when it is (e.g. when prices are diving).

There's literally nothing to like about HFT.

<comment><USER8> _Acting on public information, milliseconds before anybody else - which helps everybody else about as much as insider trading does._

"They can do it faster, therefore it must be illegal."

 _Acting on trading information gleaned from "bid stuffing" (making and canceling orders really quickly) - which helps everybody else about as much as front running does._

The only people that notice this behavior are...other people capable of doing this behavior. Why should it matter to you, the long-term investor, the trading tactics computers employ at the millisecond scale?

 _Detecting the presence of large trades about to go through or going through and capitalizing on the price movements they cause - i.e. imposing a tax others making large trades in the stock market_

This happens in any market at any timescale. Everyone capitalizes on trends.

<comment><USER9> You are replying to the wrong points.The question is not are these things illegal, or does everyone do them.

question is, do they benefit the market as a whole? Traders do not have a right to perform HFT, and if it destabilise markets, we can take steps to reduce it (of course, there is then the issue of how to take steps without causing different problems)

<comment><USER10> How else would you connect the exchanges? Or you don't want major exchanges to be connected, and say, if you dump a lot of stock at one exchange you don't want that information to propagate to other exchanges?

Benefits of having HFT traders, is that at the cost of having them around you can have fair and level ground. So if you come to one exchange to do a transaction, you don't have to think much about exchange intrinsics, like liquidity available there, fee structure, etc. Because these differences are being arbitraged away by HFT traders.

And again, what is the alternative? Exchanges that are connected by human traders making phone calls?

<comment><USER11> The real question is: Why are there multiple exchanges for the same papers to begin with?

In the case of stocks, for example, there has to be one ultimately authoritative copy of who owns which stocks anyway. So why not just do all the trading in the place where the authoritative copy is stored?

That would certainly seem to be more efficient from the perspective of minimizing the overall social cost.

<comment><USER12> The reason there are multiple exchanges is the same reason you can buy the same pair of shoes at 10 different places: it is competition.

Also, what is the social cost you are referring to? There are a lot of people here saying that HFT doesn't provide "social value". Does it somehow provide less social value than traders screaming at each other in the pits? Similar types of trading always existed, except now it's done by computers. For what it's worth, HFT provides well-paying jobs for a lot developers and ops people and often is very supportive of the engineering community.

<comment><USER11> If you try to design a system of publicly traded companies from first principles, then the purpose of exchanges should be to provide a service _to publicly traded companies_. That service would be maintaining the authoritative record of who owns how many shares of the company.

Given this notion, competition is a good reason for the _existence of_ multiple exchanges, because it means companies can change which exchanges their shares are traded over. However, it is _not_ a good justification for the fact that trading of the same stock happens on multiple exchanges.

As for the social cost, you do realize that HFT does not come for free to society. At a minimum, society must somehow pay for those well-paying jobs to developers. And what do those developers give back to society? Before you answer, please consider whether you should distinguish between _algorithmic trading_ and HFT. I do believe that algorithmic trading is useful to society (because it can do the job that screaming traders used to do better and cheaper), but the subset of HFT is not useful.

The only things anyone ever seems to be able to answer for HFT two-fold: one, that stock prices change faster, and two, that the spread is smaller. But one point one, nobody in the real economy cares about that, and to point two, the decrease in spread also doesn't matter to anybody in the real economy, because what you really care about there is the fluctuation of the share price over a larger timescale such as one full day. I have not seen any evidence that this fluctuation is affected by HFT in any way.

<comment><USER12> _If you try to design a system of publicly traded companies from first principles, then the purpose of exchanges should be to provide a service to publicly traded companies. That service would be maintaining the authoritative record of who owns how many shares of the company._

I don't think there's any reason to think that exchanges' main purpose for existence is to provide service to publicly traded companies. Exchanges are just a store, and their purpose is to buy/sell stuff and make a profit. So, in that sense, having multiple exchanges selling the same stock is the same as having multiple bike stores selling the same bike...it's competition and there aren't many downsides to it.

 _As for the social cost, you do realize that HFT does not come for free to society. At a minimum, society must somehow pay for those well-paying jobs to developers. And what do those developers give back to society? Before you answer, please consider whether you should distinguish between algorithmic trading and HFT. I do believe that algorithmic trading is useful to society (because it can do the job that screaming traders used to do better and cheaper), but the subset of HFT is not useful._

Nothing comes for free to society. Funding a never-ending number of failing start-ups doesn't come free to society either. What is that giving back to society? Your implication is that HFT trading is somehow _taking_ something from society that it doesn't deserve. What is it taking? Also, in terms of making distinctions: HFT is the superset and AT is the subset, not the other way around. All AT shops are HFT shops, but there are actually quite a few HFT shops that don't run algorithms and instead run based on inputs controlled by traders.

 _The only things anyone ever seems to be able to answer for HFT two-fold: one, that stock prices change faster, and two, that the spread is smaller._ This is the crux of the whole thing. Why does anyone have to _answer_ for HFT? This is implying that HFT is hurting people however you haven't not given any proof of this (besides that it doesn't _add value_ ). If anything, I think HFT's biggest crime (as someone else has mentioned) is that sucks some really smart people into working on problems of a rather limited scope.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> Two things I take away from this

1) Cool use of infographic :)

2) The little dots represent price changes, not trades.

FWIW, some more context around this would be-

All the major exchanges stream their best prices to all the other exchanges.

This is required because US exchanges must execute trades at the National Best Bid or Offer, or NBBO [1].

So how do you track the NBBO. In theory, by having all the exchanges send their best bids and offers to a central Securities Information Processor, or SIP (the 12:00 box) which then disseminates them (which you can see by the waves of stuff it sends out)

In practice, it's slow to go through the SIP on every price movement and the exchanges want to have the best possible information, so the exchanges mostly stream prices directly from the other exchanges (hence the fanout effect on every price movement)

Most of these prices movements don't result in trades, they just represent somebody entering or leaving the market at the BBO.

This feels like a distinction that could have been made better, rather than just saying "yeah, this stuff's complicated."

[1] <http://en.wikipedia.org/wiki/Regulation_NMS>

edit: formatting / citing

<comment><USER14> That's a nice explanation of the graphics.

I'm still having a very hard time understanding what kinds of events would cause so many rapid price changes. So many dots in just half a second -- even when time-stretched to 5 minutes! Are those price changes meaningful at all?

</comment></comment><comment><USER15> All comments so far are negative, but I fail to see how this video shows anything other than incredible engineering.

The negativity seems to be a result of previous bias.

<comment><USER16> It is incredible engineering and it has incredible downsides, not the least of which is the ability to destroy a market in seconds, due to a blip in information, with cascading domino effects.

<comment><USER17> Which market has been destroyed in seconds?

<comment><USER18> None. This provides profit opportunities to those who will "heal" the price.

Also, exchanges will revert back trades that happen over these flash crashes.

<comment><USER19> How long before someone (a hacker no doubt) games the system to create a selling spiral, just waiting to take profit of the rebound. If it´s well planned the one causing the dive is not going to be the one taking the profit (at least that it can be proved).

<comment><USER20> We need not wait for that to happen. Such shenanigans have been observed and documented already, such as in the book "Reminiscences of a Stock Operator." It was written in 1923, and worth reading today.

</comment></comment></comment></comment></comment></comment><comment><USER21> If we eventually decide that all of this ridiculously fast bid/offer blitzing by our HFT overlords is a destabilization risk to the economy [1], couldn't we start taxing these transactions, or the bids/offers themselves? This level of high-frequency noise being thrown into the market can't reasonably go on increasing forever, right... at some point we just bury ourselves in a never- ending war of inscrutable, difficult to predict machine trading algorithms, and nobody will be able to translate market movements into anything linkable to reality, right [2]? Shouldn't either market operators or the government at some point in the future start dialing back the traffic with penalties on the sheer number of actions taken?

... or is that just an insane non-starter, since it affects too many rich people in the finance sector and their colleagues rotating through the current regulatory structure?

I think it's an interesting long-term problem faced by society to decide whether we are OK with investment markets becoming completely impossible for "normal", human investors to navigate. It's already rapidly going that way-- the capability to profit is already wildly tilted toward firms that act at HFT volume. If a poker site became overrun by bots to the extent that it was no longer fun for humans to play, they would fight back against the bots (as most do to some degree). But with investments... we may be getting to the point where the average day trader needs a 3000U server farm to compete effectively, and then I question whether we've lost sight of why we subsidize and spend money regulating that market at all. It's like a chess league where the grandmasters get to use computers as aids, and the newcomers have to play blindfolded.

[1] Nothing catastrophic has happened yet, but there have been a few flash crashes that have necessitated trading to be shut down, and having to "roll back" trades is never perfectly equitable and only decreases confidence in a market.

[2] Some of those flash crashes were traced back to one overzealous seller that threw HFT's for a loop (read <http://en.wikipedia.org/wiki/2010_Flash_Crash> \-- it is quite interesting). I shudder to think of a day when the market fluctuates wildly and the data is literally too complicated for regulators to trace it back to any identifiable cause. That day is closer than anybody in finance is likely to acknowledge.

<comment><USER10> > we may be getting to the point where the average day trader needs a 3000U > server farm to compete effectively

Yes. That's actually a bit of a problem. It is perfectly all right that day traders are being out-competed by HFT firms, by itself that's fine. Humans replaced by computer, nothing bad about that. What is not good, is that a _successful_ entry into arbitrage market nowadays require a lot of infrastructure and technical skills.

That increased barrier _reduces_ a number of players on the market. That reduces diversity. And that increases risk. That's bad.

A simple example how that increases risk. Imagine that a single HFT firm had managed to out-compete all others. And now owns perfect infrastructure with nanosecond level latencies, speed-of-light channels between the exchanges and trading algos without any bugs and teams of quants maintaining them. Obviously no day trader will be able to compete with teams of PhDs. And no new newcomer HFT firm will be able to compete. But as a result diversity of day traders will have decreased to exactly one. And any glitch in the operation of that firm (sorry, a box that was trading SPY just crashed) will be creating flash- crash artifacts without easy resolutions to them.

So yes, an increased entry barrier into day trading is bit of a problem.

<comment><USER22> The cost of entry into the markets has gone down not gone up. It is orders of magnitude cheaper to set up an electronic trading operation than it was to be on the floor.

Further, successful entry into arbitrage markets always required specialist infrastructure and skills. They used to be good old boy networks, brightly colored vests, and arcane hand signals. Now it is programming and networking.

In the previous world there was not "NASA" effect at all. Now at least the skills can be transfered to other industries.

</comment></comment></comment><comment><USER23> It seems that the counter at the bottom counts all updates, and ends up at 2380, so the overall rate would be something like 4760/second, or 17M/hour. Note that the rate has slowed down considerably before .25 seconds have passed, and this was recorded within 10 minutes after NYSE opened, so I suspect this is a bit above the average rate. Also, these are bids and offers, not actual trades.

</comment><comment><USER24> Reminds me of:

"The following animated GIF chronicles the rise of the HFT Algo Machines from January 2007 through January 2012."

<http://www.nanex.net/aqck/2804.HTML>

</comment><comment><USER25> Light bulb: tax all tradings with a tax percent increasing with the number of transactions per second, in a continuous way (even for less than 1 t/s) that would not make any difference for regular traders (and have a tweakable taxing formula that could regulate a market's stability and sensitivity to information by letting more or less HFT happen by setting the 100% taxation limit - the HFTs will have all incentives to stop trading when they are taxed 100% or beyond - i.e. when they are "fined")!

<comment><USER26> Any kind of small transaction tax on trades would eliminate the worst excesses of HFT. It doesn't have to be complex at all.

</comment></comment><comment><USER27> Why is the video showing redundant details? It looks like for each event it shows a packet going to every server.

If they arranged the machines on the horizontal axis, time on the vertical axis, and showed 'packet sent' events it would look much simpler. Maybe simple enough to add in details about the trades, like dollar values, instead of pretty expanding explosions.

<comment><USER28> I believe that part of the actual infrastructure is you send the same message along multiple physical cables; one to each exchange. You also have to account for the delay that the message takes to be received by each exchange. (The speed of light isn't "instant" when you're working on the ms level.)

</comment></comment><comment><USER29> All in the name of "providing liquidity"...

<comment><USER30> As someone who's not too familiar with economics, how is HFT supposed to be good for the economy?

<comment><USER31> If you want to buy/sell at a price, and there's no one ready to sell/buy at that price, a speculator (of any stripe) coming in and making that deal with you means you got the price you asked for. Maybe you could have got better - that's what the speculator is hoping - but you're no longer taking that risk. Statistically, the money going to the trader is similar to an insurance premium then.

That's all "in principle" - whether the details work out right is a much deeper question.

<comment><USER32> Aren't these speculators constantly entering and withdrawing these orders from the market on the order of microseconds?

It's not like the order book for Johnson and Johnson is completely empty and there is absolutely _nobody_ out there willing to sell shares. If I understand it right, the HFT machines are poking numbers around the current price trying to step ahead of a regular order before it comes in.

<comment><USER18> Yes. That's what it does. If you, as a human, try to trade like this, the computers will destroy you. That's why people shouldn't trade like computers and they should use their experience and judgment to guide them.

<comment><USER32> So you're implying we should all be complacent and let HFT machines take a small parasitic profit off of every stock transaction humans make?

<comment><USER18> Complacent? Get in on HFT if you feel that it's making it unfair for human traders.

<comment><USER32> I'm speaking for the majority of people that can't afford racks of servers and custom-laid transatlantic fiberoptic lines. I'm speaking about typical americans that have their money in 401(k) accounts or maybe buy stocks from an online broker to try and fund their kids' college accounts.

These people are all being scraped, very slowly but very surely, by HFT. That's the point I'm making.

At least we all admit that the modern stock market has absolutely no connection to the economy or to the interests of long-term investing or capital building. It's just a very large and very legal casino.

<comment><USER18> _I'm speaking for the majority of people that can't afford racks of servers and custom-laid transatlantic fiberoptic lines. I'm speaking about typical americans that have their money in 401(k) accounts or maybe buy stocks from an online broker to try and fund their kids' college accounts._

Barriers to entry. Cost of business, etc... It's really not a concern to people who actually understand HFT and trade in their own way despite. They generally really don't mind the added liquidity.

 _These people are all being scraped, very slowly but very surely, by HFT. That's the point I'm making._

Buy in at $40. Sell at $80. Where does the computer scrape money from the transactions? It doesn't. Like I said, you're only losing if you're trying to trade like a computer. It's like trying to out-robot a robot on an assembly line.

 _At least we all admit that the modern stock market has absolutely no connection to the economy or to the interests of long-term investing or capital building. It's just a very large and very legal casino._

I disagree to the first part, and I think the second bit is an oversimplification.

It obviously matters, or else people wouldn't be upset by HFT or claim that they're losing money to it. We also have to consider the fact that pretty much all money comes through the bond and stock markets at exchanges. The exchanges are price arbitration centers for the economy. Paying attention to them matters because the exchanges and what happens there matters.

A casino is a place you go to lose money. It's all games and the odds are stacked against you. Everything we do in life is a gamble. An exchange is a place for people to make informed decisions about the prices of goods and financial instruments. Everyone loses and wins some.

I do relate to the long-term investing/capital building. The central banks keep printing money which funnels into the bond and stock markets. This in turn signals an abundance of actual economic capital, which there isn't. With the communication that there is plenty of excess capital for the long term, we (and especially people dealing in finance) act as if it is the case and start consuming capital. Eventually, facts catch up and we get some sort of terrible economic downturn. As a result of the long-term economic irregularity, actors act for the short-term because the long term is just too undependable.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> >You already have welcomed your robot overlords, and they're building our financial system.

Enough said.

</comment><comment><USER34> To get the perspective of different participants in the market watch this video from The Milken Institute featuring Bart Chilton (regulator), Terry Duffy (exchange), Jamil Nazarali (retail execution), and Lou Salkind (proprietary trading).

They address a lot of the common criticisms of modern markets discussed here. It provides a good perspective of what people within the industry see as the current state and future of trading.

[http://www.youtube.com/watch?v=icNGvgd27-A&feature=youtu...](http://www.youtube.com/watch?v=icNGvgd27-A&feature=youtu.be)

</comment><comment><USER35> The radiolab podcast is well worth a listen for a bit of layman's insight into HFT. The conclusion at the end makes it clear what the implications are.

</comment><comment><USER36> And the exchanges are making a killing off of this volume. You can thank the SEC and FINRA for this.

</comment><comment><USER37> We will keep cutting up time into smaller and smaller chunks until we cannot go any further.

</comment><comment><USER38> HFT is used for many things, but it makes one task almost trivial: stop hunting.

</comment><comment><USER39> Isn't the, "one" in the title redundant?

Would you say two half seconds rather than just a second?

</comment><comment><USER40> Just how profitable is HFT anyways? What kind of returns do HFT traders get?

<comment><USER22> Depends. It is mostly a zero sum game, so all told $0. Of course, some people make lots and some people make -lots.

<comment><USER41> While intraday trading as a whole is zero-sum, the HFTs are taking profits from other traders, not from each other. HFTs as a group are profitable.

<comment><USER42> A good amount of HFTs fail. I've heard numbers ranging from 70%-90% of new HFTs fail within their first 2 years. Very similar to startups when you think about it.

Also, HFTs are most definitely taking profits from each other. In fact, in a lot of cases the faster, more successful HFTs kill off the new ones to the market. Not to mention there are a good number of predatory HFTs who exist solely to game other HFTs</comment></comment></comment></comment>


Uber executive fired amid reports he obtained rape victim's medical records - <AUTHOR> https://www.theguardian.com/technology/2017/jun/07/uber-executive-fired-eric-alexander-rape-case-india <comment><USER2> Extensive discussion: [https://news.ycombinator.com/item?id=14507917](https://news.ycombinator.com/item?id=14507917)</comment>


A selection of proposed German words - <AUTHOR> http://www.nytimes.com/interactive/2013/10/12/opinion/international/20131011_Schott.html

<comment><USER2> I'm German. What kind of proposal is this?

As already pointed out these words are constructed from other more basic words. As the German language allows for this, some people like it to juggle around and come up with (more or less) funny words.

I guess the majority of English-speaking natives find this funny.

<comment><USER3> agreed. tldr as I read it: "lol look at these long words I found in the German dictionary"

</comment></comment><comment><USER4> This is advertisement for a book that is about made-up words.

I find it interesting that it is all one giant image and how the wild number of typographic styles confuses me immensely.

</comment><comment><USER5> Please note, that most of these words aren't real German words, but are constructed from other German words.

Some of these words make not the slightest sense even to a native speaker.

<comment><USER6> Most of them are perfectly valid hypothetical neologisms, and I'd say that Fingernageltafelquietschen is perfectly cromulent.

What really grates me about that list is that they write supposedly german words in broken letters without distinguishing final and terminal "s". It should be Fingernageltafelquietſchen and Tageslichtſpielſchock, not Fingernageltafelquietschen and Tageslichtspielschock. (I remember getting that one after watching all three Back to the Future movies back to back on a sunday morning, it was still like, early afternoon after that... totally confusing.)

<comment><USER7> (yes, I'm bored right now, so ... spending a lot of time writing a HN comment ;-) )

Actually none of those are proper German words, it's even the article that tries to propose _new_ terms. And yes, we Germans like to chain together words to make new and longer ones on demand, but obviously some combinations are more likely to be understood than other ones.

The ones that I assume are understood immediately by every German speaker, they use unambigous terms that allow only one interpretation and could also come up in casual conversation without someone raising an eyebrow:

• Eisenbahn·schein·bewegung — railway · virtual · motion

• Fingernagel·tafel·quietschen — fingernail · blackboard · squeal

After introduced by someone, the following could easily become part of the language spoken by maybe a group of friends, say because they just fit very well when gossiping about someone or something after a party, or maybe were a fun way to tell some story:

Easy after thinking briefly about it:

• Schmutz·wort·suche — dirty · word · search

• Plausch·plage — prattle · plague

A little more obscure, more context to explain (see the article), but probably halfway ok:

• Leer·tretung — void · stepping

• Bagger·spion — digger · spyhole

• Mund·phantom — mouth · phantom

• Feten·lauschangriff — party · eavesdropping

• Götzen·geschwätz — false goods·chatter

• Herbstlaub·tritt·vergnügen — autumn foliage · strike · fun

The following one, I'd say no one could use without running into the danger of being called a lunatic. They use a lot of uncommon, antiquated or technical terms and you can basically make up any meaning for those composites, as you'd like. Absolute bollocks.

• Tantalus·qual·erlösung — Tantalus·torment·redeption [tantalusqualen probably most people have to look up to find out that it's a name given to very severe pain]

• Zeigarnik·frustation — Zeigarnik·frustration [Zeigarnik effect seems to be a psychological technical term]

• Fingerspitzen·tanz — fingertips·dance [absolutely ambigous]

• Tageslichtspiel·schock — [tageslicht=daylight, lichtspiel=antiquated word for movie projection, schock=shock]

• Marksismus — "marxism", with "Karl Marx" replaced by the old german currency "Mark" [also completely ambigous]

This one is actually funny, because of the play on words:

• Dorn·höschen·schlaf — thorny · panty · sleep (but also sounding very siminar: Dornröschen — The Sleeping Beauty)

</comment></comment></comment><comment><USER8> None of these proposals are catchy (or funny) enough to establish themselves, except:

\- Plauschplage

\- Dornhöschenschlaf

I really might accept "Plauschplage" into my vocabulary.

</comment><comment><USER9> The Dutch language can do this too ... For example:

hottentottententententoonstelling

</comment><comment><USER10> Um...Sniglets?</comment>


Apple Notification Center Service (ANCS) - <AUTHOR> http://waffle.wootest.net/2013/09/18/ancs/

<comment><USER2> Yep, this could not in any way be used for something else, such as the already announced iOS in the Car [1] program.

I get the feeling that the iWatch will be the next "Apple will make a full sized television." Maybe it will happen, but only after 5 or 6+ years of analysts saying it will come out at the next Apple event.

Look at Samsung's watch. It's big, it's ugly, it requires a high end cell phone, it's battery is only good enough for about a day, and _it 's $300_. Maybe Apple can do better, there is a _long_ way to go for something that fancy. If you go to something simpler like a Pebble, there is less room to stand out.

Besides, does anyone think Apple can resurrect the watch industry? I'm sure they'd sell tons, but nothing compared to the tablet or phone markets.

[1] [http://en.wikipedia.org/wiki/IOS_in_the_Car](http://en.wikipedia.org/wiki/IOS_in_the_Car)

<comment><USER3> Yep, nothing in this diagram implies that a smart watch would be the Notification Consumer.

[https://developer.apple.com/library/ios/documentation/CoreBl...](https://developer.apple.com/library/ios/documentation/CoreBluetooth/Reference/AppleNotificationCenterServiceSpecification/Art/notificationAttributeRetrievalExample_2x.png)

<comment><USER2> Well crud.

</comment></comment></comment><comment><USER4> I remember before the iPhone was announced there was so much frenzied but non committal speculation that I thought that if apple weren't making a phone then they would have to be complete idiots.

Then the word phone appeared in some meta data file and word got out, and still I failed to buy the stock just before the keynote.

</comment><comment><USER5> >Now, if only we could figure out why Apple jumps through hoops to support a smart watch.

i get what you're hinting at, but it also sounds like it could be useful for ibeacon.

<comment><USER2> My impression was the beacons were passive. Even if they aren't, I'm not sure why my notifications would need to be sent to it.

I think this sounds suspiciously useful for iOS in the Car [1]

[1] [http://en.wikipedia.org/wiki/IOS_in_the_Car](http://en.wikipedia.org/wiki/IOS_in_the_Car)

<comment><USER6> > Siri: Eyes Free mode – for eyes-free and hands-free operation.

HFP already works with iOS

> Satellite navigation (Satnav).

this is interesting, but is more likely built on top of an existing GATT profile, such as L&N

[https://developer.bluetooth.org/gatt/profiles/Pages/ProfileV...](https://developer.bluetooth.org/gatt/profiles/Pages/ProfileViewer.aspx?u=org.bluetooth.profile.location_and_navigation.xml)

> Telephony instruction and control.

HFP works to some extent. PBAP is part of this.

> Music control.

AVRCP 1.4 already works ([http://support.apple.com/kb/HT3647](http://support.apple.com/kb/HT3647))

> iMessage control and response.

MAP already works for this

</comment></comment></comment><comment><USER7> This excites me very very much!

</comment><comment><USER8> iWatch anyone?</comment>


Unconventional But Yet Successful Online Homebusiness Ideas - <AUTHOR> http://nichegeek.com/10_unconventional_but_successful_online_homebusiness_ideas <comment><USER2> My first startup was homebased. It took almost 2 years before it started doing good.

Most canned solutions for homebased businesses are total scams. You really have to conjure up something yourself if you want any chance at success.</comment>


Declined Proposal: A built-in Go error check function, "try" - <AUTHOR> https://github.com/golang/go/issues/32437#issuecomment-512035919 <comment><USER3> This hits at something fundamental about Go, which is what I like the most about it...

It's a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you're forced to carry them up the chain.

Do I particularly _like_ managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects.

The same goes with the Go ecosystem and tools. You might not like how gofmt forces your code or the documentation conventions used by golint but the fact that we all use the same convention and documentation is awesome and it's what allows things like godoc.org. I think the proverb is "gofmt's style is no one's favorite, yet gofmt is everyone's favorite".

And things like the lack of abstractions and generics are what create a community that's less reliant on dependencies. "A little copying is better than a little dependency" and you can see it in stark contrast to something like the JS community with its require('left-pad') NPM ecosystem.

So, yeah, I like that they didn't fragment the community around something as arbitrary as this. And I get that some people won't like it, just as they don't like the lack of generics, but there is strength in some of these approaches that isn't immediately obvious.

<comment><USER4> > Do I particularly like managing errors that way? No, but I do think that it > improves the transparency and quality of a lot of Go projects.

So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics.

That lead to a world where folks felt "forced" to use Java, and that's a sticky label that's difficult to remove. I think the Golang community is going to find itself growing more slowly as folks increasingly realize other options offer similar benefits without the bad ergonomics.

<comment><USER5> Literally the first non-trivial code I wrote in go (running a bunch of goroutines to download a ton of files from a website in parallel)... I knew exactly where and how things could fail and where things were failing just by looking at the code. Coming from C++ and C# and Python, there was no comparison. I had never been so confident in the code I'd written, even though I was a newbie at Go and a veteran of the other languages.

<comment><USER4> I guess then I have to ask, why would try() make that worse?

Because I can't stand Golang error handling. It's repetitive, it's error prone, and other language features interact with it so that when you make a mistake it can be as hard as a double free to track down where the erroneous default value was introduced.

On the other hand, using Rust, Ocaml, F# or Haskell I understand how my code composed and I can be confident I can just use an error handling strategy. The only complexities appear, as with everyone else, when we have asynchronous code.

So I don't mean to disagree with your feelings, but they're sure not mine and they're part of why I don't use Golang. I was excited about try() because it at least addressed the most tedious part.

<comment><USER5> Try makes it worse because it is so easy to miss when reading the code. Because it encourages nesting function calls, which is harder for a human to parse than separate statements across lines. Because it means you can exit the current function from the middle of a line of code, and what runs before or doesn't run before is based on order of operations rather than requiring the exit to be a statement on its own line whose order cannot be misunderstood. Because it discourages giving more information with an error, so instead of "failed to open config file: EOF", you just get the EOF.

Go's error handling isn't any more error prone that writing if statements for all the rest of your code. if err != nil is no different than if age < 18\. Either one is a branch in the code. I can literally count on one hand the number of times in 6 years of full time go development that I've seen people miss writing the if err != nil.

Being explicit is good. Spreading out the logic is good. Cramming a lot of logic into one line is bad.... and that's the sole purpose of try.

Maybe there's another way to make error handling better in Go. I'm not averse to looking into that. But try wasn't it.

You're talking about writing if err != nil being tedious, but what about matching Results from Rust, isn't that tedious? What about writing proper catch blocks in java or C++ or python, isn't that tedious? It's all just logic.

<comment><USER6> The difference with catch blocks in Java, C++ or Python is that you only need to write them when you actually have something g meaningful to do.

If you only need to propagate the error or cleanup resources then propagate the error, then all you would write is... Nothing. And cleanup+propagation is by far the most common error handling strategy. In Java and Python exceptions even add context for you automatically to help track down what happened.

<comment><USER7> One foundational principle of Go is that the sad path is at least as important, and maybe more important, than the happy path. The best Go programmers I know write the sad path of their programs first, and then backfill the happy-path logic. So:

> you only need to write [error checking] when you actually have something > meaningful to do.

Although it's the subject of a lot of ridicule, `if err != nil { return err }` is actually bad Go code, and not often written by good Go programmers. Errors in Go are, at a minimum, annotated with contextual information before being returned. Frequently, they are programmed-with in other, more sophisticated ways, depending on the domain of the program.

Shifting your mindset to understand errors as something significantly more important than the off-gassing of your program's execution is worthwhile in general, and, in Go, fundamental.

<comment><USER8> > Errors in Go are, at a minimum, annotated with contextual information before > being returned.

What surprised me when I last wrote Go was that there was no out-of-the-box solution to adding a stack trace to the error.

<comment><USER9> Does anyone know if this was a conscious decision? I mean IIRC in Java you're generally discouraged from throwing errors for control flow because creating the stack trace is a relatively heavy process. In Go this is of less concern and returning an error is pretty normal for control flow (as in errors are expected, not exceptional), and you shouldn't have to worry that an error path would be 100x as expensive as a normal flow because a stack trace is being generated.

<comment><USER10> Java allows since ~a decade time to omit the generation of stacktraces, for exactly such cases

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Kudos to the Go team for their process on this. IMHO it's worth reading Russ Cox's explanation of the problem area, including examples, and comparisons to other languages e.g. Rust and Swift.

[https://go.googlesource.com/proposal/+/master/design/go2draf...](https://go.googlesource.com/proposal/+/master/design/go2draft- error-handling-overview.md)

<comment><USER12> "But Rust has no equivalent of handle: the convenience of the ? operator comes with the likely omission of proper handling." what's that supposed to mean? The ? operator just bails out if an Error result is returned from the called function, and forwards that Error to the caller. Cleanup is performed implicitly by drop implementations (destructors) using the RAII pattern ala C++.

<comment><USER13> In the draft design, they give an example of special-case cleanup that would only execute _only when an error occurs_ , not on the success path.

You can emulate this with a boolean flag in your RAII types in Rust or C++, that's set or cleared immediately before a successful return, and then doing conditional logic in your Drop/dtor. Or you could do a std::mem::forget before successful returns. But I guess they think this is an important enough case to dedicate syntax to it for ergonomic reasons, which Rust doesn't have - <USER2> is what I think they're getting at.

<comment><USER12> > execute _only when an error occurs_

You can use the match construct for that, and the Result<T,E> type comes with some utility methods that make it easier to clarify your desired semantics in many cases. The page complains that the "match" syntax is clunky, but I'm not _that_ sure how 'handle' is supposed to be better.

<comment><USER13> As Arnavion points out, handle handles multiple error cases. That said, I'm not convinced it's better _in practice_. For some comparison points - here's how I'd write the Go CopyFile in Rust:

[https://play.rust- lang.org/?version=stable&mode=debug&editio...](https://play.rust- lang.org/?version=stable&mode=debug&edition=2018&gist=c833de2b2d697abeed59cd59cec8fd1b)

Or, if we want to keep a more 1:1 direct mapping to the Go code:

[https://play.rust- lang.org/?version=stable&mode=debug&editio...](https://play.rust- lang.org/?version=stable&mode=debug&edition=2018&gist=c833de2b2d697abeed59cd59cec8fd1b)

Caveats with the "1:1" mapping:

1) In a real rust codebase you'd probably simply forward std::io::Error instead of converting it into a string like I have here, or give it a better error struct/enum type. I've tried to mimic the Go code here, not fully convert to Rust idioms.

2) You could get rid of the .as_ref() spam by just using &str or &Path to be closer to the Go code, but I'd rather stick at least that close to std::fs::copy's file signature.

3) All explicit close operations are dropped as unnecessary vs the Go code. I guess I could've used std::mem::drop to be more explicit?

4) TempPath is obvious overkill for the single remaining error point

5) In temp-file heavy code you'd probably wrap TempPath + File into TempFile. keep could return the interior File as well.

<comment><USER14> >1) In a real rust codebase you'd probably simply forward std::io::Error instead of converting it into a string like I have here, or give it a better error struct/enum type.

In all the real code bases I've worked on, there are multiple disparate types of errors that nevertheless have the same context.

Example: A function that takes in a path and parses a config file at that path fails if it can't open the file or if the file is malformed. The file can be malformed because indentation is wrong, because there's a string where there should be an integer, or because a required field is missing. All of these are different error types.

So a single `std::io::Error` is not possible, and erasing them into a `Box<dyn Error>` or wrapping them in a custom (context-containing) type nevertheless requires writing a `.map_err` per each Result value.

<comment><USER13> `?` uses the `From` trait which means you often don't need `.map_err`. Ignoring crates like error_chain, even the stdlib comes with a From implementation for `Box<dyn Error>` - as long as your error types implement std::error::Error, you shouldn't need an explicit .map_err to box them:

[https://play.rust- lang.org/?version=stable&mode=debug&editio...](https://play.rust- lang.org/?version=stable&mode=debug&edition=2018&gist=f8aaf49fee7632058db95e9bc72b31a2)

EDIT: That said, adding extra context will often require map_err or similar. But merely type erasing / combining error sources shouldn't need it, unless I'm missing something. (Most of my Rust use so far has been on toy codebases...)

<comment><USER14> >`?` uses the `From` trait which means you often don't need `.map_err`.

1\. `From` is a global solution to a local problem. All `std::io::Error` must necessarily be converted to the same enum variant regardless of what caused them. Failing to open a file and failing to write to a network socket will create the same variant.

2\. `From` does not have access to context anyway. A `From<std::io::Error>` is not going to know that the error was hit specifically when "parsing the /etc/foo.conf file", and a `From<std::string::ParseError>` is not going to know the error was hit when "parsing the bar field of the /etc/foo.conf file because it is set to `baz` which is not an integer".

>as long as your error types implement std::error::Error, you shouldn't need an explicit .map_err to box them:

This only works when you want your function to return `Box<dyn Error>` itself without any additional context. The conversation was about needing to add context like in the golang example.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> I suspected this was coming, and it's unfortunate. If Go had implemented try, then in a year everyone would be happy using it and the controversy would have died down. I've seen this happen before.

Unfortunately, the community that has sprung up around Go is more or less opposed to new language features on principle.

<comment><USER16> The controversy may have died down, but the impact on code written would have been permanent.

There's a lot of value to there being "one way to do things", even when it's not the best way from any particular point of view.

Go holds this principle higher than most other languages and I think that should be either embraced, or one should look elsewhere - and I'm saying that as someone who "looked elsewhere".

<comment><USER17> Agreed, no one is forced to use Go. I think it is refreshing to see a language like Go. You don't want all languages to asymptotically approach each other in features. We need diversity in our languages, that way you have flavors to choose from.

<comment><USER18> > no one is forced to use Go.

I suspect some people are. Languages have network effects, which get stronger when FFI is uncommon. My team and codebase mostly keep me on Java even though I find Kotlin clearer in _every way_ and I'd love to get better with Scala and Haskell. If for some reason my team switched to something like Go or VB I'd have to find another job or else put up with it.

</comment></comment></comment></comment><comment><USER19> This is great news.

I really like how errors are handled in Go and I hated this proposal.

The current implementation forces you to constantly think about errors at each single point and it is extremely good at standing out. This is something very valuable, not something that requires or needs to be hidden behind syntactic sugar. It improves the readability of the code and the quality of the software.

If it ain't broke, don't fix it.

<comment><USER15> Go does not force you to think about errors at every single point. If a function returns only an error (such as, for example, os.Mkdir), the language will happily let you drop the error on the floor.

<comment><USER20> This is underappreciated! I suppose you are less likely to care about errors if you aren't getting values from a function, but not always. I wonder if there is a proposal to force this case to be handled, like Haskell's -Wunused- do-bind?

<comment><USER15> There's go vet. But it's inconsistent with the Go warnings-are-errors philosophy. Ignoring the return value of os.Mkdir() is far more likely to be a bug than an unused import is.

</comment></comment></comment></comment><comment><USER21> A lot of Go programmers didn't like this proposal at all. I'd like to think this is just because they didn't think it was good enough. However, it seems that many, many Go programmers didn't like it because they think Go error handling is just fine the way it is.

<comment><USER22> I am one of the Go programmers who didn't like this proposal.

I also spent a significant amount of time discussing with many people, including the Go team, and I am glad the proposal was declined, not because I like "if err != nil {…}" but because the proposal to add "try()" was not solving a good problem. Many, and I would say, every Go programmer wants better error handling, but "try()" was not it.

I hope the Go team keeps exploring other ideas to hopefully one day have a better error handler.

<comment><USER23> The maybe monad is the best solution for this.

Usually to support this the language needs Enum support and a proper type system neither of which golang has. So I'm ok with the developers just baking in syntax for an error monad with specific sugar for extracting the value or handling an error.

<comment><USER24> Why is a monad the "best" solution? Best according to what criteria?

Special purpose syntax can buy you a lot more. For example Swift's try makes it obvious which statements contain error handling without burdening each expression.

<comment><USER23> Ok let me tell you the criteria. There are two.

First: The monad allows for composition of functions. Returning two values does not. It breaks the flow of a function pipeline and forces you to handle every error in the same way.

Second: Extracting the value via pattern matching guarantees that the error will either be handled or used correctly. This is a way to 100% guarantee that there are No runtime errors. That's right. Using the error monad with pattern matching makes it so that there is zero room for runtime errors.

Why create a language that has runtime errors? Create a language that forces you to handle all possible runtime errors before it even compiles.

According the criteria of safety, zero runtime errors, and expressivity via composition the monad is the Best solution. There is literally no other way of error handling that I know of that can catch runtime errors at compile time.

I know you tried to flip my statement on it's head by using the term "criteria" as if there are many many different criteria for "best." And you are right, programming is an opinionated thing. However, ZERO runtime errors is a too powerful of a feature to assign to a specific criteria. Such a feature is so powerful, it should be part of EVERY criteria.

If you don't understand completely what I mean by "composition" or how pattern matching and a maybe monad can guarantee a runtime error will NEVER occur, ask me to elucidate, I'm happy to clarify.

<comment><USER25> I'm interested in the zero runtime errors piece - how would a language with the maybe monad handle an out-of-memory error at runtime?

<comment><USER23> There is a way of which (to my knowledge) is not implemented in any technology.

Presuming you know how the maybe monad (or similar named monads) handles errors. A MaybeOutOfMemoryError works in a similar way in the sense that any attempt to use the value meaningfully will force you to handle the error.

       data MaybeOutOfMemoryError a = OutOfMemoryError | Some a

       ioFunction :: MaybeOutOfMemoryError a -> IO

       ioFunction OutOfMemoryError = println "ERROR"
       ioFunction Some _ = println "No ERROR"

exhaustive pattern matching with the error flag enabled makes it so that if you forget the OutOfMemoryError case an error will occur during compile time.

Any function that can potentially trigger a memory error should be forced to be typed like this. However in programming, ALL functions can potentially do this, and side effects outside of the scope of the function (total memory available) will trigger it meaning that the only way to do this effectively is to make ALL functions typed this way. Which is inconvenient to say the least.

That being said you can just type the main function as something that can only accept this monadic value forcing users to wrap this handling in a top level function:

       myWrittenProgram :: MaybeOutOfMemoryError a
        -- not defined in this example

        -- main is forced to be typed this way just like how in haskell it is forced to be typed IO ()
       main :: MaybeOutOfMemoryError a -> IO ()
       main Some a = printLn a
       main OutOfMemoryError = printLn "Error out of memory"

Obviously the above has some issues with the rest of haskell syntax and the way things are done, but I'm just showing you a way where it is possible to make sure that a memory runtime error does not happen (that is an unhandled runtime error).

That being said unless you know haskell or know what a maybe monad is, you wouldn't be able to fully comprehend what I said. Exception monads exist in haskell, but nothing is forcing the main function to be typed this way.

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> Good on the Go Team listening to the community, I definitely saw more people against this feature than for it.

I hope they take another stab at improving error handling. I like Go a lot and do think error handling is one place it could use improvements.

<comment><USER27> I don't understand why anyone would be (strongly) against this proposal. If I understand it correctly, it's just a shortcut. That is, the old (existing) way would still work. If anyone didn't like "try", well, don't write your code that way.

It would also appear to be amenable to an automated tool that would convert to or from try-style.

Given that, why would people have strong feelings against? Because they think go needs something better, and if this passes, they'll never get it?

<comment><USER28> This is the prime example of what makes Go different than most other languages. They don't put things in attached with the argument "if you don't like it, you don't have to use it." Go is a language designed to be written and read by teams. You don't like try. Bob does. Bob writes code that uses it. You still have to read it.

<comment><USER29> > They don't put things in attached with the argument "if you don't like it, > you don't have to use it."

I agree with this. I think many Go users like Go because of its simplicity that prevents unnecessary bikeshedding so prevalent in other languages.

</comment></comment></comment></comment><comment><USER30> Perfect timing. Started mucking around with the Go compiler recently to implement my own error handling.

[https://pbs.twimg.com/media/D_ojiEqUYAAhmrH.png](https://pbs.twimg.com/media/D_ojiEqUYAAhmrH.png)

edit: s/%s/%d/ but you get it.

</comment><comment><USER31> Just try writing three Go programs with error handling, then, try other languages!

I was pissed at first. However, now I cannot code in any language without overusing try and being scared of each line.

Using Go's error handling is actually making your code smarter, I mean, you don't want your code to break with a weird message because of something stupid.

The simplest example is adding a default-path whenever I'm reading a file, Go's error handling reminds me of what to do if this file doesn't exist! Or cannot read etc.

Don't take my word for it, Go ;) try it.

<comment><USER32> try errors in elixir:

       with {:ok, val1} <- happy_path1(val0),
            {:ok, val2} <- happy_path2(val0, val1),
            {:ok, val3} <- happy_path3(some_val) do
         function_might_crash_let_it_crash!(some_val)
         happy_result()
       else
         {:error, :enoent} -> handle_notfound_error()
         {:error, :eperm} -> report_permission_error()
         _ -> raise("don't worry this process is supervised, let it crash!")
       end

low cyclomatic complexity makes for a nice user experience, and you learn the philosophy of "if it doesn't work, just turn it off and on again". Why be scared? Just let it go. The VM has your back.

<comment><USER33> What's the equivalent in elixir for something like this?

        func do(a Param) (res Result, err error) {
            var aPrime T
            if aPrime, err = getResource(a); err != nil && err == RecoverableError {
                aPrime = definitelyNoErrorAlternativeGetResource(a)
            }
            var aPrimePrime T
            ... // many more steps
            return doSomething(aPrimePrimePrime)
        }

<comment><USER34> What happens with this code when err isn't recoverable?

you can manage it a few ways in Elixir, struct matching is one:

      def perform(param) do
        res =
          case get_resource(param) do
            {:ok, val} -> val
            {:error, %RecoverableError{alternative_value: val}} -> val
          end

        do_more_things(res)
      end

</comment></comment></comment></comment><comment><USER35> Quite rightly, too! It's annoying for beginners, but you quickly see the utility in the if err != nil {} approach, or 'sad path' approach after a few years of using Go in production. You learn to love it! To be honest, there's very little I'd add to the Go language, if anything. It's very unique that most Go developers share that view of a language. With Javascript, for example, I can't wait for 'new stuff', I think that's sometimes symptomatic of a broader dissatisfaction.

<comment><USER36> Agreed. When I first started writing go I thought "Wtf is this caveman language"

And now years later I couldn't imagine going back to using exceptions. The non-linearity of exceptions creates such a cognitive load of picking up unfamiliar code, and this is where go really shines. I can dive into almost any go codebase and get a lay of the land very quickly.

On another note, I've been enjoying rust's approach with Result<T,E> / the ? operator. Same principle with less visual bloat.

<comment><USER37> > On another note, I've been enjoying rust's approach with Result<T,E> / the ? > operator.

For the record, the `try` proposal which was just declined, is almost equivalent to the `try!` macro in Rust, which was the "testbed" for the `?` operator.

</comment></comment></comment><comment><USER38> It's rather disappointing that Go has managed to bungle error handling so badly in a language only a handful of years old.

<comment><USER39> Probably something about ideology overriding practicality.

Personally I find go error handling okay but that's because I exclusively use panic().

<comment><USER40> Just don't let any true believers near it or they'll tear you a new one.

I've published plenty of Go code with a panic() here or there to handle fatal issues, and there's never a shortage of ignorant fools dropping in to lecture me.

If I'm not supposed to use it, why is it even in there? To tempt me? That would fit with the glorification of pain and boredom, I guess.

</comment></comment></comment><comment><USER41> This thread is rife with "Go should have Try because I want Try" that also seem to be made by developers that do not write Go. It seems confusing to me that voices generally involved from Go are so demanding of its maintainers.

Curious, are there full-time (or at least Primary) Go developers that are upset by the lack of Try?

<comment><USER42> > Curious, are there full-time (or at least Primary) Go developers that are > upset by the lack of Try?

I use golang at an employer. error handling in golang is verbose, error prone, distracting, and difficult to make sense of when there is actually an error (composing). I've seen on several occasions now errors being mishandled (either dropped by accident, or by overwriting already existing error variables in the same scope). These issues don't happen with exceptions.

<comment><USER43> It's interesting that as a full time Go developer myself, my experience has been very different about the points you have mentioned. I personally think verbosity is good. For one, lack of verbosity catches my attention. If I am reviewing code that looks like some part of it is ignoring the error, I would try to find a reason about that error check exclusion. This also prevents errors being dropped by accident.

About overwriting, again this has never been a problem for me (as far as I can recall). Error values are very much localised in almost all Go code I have seen and written. If a function returns an error it is either immediately acted upon or returned by the caller. As such, any overwriting done at a later stage is more or less for convenience sake.

<comment><USER44> > This also prevents errors being dropped by accident.

Instead of designing a language that prevents errors from being dropped by accident, hire a bunch of literal gophers to search your codebase for inverbosity. Good plan will work 10/10 times.

</comment></comment></comment></comment><comment><USER45> Personally, I feel that the motivation for the issue is one of convenience. The most common use case is changing the flow control in the event of an error to return from the current stack. I'm not a fan of defining an error handler. This seems far too intrusive and cumbersome and a bridge too far.

GoLand gets around this somewhat by adding in the Live Template of "err" being a macro expansion for the if err != nil { return }. However, it still adds those 3 lines below each requisite call.

If they added a new keyword that took the place of this macro, would that be too intrusive? Clearly, this only works if you have named return values.

It would be nice if there was a bash/Ruby-like chaining, such as:

      var1, var2, var3, err := call1(args) &&
      var4, var5, var6, err := call2(args) &&
      ... and more calls and so on ...
      return callN(args)

Where "&&" would perform the if err != nil { return } in-line. Should the first call return a non-nil error as the last argument, flow would be returned to the caller. If not, the flow continues as normal.

This could even be extended in the case of function chaining:

      return call3( call2( call1(args) && ) && )

The downside of using && is that it's overloading the && and may cause some compiler/developer confusion. This was just an example based on a familiar use case (bash); another token can be used.

Rasky suggested something like this based on another proposal in the thread, but using "?" instead.

Another way to approach this might be an overlay language analogous to Kotlin. There could be a Go dialect that compiled into Go that provided this feature. Or, possibly an optional "plugin" for go's compiler that added an intermediate transformation step prior to compilation based on new keywords, but this will frustrate debugging and lead to other surprises. Generators tried to do this, but it doesn't seem to have taken off, from the repos I've read.

Just my 2c

</comment><comment><USER46> I think this is the right decision. Error-handling the go-way focuses on _whether_ a single operation failed, rather than _how_ a set of operations failed.

In Python or Java, you see a lot of try-catches around blocks of code, which can obfuscate where the _source_ of the error is, despite having particular handling for the _type_ of error.

For systems code, I mostly care about whether something failed... like: \- Was the socket opened? \- Was the file created? \- etc.

</comment><comment><USER47> With try, Go might have been a language I'd have enjoyed using. It's a shame. Right now, I see Go as being anti-abstraction and anti-cleverness, and I'd rather not work on codebases in which the language of choice is designed to deter creativity and encourage monotony. Heavy use of Go is a big negative when I evaluate potential projects to work on.

<comment><USER48> Anti-cleverness is what makes Go great. Go code is simple, and it is easy to read/understand. It's a feature of the language

<comment><USER49> Go code is all about being able to see the trees, forget about the forest. Go programs are rarely easy to read or understand unless they are written by exceptionally talented developers in my experience.

<comment><USER42> Agreed. Because golang is "simple", the actual code base becomes a mess, littered with 10 line functions that are basically map/filter/etc. calls, which can be written on a single line in a proper modern language. The majority of golang code bases I've seen are much more difficult to follow compared to if they had been written in something like Java or C#.

</comment></comment></comment></comment><comment><USER50> Great that they listened to the community

<comment><USER51> They listened to the part of the community that agrees with you.

I'm "community" and I would prefer to have `try()` than not to have. They didn't listen to me.

<comment><USER52> "Listened to" is colloquial for "engaged with". They engaged with people who represented the `try()` option and declined to implement it.

It is impossible to implement every proposal their ears listened to so obviously that's not what listened means.

<comment><USER53> And they also "fast tracked" the decline "ahead of schedule".

</comment></comment></comment></comment><comment><USER54> Try not. Do. Or do not. There is no try.

</comment><comment><USER55> Lack of try and go's error handling is part of my attraction to go. Explicit handling of error is much better than implicit and having to guess how things might get handled.

<comment><USER37> try may have drawbacks but not this one. try is perfectly explicit. There is no implicit error propagation.

</comment></comment><comment><USER56> Has the idea of making the returned error implicit and handling(or discarding) of the return value mandatory been explored? Thinking on the lines of errno in C.

</comment><comment><USER57> Well, that seems like the most obvious feature add to Go.

</comment><comment><USER58> I think the proposal's intent was great but had some serious issues.

I created my own proposal that I think addresses the issues. I would love some constructive feedback. [https://github.com/golang/go/issues/33161](https://github.com/golang/go/issues/33161)

</comment><comment><USER59> Thank you Go developers! Please keep the language minimal, opinionated, and never subject to the bikeshedding mobs!

It wouldn't have been the end of the world but I'm glad to see Go still has alive the spirit that made it so popular in the first place.

</comment><comment><USER60> This is why we have nice things!

</comment><comment><USER61> I'm extremely happy about this, and am hopeful this approach to community feedback continues. I previously said that this was a fait accompli like Go modules, but now I will happily withdraw that criticism.

/cheers

</comment><comment><USER62> I appreciate this change of heart, as I wouldn't want a half-baked solution to make it into Go, but I hope they don't just stop there.

What the try() proposal gets wrong is that it tries to automatically bounce the error back the stack, being equivalent to "if err != nil { return }", which is ofte reasonable, but at the same time lacks the flexibility that current Go code has in terms of augmenting the error, or indeed handling it: You'd end up with try() calls for _some_ things, but not all, so it's just ironing out one wrinkle and not every wrinkle. The second argument to try() is too heavy-handed. What we need is easy, readable syntax for all cases.

In current Go code, people like the "v, err := someFunc()" syntax because it allows the happy path to stay in the current scope, with the secondary syntax "if v, err :=" introducing a new scope to avoid polluting the parent scope. If you're in the current scope, your code stays flat and clean (although Go's love of shadowing cause subtle).

In my opinion, we need a syntax that is similar to a "catch" block in other languages, but easier. Perhaps something like this:

      v := getName() check err: {
        return errors.Wrap(err, "could not get name")
      }

This allows you to handle the error and augment it, while not introducing anything magical. It's exactly equivalent to an "if v, err :=", but without introducing a new scope _and_ not polluting the current scope with an error variable. This syntax would happily support fallthrough:

      v := getName() check err: {
        log.Printf("could not get name, ignoring: %s", err)
      }
      // v is now the zero value

And of course you could still support a syntax for introducing a new scope:

      if v := getName() {
        // v is now valid
      } check err: {
        // You can return or anything else
      }

You could easily extend it to error types with some kind of matching syntax:

      v := getName() check err == io.EOF {
        // On EOF
      } check err: {
        // All other errors
      }

The above syntaxes don't support chaining. I'm on the fence. I like Rust's "?" postfix syntax, and I think it could work:

      // This could be "monadic"; the first error short-circuits
      ceo := getPerson()?.getCompany()?.getCEO() check err: {
        return errors.Wrap(err, "couldn't get CEO")
      }

But why not just let "." be smart about errors and fall through like this?

      ceo := getPerson().getCompany().getCEO() check err: {
        return errors.Wrap(err, "couldn't get CEO")
      }

After all, "." can know if the function returns multiple values, and "." on a tuple (or whatever Go calls it) isn't valid, so why not "promote" the "." to a high-level operator here?

The awkwardness of the try proposal goes deeper than just error handling, too, I think. One reason Go can't solve its error handling problem _elegantly_ is because of its reliance of multiple, exclusive return types. Almost all functions with this signature:

      func getName() (string, error)

...obey the unwritten rule that the function returns _either_ a valid value, or an error. If you get an error, the value is supposed to be unusable, and the way to check for it is to look at whether there was an error.†

In many type systems, a situation where a return value can be _either_ A or B is variously called a union, or discriminated union, or enum, or sum type, which is the term I prefer. It's always bugged me that Go's designers didn't go one step further and made sum types a first-class citizen, because I think it would fit Go rather nicely. TypeScript solves it this way:

      function getName(): string | number

And you can also define types this way:

      type number = int | float64

This, incidentally, introduces the idea of optional values:

      function takesOptional(x: string | null)

Back to error handling, it would be more natural for a function to declare itself this way:

      func getName() string | error

After all, it returns a value _or_ an error. It can never be the superposition of both.

In this regime, anything that gets a value needs to explicitly check for what it is. "switch" on type would work, just like today, but that gets verbose for mere errors. So we just say that the "check" syntax as outlined above would work for any union that involves an error. In other words:

      func getThing() Person | Company | error {
        ...
      }
      thing := getThing() check err: {
        return errors.Wrap(err, "can't get thing")
      }

We can do this because we can say that "error" is special and known to the compiler, just like make() etc. are special.

Of course, sum types go beyond errors, and open other avenues that are very poorly served by Go right now.

\---

† This, unfortunately, isn't universally true. For example, io.Reader's Write() method's contract says that if it returns io.EOF, it may still have read a final amount of data into its buffer. Many get this wrong and ignore the data read. Which points to the problem of conventions that only _seem_ like unwritten rules, but also highlights how the lack of strong type-system support creates the issue in the first place.

</comment><comment><USER63> >The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

<comment><USER64> The average skill of most software teams is probably not far if not lower. I've been on very good ones and very bad ones -- lots of the code becomes least-common-denominator/weakest-link quality.

<comment><USER65> This isn't about good and bad, it's about experienced versus beginner, for certain values of "beginner". Not complete novices, but people who have already been programming in some other languages, but are new to Go. Think new college grads.

</comment></comment></comment><comment><USER66> "Do or do not. There is no try." ~ Golang master Yoda

</comment><comment><USER67> This reads like script kiddies who became professional programmers and just want things done how they've always been done.

Error handling in go is not concise, and calling it explicit is in insult to anyone with a modicum of abstract reasoning skills. Error handling in go is not explicit, it's verbose. Error handling in go is not concise, it's broad. Error handling in Go is not consistent, it's an exercise left up to diligent programmers.

As golang's code base grows, you're going to see this mistake play out over and over and over again.

Having a Result<T> construct would have been great for go.

</comment><comment><USER68> I mean...

If you don't like writing `if err!=nil {...}` throughout your code base surely you can just create some middleware function in its own package that has switch statements based on error cases. Checking for errors frequently in the running of the code is more or less a Good Thing.

<comment><USER69> I don't see how a switch statement helps you avoid checking for errors when methods you use return errors, and a lot of methods return errors.

<comment><USER68> You can pass functions to functions ([https://play.golang.org/p/XNMtrDUDS0](https://play.golang.org/p/XNMtrDUDS0)).

So you can do (sans syntax):

        ErrorCheckerFunc(fn myParams -> MyFunc(myParams), "message")

        ErrorCheckerFunc(fn myParams2 -> MyFunc2(myParams2), "message2")

etc...

and then the actual function:

        ErrorCheckerFunc(fn myFunc, message){
         returnVal, returnError = myFunc();
         switchError:
          case error is foo:
           print error
          case error is bar:
           log error print "error logged"
          ...
          case n+1 etc

          // you can handle message in a similar way to get
          // cases by function names, and if you have elixir
          // style quote unquote metaprogramming in Golang you might just be able to get function names based on passed function - I don't think this is in the language spec though it may be possible to do some other way.

          if error not nil do switchError(error)
           return RuhRoh
          else
           return returnVal
        }

It's not so bad, it's just a middleware.

<comment><USER70> I'm not clear on what exactly you're trying to represent here, but it looks like something that wouldn't work with Go's type system. ErrorCheckerFunc would need to always have the same return type and accept a function with the same type signature.

<comment><USER71> If only there was a way to make a single function work with multiple different types. A way to "genericize" it, you might say.

Alas, that's obviously completely impossible. Such a thing is beyond the capabilities of us mortal programmers. But maybe one day PL researchers will discover a way. One day...

<comment><USER72> Rob Pike would rather use a for loop than map or filter.. so yeah don't dream too big

[https://github.com/robpike/filter](https://github.com/robpike/filter)

<comment><USER69> That's kind of awesome code though. I learned things about go looking through how he implemented reduce. Thank you for sharing it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER73> Do or do not, there is no 'try'.

</comment><comment><USER31> Thank God!

<comment><USER74> God codes in C, and uses three space tabs.

<comment><USER75> I'd definitely be interested in knowing what His take on error handling is.

<comment><USER76> It's undefined and implementation specific.

Or maybe she took the approach Linus did with git and just let it crap out and start clean next big bang.

</comment></comment></comment></comment><comment><USER77> No wonder people are leaving in droves for Go++.

</comment><comment><USER78> I hope somebody submits a "Do" and a "Do Not" amendment. Think of Yoda.</comment>


I'm working on developing a Product, uncertain of success. Am I wasting time? - <AUTHOR>

I'm developing a product which puts an Interactive Restuarant Menu on a Tablet Screen, expecting it to be bought by hotel firms. Almost complete, I'm starting to feel as if I'm wasting time on building something unsure of its success. Is it normal? or should I switch project? P.S I'm a yet to pass out college hacker <comment><USER2> Develop customer then the product. Take a look at Lean startup by Eric Ries, search for Customer Development, read Steve Blank, read Start slow & Stay Small by Rob Walling. Talk to businesses. Get out of your computer screen. Ask their opinion. Ask them to pay you.

</comment><comment><USER3> I would approach some hotels and restaurants now since you indicated it's almost completed and see what their feedback is, what features they like and would like added, how much value does this bring their hotel/restaurant.

If you have a friend in the restaurant business or become friends with one during your initial demos get some feedback on pricing as well.

Consider a setup fee and a monthly maintenance fee that includes improvements to the product and making up to once monthly updates to the menu on an ongoing basis.

Good luck in 2013.

</comment><comment><USER4> Have you talked to your market? Done any type of research? Did you one day decide this would be a great thing to build?

If you answered no any of the first two questions and/or yes to the third one, then go ahead and stop wasting your time. you need to realize one thing: Products are not born because you think there is a need. Products are born because you found a need and want to cater to it.

</comment><comment><USER5> If it's almost complete, then finish it. Load it on your tablet and start marketing yourself. Talk to local restaurants and ask then to try it out on 1 or 2 devices. Give it off for free and just collect feedback. It is a decent idea and has potential.

</comment><comment><USER6> There is still value in a completed product, even if you never get a single paying customer. Taking something from basic idea to completion on your own is a positive signal, giving you a lot more career and business options down the line.

</comment><comment><USER7> Find out if anybody needs or wants it first. The worst thing that can happen is that you spend X amount of time building something that you never determined anybody needed or wanted in the first place.

<comment><USER8> Do that by getting businesses to PAY you (even if it's not finished yet). Sometimes people say that they would like a solution for X, but when it comes to paying for it they back out.

</comment></comment><comment><USER9> Have you done any presales stuff? Have you talked to customers, drummed up business yet? Have any of them seen your prototypes?

If you haven't, you may be shocked once it comes time to sell.

</comment><comment><USER10> I will suggest keep building.</comment>