Missing $10,000 package of PAL SNES games recovered - ryan-c https://byuu.org/emulation/preservation/found-package/ <comment><USER2> While I love a happy ending as much as the next guy, this is a bit troubling:

> It wasn't until the story really started to take off that on February 16th, > finally a manager at the USPS Consumer Affairs department took note of the > case.

> And I mean that literally: he told me straight up the reason he was > contacting me was because of the news articles he had encountered on this > case.

Welcome to a future where only voices that broadcast their grievances loudly over social media get answered.

<comment><USER3> USPS is especially bad. Google 'how to talk to a human at USPS' for an illustration of their approach to customer service. Then know that the advice on the first page of links is all obsolete. USPS is plugging the 'security flaws' in their customer support system as quickly as people can find them. However, there are other options. When I recently had a problem with a package, I was finally able to talk to a person by first calling Amazon. The Amazon employee connected me using a secret number.

<comment><USER4> When I had a lost package I called their regular number, and had no problems at all.

They started a case for me, and eventually called back to tell me they spoke with with mail carrier who was the last to scan the package, who explained that the package was routed incorrectly, but they had it and would be delivering it shortly.

In another case I've also had good luck simply calling the sorting station and talking with the actual human who handled my package (there was just a backlog and it would be delivered soon).

I did not get an "corporate vibe" either time, but rather was able to communicate with the actual person who would know.

<comment><USER5> I feel like this depends a lot on the location.

My mail got delivered wet a few times, so I complained. And all they said to me is, it got wet because it was raining. They basically said that there is nothing they can do when it is raining...

<comment><USER6> A note about when it's raining.

Don't put out any outgoing mail. Even if yours is dry it will get wet when it comes in contact with other mail that is wet.

If you can hold off sending a letter in the rain do so

<comment><USER7> As an Irishman, this concept confuses me.

<comment><USER6> Outgoing mail can be placed in the mail recepticle where you receive incoming mail. Often the letters get wet. The carrier takes the outgoing letters.

If it's raining the wet letters get tossed into a bucket, then into a larger hamper than into a machine for sorting.

Wet letters make other dry letters wet. So even if you take them to the post office they may encounter wet letters in their way.

Ink runs.

<comment><USER8> I think the implication was that in Ireland, it's never not raining.

<comment><USER6> Lol. Man am I stupid.

Although I have had Canadians tell me that their postman does not pick up outgoing mail. Thats what I thought. DUH!2

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> I didn't comment at the time, but I found the prior comment thread a little unsettling: people trashing on USPS and irrationally holding UPS and FedEx in very high regard. It's not like the other guys are universally honest and true. I had one experience a few years ago where it seemed pretty clear that a UPS employee stole a laptop. I have seen FedEx tracking claim they did a delivery attempt when I have a camera at my door suggesting nobody was there all day. At one prior address I had, UPS literally never attempted any deliveries on Saturday, and wrote "business is closed" in tracking - at my apartment.

I think people are really quick to assume that government employees are lazy and out to screw them, and so something like UPS or FedEx which are private should automatically be better. In truth, I really appreciate the post office. They work hard for us. They're our public servants.

</comment><comment><USER10> I'm happy for a good ending. Reading this story when it first came out definitely made me feel sorry for the people involved.

Side note, when I worked at UPS they wouldn't even accept packages wrapped in brown paper for this exact reason. It gets stuck in the machine and ripped off, never to been seen again. When sending a package, put the label directly on the cardboard and write the address in marker on the side.

<comment><USER11> When I was a young hoodlum, one time I took a piece of a paper shopping bag, wrote my home address on it, and dropped it in a mailbox. About a month later, it was delivered to my house in a zip-lock bag, with the same note the OP got.

> When sending a package, put the label directly on the cardboard and write > the address in marker on the side.

While you've got the marker in your hand, also make sure you black out any barcodes on the box from previous mailings, because supposedly they can make your package get redirected to unexpected places.

<comment><USER12> You might enjoy this article on Postal Experiments: [http://www.improbable.com/airchives/paperair/volume6/v6i4/po...](http://www.improbable.com/airchives/paperair/volume6/v6i4/postal-6-4.html)

They tested all sorts of wacky stuff sent through the mail, including an unpackaged flower and a ski, both of which made it to the recipient (but various others did not).

<comment><USER10> Awesome site. I shipped a few car tires when working at UPS that we just slapped the label on and a box of rare earth magnets that was a huge pain to ship. Also some guy's removed testicle to get tested for tumour cells was pretty weird but it just went in a normal box.

<comment><USER13> My test of the UK postal service was to address a postcard to my email address.

I figured they could lookup WHOIS on the domain, get the address, and deliver it.

Sadly not..

</comment></comment></comment></comment></comment><comment><USER14> > took them to Deutsche Post for assistance in packaging them up. They ended > up taping my two boxes together, and then wrapping the box in thick brown > wrapping paper.

If you've ever shipped or received anything internationally, you know packages get really beat up. Taping two boxes together and then wrapping that makes absolutely no sense.

I'm glad this was resolved well, but you can avoid a lot of headache by not trying to ship homebrew packaging internationally.

<comment><USER15> It sounds like _Deutsche Post_ did this, not the original sender.

<comment><USER16> Yep. The guy is not a big-time games distributor. He's a guy with a childhood collection that offered to lend it to me for a few weeks.

There were definitely mistakes made on our part. But what I really can't forgive is ... once the outer wrapper came off, my address was still plainly visible on the box.

I can't for the life of me understand why they shipped it to their undelieverable mail / govdeals.com auction site location.

</comment></comment></comment><comment><USER17> What an emotional rollercoaster this has been.

It's also a lesson in not putting all your eggs in one basket. Shipping these out incrementally, and via a system that has the proper insurance in place, would have been a better move. Hindsight and all that.

<comment><USER16> We actually did. His collection was 400 games. I asked to split it into four smaller shipments. But what I failed to take into account was that I really could not afford to replace even 100 PAL SNES games. They're just too expensive anymore.

I hate that blame is being placed on him for the shipping. He was doing me the favor. It was my fault for requesting so many games to be sent at once.

<comment><USER18> Prices of SNES games have gone crazy recently. I'm seeing the same with Gameboy/Gameboy Colour, but not with Gameboy Advance.

Anyway, I'm very happy that the games got to you eventually.

<comment><USER16> The scary part is I keep saying that each and every year.

They just keep getting more and more insane.

Even two years ago when I bought Iron Commando for the Super Famicom, the $240 asking price was insane. It's at $1500 now for a complete copy. I passed on Pokonyan for $100, thinking that was too high, and a year and a half later ended up paying $800 for it.

How many years can the prices keep doubling like this? How can _anyone_ afford to collect these games at these prices?

The whole thing feels like a giant hyper-inflated bubble.

</comment></comment></comment></comment><comment><USER19> "I am ashamed at having to abuse my position and ask for help in getting this story out there. It's not something that most people can do, and in any other circumstance, is not something that I would ever do."

No reason to be ashamed at this. All the free time invested into this project gave the author a little fame. They used that fame to further the interests of the project. Win win.

<comment><USER16> Thank you very kindly.

But I mean, it's not fair in the sense that other people have packages they really care about, but can't get help on.

That and the fact that I probably took someone else's place in the queue to find their lost package :(

<comment><USER19> On the flip side, this media attention may help motivate the USPS to improve their systems. So while some may have lost a place in a dysfunctional queue, there is a chance future customers will not have to wait as long.

</comment></comment></comment><comment><USER20> I think postal staff really don't like to lose items in general. Here in the UK, I ordered a couple of metal pill bottles a few years ago. What I received was a clear plastic Royal Mail bag apologising for the damage to my parcel, contents: one loose metal container, one bubble mailer containing the other item and a circular tear exactly the size of the loose item. Clearly one of them had made a bid for freedom somewhere in mail processing and someone had gone to the trouble of matching up the completely unmarked and unbranded loose item with the corresponding hole it escaped through.

</comment><comment><USER21> > Had this case not been escalated to the media, it likely would have gone up > for auction in a bin with other electronics sometime in March.

I'm just picturing some guy in a back corner of an auction room hesitantly putting up a numbered sign to an rambling auctioneer and getting the whole package for $20 bucks.

<comment><USER16> They do it all online now, and all the big-time retro game sellers on eBay know about govdeals.com now. The auction would have gone for thousands of dollars, easily.

</comment></comment><comment><USER6> Well done.

As I said. It is a government agency and upper forces will create action.

We always like to say "if it had an address it will get there. - eventually. "

Despite the awful reputation, every carrier I know takes great pride in delivering. Most people take it for granted and remember the bad experience.

Like seeing the cop hiding in the hill once and always driving slow everytime you pass it -even though the cop is not there 95% of the time.

</comment><comment><USER22> >Further, I understand they can't go to these lengths for every single lost piece of mail. But surely there has to be some sort of middle ground here? It should not be so impossible to escalate a case when something of significant value goes missing.

It's not. You just have to insure it for the correct value...

<comment><USER23> Insuring it doesn't help you in recovering the package. It just mitigates the loss. I fully expect that both byuu and the donor would much prefer to have the 100 SNES games than to have a $10k payout.

<comment><USER22> The higher the insurance amount is, the more likely it is that it'll be worth it for the company to look for your package.

<comment><USER16> Yes, it was under insured. But do you feel the $1000 insurance we had was not enough insurance for them to locate the box that has my address clearly written on it? :/

If not, then I'm not sure $10000 would have been either.

There were many reasons we couldn't insure for $10000. That wasn't our mistake, though. The mistake was shipping 100 games at once instead of 20 - <AUTHOR> games at a time.

<comment><USER24> > If not, then I'm not sure $10000 would have been either.

i'm given to understand that with at least fedex, there are magical cutoff amounts which change the handling of the package. qualitatively different things happen with something insured for $5000 than $4999.

so, yes, i'd be willing to believe that $10k might've triggered processes that would've gotten the package to you with less hassle.

</comment></comment></comment></comment></comment><comment><USER25> _They ended up taping my two boxes together, and then wrapping the box in thick brown wrapping paper._

Somebody failed Shipping 101.

</comment><comment><USER26> "My package was sitting in Atlanta, GA for well over a month with my address clearly visible right on the box."

WOW, and they would just put that up for auction. That is the definition of theft. Don't apologize for that.

<comment><USER4> They did not actually put it up for auction, there is a long process before that happens.

Don't falsely accuse people!

The post office goes to great lengths with undelivered mail they open the boxes and try to find any kind of address, perhaps an invoice or other clues.

<comment><USER16> Do you think my address being plainly visible and highly legible right at the top left of each box counted? Because they had it for at least 40+ days just sitting there collecting dust. Even though I had my missing mail search in, just idling and going nowhere.

You're right though, there's the possibility that they don't actually try to deliver the mail properly until right before they are getting ready to auction it.

However, I'm very glad I didn't have to find out whether or not that was the case.

<comment><USER4> Until they open it all the way (remove the brown paper) they would not have seen the address.

They would only open it as part of the process to eventually auction it.

So I can totally imagine it sitting there waiting for someone to claim it (like you did), without anyone seeing the address.

Stop being so negative, it's not good for you.

</comment></comment></comment></comment><comment><USER27> The owner's address was clearly on the package. They knew whose it was and clearly did not intend to make the effort to deliver it. Until they were publicly embarrassed. That sucks.

</comment><comment><USER28> > _There is a very real issue in that [USPS 's] machines are ripping the > labels right off of packages._

I recently sent a USPS package that "disappeared," and they offered the same explanation. A month later it magically showed up at the receiving end. This wasn't a brown paper package or anything -- it was packaged for me by UPS employees in a UPS store and mailed US postal service by them.

Wondering if there's some new (flaky) label scanning tech in play at USPS?

</comment><comment><USER29> All good that ends well! Just looking at those SNES cartridges makes me feel good!

</comment><comment><USER30> Congrats on locating the package.

This govdeals.com site looks nifty. I may need to peruse it for, uh, research.

<comment><USER31> I know what you mean. Anyone need a DNA Analyzer?

[https://www.govdeals.com/index.cfm?fa=Main.Item&itemid=296&a...](https://www.govdeals.com/index.cfm?fa=Main.Item&itemid=296&acctid=3227)

</comment></comment><comment><USER32> Happy Valentines Day!

</comment><comment><USER33> The USPS is something right out of a dystopian hellhole. I bristle every time I have to deal with some awful error of theirs.

</comment><comment><USER34> Are these the same SNES games that 1 or 2 weeks ago were worth $5000

<comment><USER35> It was always 10k:

[https://news.ycombinator.com/item?id=13646438](https://news.ycombinator.com/item?id=13646438)

<comment><USER16> It's always been $5,000 - $10,000. It's extremely difficult to assign an exact value because PAL game prices are extremely fluid. One day a game can go for $50, the next day the only copies are all $200 and another copy won't show up for three years.

<comment><USER35> Sure, I was more replying to the insinuation that the value went up now that they've been found, by showing that it was always reported as 10k.

</comment></comment></comment></comment><comment><USER36> I'm a little confused. In the original story, they didn't mention that:

> Apparently, their machine ripped the shipping label right > off the box. And > so the USPS sent me just the label in an > envelope, and proceeded to berate > me to ship better next > time, even though I was the recipient.

They just wrote,

> As of the time of writing, February 14th, 2017 — this > package has yet to > arrive. It has been stuck in the Jersey > City, NJ 07097 bulk mail > processing warehouse with > absolutely no movement.

I was under the impression that the package simply vanished, rather than being given evidence that something else was up, like damage to the packaging.

Why not just tell me about the latter, first? It does shift blame a little...

<comment> crooked-v Presumably the author didn't get the label in the mail until after they made the post mentioning the NJ warehouse.

<comment><USER36> The day of the first, "lost package", and receiving the letter are the same: February 14th.

[https://byuu.org/emulation/preservation/lost- package/](https://byuu.org/emulation/preservation/lost-package/):

        As of the time of writing, February 14th, 2017 — this
        package has yet to arrive.

[https://byuu.org/emulation/preservation/found- package/](https://byuu.org/emulation/preservation/found-package/)

        On February 14, 2017, I received the following letter
        from USPS:

They totally left out this when making their initial post. Part of the package arrived, with a letter by USPS - the package didn't mysteriously vanish. It's a little different story. I don't know why they wouldn't have mentioned it. In the initial story, he blamed USPS for being incompetent on taking control of the delivery; in the second he blames Deutsche Post for a bad packaging job.

<comment><USER16> I received the letter with the torn off label about six hours after having published that article, and after Kotaku ran the original story.

I was swamped with updates so I didn't get the chance to get to my mailbox sooner in the day.

<comment><USER36> Personally, I think that type of transparency is important, especially when you're asking for donations and you're publicly pressuring the USPS to do something. Why wait 9 days?</comment></comment></comment></comment></comment>


Upgrading to Docker 1.7.0 on Ubuntu 14.04 will screw up containers by default - <AUTHOR> https://github.com/docker/docker/issues/14035#issuecomment-113584380

<comment><AUTHOR> Just got bitten by this one, upgrading a default ubuntu installation of lxc- docker from 1.6.0:

      > sudo tail /var/log/upstart/docker.log
      ERRO[0000] [graphdriver] prior storage driver "devicemapper" failed: driver not supported
      FATA[0000] Error starting daemon: error initializing graphdriver: driver not supported
      /var/run/docker.sock is up
      ERRO[0000] Udev sync is not supported. This will lead to unexpected behavior, data loss and errors. For more information, see https://docs.docker.com/reference/commandline/cli/#daemon-storage-driver-option</comment>


First U.S. use of CRISPR to directly target cancer seeks approval - <AUTHOR> https://www.statnews.com/2019/05/02/crispr-targeting-cancer-seeking-go-ahead/ <comment> Funes- As someone who lives with and takes care of a cancer patient, I'm really frustrated with how little effort has been devoted to cancer research in such a long period of time, taking into account that it's been several decades of misery now for millions of people--and a lot more to come; that's for sure.

Besides governments allocating less funding to research, prevention and treatment--for cancer as well as other grave ailments--than they could, what especially irks me is this: negligent practices carried out by big corporations to which authorities have always turned a blind eye. The sheer amount of unregulated, harmful practices that has come to define our current lifestyle is abominable. Radiation, pollution, carcinogenic and generally unsafe food, hygiene products, food and liquid containers... All factors whose pervasiveness correlates with cancer cases skyrocketing.

We should all be willing to reflect upon what we're doing to our personal and collective health, and if our lifestyles are actually sustainable or do require to be reformed.

<comment><USER2> There's a LOT of effort going into cancer research. It's just cancer is not one thing. It's not like HIV. There are many many different types of cancers, and they are currently treated and diagnosed differently. They are expressed differently. Many cancers are extremely treatable now thanks to research (testicular cancer >98% survival rate), while others are not at all (<1% for pancreatic).

<comment><USER3> main problem with pancreatic cancer is lack of detection. Virtually no symptoms or markers until very late stage.

<comment><USER4> That's true, though the five year survival rate is still pretty dismal (34%) if they find the pancreatic cancer early, when it is still localized.

[https://www.cancer.org/cancer/pancreatic-cancer/detection- di...](https://www.cancer.org/cancer/pancreatic-cancer/detection-diagnosis- staging/survival-rates.html)

</comment></comment></comment></comment><comment><USER5> It's a safe first step. These patients are guaranteed to die very soon without a miracle, so the risk of causing a new cancer doesn't matter.

<comment><USER6> Statistically likely, not guaranteed. I'm already statistically likely to be dead and resistant to chemo but so far so good. The patients know the risk though and decades is dramatically longer a time frame than they likely have. Hopefully this works wonders and can be pushed to other types of cancers.

<comment><USER7> Wouldn't accepting only those that had such advanced cancers though skew any results? I'm very much in favor of these individuals getting any and all help they can as soon as possible but I want to remain optimistic about the validity of the results.

(I can't tell if you meant to imply that you are in remission or going through chemo now).

</comment></comment></comment><comment><USER8> Just wanted to mention... if you (or one you know) get cancer, once the type of cancer has been established, ask where it typically spreads to. Monitor changes in those areas.

A relative got cancer in a lymph node, and got it successfully operated out. A couple of years later got shortness of breath and back pain. Doctors gave asthma medication for the breath and physio for the back pain.

After a year of no real progress, an unrelated shoulder x-ray showed spots in the lung tissue. X-ray technician noticed this and escalated it, and only when they verified it did we learn that the original cancer typically spreads to the lungs and bones...

Now in this case, finding the cancer had spread to the lungs and spine a year earlier probably wouldn't have done much to delay the inevitable, but it would have allowed them to start pain medication much sooner, making that year less painful.

<comment><USER9> This is definitely good advice. Also, from my own experience with cancer that spread: get a second opinion from another oncologist (get a third if you feel the need). It's your body, it's your life, do your homework.

After all of that, do your follow-ups.

Oddly enough, I'm two years out of my initial diagnosis, sitting in the oncologist's waiting room for results of my latest scans as I write this.

</comment></comment><comment><USER10> China is experimenting with CRISPR on people from 2016, NPR have an article about this [1].

It involves using cells from his own immune system, known as T cells, after they have been taken out of his body and genetically altered in a lab.

* [1] [https://www.npr.org/sections/health-shots/2018/02/21/5853365...](https://www.npr.org/sections/health-shots/2018/02/21/585336506/doctors-in-china-lead-race-to-treat-cancer-by-editing-genes)

<comment><USER11> This is such a great idea. Much more direct than trying to train the immune system with a vaccine.

<comment><USER12> We tried something similar with children with SCID [edited] a while back. Many of them were accidentally given leukemia.

Not saying we shouldn't try this, but genetics are capricious, and we should be very careful when trying things like this on humans. Plants and test animals are one thing, but when we're doing trials on humans, there's a lot more at stake.

[https://www.sciencedaily.com/releases/2008/08/080807175438.h...](https://www.sciencedaily.com/releases/2008/08/080807175438.htm)

</comment></comment></comment><comment><USER13> Love this. I really hope they get to try properly. Similarly to giving people the right to die, I wish people could get full clarity on these trials and make up their own mind. I hope it works out for them. We really need cancer to end.

</comment><comment><USER14> This will be very interesting to see. Would this be the first big use case of crispr?

<comment><USER15> All throughout biology people are using CRISPR/Cas for endonuclease and binding activity. A lot of engineered plants for instance are based on this system.

It is not simple to apply to adults, unless it's by engineering a cell culture (like T cells).

</comment></comment><comment><USER16> Messing with transcription factors? Sounds a bit like shotgun debugging

</comment><comment><USER17> That's ironic- I was under the impression that CRISPR actually caused cancer, as targeting a single gene has the effect of altering hundreds of other genes.

<comment><USER18> Not really sure where to start, but 1) CRISPR's altering doesn't necessarily only alter one gene, and 2) altering one gene doesn't necessarily alter "hundreds of other genes" either.

<comment><USER12> CRISPR isn't as specific as the (popular) scientific literature makes it out to be. It's way better than most other methods, but there's always a chance that other genes (or transcription factor binding sites, or any of myriad other constructs in the genome) are also hit accidentally.

<comment><USER19> Is that a big risk though? I imagine that for a patient (and with that a specific genome with specific editing errors) you could extract some cells, grow an in vitro culture, and test the CRISPR on that? You could then sequence the altered genome and see how much genes were "collateraly edited" and only if the result is non-risky apply the medication to the patient.

<comment><USER12> T-Cells are remarkable tricky to grow in-vitro. Most of them only grow after presented the particular antigen (for the non-biologists: the part of the virus/bacteria which they recognise) which they are keyed to. I haven't looked at the actual proposals, but I figure they'll take T-Cells, use CRISPR on those directly, clean them off (so you don't accidentally CRISPRize other cells in the body) and re-inject them directly so they won't die off.

You could sequence part of them before insertion, if you manage not to kill the rest of the T-Cells with the wildly differing in vitro environment, but by that point you're playing a numbers game. The non-specific CRISPR action (called off-target mutagenesis in the literature) is a low probability event, but if you sequence part of the T-Cells, you could easily miss one with a bad (read: non-lethal) off-target mutation.

<comment><USER19> That makes sense! Thanks for the insight!</comment></comment></comment></comment></comment></comment>


Amazon introduces Kindle with Special Offers for $114 - <AUTHOR> http://phx.corporate-ir.net/phoenix.zhtml?c=176060&p=irol-newsArticle&ID=1549144&highlight=

<comment><AUTHOR> I know the $114 price has been criticized, but I wonder if this is Amazon's way of testing the ad-supported model. Perhaps if the $25 is actually recovered through ads, then we'll finally see a $99 Kindle for Christmas.

I do wonder, however, if a Kindle is the ideal device for ads. With web browsing being so difficult on a Kindle versus a proper tablet, it should be interesting to see if Amazon can move from simple "branding" campaigns to actual intent-to-purchase campaigns.

</comment><comment><AUTHOR> Amazon's posted pictures of the screensavers and new "AdMash" tool as well: [http://www.amazon.com/gp/help/customer/display.html/ref=hp_n...](http://www.amazon.com/gp/help/customer/display.html/ref=hp_navbox_kspot_ksupport?nodeId=200671290)</comment>


I made StartupLiker.com for you - <AUTHOR> http://startupliker.com/about-startup-liker/

<comment><AUTHOR> Hi everyone, I made the service to help startups get more followers on their social sites.

Hope this works for those of you in startup land!

I'd be more than happy to take feedback

Thanks

<comment><AUTHOR> It is built of a simple wordpress template, but it should let startups easily make an account and post their info for everyone to see.

</comment></comment><comment><AUTHOR> Was hoping for some signups... anyone feeling it?

</comment><comment><AUTHOR> Does anyone know of services similar to this?</comment>


Richard Feynman and the Connection Machine (1989) - <AUTHOR> http://longnow.org/essays/richard-feynman-and-connection-machine/ <comment><USER2> This is probably the most important habit of Feynman, I tried to incorporate into my own life and studying:

"Then he would set to work, scribbling on a pad of paper and staring at the results. While he was in the middle of this kind of puzzle solving he was impossible to interrupt. "Don't bug me. I'm busy," he would say without even looking up. Eventually he would either decide the problem was too hard (in which case he lost interest), or he would find a solution (in which case he spent the next day or two explaining it to anyone who listened). In this way he worked on problems in database searches, geophysical modeling, protein folding, analyzing images, and reading insurance forms."

</comment><comment><USER3> I think this sentence from the essay does a nice job of summing up Feynman's character:

' _The act of discovery was not complete for him until he had taught it to someone else._ '

I'd recommend Hillis' Web of Stories interview series [1] to anyone who appreciated this piece. He shares several of the stories described in the essay in video form (e.g. 105, 106, 119, 127 & 234), and there are plenty of other anecdotes and insights worth listening to.

I think Hillis is pretty interesting in his own right, but he's crossed paths with some other people in addition to Feynman that HN readers might be interested in hearing about: Marvin Minsky, Jeff Bezos, Freeman Dyson, Steve Jobs etc.

[1] [https://www.youtube.com/playlist?list=PLVV0r6CmEsFzo005LM6PT...](https://www.youtube.com/playlist?list=PLVV0r6CmEsFzo005LM6PTERy4uxq92sWe)

</comment><comment><USER4> This is one of those ones I'll stop and read every time it gets posted.

Bit of trivia: in the novel, "Jurassic Park", the park's supercomputer is a Cray, but Spielberg picked a Connection Machine for the movie because he thought it looked cooler.

Also, the artist Karl Sims did some outstanding work using the Connection Machine that was mind blowing for the time, and still pretty darn cool today. The computer itself was part of the art installation:

[https://www.karlsims.com/genetic- images.html](https://www.karlsims.com/genetic-images.html)

<comment><USER5> This is the fat-tree connection diagram for one of the cabinets of a CM-5. It was posted on a wall at one of the national labs in the US which had the pleasure of working with a CM-5 around the time War Games was in theatres. People still gushed about how nice that machine was to program 10-15 years later. SiCortex[1] tried to do something similar with their computers, unfortunately they failed and with them the last interesting connector architecture and the last interesting "supercomputer". even cray does linux now...

[http://i.imgur.com/jHtf4QB.jpg](http://i.imgur.com/jHtf4QB.jpg)

1: [https://en.wikipedia.org/wiki/SiCortex](https://en.wikipedia.org/wiki/SiCortex)

</comment></comment><comment><USER6> A very entertaining and informative essay.

Could perhaps someone try to elaborate on the calculation of buffers needed per chip?

Quote: _To a physicist this may seem natural, but to a computer designer, treating a set of boolean circuits as a continuous, differentiable system is a bit strange. Feynman 's router equations were in terms of variables representing continuous quantities such as "the average number of 1 bits in a message address." I was much more accustomed to seeing analysis in terms of inductive proof and case analysis than taking the derivative of "the number of 1's" with respect to time._

How did he do it, conceptionally, and in practice?

<comment><USER7> The problem sounds like it can be solved with queueing theory. The (common) inductive proof method is covered by the wikipedia article:

[https://en.wikipedia.org/wiki/Queueing_theory#Example_analys...](https://en.wikipedia.org/wiki/Queueing_theory#Example_analysis_of_an_M/M/1_queue)

However since the arrival of messages can be modeled as a probabilistic or continuous rate, differential equations can also be used. I'm not sure if this is how Feynman did it, but this paper shows how to model queueing using differential equations:

[http://pi.math.cornell.edu/~rand/randpdf/ENOC2017_queueing.p...](http://pi.math.cornell.edu/~rand/randpdf/ENOC2017_queueing.pdf)

<comment><USER6> Thanks for looking into this, and posting these directions!

</comment></comment></comment><comment><USER8> Many previous threads, but not for a couple years.

[https://hn.algolia.com/?query=Richard%20Feynman%20and%20the%...](https://hn.algolia.com/?query=Richard%20Feynman%20and%20the%20Connection%20Machine%20points%3E10&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0)

(We changed the URL above from [https://web.archive.org/web/20070228104914/http://www.kurzwe...](https://web.archive.org/web/20070228104914/http://www.kurzweilai.net:80/articles/art0504.html?printable=1))

<comment><USER9> I don't mind high quality content such as this being shared at regular intervals for the sake of new readers.

<comment><USER8> Yes! The purpose of posting those links is to point new readers (and old ones!) at the earlier threads.

Just to be clear, if the repost was inappropriate we'd have marked it [dupe] above. The rules for that are at [https://news.ycombinator.com/newsfaq.html](https://news.ycombinator.com/newsfaq.html).

<comment><USER9> Thanks for the clarification.

</comment></comment></comment></comment><comment><USER10> I'm glad this was posted despite being perennial -- it's the first time I've read it.

Does anyone have any similar "classic" Feynman stories to share?

<comment><USER11> He wrote a few books of reminiscences which are full of them, great reads.

But this was the first time I've seen his...extremely ugly sexist behaviour displayed, not just hinted about. Very odd. In his books he's just a bit of a ladies man.

<comment><USER11> What am I being downvoted for here exactly, downvoters?[0] Do people think the behaviour mentioned is at all acceptable?! Or that 'extremely ugly sexist behaviour' isn't a fair characterization? I can't see what else in what I said could cause offence. We _are_ talking about Feynman, who believed in speaking the plain truth, pretty or not. And that story is just very creepy:

"in many ways Richard was a sexist. Whenever it came time for his daily bowl of soup he would look around for the nearest "girl" and ask if she would fetch it to him. It did not matter if she was the cook, an engineer, or the president of the company. I once asked a female engineer who had just been a victim of this if it bothered her. "Yes, it really annoys me," she said."

[0] Sorry to mention it, but this doesn't seem quite the standard case.

<comment><USER12> Don't leave out the rest of the quote.

>"Yes, it really annoys me," she said. "On the other hand, he is the only one who ever explained quantum mechanics to me as if I could understand it." That was the essence of Richard's charm.

<comment><USER11> I "left that out" because it reminded me of how people say "Yes, my husband was a violent psychopath, but underneath he was a gentle, sensitive man." or something. Being 'charming' is how sociopaths get away with it, not a balancing, redeeming feature. So don't tell me I have to mention the "redeeming feature", thanks.

(Besides, I thought it was strange she said "as if I could understand it", not "in a way I could understand"...it sounded to me like she didn't understand.)

<comment><USER12> Whoever this woman was, she was an engineer working at a cutting edge computer company in the 1970s. She likely suffered ridiculous prejudices to get to the point where she was. I'm inclined to believe that she did know (at least some) quantum mechanics and had to put up with people treating her as if she didn't know.

I can see how you've read the context and I think I've taken the opposite understanding. Either way, now people who didn't read the article can see both and decide for themselves!

<comment><USER11> I'm sorry I wrote the bit in parentheses as it meant you didn't respond to the important point, the part not in parentheses. The bit about his charmingness seemed like those justifications people give to arsehole behaviour - sociopaths are usually charming - not an effectively "balancing", redeeming one. Maybe you thought otherwise. And please allow me to make a point without being told to quote some part other than what I choose to. Thanks.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Feynman is one of the few dead people I wish I could have had many conversations with while on a long hike.

His talk describing computers to a lay audience at the Esalen Institute [1] is my goto resource whenever someone asks me how computers work. It's from the same era as the referenced article, he's even wearing the same Thinking Machines shirt.

[1] [https://www.youtube.com/watch?v=EKWGGDXe5MA](https://www.youtube.com/watch?v=EKWGGDXe5MA)

</comment><comment><USER14> "treating a set of boolean circuits as a continuous, differentiable system"

Any additional information on this?

</comment><comment><USER15> Don't read to the end, it is heart breaking.

<comment><USER16> It's not too bad if you have already read about Feynman's life and death. I liked the bits about telling and teaching.</comment></comment>


Show HN: Deployments with the Blockchain - <AUTHOR> https://www.stackmonkey.com/

<comment><AUTHOR> I built this last year using OpenStack and Bitcoin technology. The project has a site at [http://utter.io](http://utter.io). It uses callbacks from Coinbase to ping the virtual appliances, which can be run by volunteers that have an OpenStack cluster running and don't mind having strangers launch instances on them. The use-cases for this are _interesting_ and I'd suggest you treat it the same as any other early alpha software.

While working on an installer for OpenStack I came up with the idea of implementing federation with the blockchain. The general idea is that federation requires identity management, payments and some standard way of deploying code in a trustworthy way. The blockchain gives you most of that, although the storage bits are probably better served by something like Ethereum.

I went around pitching the idea a bit toward the end of the year and got pretty close to raising a round. Being a solo founder and at least a few years too early probably didn't help much. I was in the process of converting the site to use container technologies when I decided to join a German company who is writing a container stack: [https://giantswarm.io/](https://giantswarm.io/).

The whole shebang is Open Source and I'm happy to answer questions about it, if anyone has them: [https://github.com/stackmonkey/](https://github.com/stackmonkey/)

<comment><USER2> >The use-cases for this are interesting

.. and by "interesting", we mean of course "botnets."

</comment></comment><comment><USER3> very intersting</comment>


Jam the NSA Day - <AUTHOR> http://www.thing.net/~rdom/ecd/jam.html

<comment><AUTHOR> "Monitor This, Echelon" Chris Oakes Email 10.22.99

[http://www.wired.com/politics/law/news/1999/10/32039](http://www.wired.com/politics/law/news/1999/10/32039)</comment>


Skype network is down, possibly under viral DoS attack. Lessons? - <AUTHOR> http://blogs.zdnet.com/Ou/?p=683 If this is true, there are lessons to learn: (1) be open and (2) leave a door for emergency upgrades. <comment><AUTHOR> If this is true, there are lessons to learn: (1) be open and (2) leave a door for emergency upgrades.</comment>


What exactly is RESTful programming? - <AUTHOR> http://stackoverflow.com/questions/671118/what-exactly-is-restful-programming <comment><USER3> REST is a scam.

For most people, REST is simply the negation of SOAP. They should really use some term like POX (Plain Old XML) or POJ (Plain Old JSON) for simple RPC protocols implemented over http.

If I still was interested in being a maintenance programmer, I could make a pretty good living fixing broken systems based on people who drank Fielding's Kool Aid.

For instance, I once saw a Silverlight app that took 20 minutes to initialize because it traversed a tree of relationships using REST. It started out O.K. but as the app grew more complicated it took tens of thousands of requests and an incredible amount of latency.

I reorganized it so that it got all this information in one POX call that took 2 seconds. A bad architecture slowed the application down by a factor of 600 and made the difference between something that would have worked and something that failed.

People who are building toy applications can blubber about "the decoupling of the client from the server" but the #1 delusion in distributed systems is that you can compose distributed operations the same way you compose function calls in a normal program.

The issue is that the latency involved in a distributed call is about 100 million times more than that involve in a function call, and the failure rate is more than 10 trillion times more. All of the great distributed algorithms such as Jacobsen's heuristic for TCP and Bittorrent have holistic properties possesed by the system as a whole that are responsible for their success.

Hypothetically you could deal with the reliability problems of REST applications by using distributed transactions, but so far as performance and latency goes, this is like putting out a fire with gasoline.

Security is another problem with REST. Security rules are usually about state transitions, not about states. To ensure that security (and integrity) constraints are met, REST applications need to contain error prone code that compares the before and after states to check if the transition is legal. This is in contrast to POX/RPC applications in which it is straightforward to analyse the security impacts of individual RPC calls.

<comment><USER4> REST is not a scam, it's THE term for the underlying architectural style of the web.

Your straw-man interpretation is a scam.

The crappy silverlight app is badly designed and the performance issues you were seeing can be optimised away trivially. (create a new composite resource which can represent the entire tree in one go). That is nothing to do with REST.

"the #1 delusion in distributed systems is that you can compose distributed operations the same way you compose function calls in a normal program" - <USER2> is exactly what REST addresses as a style.. i.e. REST is not RPC.

Latency is another issue which REST addresses directly. This is why caching is an explicit constraint.

I have no idea what your point is re: security, sorry. Modelling state transitions is not that difficult, many languages have existing tools to help you do this.

<comment><USER5> People say stuff like "[REST is] THE term for the underlying architectural style of the web", but that assertion is pretty much back-rationalized onto the web. I know I'm not the only HN'er who was there at the beginning for HTTP, and this conceptual purity that RESTians allude to just wasn't there.

For as long as there has been a web, there has been at least one (often more than one) conceptual ideal claimed to be the heart of the World Wide Web. The reality is that the whole system is hacked together. Things that work well tend to be discovered, re-discovered, and perpetuated --- but that doesn't make any of them the web's "underlying architectural style".

I tend to buy the idea that REST-ish-ness makes for better, clearer, more usable APIs than RPC. But I also think REST needs to win on the merits, not by waving some imaginary "REST is the web" flag.

<comment><USER6> The reality is that both are true - there was an "HTTP Object Model" that TBL and Roy Fielding had in mind in the 90s, but it was never formalized until Roy's thesis. Not everyone on the various IETF and W3C committees understood or agreed with it, clearly, and there are a lot of hacks in practice. There were attempts like HTTP-NG to supplant HTTP with CORBA-like Object RPC, but the arguments against this were basically informal arguments in favour of the uniform interface of URI + HTTP + MIME. Even today, the current HTML5 leads don't particularly seem to have much appreciation for the style.

That said, starting with the Apache web server, Roy had a lot of control with its architecture and approach to supporting particular HTTP features, using his mental model of the "Web's architectural style" to guide it. After 2000 and the thesis, there are many people that started implementing their clients and servers with the style as a philosophical guide.

The style also tends to be widely misunderstood and buzzword-ified, which is scammy.

<comment><USER5> I'm not sure I buy the argument that being a key contributor to Apache gave Fielding a huge amount of influence over the architectural style of web applications. The barn door on that was opened with CGI, and since then, the architecture of web applications mostly been up to the market and the lowest common denominator of programmers.

<comment><USER6> I was not referring to the internal architecture of web applications inside an origin server. I was referring to the architecture of a web application across the various components (agent, proxy, gateway, server), connectors (client, server, cache, resolver, tunnel), and data elements (resource, identifier, representation, metadata) in the style.

The architecture of those _interactions_ has remained fairly stable over the past 15 years, even specs that route around REST like WebSockets are trying to at least adopt the HTTP upgrade & tunnel connector (HTTP CONNECT) to ensure it integrates consistently with the style.

</comment></comment></comment></comment></comment></comment><comment><USER7> REST is an anti-anti-pattern where the anti-pattern is WS-* and SOAP. If there had never been SOAP, I strongly doubt there would have been a strongly opinionated REST movement.

"Little-r REST" is very little on it's own. It's mostly just common sense as settled by about a decade of trial-and-error. I remember dabbling in PHP-RPC about 10 years ago, and most of the takeaways aren't lightyears from what REST is today.

</comment><comment><USER8> I write RESTful services, to the best of my ability. Half the tools I use enforce or encourage it.

Confession: I don't understand what the advantages are supposed to be. I want to believe it isn't just arbitrary dogma. I really do.

Applications don't care about the method or protocol a web service is using. Just get the data to and from.

Humans should care about how easy it is to maintain and implement the web services and anything they choose to do to make that goal a reality is good.

Oh, it makes for cute looking URIs, I guess.

<comment><USER9> Here are some benefits:

* _A RESTful API is discoverable_. With no background knowledge, a client can do a GET request on the root URL to get a list of resources with URLS. It's easy to dive right in and quickly figure out what is available.

* _Developers understand HTTP._ REST is essentially just HTTP, and we already understand HTTP. REST means the API developer doesn't need to waste time and energy (badly) reinventing/re-implementing what HTTP does on top of HTTP; and the client doesn't need to waste time and energy learning a bunch of ad hoc protocols.

* _Our tools understand HTTP._ Just about every client language/framework on earth already understands HTTP. Without jumping through any extra hoops, a client working in Python or Ruby or C# or Java or JavaScript or PHP or even VBScript can execute an HTTP request on an API resource and understand the response.

* _REST keeps us honest._ A RESTful API architecture forces the API developer to be clear about what is a resource and what methods clients can execute against each resource. This makes for a better-organized, more orthogonal API.

<comment><USER10> >> A RESTful API is discoverable

So is SOAP.

>> Developers understand HTTP

SOAP runs on just about anything including HTTP or even SMTP.

>> Our tools understand HTTP

SOAP doesn't care what the clients or servers are written in or run on.

>> REST keeps us honest

I disgree, you can change something in a JSON packet and the client will only know it broke when it's run. With SOAP, if your client uses a compiled language then you as a developer will know first before you give it to a customer to run, you can fix it then.

<comment><USER9> > So is SOAP.

No it's not. In theory, you can just consume the WSDL and have all the methods available to you, but in practice, there are huge and unbridgeable issues with interoperability. A C# SOAP client will have trouble consuming a Java WSDL, and so on.

> SOAP runs on just about anything including HTTP or even SMTP.

SOAP runs on top of HTTP but merely uses HTTP as a tunnel. All the stuff that should be in HTTP - the resource, the method, the data - is inside the XML envelope.

If you want to consume a SOAP web service, expect to get your hands dirty.

> SOAP doesn't care what the clients or servers are written in or run on.

In theory, no. In practice, interoperability is by no means a given.

> you can change something in a JSON packet and the client will only know it > broke when it's run.

That's not really what I was talking about, but if you make a breaking API change in any system, you should have a way to do it so clients aren't caught flat-footed when their app breaks.

Neither REST nor SOAP inherently solves this problem, but REST does allow for custom media types that include versioning.

<comment><USER11> > No it's not. In theory, you can just consume the WSDL and have all the > methods available to you, but in practice, there are huge and unbridgeable > issues with interoperability. A C# SOAP client will have trouble consuming a > Java WSDL, and so on.

This is something I have a hard time understanding. Your hypothetical generic REST client will have a hard time understanding my HATEOAS, discoverable, fully REST-ified service, if it has no idea what the service is supposed to do contextually. If my 'blog' resource has links to 'metadata' and 'related' things, without knowing what those are, how does a 'generic' REST client do anything with them?

How is that significantly different than SOAP?

I would love to see an actual example of the difference, rather than abstract discussion, as this is the point I have the hardest time understanding.

<comment><USER6> The only difference between REST-in-practice-today and WSDL is that you aren't expected to map each network interaction to a single procedure call. This makes a number of things easier: cache the results, GET data across many different endpoints if you know the format, enable data and metadata extensibility through the payload, and follow hyperlinks if you know the link relation and target format.

The Facebook Graph API is a great practical example of this ease of use in practice: <https://developers.facebook.com/docs/reference/api/>

You're quite right that things like "related" and "metadata" link relations mean nothing if you don't know what those mean - they are hooks for future bits of agreement. The difference between REST and WSDL in the long run, in my opinion, is the practical composability of small bits of agreement (or specs). The Web Services stack (SOAP, WSDL, WS-*) has had a very difficult time composing a bunch of specs together as the kernel of their agreement is basically the XML Infoset. With the RESTful Web, the kernel is HTTP, URI, and MIME (for now), which has endured a number of extensions (Flash, HTML5, Atom/RSS, etc.) and evolutions (the rise of mobile devices).

<comment><USER12> Caching at the architecture level has caused more problems than it has solved. How many times have you heard the phrase "empty your cache, then try again..". Utterly stupid. This is an optimisation that should be implemented by the application designer as needed, and if it is within their capabilities.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> I am beginning to gather from this SO post as well as the other HN link to ShareFile, that REST is not something that can be summed up in a paragraph on HN or SO.

This is why the arguments over it are getting heated without seeming to go anywhere. All of the descriptions of REST are met with "That's X, that's not REST. X May be part of REST, but it's not all that REST is".

Turning the SO article into a community wiki is probably the way to go, and allow the discussion to expand until someone who reads it is able to get the concept of REST even though they'll never be able to explain it in a paragraph.

</comment><comment><USER14> My $0.02. In general, I've found many people describe something as "RESTful" but not actually know what RESTful truly means. Instead, they use it as an acronym to say "A web-based API", which is not necessarily the same thing as RESTful.

The best follow-up question to ask someone is: "What level on the Richardson Maturity Model is your RESTful API?" If they can't answer that, they're probably using the term RESTful to describe something else.

Richardson Maturity Model:

        Level Zero Service  - URI API. Usually just POST. SOAP, XML-RPC, POX.
        Level One Service   - URI Tunneling via URI Templates. GET/POST.
        Level Two Service   - CRUD (POST, GET, PUT, DELETE). Amazon S3.
        Level Three Service - "Hypermedia as the Engine of Application State" (HATEOAS).

The higher up the level, the more "RESTful" your API (you can argue about the order of level's 0 and 1), but the more complex it will be. Not everything fits perfectly in those levels either; you're free to borrow concepts and mash-up your own custom API.

HATEOAS is the most complicated. Imagine you're browsing the internet. You go to a webpage, and it loads with lots of text, links, images, and videos. You can interact with it, click on links, watch videos, submit a form, and go elsewhere. You have no idea what appeared on the webpage until after you visited it, and the next time you visit it might change entirely. The link might become broken and you get 404'ed, or you need a username/password otherwise you get 401'ed. HATEOAS is similar to that, but instead of a "person" browsing a "website", it's "client software" browsing "XML/URIs/Resources" received from a server API.

REST is not easy to understand or explain, as it entails learning about many different concepts, ideas, and custom-building something based on them. This is probably why there's no single-sentence which easily describes REST. Saying that something is RESTful is like saying something is Drivable. You can drive a car, truck, motorcycle, bicycle, or boat, but they're all very different from one another. There are similar concepts between them, like accelerating, steering, breaking, but how they do each of those things is very different.

A good book I recommend is "REST in Practice" by Jim Webber, Savas Parastatidis, and Ian Robinson ([http://www.amazon.com/REST-Practice- Hypermedia-Systems-Archi...](http://www.amazon.com/REST-Practice-Hypermedia- Systems-Architecture/dp/0596805829) or <http://shop.oreilly.com/product/9780596805838.do>). That helped me grasp what REST means.

<comment><USER15> _HATEOAS is similar to that, but instead of a "person" browsing a "website", it's "client software" browsing "XML/URIs/Resources" received from a server API._

A person browsing a web site is not "like" HATEOAS, it is the canonical example. The client software, in that case, is a web browser.

</comment></comment><comment><USER16> In the accepted answer, what's so bad about the "non-restful" approach the author describes? Who cares if I use GET/DELETE/PUT/POST vs putting the "verb" in a query string argument or the name the file that's being called?

<comment><USER17> RESTful, as opposed to REST, seems to be clear about the use of HTTP and all of its verbs. It is not RESTful if you do it any other way just by definition.

REST itself does not concern itself with the protocol you use. Theoretically you could build a REST protocol over HTTP that does not use HTTP verbs, using it as only a transport layer. Though I'm not sure what you would gain by implementing a REST protocol over another REST protocol.

Pragmatically, if you choose to use HTTP, you need to think about the infrastructure that exists. Each verb comes with a very specific meaning, and systems like proxies and other software that come between you and the client will act in different ways depending on which verb you choose. To meet the goals outlined in the REST dissertation, you need to be aware of those behaviours.

</comment></comment><comment><USER18> I would say the real power is the simplicity of stateless programming. It's easier to debug and easier to code, thus stronger and faster development.

I think a lot of devs assume it just about "using HTTP to its true potential" which is incidental. Other protocols could be implemented in a restful manner.

</comment><comment><USER4> Producing RESTful applications is more of an art than a science.

There are two key objectives to bear in mind when designing a web app to be RESTful:

\- your app should produce client/server interactions which complement the semantics of HTTP. (this makes the interaction visible and helps with intermediate processing e.g. caching)

\- expose your application in a way that minimizes the assumptions clients can make about it - aka 'HATEOAS' (this will reduce risk when making changes to your application and therefore improve the evolvability of your application)

</comment><comment><USER19> Just thought I'd add that a lot of people are raising the issue of discoverability in restful services. From what I have read this is dealt with with three key constraints: mediatypes, link relations and HATEOAS (hypertext as the engine of application state).

Mediatypes provide a standardised way of processing the representations provided to and from a resource (HTML is processed in particular way, as is JSON, as are PNGs, etc). REST has a constraint that requires you use registered mediatypes. On the web, this is the IANA (<http://www.iana.org/assignments/media-types/index.html>). If you mint your own mediatypes and use them on the public web, they must be registered with IANA for a service to be considered RESTful.

Link Relations again provide a standardised way of manipulating resources. They describe how resources at the end of a link can be manipulated. Examples include the ATOM edit relation, others include the stylesheet relation.

HATEOAS is a constraint that demands that the the client application should move between states by processing the hyperlinks contained within a representation via the relations provided.

There are two things you should pick up from this: a general REST client will not be able to do much with a service without knowing how to process the mediatypes of the representations returned by resources, and will not be able to move between states on the client without understanding how to interact with the service via the relations the service uses. Think about the most common REST clients out there: web browsers. If I mint a new mediatype that represents "a visual representation of a kitten with a comical caption", I cannot realistically expect a web browser to understand how to process this. The knowledge of how to process my custom mediatype must be baked into the web browser, much like web browsers know how to process image/* media types.

Much the same problem exists with link relations. Most of the time Link Relations are defined with a mediatype (think how a web browser must move to the state of processing a stylesheet by understanding that the link rel "stylesheet" dictates that the user-agent must retrive the stylesheet resource by performing a HTTP GET on the linked resource).

RESTful client applications must be able to understand the mediatypes and link relations used in a RESTful web service.

These three separate constraints, constraints that must be adhered to to be considered RESTful allow a REST client to navigate a REST service. The beauty here is that the service may change the url space of a service at any point without breaking a client, as the client knows all it needs to know to safely move around the client application state, as the rest is provided by the service on a per request basis.

As others have pointed out, caching (another constraint) cuts down on the constant round trips that such a setup would suggest, but I'll leave that constraint for another commenter to flesh out :)

Finally, two points: HTTP headers are part of the representation. This means that mediatypes that may at first appear to violate the hypermedia constraint can be made into hypermedia representations via the link header ([http://tools.ietf.org/html/draft-nottingham-http-link- header...](http://tools.ietf.org/html/draft-nottingham-http-link-header-06)). So PNGs can link to resources that contain metadata with a link relation such as "meta" (for example).

Second, many people mention the common HTTP verbs but ignore the OPTIONS verb. Calling OPTIONS on a resource can provide a lot of information back to the client about how they can interact with a resource. I've built systems that provide a list of HTTP verbs that a logged in user may perform on the resource, for example. Different users with different roles may be able to POST or DELETE, whilst others would see that they can only GET.

Hopefully this sheds some light on how RESTful services are made discoverable.

<comment><USER20> What syntax should one use to define link relationships in a RESTful service?

Most of the examples I've seen extolling the virtues of HATEOAS use XML, specifically the <link uri="..." rel="..." /> element. That's great for a single media type (XML), but what about JSON, which is by far the dominant media type used in RESTful APIs?

A google search for "hateoas json": [https://www.google.com/#q=hateoas+json&fp=1](https://www.google.com/#q=hateoas+json&fp=1)

reveals...a bunch of people asking how to format link relations in JSON, without a definitive answer that I can see.

HATEOAS and discoverability are principles that _sound_ great in high-level discussions but I have yet to see them implemented in a meaningful, helpful way.

Anyhow, you seem quite knowledgable on the subject so perhaps you can enlighten me. Usually it's my own ignorance/obstinateness that's to blame rather than a flaw in the concepts themselves...

<comment><USER21> I would argue that you don't. JSON isn't a format for HATEOAS, for the reason you state. I'm leaning towards saying HTML 5, with some of the new semantic markup, though it's not perfect.

You can use both, and simply use the Accept HTTP header to determine which format you want. It gives you both discoverability of HTML (with <a>), and data transfer that is easy to parse.

</comment></comment></comment><comment><USER22> There are two aspects to discoverability: A) listing all of the operations, and B) getting detailed method signatures for a particular operation.

A) is a noble idea but so far few people need to automatically discover and consume web services. B is the real issue: something like SOAP was necessary to make RPC possible over the web for typed languages like C# and Java.

REST was a counterargument made by some people coming from a dynamic languages standpoint who really didn't need as much information as the statically typed language people. Its too bad that people have taken A so seriously though and gotten confused or misled (probably deliberately) about what SOAP was for and then tried to make REST into that.

The most convenient and useful API, even over the web, is one that is as close to normal programming as possible. In other words, RPC-style (or some improvement on that like NowJS). That doesn't mean that you can or should forget that you are making remote calls, it just means that you have less other unrelated plumbing to think about.

If you want to do RPC in a dynamic language over the web, NowJS is your model. The problem is that dynamic languages and statically typed languages have different requirements. I don't think that either SOAP or REST are a good solution to making the two styles work together on a web RPC. I think we need to work on that more.

I guess one more thing complicating this is the fact that most APIs (just like most software systems in general) are in fact dealing with the standard create, read, update, delete operations on data, with some variations. Batch updates are the most common variation, which you could actually easily extend the CRUD model for. The thing is, you almost always have important deviations from that where the CRUD model doesn't fit. But regardless of whether you are doing CRUD or something else, you still want your API to be as simple and normal as possible and that means RPC.

Maybe as some point we can focus more on languages or frameworks that better integrate the CRUD concept and things like calculated fields and aggregation, and transparently handle tasks like persistence and shared state.

Just about all of the programs I write need to persist their data and transmit/share their state. Maybe we want a semantic data oriented networking programming system (or more of them). This would be inspired by dynamic languages like JavaScript but necessarily incorporate some kind of typing more integrally (inferred?).

Maybe just start with NowJS, bake in some kind of CRUD generation based on nested schema definitions, put that on the server, add a way to indicate that operations need to be batched (for transactional consistency and practical network performance) and make the nice MongoDB criteria and now aggregation stuff baked into the client-side also. That would be cool (much cooler and more useful than me thinking or caring about HTTP PUT or DELETE).</comment>


What's New in C# 6.0 [video] - <AUTHOR> http://channel9.msdn.com/Events/Visual-Studio/Connect-event-2014/116 <comment><USER2> You can also view a summary of the video/features as a presentation: [https://view.officeapps.live.com/op/view.aspx?src=http%3a%2f...](https://view.officeapps.live.com/op/view.aspx?src=http%3a%2f%2ffiles.channel9.msdn.com%2fthumbnail%2f6fcbe7ba-1cf1-4332-a9e3-ad559fe907c1.pptx)

<comment><USER3> Can't get past slide 4 (blue spinning ball on the cursor, yay Office Live).

Anybody have a pdf version?

<comment><USER4> Here you go: [http://cl.ly/0C25161f2T1q](http://cl.ly/0C25161f2T1q)

</comment></comment></comment><comment><USER5> Interestingly, if you'd like to check out how some of these features were implemented, you totally can. Roslyn is open-source ([http://roslyn.codeplex.com/](http://roslyn.codeplex.com/)).

That being said, I hope that all the open-sourcing is going to make it available where I really want to use it - Unity, for instance. (Disclaimer: I'm an open source dev @ Microsoft)

<comment><USER6> I was hoping Unity would start loosing some market due to outdated Mono. I guess we are in for another github-like "monopoly".

<comment><USER7> Nah, it won't have a monopoly. UE4 is a big deal for a lot of reasons, particularly its graphical quality. It's not the friendliest for indie devs at the moment, but it's been evolving and improving very rapidly.

And we'll see how long it takes Unity to actually support the current C#. My guess would be a couple years, since Unity 5 isn't even out yet, and there's usually 18 months between major releases.

</comment></comment></comment><comment><USER8> Nothing not to love -- a whole bunch of syntax sugar that makes code cleaner without messing around with core concepts that breaks code conceptually. It's also great to see how quickly good ideas permeate the language landscape today versus ten years ago (or maybe it's just good ideas finally permeating the landscape all at once).

<comment><USER9> From what I understand, this has been on the list for awhile, they are just working through it in each version. None of the ideas are very new at all, and could have been on the list quite awhile ago.

</comment></comment><comment><USER10> I'm going to take some hits for that but... with .NET being open source (never liked Mono..) and all..

I'm tempted to use C# in the future again. Using it on Windows has always been good - and now that it compiles to native code too and that the libs are open....

<comment><USER11> I thought that native compilation was only for "Windows Store" apps. Do they now have that available for regular Windows desktop apps too (or more importantly, server-side Linux apps)?

<comment><USER12> I haven't played with it much, but it says in the FAQ[1] :

"Will Server/Desktop apps benefit from .NET Native and/or the Compiler in the Cloud?

Desktop apps are a very important part of our strategy. Initially, we are focusing on Windows Store apps with .NET Native. In the longer term we will continue to improve native compilation for all .NET applications."

[1] [http://msdn.microsoft.com/en- US/vstudio/dn642499.aspx](http://msdn.microsoft.com/en- US/vstudio/dn642499.aspx)

<comment><USER13> I'd love to be able to write drivers in c#.

</comment></comment></comment></comment><comment><USER14> Still hoping they add the !(non-nullable) operator.

I know its hard [http://blog.coverity.com/2013/11/20/c-non-nullable- reference...](http://blog.coverity.com/2013/11/20/c-non-nullable-reference- types/#.VGY_5fnF-QA)

But dang I would appreciate it. So much code is cluttered with null checks that increases the robustness of the code at the cost of correctness, readability, and poorly defined behavior.

<comment><USER15> Aren't you just shifting the problem rather than solving it?

For example, let's say I am calling a function which returns an object:

           var myStuff = new GiveMeStuff().GenerateStuff(1337);

The return of this value can be valid "stuff," an exception, or null. If we remove null as an option, what happens when internally an exception is thrown within GenerateStuff()? Does it re-throw that exception? Or do we now need a property within stuff like (bool)myStuff.validStuff?

Null is a very useful way of communicating something failed. It is useful firstly because it is a "cheap" comparison and secondly because it saves us from having to place try{}catch(){} blocks around all of the things.

So my question is: without null how are we communicating failure? More exceptions? Or more clutter within our objects.

<comment><USER16> Null values don't go away, it's just that reference types aren't by default nullable. Your function can still return null (if you really want it to) as long as that is indicated by the return type. What you can't do is directly assign the possibly null return value of your function to a non-nullable reference.

</comment></comment></comment><comment><USER17> While all of the changes look nice in terms of writing less code, they are the kind of syntactic sugar I learned to hate in CoffeeScript. Mostly because the code was so much denser and harder to read. Especially when reading other people's code.

As I write more and more code, the more I want simplicity and ease of understanding over typing a few less characters or having more elegant code.

<comment><USER18> _As I write more and more code, the more I want simplicity_

I had a 24 year old developer report to me that apparently thought his bonuses were tied to how many operations he did on a single line of code.

He consistently wrote unbelievably complex lambda expressions with multiple conditional operators that would make a single line take up at least 1.5 screenfulls in Visual Studio on a 1920x1080 resolution monitor. These lines were impossible to debug and had to be inevitably broken up.

For a while I thought he was following the conventions laid forth in:

[https://www.thc.org/root/phun/unmaintain.html](https://www.thc.org/root/phun/unmaintain.html)

...but he really seemed to be genuinely thinking he was accomplishing something good by doing this.

I'm with you though. I'll take simplicity.

<comment><USER19> Ha! "Exploit Compiler Name Length Limits"

I worked for many years on a FoxPro application with a 10-character limit. The first version of the program was written under a _two_ character limit. This never bothered my boss, who was a terrible typist and always used short names anyway. But I at some point took up the practice of descriptive names, on top of the Hungarian notation we'd adopted for sanity. So I was exceeding the limit all over the place.

Ten years later, guess who had to convert the program to VFP, which has _no_ variable name limit. And no compile-time checks on variables, even when they are declared. Glad that year's over.

</comment></comment></comment><comment><USER20> Still no first-class tuple support? Argh! All want is:

      var first, last = parseName(fullName);

Instead of:

      String last;
      var first = parseName(fullName, out last);

<comment><USER21> Totally agree on the need for tuple syntax (and pattern matching to make it really useful):

        return Tuple.Create(foo,bar);

Should be:

        return (foo,bar);

The worst part is using the Item1..ItemN properties. One way I've gotten around it is to create a Tuple extension method called Apply [1]. I allows you to do this:

        ParseName(fullName).Apply((first, last) => ... )

That allows for giving names to the tuple ItemX fields and uses them 'in scope'.

At least with C#6 we can now open static classes like namespaces and do something this:

        using Language.Helpers [2]

        ...

        return tuple(x,y);

Which already makes it start to feel like it's part of the language.

[1] [https://gist.github.com/louthy/f4cee2524d0d049b4378](https://gist.github.com/louthy/f4cee2524d0d049b4378)

[2] [https://gist.github.com/louthy/dc06868c446ed76f0d7a](https://gist.github.com/louthy/dc06868c446ed76f0d7a)

<comment><USER20> Apply creates new scope, which is often undesirable. Consider the "Declaration expressions" feature in C# 6:

      ParseName(fullName).Unpack(out string first, out string last);

However, this makes for essentially left-to-right assignment, which is contrary to the usual order. So this creates discontinuity when moving from one return value to two return values.

<comment><USER21> My personal opinion is 'out' is a total abomination. I will do everything I can to avoid using it. I prefer expression based programming where there's a balance between the two sides of an operator. Declaring named values on the RHS is just horrible (again, IMHO). The only reason for it to exist is because C# hasn't got proper tuple support.

By the way, creating a new variable half-way down a method is also creating a new scope (the variable isn't in scope above the declaration, and it is in scope below it, until the end of the method).

For example:

        public int GetSurnameLength()
        {
            string fullName = ReadFullNameFromDb();
            Tuple<string,string> result = ParseName(fullName);
            return result.Item2.Length;
        }

Has the same effect as:

        public int GetSurnameLength()
        {
            string fullName = ReadFullNameFromDb();
            return ParseName(fullName).Apply( (first,last) => last.Length );
        }

The only real downside to the Apply method is the syntax clutter from the closure. But there's no real issue with scope as far as I can tell (because the rest of the method can be within the closure if necessary). This is very similar to how 'let' works in F#.

</comment></comment></comment></comment><comment><USER22> Seems like a small change but that nameof(argument) method for ArgumentXExceptions is incredibly handy.

<comment><USER23> And also for INotifyPropertyChanged! (Although CallerMemberName helped that some in C#5.)

<comment><USER24> Still wish they would implement something better for INotifyPropertyChanged like key-value observing in obj-c or object.observe proposed for js. Basically automatic property changed events. At least this removes the magic strings in the boiler plate.

<comment><USER23> I've really wanted to have some sort of property token similar to how we can use method groups as tokens for event subscriptions and delegate creation.

I've also wanted a system similar to dependency properties in WPF that was a little lighter weight. DPs do pretty much everything i could ask for from change notification to binding to pluggable validation, I just wish they we not so tied into the WPF code so i could apply them to my data layer.

</comment></comment></comment></comment><comment><USER25> Being able to use await in catch and finally must have been incredibly hard to implement for them. Especially in the finally part.

I mean - I'm saying this as somebody who hasn't done a lot of C# or .NET work in the last few years, but think about what you would have to do if you had to implement this in a safe and bug-free way.

<comment><USER26> Given that the 'vanilla' async-await isn't always safe/bug-free, I can't imagine that the harder version will be.

</comment></comment><comment><USER27> The null-conditional operators and string interpolation are really cool.

I don't use C# anymore (job change, not out of dislike), but I was always really happy working in it. I'm still not a huge fan of Windows, but C# is a wonderful language.

<comment><USER28> I wonder how string interpolation interacts with translation though? I thought the whole idea of the numbered placeholders was so that you could translate the string and rearrange them for different languages. Now do your translators have to be careful not to break your code if they're editing it as part of the string?

<comment><USER29> Even if an application gets localised, it may do less formatting of localised messages than of non localised ones (think (debug) logging, textual protocol formatting, exception messages and the like)

I also expect that a large fraction of applications never gets localised (in- house tools, scientific software, etc).

In total, I think there are orders of magnitude more lines of message formatting code that do not get translated and likely never will be translated.

It appears modern language designers think it worthwhile to make life for that use case a bit easier.

(it is not that the code gets much shorter, but more that, for true translation, you have to move the format string into a resource, and load it from your code)

</comment></comment></comment><comment><USER30> What's new in VB 14 (video): [http://channel9.msdn.com/Events/Visual- Studio/Connect-event-...](http://channel9.msdn.com/Events/Visual- Studio/Connect-event-2014/113)

<comment><USER31> > New feature: Go To Definition

Oh those poor, poor souls who have had to work in C#'s shadow.

<comment><USER32> Not knowing anything about VB these days, this video almost looks like satire :P

<comment><USER33> I'm sorry for my coworkers and whoever else around me - I will now shout "NEW FEATURE" constantly.

</comment></comment></comment></comment><comment><USER34> Using static classes as namespaces addresses something I was just complaining about a week ago. Let's take it a step further! Just let us put bare functions in namespaces without the dance of the static class.

<comment><USER12> >Let's take it a step further! Just let us put bare functions in namespaces without the dance of the static class.

No. C# is an object-oriented language. It doesn't have functions, it has methods. Methods are always attached to a class. Even anonymous methods (lambdas) are compiled to be a method on a class (like c__DisplayClass1).

"Bare" or "global" functions have no place in C#.

<comment><USER34> If you think that way, then C# left you behind a long time ago. Because if functions had no place in C#, then there would be no static classes in the first place. The static class is nothing more papering over object oriented bureaucracy that "everything is an object" to provide functions. And using a static class as a namespace furthers that.

I get that the CLR expects a certain way of implementing things. But your own example of Lambdas are an excellent example of how we can use syntax to overcome bureaucracy in the runtime, or else we would be stuck in Java land with anonymous classes implementing interfaces.

Ultimately, it's all sugar. If a static method of a static class can be made to look like a function in calling code, then it makes sense to make it look like a function in the definition.

<comment><USER35> > The static class is nothing more papering over object oriented bureaucracy > that "everything is an object" to provide functions.

Classes (in typical static, class-based "OO" languages like C++/Java/C#) aren't objects, and static classes are classes that don't even _relate_ to objects the way that "normal" classes do. Static classes as containers for functions aren't papering over _object_ -oriented bureaucracy that "everything is an object", they are papering over _class_ -oriented bureaucracy that "everything is connected to a class".

(This is a general agreement with your basic point, though.)

</comment></comment></comment></comment><comment><USER21> I think they missed a trick if the goal was to reduce boilerplate; which I'm all for, I'm very much moving away from C# to F# for this reason (and a few others).

Why this:

        public int X { get; }
        public int Y { get; } = 5;

And not this:

        public int X get;
        public int Y get = 5;

The braces serve absolutely no purpose anymore, the semi-colon doesn't serve as a separator between statements. So why leave them?

<comment><USER36> public int X { get; } is more consistent with how properties are declared. Consistency is important.

If you care about clean code, here's an even better way public readonly int X; They are not exactly the same but they are equivalent in most cases. In exotic cases where you're required to use auto-getters, adding the brackets wouldn't hurt.

<comment><USER21> > public int X { get; } is more consistent with how properties are declared. > Consistency is important.

As mentioned in my other reply. If that were the case, why have they just changed the method declaration syntax? It's inconsistent and therefore unacceptable right? If everything has to be consistent we wouldn't have LINQ, lambdas, generics, etc.

The braces are for scope in C# and all C derivative languages. There is no scope being created here and no requirement for scope. Also there are other places in C# where the scoping braces can be dropped [when there's only a single statement within]:

        if(foo == 1)
        {
           bar();
        }

Can be written:

        if(foo == 1)
           bar();

So I don't see the inconsistency at all if they were to drop the braces.

> If you care about clean code, here's an even better way public readonly int > X

That's what I use. Cue the next round of discussion about fields and properties...

<comment><USER37> >As mentioned in my other reply. If that were the case, why have they just changed the method declaration syntax?

They did change the property declaration syntax too.

        public int X => 5;

is the same as

        public int X { get { return 5; } }

This is exactly the same change they made to the method declaration syntax, so I'm not sure what you're complaining about.

Of course it isn't identical to public int X { get; } because the latter is assignable in the constructor. But comparing _that_ to methods is apples to oranges since methods aren't assignable.

<comment><USER21> I think you're quoting me out of context here. I am debating the consistency angle. My argument is that if there is such a drive for consistency (and therefore that's a good reason to keep the braces) then the method syntax wouldn't have changed to drop the braces. So I feel that argument is moot when discussing the reason for keeping the (what I believe to be) ugly syntax of X { get; } = 5;

Your example of the computed properties is not the same. I like the computed properties syntax, but unless the properties can be computed from the constructor parameters then you will still need to either use the ugly property syntax, or readonly fields to get the same immutable guarantees.

Personally I am fine with using readonly fields, I was only commenting on how the C# team have (in my opinion) missed the opportunity to get rid of some of the unnecessary clutter. I know however many people don't like using readonly fields for various reasons: serialisation, data-binding, interface declarations, etc.

</comment></comment></comment></comment></comment><comment><USER38> I'm a tiny bit disappointed with the inclusion of exception filters, but I suppose it is pragmatic feature.

I'm fond of a pattern where error codes can be implicitly converted to Exceptions[1].

It's often argued that exceptions are for things that your program cannot handle and error codes are for things that it can. But, in my experience, whether or not a bad condition is an error or an exception depends upon the layer in which the code lives.

Also, a side benefit of this scheme is that most of the exceptions show up in the class browser, or can be explored through reflection.

[1][https://gist.github.com/noblethrasher/ba37ed6176ebeb679dd2](https://gist.github.com/noblethrasher/ba37ed6176ebeb679dd2) \-- In my example, the error code is an integer, but it could be another class that holds more information about the operation.

<comment><USER39> I've never seen the arguments for error codes vs exception. Care to explain briefly or link me some information?

<comment><USER38> Here's the first essay I remember on the subject: [http://www.joelonsoftware.com/items/2003/10/13.html](http://www.joelonsoftware.com/items/2003/10/13.html)

</comment></comment></comment><comment><USER40> These are very nice changes. Especially the ability to write a quick lambda for named functions (or functions which are needed often).

The elvis operator is useful to. Makes me think sticking to F# will cause fewer classes of bugs that can happen in C# (the onChanged example is quite interesting).

</comment><comment><USER41> i love the new "?." similar to coffeescript. definitely make our lives easier.

<comment><USER42> I knew I'd seen that somewhere before, good call. There's a lot of things in coffeescript I'd love to see in other languages.

<comment><USER3> To be fair, the first time I saw this was in Groovy, almost ten years ago.

<comment><USER43> What is this called? It's impossible to google for

<comment><USER44> Informally the "Elvis operator".

<comment><USER3> Correct: [http://groovy.codehaus.org/Operators#Operators- ElvisOperator](http://groovy.codehaus.org/Operators#Operators- ElvisOperator)(?:)

</comment></comment></comment></comment></comment></comment><comment><USER45> So these lines are now equivalent:

       public override string ToString() { return String.Format("({0}, {1})", X, Y); }
       public override string ToString() => "(\{X}, \{Y})"

Could it go even further? This isn't paper after all, on screen why shouldn't it look like;

       public override string ToString() => "(X, Y)"

where the X and Y are either slight italics or underlined or colored to indicate they mean X and Y the variable not X and Y the letters. The IDE would let you just toggle the state between 'variable' and 'literal' with the keyboard.

We also get better array initializers:

      public JObject ToJson() {
        var r = new JObject();
        r["x"] = X;
        r["y"] = Y;
        return r;
      }

becomes:

      public JObject ToJson() => return new JObject() { ["x"] = X, ["y"] = Y };

That's cool! Next comes the null-conditional operators:

      public static Point FromJson(JObject json)
      {
         if (json != null &&
             json["x"] != null &&
             json["x"].Type == JTokenType.Integer &&
             json["y"] != null &&
             json["y"].Type == JTokenType.Integer)
         {
             return new Point((int)json["x"], (int)json["y"]);
         }
         return null;
      }

Becomes...

      public static Point FromJson(JObject json)
      {
         if (json?["x"]?.Type == JTokenType.Integer &&
             json?["y"]?.Type == JTokenType.Integer)
         {
             return new Point((int)json["x"], (int)json["y"]);
         }
         return null;
      }

The check against JTokenType.Integer is just to avoid a casting exception. The null checks are just to avoid null exceptions. I wonder if the compiler could ever handle something like 'this if you can, else null', without actually having any exceptions getting throw and caught underneath:

      public static Point FromJson(JObject json) =>
          return new Point((int)json["x"], (int)json["y"]) ?: null;

<comment><USER46> >where the X and Y are either slight italics or underlined or colored to indicate they mean X and Y the variable not X and Y the letters

So what happens if you open the file in a different editor?

<comment><USER45> I guess it could show up with the \\{X} escape notation in Notepad. But in theory almost no one would even notice that, the "natural form" would be to eliminate excessive escaping and just show what the string will actually be.

</comment></comment></comment><comment><USER47> It's funny that of all those, i'm most excited about nameof

</comment><comment><USER48> Because primary constructor was slashed to make a true record type, my new favorite feature is the nameof operator, it is very useful with IPropertyChanged, when you have to use the name of a property to raise a change, it was not type safe if you refactored the name of the property, a workaround used Expression capturing using RaisePropertyChange(p => p.MyProperty) which is very slow (or a CallerMemberName attribute in C# 5 but can be abused), nameof is more elegant.

I also love the ?. operator.

</comment><comment><USER15> They need to add these:

[https://github.com/MiniProfiler/dotnet/blob/master/StackExch...](https://github.com/MiniProfiler/dotnet/blob/master/StackExchange.Profiling/Helpers/ExtensionMethods.cs)

They're extremely useful and intuitive string helper methods. Truncate(), IsNullOrWhiteSpace(), etc are things I use daily. And while you can type string.IsNullOrWhiteSpace(string) that is annoying and counter-intuitive.

<comment><USER49> IsNullOrWhiteSpace() was added in dot net 4: [http://msdn.microsoft.com/en- us/library/system.string.isnull...](http://msdn.microsoft.com/en- us/library/system.string.isnullorwhitespace\(v=vs.110\).aspx)

I agree that Truncate would be a nice one to include in the core.

<comment><USER15> > IsNullOrWhiteSpace() was added in dot net 4:

Look at what the helper actually does. I already addressed this in my comment.

         string hello = magic();
         if(hello.IsNullOrWhiteSpace())
         { ... }

Is significantly more intuitive than:

         string hello = magic();
         if(string.IsNullOrWhiteSpace(hello))
         { ... }

Plus it is consistent with things like Contains("XYZ") (e.g. hello.Contains("something")).

Truncate is useful just because Substring() throws a bunch of dumb exceptions. It is mostly a workaround for Substring's poor design.

<comment><USER50> That defeats half the purpose though, because if the string _is_ null, you won't be able to call the method without throwing an exception. Or is that not the case for extension methods?

<comment><USER51> Extension methods are rewritten by the compiler to a normal static method call with the subject as their first argument (that's how they're defined, anyway). And since you can legitimately pass null to those methods there will be no NRE by default.

</comment></comment></comment></comment></comment><comment><USER52> I did a talk a few months back going over the changes up until today, and what is coming in C# 6, this was before they decided to drop primary constructors.

[https://www.youtube.com/watch?v=BA3sL783_Co](https://www.youtube.com/watch?v=BA3sL783_Co)

</comment><comment><USER53> It all looks really promising. Love it.

I'm a little worried about "nameof" in the hand of amateur programmers though. Efficiency aside (because it's not efficient), code readability might take a hit.

<comment><USER54> He explains that this is for refactoring.

As others have said, I'd therefor expect this to be a purely compile-time feature that just inserts the name of the reference within. The whole reason for this keyword seems to be that you have no string ("foo") but a reference/name instead (foo). Which can be picked up easily by tools.

</comment></comment><comment><USER55> I love the new read-only auto properties. 90% of the objects I write are immutable and it's a pain to declare all those private readonly backing fields just to return them in getters.

<comment><USER38> Agreed, I hardly ever used auto-implemented properties for that reason. But, Is the backing field for a read-only auto-property still readonly (i.e. only assignable from within a constructor body)?

<comment><USER56> Yes, the backing field is readonly.

</comment></comment></comment><comment><USER57> Lots of little things but they're pretty handy. I wish I still wrote in C#; perhaps that day will come when they start distributing the .Net runtime on Linux / Mac OS X.

<comment><USER58> Crazy, that will never happen :)

<comment><USER59> [https://news.ycombinator.com/item?id=8595905](https://news.ycombinator.com/item?id=8595905)

</comment></comment></comment><comment><USER60> await in catch and finally is going to be great! I'm an amateur c# programmer, but I hated having to set flags that get called later to do async methods with try/catch.

</comment><comment><USER61> Good to see immutability being given some attention. Elvis operators though, I think they make code shorter rather than easier to understand

</comment><comment><USER39> More fun for the juniors who have just come to terms with the ternary operator.

<comment><USER62> It has only been like 50 years since it was introduced. The juniors are coming to terms with retirement now.</comment></comment>