Yahoo will serve Bing results - <AUTHOR> http://www.businessweek.com/technology/content/jul2009/tc20090728_826397.htm

<comment><USER2> One of the bigger aspects of this deal is that it makes it much harder for yahoo to be acquired by parties other than microsoft.

Essentially microsoft gets two things out of this deal, they get to keep their cash while getting the same effect for free _and_ a big boost for bing.

Yahoo gets to control their cost a bit better.

</comment><comment><USER3> IMO Yahoo was never a search company anyway. It was a directory of sites and is better positioned like the article says as a media company. It tried to buy it's way into the search technology market (overture, altavista, inktomi, et al) but they didn't know how to manage and integrate the disparate technologies into one holistic search experience. Yahoo is terrible at managing search technology. Period.

It is about time Yahoo stopped pretending to be a search company. Concentrate on growing and monetizing the new media properties they have and they could be very successful. In fact it's the only sane play at this point.

</comment><comment><USER4> I wonder what will happen to Yahoo's webmaster tools (especially Site Explorer). Those are a good deal better than Bing's...

</comment><comment><USER5> What happens to BOSS?

</comment><comment><USER6> I hope they won't mess with the API.... I use that for langpop.com and some other things, and have found it quite pleasant to use.

</comment><comment><USER7> smart move for yahoo

sooner or later bing would overtake it, given its superior quality and msft's deep pockets. by selling new, bartz gets to bargain while ysearch is still worth something. two years from now after bing had eclipsed ysearch organically, she would have had little to bargain with

search was bound to become a two-horse race...the capital needed to compete is enormous, and it has been clear that yahoo won't be able to go the distance

expect 3k layoffs or more...besides the payouts from msft, the headcount reduction will be a major gain on the balance sheet for bartz

bartz will have to actually stop selling off and closing bits of yahoo and actually try growing something. that challenge still awaits her

</comment><comment><USER8> Wow, must be a real kick in the nuts for the Live Search people, to go from "Google killar?!" to "replaced by Google's old pretend-rival".

<comment><USER5> You got it backwards. Yahoo is scrapping its search engine technology and will use Bing results.

<comment><USER8> Good call! You've got to admit the title is ambiguous... ;)</comment></comment></comment>


Securing a SoC is Not Easy - <AUTHOR> http://pandoralive.info/?p=2808. <comment><AUTHOR> OK, following the comment below, the post is about the difficulties of sourcing a SoC (system-on-chip such as the ARM processors you find in most mobile devices out there) for a relatively small hardware project led by a small company. While we all get the impression that SoCs are so common that you can buy them from anywhere, the actual supply of these parts is an issue if you are not sourcing tons of them at the same time. And another intricacy is that the continuous supply of the very same chip is not a sure thing: suppliers move on to the next design year after year and it's another issue to resupply it over and over again over time.

<comment><USER2> Sourcing is a better word than "securing" though the title is accurately quoted.

I thought it was going to be security related.

<comment><AUTHOR> Agree, Sourcing may have been a better wording. Securing was used here in its other meaning.

</comment></comment></comment><comment><USER3> High end SoC vendors generally don't care about you until you're buying millions of devices. If you can't find it on Digikey/Mouser/etc you're probably not going to get your hands on these parts without an in with one of the big name suppliers or the SoC vendor itself. However, in the case where you are shopping for millions of devices - say you're looking for the centerpiece of a new smartphone, its not unusual for them to fly a team of applications engineers to you to facilitate getting the part into your system.

Of course, merely procuring the part itself is just the beginning. The early revisions of a SoC (and in many cases even small microcontrollers) can have fairly extensive errata sheets (basically a list of known hardware bugs). If you aren't a first class customer (usually based on order volumes), this is a world where you can spend weeks to months wondering why your code doesn't work only to find out that it legitimately was a hardware problem in the silicon.

Trying to source displays is also a nightmare for relatively low volume (<100K) designs.

<comment><USER4> That's not always the case. It depends how hungry they are. I was involved in a project that was clearly not going to require millions of devices. We were a small startup (though with some big partners). Texas Instruments really wanted to get their SoC into this segment though and we got a lot of their attention + pre-production samples + technical support. If this is an SoC looking for customers (like this was) and you can get the ear of the marketing team and/or have the right partners things will work out.

There are a lot of other electronic parts that are like that. If you get to talk and have a relationship with the right people you can get samples and support. Otherwise it can be virtually un-obtainium if it's not in Digikey's inventory. It's always been like that...

<comment><USER5> Yes, Texas Instruments does that, I had the same experience (were we involved in the same project?). They do it if they are strategically interested in a certain market segment. Your project might look like a demo to them — worth investing some time and effort into.

Unfortunately, I'd say they are the exception. Good luck even getting someone at Broadcom or Qualcomm to speak to you. If your projected volumes are not (convincingly) into at least hundreds of thousands, you will get a simple "no", if you even manage to get an answer at all.

<comment><USER6> Engineer at Qualcomm here - I did check with our biz dev folks and we have mechanisms in place to supply in smaller quantities (a few hundreds..)

<comment><USER5> Interesting! Things might have changed, then. But to confirm: do you mean I can simply start developing a product based on Qualcomm chips (with projected volumes into hundreds or low thousands), and I'll get access to all the necessary documentation (datasheets, reference designs, etc)?

<comment><USER6> @jwr: Sorry for the delayed reply, was down with a fever. (Posted the info below in a separate comment, in case anyone stumbles across the thread later). 1\. [http://www.intrinsyc.com/products/qualcomm/dragonboard- devel...](http://www.intrinsyc.com/products/qualcomm/dragonboard-development- kits.aspx) Intrinsyc is one of two partners who offers "Dragonboards" with the latest (so far, that will change soon) SoCs (APQ8064 and contemporaries). AFAIK, these boards can be ordered in any quantity from 1 to 100s, so they should be a good start for a development kit. Intrinsyc offers a Linux distribution for the 8074 SoM. Not too sure about the maturity of Linux support, but I am expecting updates in the near future, and will post them here. For those who need to eventually build their own boards using Qualcomm SoCs, Intrinsyc's FAQ here should be useful: [http://www.intrinsyc.com/products/qualcomm/dragonboard- faq.a...](http://www.intrinsyc.com/products/qualcomm/dragonboard-faq.aspx) 2\. Inforce computing also offers a cute board with the APQ8064. [http://www.inforcecomputing.com/product/qualcomm.html](http://www.inforcecomputing.com/product/qualcomm.html)

Not sure if these offer the level of detail/support that folks here are looking for, but they seem like a good start.

</comment></comment></comment></comment></comment></comment><comment><USER7> Could anyone familiar with the project reveal what kind of volumes are we talking about? E.g. nvidia's web page says that the minimum is 100,000 units.

It kinda makes sense not to sell these in small quantities because the SoC manufacturer would either end up getting lots of support requests or they would get a bad reputation for ignoring support. The reason is that unlike in the x86 world where there's some kind of a "standard" (derived from the IBM PC), ARM SoCs don't have any kind of consistent ecosystem where the motherboard components, firmware, etc would be specified. Every ARM SoC boots in a different manner, they might have separate bootloaders and there's a whole lot of SoC specific code in the Linux kernel.

Of course, the SoC manufacturer might be able to release documentation about the chip, but that kind of documentation might not exist (in a neat package that can actually be released and not e.g. an intranet wiki), it might contain sensitive IP (lawyers would have to get involved) or it might be written in a foreign language (and translating technical documentation from Chinese or Korean is not cheap either).

For the industry to mature and move forward, a common standard for SoCs would be a very welcome development.

Disclosure: I work as a SW engineer in a SoC company but I have no connection to the sales department and don't really know how this works in practice.

<comment><USER8> I've been a backer/supporter/follower of the Pandora project since the very early days. What I have to say is not official - but to answer your question the impression that I have is that the volume is literally in the 10k - 20k. The reason is of course economy - this is a hardware startup, and the funding is not nearly at the levels to support 100k quantities.

This is a real shame in the SoC market right now - so many great products could be being made if only the chip mfr's were paying attention to the little guys. Its why companies like ACME Systems ([http://www.acmesystems.it/](http://www.acmesystems.it/)) are working hard on providing SoC's and SoM's to the little guys - for a fair price - but its also why they have a fixed-price policy (no matter what quantity: the same price.) This has the advantage (for the hardware developers) of having _access_ to the chips in small quantities, but it eats the margins when the quantities get larger (>10k), because the price will be the same.

This is an area where a new startup could really come along and eat everyones' lunch. Ignoring the little guys is going to hurt the Samsung and Nvidia's of this market, but I suppose they know that already and its why they price/set policy that will exclude newcomers to the scene ..

<comment><USER7> My personal opinion is that the SoC business is stuck in a chicken and egg scenario where there will be no sense to sell to small players because there's no common ecosystem to leverage (and thus SoC sales will come with heavy support costs) but there's no incentive to create a PC-like standard since it is not a commodity market like x86 chips and motherboards are.

Currently selling a small batch of chips (even individual ones) to someone makes no sense because the customer would be unable to do anything with the chip simply because they wouldn't know how it works without support or documentation (which costs money to create and maintain). The small players market (all of them, combined) is not worth enough money to put the effort in. We can argue about the PR value (among geeks) but that's not deemed valuable by management at this point.

It's certainly not about ignoring or setting price points to exclude little guys, it's about running a business for profit.

If and when we get some kind of a standard for SoCs and it becomes viable that you can build a motherboard and put any ARM SoC in it, it will also become sensible to sell them like commodity products but the industry as a whole is not at that stage.

As there is very fierce competition among the individual SoC manufacturers and very little co-operation takes place, I think that ARMH is pretty much the only ones in the position to make any such development.

I don't like the way the industry works at the moment but that's just the way it is. Maybe it will some day mature and stabilize.

</comment></comment></comment><comment><USER9> This is, I believe, the only thing that has kept Intel in the game. Had someone had some foresight to go "all in" with the open source bit they could retake the old IBM PC spot (I'm talking about the one the PC in 1981 took away from CP/M machines, not the current spot). People who build appliances won't care but people who build computers will.

<comment><USER10> I get what you mean but selling 1000 units is hardly a game changer :p

<comment><USER9> You both correct and very very wrong at the same time. What history has shown in the technology world is that the person making "1000 units" is changing the game, just the game doesn't know it yet.

The folks who embrace selling in small quantities to the individual developers see a huge diversity in designs that are built with their tech, that trains up the tech provider on the strong and weak points of the technology and often helps them produce easier to implement solutions. The diversity of designs trains the consumers on possibilities which they may not be considering. When they connect, as they did with putting a microprocessor into a "home" computer, the results can be stunning.

So you don't sell 1000 units because you think _this guy_ is going change the world, you sell them in 1000 unit quantities to a bunch of guys and gals because one of them may change the world in a way you haven't foreseen, and if they do, you will benefit hugely from being the tech they used.

</comment></comment></comment><comment><USER11> I've heard from a friend that for Asian companies like MediaTek, "going through the front door" is the wrong way to approach them, unless you are a very large and well-established company.

[http://www.bunniestudios.com/blog/?p=3040](http://www.bunniestudios.com/blog/?p=3040)

<comment><AUTHOR> So what is the recommended approach ? (sorry if the link you shared answers the question, i have not checked it yet)

<comment><USER12> The link, and indeed the whole blog, is worth reading. However, it doesn't directly answer the question. Bunnie suggests dealing with Chinese brokers who can source availability of 'cut tape', remnants from large production runs of the chip. It doesn't address consistency and reliable supply issues over a longer period of time but does allow for procurement of relatively small quantities of parts.

Bunnie also suggests learning enough Chinese to participate in what he terms the "gongkai" (公开), the quasi-open but legally murky design and production ecosystem producing much of our electronics, where documentation and specs are apparently available about as freely as torrented episodes of Game of Thrones.

<comment><USER11> The idea is to "feed off the leftovers" until you grow to the point where you can order above the MOQ directly. It's a very different growth model.

<comment><USER13> Brokers are very common in electronic production.

You need to be careful when asking for quotes. If Bob has stock of product, and you ask 3 different brokers for quotes, you've just driven cost of that product up.

That's especially frustrating when three or four sub contractors are requesting quotes for the same part to be used for the same potential job being inquired about by the end customer.

</comment></comment></comment></comment></comment><comment><USER6> I work for Qualcomm and am surprised that the blog post author didn't consider our SoCs - it would meet all the requirements and I believe its not too much hassle to source from us.

<comment><AUTHOR> Thanks for the feedback! I believe ED (the one who shared his experiences from the article) did contact Qualcomm but had difficulty securing small quantities as well from them. He probably forgot to mention it this time. However, if you think that it would still be possible and if you have commercial contacts within Qualcomm, I'd be happy to put you in touch with him.

<comment><USER6> Yes, would be happy to talk with your colleague and point him to the right contacts. I am at the San Diego headquarters.

<comment><USER8> I also have a need (and am also an avid OpenPandora groupie) for a SoC vendor - any chance I could get your contact info as well? I'd be very happy to consider Qualcomm for my project..

<comment><USER6> How do I reach you? Not too happy sharing a company/personal email address here and my name is too complicated to describe my ID in a email-address- extractor-safe way.

<comment><USER8> email@example.com is a tempmail I set up for the purpose ..

</comment></comment></comment></comment></comment></comment><comment><USER14> All sorts of parts can be surprisingly hard to find. I've been working on a radio product where the 16-way channel selector switch had to be specially ordered from China, while everything else came from Digikey.

</comment><comment><USER15> The situation for hobbyists getting SoCs is terrible - I've got a MiiPC at home that won't be getting much use because Marvell won't release any documentation on it without an NDA

<comment><USER16> NDAs are firmly integrated in the embedded industry. If you could get your hands on any other SoC, you would need to sign an NDA as well. For example Tegra documentation needs an NDA too.

<comment><USER17> Freescale and TI tend to be good about providing heaps of documentation without requiring any NDA.

Unfortunately, they're pretty alone in that regard.

<comment><USER18> I tend to think the only reason TI and Freescale have good documentation is because they've been in the market a lot longer than the others and have had time to mature the work. TI had early wins with Nokia and Freescale has been in the automotive market and had some early multimedia work like the Toshiba Gigabeat (aka Zune 1).

Providing a complete doc set for these chips runs well above 10,000 pages. I recently got to evaluate a Marvell chipset and...um...let's say it wasn't pretty.

</comment></comment></comment></comment><comment><USER6> For anyone watching this thread, here's what I know about Qualcomm's offerings (through our embedded program partners) - 1\. [http://www.intrinsyc.com/products/qualcomm/dragonboard- devel...](http://www.intrinsyc.com/products/qualcomm/dragonboard-development- kits.aspx) Intrinsyc is one of the partners who offers "Dragonboards" with the latest (so far, that will change soon) SoCs (APQ8064 and contemporaries). AFAIK, these boards can be ordered in any quantity from 1 to 100s, so they should be a good start for a development kit. Intrinsyc offers a Linux distribution for the 8074 SoM. Not too sure about the maturity of Linux support, but I am expecting updates in the near future, and will post them here. For those who need to eventually build their own boards using Qualcomm SoCs, Intrinsyc's FAQ here should be useful: [http://www.intrinsyc.com/products/qualcomm/dragonboard- faq.a...](http://www.intrinsyc.com/products/qualcomm/dragonboard-faq.aspx) 2\. Inforce computing also offers a cute board with the APQ8064. [http://www.inforcecomputing.com/product/qualcomm.html](http://www.inforcecomputing.com/product/qualcomm.html)

Hope this helps!

</comment><comment><USER19> This doesn't even include all the other pieces that go obsolete 2 months after you start production and then turn into unobtanium with no replacement. Oh and the manufacturers and your sources told you for months that there are no plans to stop production. The logistics of building hardware is fucking brutal.

</comment><comment><USER20> This is true and has been true for everything non-Intel forever. I really thought open source operating systems would be a game changer for MIPS, Alpha, PowerPC, and others but it was a challenge getting hardware just to port stuff to. Literally, it took heroic efforts within those companies just get hardware to like a Linus or something.

It's a little different with some of the raspberry pi like platforms on arm but you have some work to do if you want a specific late model processor. Sort of seems like an opportunity of Someone to build arm atx and miniitx like hardware but I don't know anybody doing it. It's all custom application specific stuff anyways...

</comment><comment><USER21> Woh-hold on now, I have a Pandora (though it got delivered too late for me to really use it) Getting parts has always been a rough time!

Parallela board, the Pandora, the iControlPad2 from kick starter failed because of parts not being sourced on time.

<comment><AUTHOR> To be fair the Pandora still exists and is still produced (while you are right that it suffered huge delays in the first place linked to supply but also to manufacturing). As for the ICP2, I believe it was not just a supply issue but a lack a coordination (the design was still being discussed several months after funding).

<comment><USER8> Actually, the iCP2 died because of a total failure of its management to get things sorted out. The drama around Mr. Rothwell and his hijinks is _bound_ to be a made-for-TV movie one of these days .. assuming that EvilDragon makes it with the Pyra, and gets some fame/fortune in the next project.

(Disclaimer: I'm an OP fan, a first-batch'er, and avid supporter of everything that EvilDragon and his motley crew are getting up to..)

<comment><USER21> Nice to meet you, I am as well. Craig is quite a character.

I think the failure also comes from changing the design mid process.

</comment></comment></comment></comment><comment><USER22> You know, if you feel the need to link to a post that is highly specific to a narrow field of technology, which uses a lot of unexplained terms, it would be polite to actually leave a comment to explain what the post is about.

<comment><USER23> As far as I can see, the only unexplained acronym is "SoC". The first result on Google for that term is the wikipedia article explaining "System on a Chip".

HN has always been for technical news. There is always some domain specific knowledge required in technical topics. Judging by the comments here though, it's obvious that the domain specific knowledge this article assumes (which isn't particularly great - not much more than a rudimental understanding of the components that make up a computer) overlaps with quite a number of HN readers.

If you read an article that you don't understand, use it as a learning opportunity. The resources are at your fingertips!

</comment></comment><comment><USER24> I would never have known they were difficult to obtain.

</comment><comment><USER25> a SoC question, in Steve Jobs era before he cofounded Apple he was sourcing cpus an chips in small batches by forging through junkyards,etc.

Would not these small hardware firms benefit form forming a legal co-op that ordered the SoC in batches of 100,000 and than those batches would be shred among all co-op members?

<comment><AUTHOR> Because it may be difficult for those hardware firms to agree on using the very same chip, if they have different needs/markets/consumers/pricing and so on.</comment></comment>


WikiLeaks and 9/11: What if? - <AUTHOR> http://www.latimes.com/news/opinion/commentary/la-oe-rowley-wikileaks-20101015,0,5616717.story <comment><USER2> Dear god. It's been 9 years. About ~3,000 random people died. Do you have any idea how many random people have died in the last 9 years? Could we maybe solve car accidents rather than _potential terrorist attacks_?

I'm sorry for being callous, but _damn_ , let's agree to prioritize...

<comment><USER3> 3000 people died, but if you don't think the events _changed the world_ you're delusional. We're talking about two prolonged wars, trillions of dollars, thousands of american lives being lost, countless civilians being injured or killed in war, a loss of civil liberties, hundreds if not more afflicted with illness due to the toxicity of ground zero, questions about our governments ability and willingness to protect against terrorism, possibly hundreds tortured in the name of fighting terrorism, and I could go on.

<comment><USER2> That's my point. All of that is a consequence of people being so massively upset about this one particular event. And for what? Exactly what you said: for no good reason!

Let us please learn to put things into perspective _so that we can avoid the true tragedies which you described_ :

\- two prolonged wars

\- trillions(!) of dollars spent

\- countless civilians being injured or killed in war

\- a loss of civil liberties

\- possibly hundreds tortured in the name of fighting terrorism

Those tragedies were not caused by 9/11. They were caused by our _perception of how terrible 9/11 was_. In reality, the 3,000 lost lives pales in comparison to the bone-chilling list you assembled.

<comment><USER4> This is something I want to deeply understand some day. 1.8 people die around the world _every second_ , and here we are getting pissed over a few thousand dead 9 years ago, the US media is drumming up an old fashioned _religious war_ , and meanwhile 150,000 humans each with their own lives and family die every day. Human psychology is a funny thing.

<comment><USER5> The thing is, those 150,000 humans don't all die of the same cause. These 3,000 did.

Also, this has been stated multiple times, but 9/11 wasn't about killing 3,000 people, it was about attacking America as a whole, making people feel that they weren't safe in their own country. Surely you don't feel that way just by knowing that 150,000 humans die of random causes each day.

This is major speculation, but what do you think would've happened if the fourth plane reached the White House/Capitol Building ?

<comment><USER6> _Also, this has been stated multiple times, but 9/11 wasn't about killing 3,000 people, it was about attacking America as a whole, making people feel that they weren't safe in their own country._

They aren't safe in their own country. Huge numbers of them die prematurely of random causes every month.

 _Surely you don't feel that way just by knowing that 150,000 humans die of random causes each day._

I look both ways when I cross the street. I don't check my car for bombs every morning. That should tell you something about which I fear more.

Disclaimer: IANAA (I Am Not An American). Perhaps they feel differently than I do.

<comment><USER7>
      > They aren't safe in their own country. Huge numbers of them
      > die prematurely of random causes every month.

The crux being that people have either accepted those random causes of death, or they feel that they have enough control to avoid them (even if that isn't true). Terrorist attacks (though rare on American soil) are something that people have not (yet) accepted as unavoidable, or are something that they feel they have control over avoiding.

The following also contributed:

\- The attack was perpetrated by Muslims against a predominantly Christian country. Especially a country with a lot of 'born-again'/Evangelical Christians that are rabidly religious. This helps to form a "Us vs. Them" mentality as well as a "They are attacking our way of life; our very identity." I have a strong feeling that the reaction would be less severe (though maybe not by much) if it had been perpetrated by members of another religion (or at least people that didn't use their religion as a reason for their actions).

\- The attack was perpetrated by a group. A group that has members that are still 'at large.' (i.e. "It could/will happen again.") By contrast, the Oklahoma City Bombing was easy to dismiss as some random crazy guy.

\- It came from outside of the country. If the attack had been from a group that was based in the US (i.e. some political group that resorted to terrorism), then the reaction probably wouldn't have been so severe. It's easier for form an "Us vs Them" mentality when there is a greater distinction between "us" and "them." If the people behind the attacks were Americans, people would still be outraged, but it would be a hell of a lot easier for them to picture those people as just 'crazies.' I think that a number of people also view Arabs/Muslims as 'below' them (i.e. "a bunch of rag-heads living out in the middle of god-forsaken desert") even if they consider themselves to be more enlightened than that.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> > There were a lot of us in the run-up to Sept. 11 who had seen warning signs > that something devastating might be in the planning stages.

With 20/20 hindsight, yes. Intelligence services are constantly going through _massive_ amounts of information trying to pick out credible threats. When they eventually miss one, sure, it looks obvious in retrospect. But I bet there's dozens of "kill the evil Westerners" speeches happening in third world countries around the world right now. And then when there's a military raid or drone attack on someone who gives such a speech, people get outraged. It's a no gratitude, no-win business for the intelligence services, who actually seem to be doing a pretty outstanding job that's really difficult and important.

<comment><USER9> Did you even read the article? This wasn't about some random chatter happening in some far corner of the globe it was about:

\- An actual identified terrorist showing up at a US flight school. The agents who had him in custody were begging for permission to investigate what was on his laptop and they were denied.

\- The team that was charged with the job of testing airport security were actively prevented from doing their jobs (and later, after 9/11, disbanded)

I don't see how anyone could brush this off as just "20/20 hindsight".

<comment><USER8> The problem is, you're ignoring false positives. Reports of potential threats happen frequently. The overwhelming majority of them are false positives.

> Did you even read the article? ... An actual identified terrorist showing up > at a US flight school.

Did I read the article? "A foreign intelligence service promptly reported that he had connections with a foreign terrorist group" -> Not exactly an actual identified terrorist.

"Had connections with a foreign terrorist group" could be anything. And which foreign intelligence service? Britain? Israel? South Africa? Mexico?

In retrospect, it's obvious, sure. But at the time, not so much. He wasn't a convicted criminal. He was someone who was probably friends with another guy they suspected, or went to the same mosque. If he was someone with a criminal record, of course he'd have gotten a more thorough treatment.

> The agents who had him in custody were begging for permission to investigate > what was on his laptop and they were denied.

Probably those damned civil rights and limited search and seizure things.

> The team that was charged with the job of testing airport security were > actively prevented from doing their jobs

Again, your read of the article is questionable. They identified weaknesses in the system, and no resources were spent on those weaknesses. But there's other weaknesses too, lots of them. Yes, in retrospect, it seems obvious that there were weaknesses. But there's many potential targets, and there's not an unlimited budget. Yeah, after things go wrong it's very easy to say something should have been done beforehand.

> I don't see how anyone could brush this off as just "20/20 hindsight".

It is 20/20 hindsight. There's thousands of false positives. The article is written with an assured tone because they know how history happened. How many times have there been warnings of an imminent North Korean strike into South Korea? Dozens? I do know the stats on Israeli warnings about their neighbors mobilizing near them - over two dozen times in the last 50 years, full military mobilizations... how many became invasions? 2 out of those 24+?

There'll probably be clues after any bad event happens that it was going to happen... that doesn't necessarily mean anyone was being negligent. Also, a little more friendliness and less snark when you comment? Something like, "I disagree with your interpretation" instead of "Did you even read the article?

<comment><USER10> You seem to suggest that it is all due to hindsight. Much of that suggestion is of course your own opinion from thin air as I assume you do not have any experience in intelligence service work. Even if you do, do you not think that at least some of the things mentioned in the article are mistakes even if the person is placed in the position they would have been before the attacks and used only his foresight?

</comment></comment></comment></comment><comment><USER11> In this case, the rot had spread from the top. There aren't really any formal organizational remedies for that, beyond changing the regime at the top. Check out the first two pages of the preface to _The One-Percent Doctrine_ ([http://books.google.com/books?id=gV3m6sYhnrsC&printsec=f...](http://books.google.com/books?id=gV3m6sYhnrsC&printsec=frontcover&pg=PA1#v=onepage&q&f=false))

      ...at an eyeball-to-eyeball intelligence briefing during this urgent Summer,
      George W. Bush seems to have made the wrong choice.

      He looked hard at the panicked CIA officer.

      "All right," he said.  "You've covered your ass, now."</comment>


Pandemic Making College Students Question the Price of Their Education - <AUTHOR> https://www.wsj.com/articles/the-coronavirus-pandemic-is-making-college-students-question-the-price-of-their-education-11598619781 <comment><USER2> Prior to the pandemic, most jobs were not remote. Now something like 40% of them are. Our schools were set up originally to train obedient factory workers, and to serve as daycare centers that allow mom and dad to go to the office. I can't help but to think that schools will have to change to reflect the new permanent situation.

What will happen to teachers? I suspect that over time, there will be fewer of them, but people will learn more than ever. In 1900, 12 million Americans were farmers. 120 years later, we have four times as many people to feed, and only 2 million of us are farmers.

</comment><comment><USER3> Seeing as a large portion of tuition costs come from the need to pay to fund large numbers of administrative staff which are employed to support and operate the glitzy, college life experience crap, that students can't use now I would say a full re-evaluation of college costs are in order.

</comment><comment><AUTHOR> Should teachers and administrators get full pay when a lot of the campus is shut down and instruction is virtual? If I were a student or parent of a student, I wouldn't be too happy with that.

<comment><USER4> Most instructors are paid so little if you cut their pay they wouldn't even make minimum wage.

<comment><AUTHOR> Good point. And the ones in the bottom quartile on the pay scale are doing most of the work. The more senior profs don't teach much and get paid a lot more.

</comment></comment></comment><comment><AUTHOR> The article doesn't mention it, but you wonder if the all-online model, sometimes with non-traditional funding (like Lambda School) will gain in popularity.</comment>


Show HN: EasyPost - the Stripe for postage - <AUTHOR> http://easypost.co <comment><USER2> I've been using this for years now and love it:

<https://rocketship.it/>

It is a slightly different concept, you pay once and get code that gives you a uniform interface for communicating with the different carriers (USPS, FedEx, UPS, etc.).

Since it is a one time fee I didn't expect support, however, the developer has been very responsive and helpful whenever I've run into a problem.

<comment><USER3> Developer of RocketShipIt, thanks for the kind words!

</comment></comment><comment><USER4> One of the ideas in my ideas file is a service that provides an API for sending letters. You simply send a PDF/DOC/etc along with address information, your API key, postage type, etc, and then the letter is printed (by myself) and posted.

Possible uses of the service would be automatic sending of invoices or mailing out payment reminders or contracts that need to be signed, etc.

There are a few companies that provide similar services but I haven't found one that does it in a particularly nice way. They often require using SOAP and don't have modules for common frameworks and SDKs for common languages.

Would any of you use this or are letters completely dead to young companies?

<comment><USER5> International is where this could really shine, print out at the location closest to where the letter needs delivering & avoid international prices

<comment><USER6> _avoid international prices_

For many pairs of countries the price of sending a letter from A->B is less than sending a letter within B. In addition I imagine the labor costs of having people stuff envelopes will a significant source of costs. So you're probably better off picking 3-5 central points with cheap labor and cheap postage, rather than opening dozens of small centers all around the globe

</comment></comment></comment><comment><USER7> Intriguing. What would HN think of an API for physically printing and mailing things? i.e., an API where you pay ~$0.50 per postcard, and it is printed and deposited in the mail autonomously. You could use it for CRM applications, address verification (like Google Adwords), etc

<comment><USER8> <http://www.postalmethods.com/lp/postcard-api> <http://www.viapost.com/>

I know there are others too but I can't find them at the moment.

<comment><USER9> <http://dev.sincerely.com/> is another.

</comment></comment></comment><comment><USER10> Extremely interested in address verification. Please tell me it does normalization/correction that is able to take fuzzy/dirty/invalid data and yield a proper and well-formatted address into standard fields?

<comment><USER11> This is exactly what I'm looking for. I'm really hoping I don't have to integrate with FedEx web services for address verification. If the price is right, my company will gladly pay for this service over the free service provided by FedEx.

<comment><USER10> We're currently using Google's Geocoder and Yahoo's Placefinder, which work okay, but they both have numerous flaws and various TOS policies we're ignoring for the moment.

Would happily pay for this service as well.

</comment></comment></comment><comment><USER12> Is anyone else experiencing DNS issues resolving api.easypost.co?

      ; <<>> DiG 9.8.1-P1 <<>> @184.108.40.206 api.easypost.co A
      ; (1 server found)
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20795
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

      ;; QUESTION SECTION:
      ;api.easypost.co.   IN  A

      ;; AUTHORITY SECTION:
      easypost.co.    1667  IN  SOA dns1.web-hosting.com. hosting-notifications.namecheaphosting.com. 2012091008     86400 7200 3600000 86400

      ;; Query time: 44 msec
      ;; SERVER: 188.8.131.52#53(126.96.36.199)
      ;; WHEN: Tue Sep 18 09:48:17 2012
      ;; MSG SIZE  rcvd: 128

<comment><AUTHOR> API not up yet, sry

</comment></comment><comment><USER13> In France, you can connect to « La Poste »'s website to send letters from the web. Problem is this site is particularly painful to use. UX is awful, error messages are useless, and so on.

I could totally use a simple rest api to print and send a pdf as a physical letter

</comment><comment><USER14> Do any of these services have the ability to optimize packaging of goods?

Say you sell physical goods. A customer buys multiple items. They each have known shipping dimensions.

The question is: How do you consolidate the shipment into one or more boxes in order to optimize for minimum shipping costs?

Keep in mind that minimum shipping costs could also include the cost of shipping supplies as well as packaging and handling labor.

The most basic problem is fitting n packages of m[i] dimensions into the available stock of standard boxes and pick the arrangement that provides the least postage cost.

<comment><USER15> You realize this is basically the same as the NP-Hard Knapsack problem?

<comment><USER14> Right, but that wasn't the question. Having done a lot of work with genetic algorithms, among other things, I have no doubt that I could sit down and write a reasonably useful solution. However, it would be absolutely brilliant if this was already part of an existing shipping API.

I think it would be very useful if these shipping API's accepted package specifications and helped optimize final packaging while in the process of providing a quote. If you want to talk about differentiating a solution, this, most definitely, would.

</comment></comment></comment><comment> chao- As someone who is just now tackling USPS integration for the first time on behalf of a client, you certainly have my interest.

<comment><AUTHOR> Cool! Exactly what I've seen with my own integration. Huge pain points here

</comment></comment><comment><USER16> On signup: Maybe more wording to indicate I've signed up for beta instead of just a check mark? Since I don't know if the check mark means I've signed up or just the email is verified.

On "using": Slightly confusing to put it after the first drop down. It took me a few seconds to get it, I would put "using" in between the 2 drop downs instead.

<comment><AUTHOR> Maybe just get rid of the validation altogether?

Fixed -- how's that look? put the 'using' before second drop down

<comment><AUTHOR> Yeah, initially had both name and email so was using the validation. Will just get rid of the validation altogether. thanks for the heads up!

<comment><USER16> typo on signup form: Shipping price "comparison"

</comment></comment></comment></comment><comment><USER17> For Canadian customers, Canada Post has _finally_ added an API to create & print labels. My company uses Stamps.com's API to print USPS labels (I have Django code if anyone's interested) but this would definitely have saved us some development time.

<comment><AUTHOR> Exactly, that's what I"m hearing from a lot of potentials--too much dev time to get postage working

</comment></comment><comment><USER18> Would totally use this for address verification. Wonder what the pricing is.

</comment><comment><USER19> Love the presentation of the various API calls in each language. My only nitpick is one I have for a lot of code displays like this -- selecting the code also selects line numbers =)

<comment><AUTHOR> Ha! I was just thinking I should get rid of those :)

</comment></comment><comment><USER20> Would love to use this for my ecommerce site (StartupThreads) as we move to a custom system.

Most interested in the shipping price comparison: what providers are you supporting?

<comment><AUTHOR> I'm looking at starting with USPS, FedEx, and UPS

<comment><USER21> Out of curiosity, how are you doing this? IIRC a few years ago when I was playing around with the FedEx API it explicitly forbade using it for price comparison with other carriers.

Are there aggregator APIs that you're using? Or have the T&C changed?

<comment><USER3> It is still the same, you can't even have other carrier rates near UPS rates.

</comment></comment></comment></comment><comment><USER22> Somewhat related question - are these types of services capable of printing first class letter postage ie something to use in place of a "forever" stamp?

<comment><AUTHOR> The closest I've seen/done for this is a $1.64 stamp for first class 1 oz. Agree, this would be very nice to have

</comment></comment><comment><USER23> Very nice. Would you plan to offer international shipping options ? Just out of curiosity, what mapping engine are you using to geocode?

<comment><AUTHOR> Planning on offering int'l but starting with domestic

</comment></comment><comment><USER24> Looking at your images of code they look blurry on Mac. Just a friendly heads up. :) Besides that, Looks like a great idea. Cheers!

<comment><AUTHOR> Thanks! I noticed that, too, but was thinking it was a Retina issue. Apparently not. Will fix

</comment></comment><comment><USER25> Interesting. I could immediately use the simple address verification.

I wonder what the return value of a purchase call is?

<comment><AUTHOR> I'm planning on making it a URL to a pdf of the postage...that work?

<comment><USER17> I think USPS labels are returned as PNGs - would probably be easier to just shoot that back, no? At least our method of generating USPS labels (Stamps.com API) shoots back PNGs.

<comment><AUTHOR> Ah, okay. Yes, that'd be easier. Other services provide PDFs but agree PNGs better

<comment><USER26> You could bake this into the REST API via the "Accept:" header. The default when not specified is whatever you set, but the caller can specify "Accept: image/png" to get a PNG image, "Accept: application/pdf" for PDF, and so on for whatever other types of output you support. The advantage of PDF (or SVG even) is that, if it was constructed using text/vectors, the output resolution is limited only by the capabilities of the printer.

<comment><AUTHOR> Ah, great idea. I like that

</comment></comment></comment></comment></comment></comment><comment><USER27> Could you add syntax-highlighting to the examples?

Using httpie as an alternative to curl would also make that easier. :)

<comment><AUTHOR> Great feedback, thanks!

</comment></comment><comment><USER28> Really interesting idea. Could seriously see myself using this.

<comment><AUTHOR> Great, what's your use case?

</comment></comment><comment><USER29> I didn't realize Dirk Diggler lived in Half Moon Bay.

<comment><AUTHOR> Word, Reed and Dirk had to get out of dodge

</comment></comment><comment><USER30> did a kind of similar project a few weekends back: <http://scrubmyaddress.com/> :)

</comment><comment><USER31> Missing a comma in the first screenshot ;)

<comment><AUTHOR> ack! fixed!

</comment></comment><comment><USER32> Ugh, I'm starting to get sick of Bootstrap. You've got a great idea and you remove value from it with bootstrap... How integral can your product be if you can't even give it a unique UI?

<comment><USER33> I disagree. Given what the app is about, I don't care about the UI. In fact, I'd rather they spend more time on the backend than on the website - at least to get started. Bootstrap is familiar, it's not bad - there's a difference.

Once the service is proven to work and they've got customers, I'm sure a UI refresh would happen. At this stage it's probably more important to worry about the things that matter most to the longevity of the project.

<comment><AUTHOR> Agreed. Stuck between working on the product and working on UI I chose an admittedly weak UI (I'm not crazy about it but it works) so I could work on more important, for now, pieces of the product

<comment><USER32> I respectfully disagree with both of you. This shouldn't be a case of not having enough time, make time and get both parts to a decent level. Creating a bespoke splash page should be the easiest bit.

You need to take your developer hats off and put your salesmen hats on if you want to sell your product.

<comment><USER34> I respectfully disagree with you. :)

When I encounter a site with Bootstrap showing, I don't think "oh, this person doesn't care about the value of having a custom UI, or doesn't know how to sell their product" - I think "this person knows where their priorities lie, and has optimized their effort towards the things that provide the most value for their business". I'm sure when a custom UI becomes something more worth prioritizing, it will be moved up the list of things to do.

<comment><USER35> Hm, my impression is more along the lines of, "this probably was hacked together in a weekend and might be discarded in another." It's not a fair impression, but my snap judgment is that if somebody is invested in their product, they'd put a little time into differentiating its look.

However, the homepage for this product emphasizes its use as an API, so I am not very concerned about look and feel at all, and am much more interested in API docs. It looks like these are not ready yet.

<comment><USER36> I spend hundreds of thousands of dollars a year with service providers and vendors as lead developer/devops/sysadmin/etc at a tech consulting firm in Chicago.

I don't give a damn how the site looks; if you're solving a problem I need to get solved, I'm taking my Amex out to pay for it if it makes our work easier.

<comment><AUTHOR> Good to hear! You in the market for a solution like EasyPost? I'm at firstname.lastname@example.com and would love to chat!

<comment><USER36> I am! Will have an email off to your shortly!</comment></comment></comment></comment></comment></comment></comment></comment></comment>


Pulling the plug - <AUTHOR> http://www.thedotpost.com/2014/11/mike-mcneil-pulling-the-plug

<comment><AUTHOR> btw some more background on where this came from: [https://gist.github.com/mikermcneil/5746660](https://gist.github.com/mikermcneil/5746660)</comment>


Cowboy - A small, fast, modular HTTP server and socket acceptor pool - <AUTHOR> https://github.com/extend/cowboy

<comment><AUTHOR> I've been using this wonderful piece of software for a couple of weeks now. It's extremely powerful when you need to implement multiple interfaces (including non-HTTP-based) to the same data-source.

The performance (only done preliminary testing) looks very promising as well.

A huge amount of kudos to the author!</comment>


Errors are values - <AUTHOR> http://blog.golang.org/errors-are-values <comment><USER2> What in Go is a return type of (Anything, error) with typically exactly one of the two being nil is in Rust the Result type, `enum Result<T, E> { Ok(T), Err(E) }`, something which is explicitly exclusively-either an OK T or an error E.

The equivalent of `x, err = expr; if err != nil { return err }` is _very_ common in Rust; it would be written `x = match expr { Ok(x) => x, Err(e) => return Err(e) }`. It's such a common pattern that a macro named try! was placed in the standard library for this incantation. Therefore you can write `x = try!(expr);` (or if you're going to ignore the Ok variant, just `try!(expr)`).

Rust also warns you if you do nothing with a Result object; you can ignore the warning or suppress it, but it all makes it very much harder to ignore such error conditions. Go is one step up from C, where integral error-indicating return codes are the norm and are typically ignored, but I feel it's still a fair way off the confidence that Rust gives me that I haven't accidentally forgotten to deal with an error case. If you want people to _get_ the message "Whatever you do, always check your errors!", it helps if you design the language to make it hard for the user to forget.

(You people that know Rust, I'm ignoring the `FromError` part for simplicity. That's only in libstd's try!, anyway; libcore's try! doesn't have it.)

<comment><USER3> In Go I not infrequently make use of a non-nil value AND a non-nil error. A canonical example of this is the io.Reader interface in Go's standard library [1]. I think it is a very useful idiom particularly when dealing with things where failure is more normal - e.g. dealing with network services, disk IO, decoding partially corrupt exif data from images. Often you want a best-effort at the value even if you run into problems.

[1] [http://golang.org/pkg/io/#Reader](http://golang.org/pkg/io/#Reader)

<comment><USER4> That can be done by either returning a tuple or providing a way to get a partial value out of your error type. (Result is generic over the error type, so you can add whatever extra data you'd like to your errors without forcing your callers to downcast.)

</comment></comment></comment><comment><USER5> >We recently scanned all the open source projects we could find and discovered that this snippet occurs only once per page or two, less often than some would have you believe.

once per page? that's once per 30 or so lines. 2 or 3 percent of the code is this same repetitive structure? Also, only takes one time to forget this for everything to fall apart.

We've spent so much time trying to deal with uninit'd pointers and things like that on the language level, and here we have something that's much simpler, yet super repetitive and should be easy to catch on compile time.

Maybe I'm just a bad programmer, but I really prefer the Java "force you to catch exception" model much more to this.

>It's worth stressing that whatever the design, it's critical that the program check the errors however they are exposed.

If it's critical to check the errors, I think that it's worth writing language rules in a way to force people to write a "has error " code path (think pattern matching).

I get go is trying to be as small of a core as possible, but I think there's a lot of value in extra compiler checks (with no runtime cost!) to catch this sort of thing.

<comment><USER6> > that's once per 30 or so lines. 2 or 3 percent of the code ... I really > prefer the Java "force you to catch exception" model much more to this.

And that 2%-3% doesn't include where errors _should_ have been checked but were not. For instance run programs without stdout ("./program 1>&-") and most Go console programs will just happily write to nowhere whereas almost all Java ones error out immediately. Closing stdout doesn't often matter, but sometimes things like this are important.

I don't understand how in the 2010s it's okay to make a language with worse reliability. And worse "JavaDoc" equivalent. Go should be better than C and Java in every category and it's just not better in way too many.

<comment><USER7> Language design is about trade-offs. Broadly speaking: being good in one category means being bad in another.

<comment><USER8> While your comment is sort of true, it's not applicable here really.

We know how to handle errors better than this. Go's error handling is C style. We've since found exceptions, Maybes, and friends which are very powerful.

What you said implies that when Rust chooses to use Maybes they're somehow being bad at something. That's simply false; computer science as a field has advanced and one of these advancements (not even that recent of one) is improved understandings of how strong type systems can be used to make code, including errors, safer. Go completely ignores this of course and they're not doing it for a tradeoff that I can see. They gain nothing in terms of performance for not having this type (everything is already a reflect/Value anyways, so much for not having the baggage that you'd need for generics) and everything in terms of having a worse language.

Being good at something doesn't instantly mean you're bad at something else. In fact, I wouldn't even claim that's the general case.

If you disagree, you're welcome to point out the tradeoffs at work here. I think your comment is just a vaguery that is completely untrue in this instance.

<comment><USER9> The corresponding loss to Rust's gain is language complexity.

<comment><USER10> I think this argument is depressingly uncharitable.

One of Rust's goals was to remove the "feature" of null pointers. In its place rose the feature of tagged unions, to support the `Option` type. This is strictly trading one feature for another. Once this necessary task was completed, Rust was happily able to reap all the benefits of tagged unions elsewhere, such as with the `Result` type. It is not greater language complexity, it is merely the reuse of simple language features to empower developers to create more robust software.

Now, I am not among those saying that Go needs tagged unions, or any other feature for that matter (no, not even _that_ one). I think Go is a good language, sometimes to the surprise of my peers. But what's disheartening to me is seeing a Go core developer imply that Go is literally the baseline for programming language simplicity, in effect papering over all the various tradeoffs that programming language design entails.

<comment><USER9> You mischaracterised my point. Go is hardly the baseline for language simplicity. We just made a different set of trade offs to the Rust team, and I believe Go is the simpler (not simplest) language.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I get being against exceptions in a language like C++ where it can leave your program in a really weird state and have some ugly performance implications, but I don't get the argument in languages where it can work just fine.

The argument seems to be "you should be checking for errors anyway", but I feel like there are basically two types of errors: the obvious kind that you're going to check for anyway (or get bug reports), like network disconnects and bad files, and the "how the hell did that even happen" exception. For the obvious exceptions it seems like a wash, other than the try catch block being a bit cleaner, but for the "hell the hell did that happen" error exceptions seem way more useful. I'd much rather my program explode immediately than risk someone letting the error passing silently because people didn't check err because like "that will never happen". I know, functions can call panic and all that, but it just seems clumsy for no net gain.

I do think there's one type of error checking that doesn't get enough love (I don't know if Go has this, but I'm guessing probably?). "assert" that gets removed in release builds. It's kind of silly when you're working alone, but in a team of programmers or for libraries it's awesome, because it's basically like runtime documentation that gets compiled out. So you can warn your fellow devs about things without it bloating your program. The newer C++ has a really great feature called "static_assert", which is basically a compile time assertion, which can be handy for things like checking in various places that maybe if the count in enum changed, that you accounted for it in another spot of the code, or that certain aspects of a new platform sit right, or things like that.

<comment><USER12> > I get being against exceptions in a language like C++ where it can leave > your program in a really weird state

If you're programming in modern C++, then exceptions allow you cleanly (as in, clean code) leave your program in a very well defined state. You have to adhere to RAII, and there's a lot of C++ shops out there that don't allow RAII (and are wary of exceptions, because they ignore RAII). I've routinely used exceptions in C++ as a both efficient and clean way to propagate errors out to a stack frame that can handle them, fully confident that RAII will clean up as I go.

> and have some ugly performance implications

More than having an error object that the calling frame needs to check? If I understand Go (and, since it's mentioned here and I think is relevant, Rust's) setup, each stack frame between the frame that can handle the error and the one where the error occurred must check that an error did indeed occur, and if so return it. Rust makes this pretty through macros, and the article has some good thoughts on it for Go. Nonetheless, can the compiler compile that to better than an `if error { return error }` type check?

My understand of C++ exceptions is that this was basically how things _were_ done (but no longer). Previously, exceptions were managed by "sjlj" (short for setjmp, longjmp, the calls used to manage exceptions); any frame that _could_ have an exception would need to call setjmp on entry, and this was a bit hefty.

However, my understanding is that, at least for g++ on Linux, C++ has abandoned this in favor of a newer scheme called "dwarf2"[1]; this scheme is such that entering a "try" (or a stack frame where RAII would need to do actual cleanup) is free (rather, it is covered as part of the normal stack setup, really), leaving it gracefully is also free; only during actual stack unwinding do exceptions add code/performance penalties.

I think there is an unfortunate amount of information that C++ exceptions are inefficient left over from the sjlj days.

[1] [http://www.x86-64.org/documentation/abi.pdf](http://www.x86-64.org/documentation/abi.pdf)

<comment><USER13> Entering a try with newer implementations of exceptions is free in that it doesn't execute anything extra, but it's not free. It inhibits the optimizer and creates a lot of duplicated code in the binary, as well as forcing exception safety on the programmer, which is pretty hard to achieve completely, efficiently, and/or cleanly.

</comment></comment></comment><comment><USER14> Rather, (in Go) errors are values that violate type safety and destroy any correctness guarantees the compiler makes.

Languages like Rust and Haskell do this right. Both make heavy use of optionals for failable functions, and Haskell's support for HKTs (and therefore Monads) allows awesome stuff like Maybe or Either chaining.

Monads allow you to write code that, syntactically, looks like you're not doing any error handling. In reality, the error handling semantics are baked in at the Monad level. This makes sense, because error handling is usually very repetitive (e.g. "Check if the function we just called failed. If it did, return early. Otherwise, keep going." ad infinitum). As a (pseudcoded) example:

        parseTimeString :: String -> Either Error Time
        parseTimeString string = parse string $ do
                hours <- readHours
                semicolon
                minutes <- readMinutes
                semicolon
                seconds <- readSeconds
                return (Time hours minutes seconds)

If any of those steps fails, the entire computation will stop and the error message will be returned. This is roughly equivalent to checking for "nil" (in Go) after every function call, except you don't actually have to do it. This is defined in the code for the Either monad, which is at [https://hackage.haskell.org/package/base-18.104.22.168/docs/src/Da...](https://hackage.haskell.org/package/base-188.8.131.52/docs/src/Data- Either.html#Either) . As you can see, it's 4 lines of code.

(Side note: this is pretty much how you write parsers in Haskell using the Parsec library)

<comment><USER15> > Both make heavy use of optionals for failable functions ….

Haskell doesn't do so enough, though (I don't know Rust and so won't comment), so that we still need manually to choose to use the safe library ([http://hackage.haskell.org/package/safe](http://hackage.haskell.org/package/safe)).

<comment><USER16> Yes, some unfortunate historical choices there.

<comment><USER15> > Yes, some unfortunate historical choices there.

Do you know anything about the motivation of those choices? Surely it won't have escaped anyone's notice, especially not the designers', that this is a wart on the language, and that there is an easy solution; so I can only imagine that the easy solution was rejected for its inelegance—which seems strange, given the devotion to theoretical purity of the rest of the language. (I contrast the situation here to that of the numeric tower, which is clearly flawed but for which, even now, the 'right' approach is not so clear.)

</comment></comment></comment></comment><comment><USER17> I disagree.

Of the various approaches I've seen to cope with this problem, Rust's try! macro is the most elegant.

Given the practical minded nature of Go and the core team's willingness to add in special cases to the language where appropriate, I think a Go version of try!() would be welcome and fit with the ethos of Go. It solves the 80% case and it doesn't mean the creation of a type-safe macro system.

The thesis of the blog post is that errors are values and thus you can program around the repetitive handling of them. But the proposed solution of writing a one-off implementation of Maybe like `errWriter` isn't an answer because:

1) Most importantly, when you need to call 3 functions which return differently typed values and can fail, there's nothing in the language to help you. This is the common case. 2) The implementation is now less obvious. To understand it, I need to read the `errWriter` helper code. 3) The code space you'll save by writing a new Maybe type is negligible.

<comment><USER18> try! isn't too hard to emulate in Go, simply write a wrapper that panic()'s on and error and passes the first value through.

The rust Result idiom is easy to implement as well, and is used frequently in the database.sql package to handle nulls.

In this way, rust and Go are not that different. The biggest difference is the lack of a generic Result, which means you have a NullString struct with a Valid and String method.

<comment><USER19> > try! isn't too hard to emulate in Go, simply write a wrapper that panic()'s > on and error and passes the first value through.

That isn't what try! does in Rust. You are thinking of unwrap().

<comment><USER18> You're right. Thanks!

</comment></comment></comment></comment><comment><USER20> This looks suspiciously like implementing Maybe every time you need to deal with a series of errors.

<comment><USER21> Maybe is not an error-handling mechanism because it doesn't report any error message. I don't know why Haskell programmers think it's any good for reporting errors.

You could use Either, but it doesn't give you any guarantee that you'll get a string back, and the naming is lousy. (Left and Right? Really? I know there's a mnemomic, but we can do better than that.)

So, might as write your own ADT and name it right.

(Also, a real error-reporting mechanism should support cause chaining so you can see the dependencies; you can sort of do it with string concatenation but it gets awkward after a few levels.)

<comment><USER22> > You could use Either, but it doesn't give you any guarantee that you'll get > a string back

1\. It's better not to use strings and instead use a user defined error type. 2\. What do you mean "doesn't give you any guarantee you'll get a string back"?

> real error-reporting mechanism should support cause chaining so you can see > the dependencies;

Can you elaborate on cause chaining, perhaps with an example?

<comment><USER21> What I mean is something like a stack trace except without all the extra detail:

      - Can't persist shopping cart
      - RPC request failed: http://example.com/update_cart
      - Can't write to database "carts"
      - Can't save file: "/a/b/c"
      - OS error: disk full

Ideally, all errors in the cause chain should be logged, and they typically cross abstraction boundaries; the message at each level comes from a different part of the stack. This seems hard to do across languages, but within a language there should be a standard way to do it.

(Go falls down on this too. Perhaps we don't need Java-style stack traces that go on for multiple screens, but we should have more than a string.)

</comment></comment></comment></comment><comment><USER23> I'm a Go developer, but I don't buy this. At best it's showing how, with a bit of work (often times by the developer), errors aren't that bad. But I don't see how it's showing that it's better?

If you log the error when checking if ew.err != nil, which might be many lines or even a different function, you'll have a hard time getting a meaningful context (which is hard to do in Go in the best case), like a stack.

<comment><USER9> The point is not to use this exact pattern, but to write code to handle errors in a way that works in your context. If the error check is many lines away or in a different function, you should use a different approach.

</comment></comment><comment><USER24> I think Peter Norvig's quote "Design patterns are bug reports against your programming language" is a perfect fit for this situation.

<comment><USER25> I'd really like to see a reputable source for this statement. All I can find are people attributing that quote to Peter Norvig.

What I can find, is this: [http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatu...](http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures)

<comment><USER26> Looks like it's from a slide deck[0] (maybe a presentation) he did. I know it's not the exact quote, but he may have said it in a talk?

(slide 4) "What Are Design Patterns: To avoid limitations of implementation language"

[0] [http://norvig.com/design-patterns/](http://norvig.com/design-patterns/)

<comment><USER26> Looks like the site is down now? Archive.org link for it:

[https://web.archive.org/web/20141224143931/http://norvig.com...](https://web.archive.org/web/20141224143931/http://norvig.com/design- patterns/)

</comment></comment></comment></comment><comment><USER27> The stdlib's compress/bzip2 internally does the same sort of thing where you do a bunch of operations and then check for errors: [http://golang.org/src/compress/bzip2/bit_reader.go#L12](http://golang.org/src/compress/bzip2/bit_reader.go#L12)

And regexp uses panics to propagate parse errors up the stack internally, and that's even described in Effective Go: [http://golang.org/doc/effective_go.html#recover](http://golang.org/doc/effective_go.html#recover)

In both cases an error value is returned to the package user.

In general, I think you should feel freer do abnormal things that suit your situation _within_ a package as opposed to across API boundaries. The standard ways of doing things should still be preferred when it's not too costly: the standards are what they are for a reason (even if the tradeoffs they represent are more appealing in some situations than others), it's easier to read code that's written in the way everyone's used to, and standards help keep you from spending time bikeshedding unimportant details. But the surface area of your package is the first thing users will have to learn, and what you have to keep in your head whenever maintaining code that uses your package--that's what it's most important to make clean and normal-looking and consistent.

I know the post talks about using an unusual error-handling pattern in an API, and you can do that sometimes, too. Just trying to make a separate point--when you're thinking about doing unusual stuff, keep in mind there's a big difference between an unusual implementation and an unusual API.

<comment><USER28> Panics can be incredibly useful. I use them in HTTP services to simplify returning error JSON objects to the consumer.

In general I'm a bit surprised about all the hate(I say hate because of how people react to it and react to suggestions for how to better work with it) the error system gets. I find that creative use of error/panic can usually scratch my "this is too much error handling code" itch when it flares up. As long as it's documented in the API I agree that unique public error handling strategies are not all bad.

Interestingly I write a lot of C#, which of course has try/catch/finally, and I find that if you are doing it properly you have many levels of handling and a strategy involved at the different levels for what should done when. I find that many people write TERRIBLE error handling. There may be try/catch sprinkled around but there will be no strategy to it with edge-cases and improper handling abound(masked exceptions, finaly's throwing new, unrelated exceptions, etc). I personally find the amount of effort required into developing and executing a robust error handling strategy to be about the same between C# and Go. That's not to say that I don't sometimes wish Go had C#'s error handling( ;) ), but I realize they are different beasts with different masters.

</comment></comment><comment><USER29> This article is bizarre. I've read it twice expecting an actual solution to null checking basically everywhere and it doesn't actually present one.

I'll stick with discriminated unions in F#, thanks. Errors are values, correct. But it seems hardly any languages actually bother to grok the concept. If your language doesn't provide type safety for ensuring that you capture all resulting conditions then it has failed its job.

<comment><USER30> Somehow the vast majority of code is written in broken languages?

<comment><USER29> Yes. Along with the vast majority of programmers being absolutely terrible at their job, to such an extent that they can't even choose an appropriate tool (language) to do their trade with.

Just look at how OpenSSL is written in C++. And look how that turned out. OpenSSL indeed. Wide-fucking-openSSL would be an even better name. Open to OSS contributions it is not; because the codebase is in such a terrible state. What is the point in OSS if nobody can contribute because it would take a year just to understand the ridiculousness of the codebase, right down to trying to understand why they chose such an inappropriate language for creating a supposedly verifiably secure software system.

</comment></comment></comment><comment><USER31> That second-last example with errWriter destroys safety AFAICT, since it requires the user to remember to check for ew.err to see if the whole sequence of operations actually succeeded or not.

Atleast the last example with flush returning the error made sense, since that's an explicit "commit" operation that the user must call for correctness. However not every series of operations has a final commit operation, so this technique is unsafe in general.

(In fact even flush might be optional? I didn't check the docs.)

Edit: The docs for flush say nothing, but the docs for the Writer interface itself ( [http://golang.org/pkg/bufio/#Writer](http://golang.org/pkg/bufio/#Writer) ) do:

> After all data has been written, the client should call the Flush method to > guarantee all data has been forwarded to the underlying io.Writer.

<comment><USER9> > That second-last example with errWriter destroys safety AFAICT

It is possible to make mistakes. Go isn't the kind of language that forces you to be safe and do the right thing all the time. Like all languages, it makes tradeoffs.

</comment></comment><comment><USER32> Go lacks a construct comparable to "with" in Python, or WITH-OPEN-FILE in Lisp, to guarantee that things get closed out on scope exit. Go has "defer", but that's a clunky replacement. You have to explicitly write the "defer", and it's always function-scope, not construct-scope.

Most of the problems with exceptions in C++ come from the C++ memory model - allocation and deallocation in exceptions are usually painful, and care must be taken to clean up and unlock things. Go doesn't have that problem - it's garbage collected.

Go does have "panic", which is Go's answer to "longjmp". People keep trying to use that as an exception mechanism, which is not a good thing.

Python seems to have the best track record with exceptions. Python's usual problem with exceptions comes from library functions which, under some rare circumstance, raise an unexpected exception and take down the whole program. This is mostly a legacy problem due to the poor original design of Python's exception hierarchy. You would like, for example, for everything that can possibly go wrong with an HTTP read or a network operation to be a subclass of EnvironmentError, as caused by an external event or data. That wasn't the case originally. There are still problems in Python 2.7 with getting a ValueError because some low-level data item was bad UTF8 or something like that.

The trouble with the "errors are values" concept is that error details tend to get lost as errors propagate upward. This came up yesterday on HN in connection with network errors for GoGo's airborne networking service. I once argued that D's error type should have a "why" pointer slot, so that, when you passed an error upward, you could link the lower-level error to the higher level error. The error message printer would then list out the errors, yielding something like

        Unable to complete transaction
        because database update failed
        because database connection was lost
        because of network error "Host down".

<comment><USER33> > Go lacks a construct comparable to "with" in Python, or WITH-OPEN-FILE in > Lisp, to guarantee that things get closed out on scope exit. Go has "defer", > but that's a clunky replacement. You have to explicitly write the "defer", > and it's always function-scope, not construct-scope.

The problem of avoiding resource leaks is somewhat orthogonal to error handling, though. Do note that Python's "with" statement doesn't play well with "yield", which is an important gotcha. But in practice, it's quite convenient.

</comment></comment><comment><USER34> "I was wrong about Gopher's Law. The probability of mentioning generics in a #golang discussion starts at 1 and raises with time." \- Dave Cheney.

Article posted 1 hour ago. Ctrl-F Generics = 3 matches

<comment><USER35> True, but I fail to see why it's relevant. Every mention of generic here (at time of reading) is along the lines of "this pattern could be generalised if we had generics", which IMO is a fair point to make when discussing ways to make a repetitive design pattern less painful.

</comment></comment><comment><USER36> If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest ``it cannot happen to me'', the gods shall surely punish thee for thy arrogance.

<comment><USER37> Upvoted -- you got the tone of go exactly right. We're headed back to C#. Don't like religion in politics or programming languages.

<comment><USER36> It's actually a quote from this document which is very very old:

[http://www.lysator.liu.se/c/ten- commandments.html](http://www.lysator.liu.se/c/ten-commandments.html)

</comment></comment></comment><comment><USER38> One thing I love about the repetitive err pattern is that I find my self wrapping/appending errors with useful context more frequently (rather than say catching an exception five frames further down and just appending "mylib: oops").

I realise the later was just laziness on my part, but the constant err checking really does force good habits on me, which of course yields higher quality code that's easier to reason about when something goes wrong.

<comment><USER39> > (rather than say catching an exception five frames further down and just > appending "mylib: oops").

That is why I like exceptions, so I don't have to explain possible errors like this if I don't have to, but can get a top level exception and see a stacktrace with it. Then choose to add aditional info.

I really like that pattern and use it quite a bit. For example, it is easy to turn code that connect into a piece of code that re-connects with a back-off without having to modify lower layers of the connect call itself (say because it is already in a library).

</comment></comment><comment><USER40> Lua uses this to handle errors---I don't find it really tedious. A common pattern is kind of the same---to return either one return value and nil and then an error message or an error code (Lua, like Go, has multiple returns) in case of errors. This results in code like

        let res, err = some_function()
        if res == nil then -- you can also check for err ~= nil like in Go
           -- return from this function with something, err contains more
           -- information
        end

I think it's very neat---you can also return nil, err from this function if you can't deal with it and some code up the stack should be able to handle it in a meaningful manner. I don't find it particularly tedious; i.e. not less tedious than writing try..catch blocks, and you can clearly see where are the function exit points, whereas with exceptions, any line can theoretically throw an exception. A missed error check can be troublesome, but generally using nil as a value further down in the function will hopefully trigger another error which might be then caught so you can spot the bug.

Lisp's continuations are also IMHO a great mechanism---you catch the error and then you can tell the function down the stack what it should do: you can abort, or you can try fixing the error and continuing, or you can try again for some number of times and then report a new error if that fails. It's more flexible than stuff I've heard of before.

<comment><USER41> Just curious---doesn't that pattern inhibit you to return nil as a meaningful, valid result? Or is nil treated as invalid value in Lua culture?

<comment><USER42> Neither. It just basically never happens that you want both error reporting and a maybe (nil or value) from the same function. Not in list? Nil. Could not parse? Nil. Iteration ended? Nil.

</comment></comment></comment><comment><USER43> I don't know if I'm just ignorant, but I like that Go forces me to use real estate for dealing with errors. It's the first language I've used where I give as much attention and design to the "sad paths" as I do to the "happy path". And I'm very comfortable navigating through text files and folding blocks of code, so it doesn't bother me if handling an error costs me a few lines.

Macros like try! might take up less space, but is that really a bottleneck for your work?

<comment><USER8> That sounds incredibly ignorant to me.

If this is the first language you've used where you give that sort of attention to errors, you must not have used and learned from the terrible mistakes of C, which constantly returns errors which are not required to be handled, just like go.

Heck, you must not have learned from bash where every second line is "if [[ $? != 0 ]]" or you just did set -e and fail hard.

For me, the problem with Go's errors isn't even the lines they take up, but the fact that they still don't accomplish anything more than C's errors.

Since C, we've learned that you can use exceptions to force errors to be handled, or Options + matching to ensure each case is handled or extremely explicitly ignored. We've learned that errors can have contexts like call stacks attached to them.

Go ignores all of that and goes back to the C way. It doesn't provide an easy way to chain errors or force them to be handled. It doesn't provide a good idiomatic way to differentiate between the majority of errors from the stdlib because it's discouraged to have multiple error struct types; rather you're encouraged to use errors.New and make an un-differentiatable error type with no good context. It's encouraged to return an err from deep in the stack without including any additional information.

In fact, Go's even inconsistent in how it uses errors in the stdlib. For example, if you look at io, you can see the following: [http://golang.org/pkg/io/#pkg-variables](http://golang.org/pkg/io/#pkg- variables)

They define their variables as error types which are simply strings. That means you can compare with the constants (e.g. err == io.EOF), but if you add any extra info to that err, such as callstack, you can no longer compare with it. If you look at os, you see "os.IsNotExist(err)" which tells you if an err is of a given type. If you look at net ( [http://golang.org/pkg/net/#AddrError](http://golang.org/pkg/net/#AddrError) ) you can see they implemented their own Error interface implementations which you check by doing `if addrErr, ok := err.(AddrError); ok { // handle error }`.. the fact that the Go authors included three different error patterns in the stdlib already shows that the entire error process in go is poorly thought out. In addition, none of the methods allow you significant flexibility in adding your own info to the error as you pass it up without losing information.

If you don't like try! in rust, you're free to write your errors out explicitly, but if try! fits then it's good to use it.

The majority of bugs in code come from people being unable to keep a sufficient amount of the program state in their head to track program flow accurately. If half of your program flow is errors, then no wonder. There's an old principal that each function body should fit, in full, on one screen because that ensures it can be read without scrolling and reasoned about fairly easily. Error handling wasting space also wastes thought and makes your code provably harder to reason about (if you don't think that's true, look at the incidence of 'mistake checking error return values in c' vs 'mistake checking error return in haskell' vs 'forgot to either catch or annotate throwable for exception in java'. Yeah).

<comment><USER44> So what's your suggestion here? It sounds like this person feels more proficient, more on-the-ball, writing Go.

So, you call them ignorant (incredibly ignorant, at that) because they're not using a language with exceptions or pattern matching, and they're wasting they're time on "C-style" error handling and... what? They're ignorant until they use something else?

You're also drawing a weak conclusion here: if you use Go idomatically, which requires more lines on your screen for error handling, and a majority of programming errors are a result of the programmer not being able to keep a sufficient amount of program state in their head because of code not fitting neatly on the screen, then using Go leads to more bugs.

Do you have anything that substantiates that?

<comment><USER45> > So, you call them ignorant (incredibly ignorant, at that) because they're > not using a language with exceptions or pattern matching, and they're > wasting they're time on "C-style" error handling and... what? They're > ignorant until they use something else?

Honestly, yes, though I would try to phrase it more constructively. If you've only seen C-style languages, it's easy to be ignorant of the world out there; it's easy to try two or three languages and think you know what's going on, when in fact the languages you know all come from a very similar lineage. Like learning English, German and Dutch, and then assuming you know the general principles of human grammar.

If you've tried a language pattern matching and higher kinded types, and found them to be not useful, then fair enough. But you owe it to yourself to try, and even if you end up not using the feature, understanding it will make you a better programmer.

> Do you have anything that substantiates that?

Over many years of research into what causes bugs, there's only one thing we've ever been able to correlate reliably with number of bugs: number of lines of code. Even across different languages, the correlation holds: [http://programmers.stackexchange.com/questions/185660/is- the...](http://programmers.stackexchange.com/questions/185660/is-the-average- number-of-bugs-per-loc-the-same-for-different-programming-languag) . So the only evidence-based way to reduce software errors is to reduce lines of code - something you can do by switching to a more expressive language.

</comment></comment></comment></comment><comment><USER46> How about just using beloved tables instead? Maybe even with function literal to prepare some stuff, if you need to.

       for _, s := []string {
          p0[a:b],
          p0[c:d],
          // ...
       } {
          _, err = fd.Write(s)
          if err != nil {
             return err
          }
       }

As others already implied it could have been cleaner with exceptions, but I don't think this is that one case where exceptions are particularly important. There is no recursion yet or anything like that.

</comment><comment><USER47> I think explicitly handling error like go is a good thing. Error handling is a tricky thing that needs thought to get right and should be expressed clearly in the code. My only complaint is that `if e != nil { return e }` takes 3 lines of code. Could `gofmt` format that into one line with no line breaking, I am already pretty happy. If they could add a keyword like `ereturn` that only returns when the last parameter (must be error) is not nil, just as an alias, I would be totally satisfied.

</comment><comment><USER48> Errors are absolutely values and that's a great perspective for any language to take. Essentially, you can see an errorful computation as "returning" either a valid return value as expected or an error. In Go the quotes are eliminated: that is exactly what happens

        ret, err = fd.Write(...)

Above we have two (initial) possibilities

        1. The return was error-free, err = nil, and
           ret is an interesting return value.
        2. The return was errorful, err != nil, err
           instead details the reason for error as
           an integer, and ret is nonsense.

This is a little challenging because we must be sure to check err in the second case since otherwise ret is silently meaningless. This is a source of bugs called "Boolean Blindness".

In a language with Sum types we'd represent this by saying that errorful computations adjoin an error type to the return type.

        Int ----> Either Error Int

What's nice is that this automatically ensures the above invariant of err/ret is held: a value of type Either Error Int is either "Right i" for some valid Int i or "Left e" for some error value e. The first thing we check is the handedness of the result and thus know the result of the computation.

Sum types like Either _solve_ Boolean Blindness because we literally cannot get access to our return type Int unless it is valid: if we find that the result is "Left e" then all we have is an Error value.

(Ultimately what this boils down to is that product types like (ret, err) behave _very_ differently from sum types and cannot replace them.)

If Go had generics we would also notice that the error-passing behavior of Either is naturally ignorant of the particular choice of types Error and ain't. We could manipulate it meaningfully (and indeed write the functionality used in this article) for any and all values e and r as the type Either e r. Then upon use Either e r would specialize to Either Error Int.

It's easy to argue that this is silly: we only need one error type and it is not difficult to replicate this code. I'll argue for now that only having one error type is at best confusing and at worst a lie. Different processes and functions have different exceptional states. Coercing all of this _variation_ in error meaning into the same error type ensures that misunderstandings and accidental unifications will occur.

Honestly, I really love Go for making sure that errors were values: it is an incredible step forward for making exceptional cases more reasonable. Unfortunately, Go does not seem expressive enough to build the machinery which makes this style of error handling all of reasonable, non-repetitive, and non- confusing.

</comment><comment><USER33> "Error are values", OK, but as a non-Go programmer, how do you handle idiomatically the most common case of wanting to bubble the error up the stack and turn it into something human-readable? Bonus if you do not break encapsulation. Double bonus if you get a stack trace out of it.

<comment><USER49> panic, recover, runtime.Stack

</comment></comment><comment><USER50> The handling of errors in go is weird if one only returns or breaks on errors. But it works fine if one does something on error, in almost every error check in my go code I have a log.Println with a human readable text like "could not read from the application configuration file." much nicer to get errors like that than a stack dump and a message like could not read from file $filename.

</comment><comment><USER51> "There is one significant drawback to this approach, at least for some applications: there is no way to know how much of the processing completed before the error occurred. If that information is important, a more fine- grained approach is necessary."

A more fine-grained approach which is conveniently omitted from the article, BECAUSE IT'S SPAMMING `if err != nil` EVERY OTHER STATEMENT...

<comment><USER52> This is required for fine grained control of exceptions too. You have to wrap each statement in a try/catch which is even more verbose than the error check in go. Otherwise you can't programmatically tell which statement failed.

<comment><USER53> Java has been recording stack traces for over a decade. This is an argument for building things into the language, because it would have been very difficult to roll our own version of it as a library.

</comment></comment></comment><comment><USER54> If you want to force the consumer to consider an error case and make _some_ decision about it... Well, I actually like Java's checked exceptions.

You've got to emit an error _somehow_ and static checking ensures the consumer won't accidentally ignore the case. (Deliberately, perhaps, but that's a people-problem rather than a technology one.)

</comment><comment><USER55> I don't get it. How is "errors are values" different from anything? In what language are errors not values?

<comment><USER52> In languages where they are exceptions and are not returned, but thrown and require special syntax to handle.

<comment><USER55> But exceptions are values too, i.e. you routinely have an object of type IOException. All of the patterns presented in the article can be done easily with exceptions.

I think maybe "errors are values" is a general principle and not meant to be specific to Go.

<comment><USER56> Exceptions are values too but they're more than values. "Errors are values" means "errors are values so just deal with them like you do other values".

</comment></comment></comment></comment><comment><USER57> Being an erlang programmer I am so used to programming for the correct case and not to check errors but let the process crash when you get an error or, rarely, use a try that I find this style of programming completely wrong. It is what we are trying to avoid. You will always miss cases.

<comment><USER58> There are many more areas where you simply cannot abort the process on any error that has been triggered. Erlang, being in the niche of network software, can get away with this because you can have mechanism that monitor the process and it's not the end of the world if one process goes down.

Imagine if your Browser crashed every time it hit an error, like a network connection issue, writing to a file, etc...! That just wouldn't be tolerated by consumers of the software.

<comment><USER59> Eh. The point is to not handle things you don't need to. There is of course a point in handling special cases (like the ones you cited). But compare Erlang's declarative & to-the-point style with Go's `…,err = …; err != nil` and you will quickly realise how much defensive programming sucks to read.

</comment></comment></comment><comment><USER60> Saying it's so doesn't make it true. You can declare that an error is simply a special value returned and expect people to check for that value all over the place, or you can declare that errors are (literally) "exceptions" and should therefore throw.

<comment><USER52> You can ignore error values returned just like you can ignore the numeric value returned from atoi. That's the point. They're just values. You are the programmer, it's your job to decide what to do with any particular value returned by a function.

<comment><USER53> It's also my job to decide what the square root of "fish" should be. What I do is use a declaration to mechanically verify that cannot ever happen. I never _ever_ want to silently ignore an error, so why shouldn't I be able to declare that as well?

</comment></comment></comment><comment><USER61> Pike's solution does not help very much, and only exposes how little work the Go compiler is actually doing to ensure your code is safe and sensible.</comment>