Nativeclient: run x86 native code in Web Applications. - <AUTHOR> http://code.google.com/p/nativeclient/

<comment><USER2> In the long run, I don't see how this is much more useful than JIT-ed Java bytecode. In both cases, you're relying on a heavyweight browser plugin to execute code. Nativeclient runs direct x86 code, after scrubbing it down to a subset of x86. JIT Java takes a bytecode stream and generates a safe x86 instruction stream.

In both cases, the plugin has to provide a system call interface to do anything "interesting" with the client. That system call interface is either too trivial to enable interesting applications, or so complicated that it, not the instruction analyzer, is going to be the primary attack surface of the plugin.

It is shocking, though.

<comment><USER3> There's a lot of legacy C code (e.g. x264) that would be expensive to rewrite in Java. Also, Java JITs aren't very good at generating SSE code.

<comment><USER4> "Legacy" C code?

There's a good reason we wrote x264 in C: can you imagine trying to write a performance-critical app like that in Java?

The assembly alone contributes a 5-7x performance increase: the difference between running real-time HDTV encoding and being stuck making video for iPods. It is _literally_ the difference between having a working business model and not having a working business model.

People in the web world always think they can get away with purely interpreted and JIT'd languages until they realize they actually have do things like _encode and decode video_ , and suddenly even pure C isn't anywhere near fast enough.

<comment><USER2> I'm not sure why, in the abstract, the performance you're talking about isn't just a set of bytecode intrinsics away from being realizeable in Java. Your 5-7x performance increase is presumably from SIMD, not instruction scheduling.

Obviously today's bytecode JITs aren't faster than C or C+assembly. But if you're going to pick a platform to innovate on, I'm saying it's not a total no-brainer to think about JIT (well-understood and working) instead of x86 verification (poorly-understood, science project).

<comment><USER4> Yes, the performance increase is mostly from SIMD (though not entirely: we have a few assembly functions with minimal to no SIMD that offer a great improvement over pure C).

Though I would quite confidently say that our C code is quite a bit faster than the naive Java equivalent, for a number of reasons, mostly because all the critical sections have been hand-optimized using explicit write-combining, branchless algorithms, lookup tables, etc. Of course, one can do most of this in Java, but I still would imagine it would be somewhat slower simply because one has less control over the generated assembly.

JITs are well understood and work--but some tasks are simply not well-suited to them. Sometimes you need SIMD. And if you're suggesting handwritten assembly in Java, that completely comes back to the same problem, since you need to verify that the x86 code is safe (etc etc).

<comment><USER2> It doesn't come back to the same problem at all; SIMD assembly generated from Java bytecode intrinsics doesn't have the same verification problems that x86 does. That's why Google's paper had a section structured as a formal proof. JITs are inherently safer than verified x86.

I'm not saying NaCL is unsafe, just that there are easier ways to get some of the same benefits.

<comment><USER4> Intrinsics are no substitute for handwritten assembly, and anyone who has actually tried to use them should know this.

Compilers are _dumb_. This gets an order of magnitude worse when you expose them to SIMD.

<comment><USER2> You seem to be stuck on compilers; I'm talking about virtual machine architectures. You're also not making a case for verified x86 so much as you are for generic native code.

<comment><USER4> "Generic native code" is quite literally a contradiction in terms. What kind of virtual machine are you proposing that doesn't require translation of instructions from some intermediate bytecode instruction set into x86 (a process sometimes called "compiling")?

If I can't write assembly in your language and have it run exactly as I wrote it, in the order I wrote it, with the instructions I used, your language is not suitable for performance-critical applications like the aforementioned.

And my assembly includes things like computed jumps to one of 16 functions based on known variables, which you _cannot_ write using intrinsics (you're forced to, at best, do a jump table instead, since you don't know the exact size of each function).

(Now, I do fully understand the argument that JIT is probably easier than x86 code verification, and that you could get "good enough" code using intrinsics in a JIT. But of course, that requires convincing everyone who already wrote their code in C and asm to go rewrite it for your JIT.)

<comment><USER2> I have no idea what your first paragraph means.

Your second two paragraphs are mostly subjective. I also think you've staple gunned your design sensibility to 2008; Java (for instance) is over 10 years old. Do you think that in 2018, you'll be hand-carving computed jumps and manually re-ordering instruction sequences just to decode video? If Perl isn't decoding HD video in 2018, I'm going to be disappointed.

Clearly, pure interpreted runtimes are giving way to "modern" (ie, "standard in academia since 1995") native code runtimes. Java has been there forever. Along with the cost of proving out and converting developers to a verified x86 plugin, you also need to factor in the fact that virtually every browser in the world has Java, and is an auto-update away from a much better JVM.

The real issue is, I don't think anyone's going to care about this. I could be wrong, obviously.

<comment><USER4> Every few years, they tell us that performance won't matter anymore in a few years, because CPUs keep getting faster.

"In a few years any CPU will be able to decode DVDs easily. SIMD will be obsolete!"

And every single time, a few years pass, and it never, ever happens, because CPUs don't get faster in a vacuum. Just as much, our demand for performance increases.

In fact, right now, I'd say that the demand for performance is outpacing CPU development. The CPU requirement for 1080p H.264 from a Blu-ray disc is easily 20-40 times greater than the video from a DVD. CPU's haven't gotten that much faster in the meantime, forcing graphics card makers to add hardware acceleration, just as in the earliest days of DVD playback.

<comment><USER2> If you (generously) count MMX, x86 SIMD is still younger than the JVM, or even JIT JVM. But I agree that "hardware acceleration" is going to take up a lot of the slack here; all the more reason not to chase unproven performance tricks like verified x86.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> Yet another way to run unsigned code, er viruses in your browser. :)

</comment><comment><USER3> Dupe: <http://news.ycombinator.com/item?id=390352>

<comment><AUTHOR> Whoops, my mistake.

</comment></comment><comment><USER6> shall we call this activeG?</comment>


A Guide to Public Speaking for Introverted and Shy People - <AUTHOR> http://www.jonathoncolman.org/2013/01/07/a-guide-to-public-speaking-for-introverted-and-shy-people/ <comment><USER2> Here's some more information about the difference between shy people and introverted people. [http://www.thepowerofintroverts.com/2011/07/05/are-you- shy-i...](http://www.thepowerofintroverts.com/2011/07/05/are-you-shy- introverted-both-or-neither-and-why-does-it-matter/)

Everyone's different and your mileage may vary, but it's important not to generally conflate these two concepts or else you risk framing someone the wrong way and end up totally misunderstanding them.

</comment><comment><USER3> love this quick guide - not only does it do a nice job of explaining the difference between introvert and "shy", but also provides some practical tips. Nice job!</comment>


GM Apples That Don't Brown to Reach U.S. Shelves This Fall - <AUTHOR> https://www.technologyreview.com/s/609080/gm-apples-that-dont-brown-to-reach-us-shelves-this-fall/ <comment><USER2> It annoys me that fruit/vegs has to "look good". Anyone that has grown their own carrots know that the results you get are far from the "ideal carrot" :')

That being said, I believe GMO food is the future. It's safe and environmentally friendly: we can use far less land and water to produce larger amounts of crops.

<comment><USER3> I think were shooting ourselves in the foot. We did the same with antibiotics. Disease gets worse and we make super bugs and are more and more reliant on our defenses. Eventually GMO will be the same thing. You won't be able to grow nonGMO crops because we have weaponized the crop killers to such a high degree.

<comment><USER4> News flash : "nonGMO" crops are already genetically modified from wild plants, just through a more painstaking process of cross breeding and artificial selection over random mutations. This is already happening and would happen anyway.

<comment><USER3> All genetic modifications aren't created equal. If you can get to it from cross breeding, it's probably not that foreign a trait, but if you to say splice pea DNA with mesquito DNA or something, that result could have consequences consumers would rather not worry about when buying produce. I'm not saying it's a fine dilineation or anything and I'm not anti science, but there are more nuanced regulations in food labeling today than GMO nonGMO.

<comment><USER4> With the availability of genetic sequencing you can get from anywhere A -> B in the reachable genetic search space through selective breeding, and still qualify for regulatory purposes as non-GMO. You can get out of that loophole by prohibiting the non-GMO label for anything that was bred based on direct genome sequencing, but that's a game a whack-a-mole as I come up with another scheme.

And at the end, what's the point? Regulate what you actually care about in the food, not what process was taken to get there.

</comment></comment></comment></comment></comment><comment><USER5> I wonder how this will affect taste. Apples bred to look picture perfect often/usually/always? have terrible tastes in my experience.

<comment><USER6> I don't think this is meant to affect how apples look initially, only once they've been bitten into/cut so that the white part is open to the air.

Lemon juice used to be the trick, but if this does the trick then cool.

<comment><USER5> > I don't think this is meant to affect how apples look initially, only once > they've been bitten into/cut so that the white part is open to the air.

I know, my point was that so far my experience with apples made to be better commercially fail when it comes to taste. I wonder if this will be different.

</comment></comment></comment><comment><USER7> It was a bit shocking to me when I first walked into an American super market to see tomatoes all the same big size and shining red color. This is in sharp contrast to what we get in India - they come in all sizes and different shades of orange, green and red.

Even though the American ones were instantly attractive, it slowly dawned on me that perhaps something is wrong. Now I appreciate the Indian vegetables a lot more.

</comment><comment><USER8> For anyone interested, Scientific American tells a bit more about the enzyme which causes browning in apples:

[https://www.scientificamerican.com/article/experts-why- cut-a...](https://www.scientificamerican.com/article/experts-why-cut-apples- turn-brown/)

</comment><comment><USER3> Put the information on the package. Let consumers decide, irrational or not, there's a market for nonGMO. If you want to supplant that market with GM foods, do it through informing consumers not blending in with food they already trust. The labeling games producer's play with our food is really unfortunate.

<comment><USER9> Problem with that is it sounds scary. Some big companies already are and hide the text on the bags, but your average consumer sees it and thinks it's full of chemicals.

Personally, I'd rather eat a gm crop that's been altered to resist insects than eat an organic crop that's been sprayed with organic pesticides such as (the now not used) rotenone.

</comment></comment><comment><USER10> As a general rule, looks good and tastes good are inversely proportional to each other.

<comment><USER11> Explains why most supermarket tomatoes are _terrible_

</comment></comment><comment><USER12> I'll buy a bag or two, just to encourage research into what benefits these types of genetic modification techniques can bring to market. I hope their business results are as successful as their produce results seems to be.

</comment><comment><USER13> You guys are freaking out about apples, but I'm excited for the application of (the concept of) silencing towards humans. I don't think* it quite works this way & I'm sure biologics are similar, but it would be amazing if you could do the same thing for humans. Imagine doing that for people who have psoriasis. Would be amazing if the body took to that & could continue producing cells that react properly.

<comment><USER14> It is happening. Hemophilia being cured at Marin Bio [1].

There are a bunch of therapies where Cas9 is being used by to therapeutically knock out or repair particular proteins. Indications currently targeted at Intellia: ATTR, Hepatitis B, AATD, PH-1, etc. [2].

[1] [http://investors.biomarin.com/2017-07-11-BioMarins- Investiga...](http://investors.biomarin.com/2017-07-11-BioMarins- Investigational-Gene-Therapy-for-Hemophilia-A-at-6e13-vg-kg-Dose-Maintains- Average-Factor-VIII-Levels-within-Normal-Range-for-over-One-Year)

[2] [http://www.intelliatx.com/pipeline/](http://www.intelliatx.com/pipeline/)

</comment></comment><comment><USER15> So... its still going to go bad, but it just won't turn brown? And it won't be labelled, so I won't know its not an ordinary apple?

Sigh.

<comment><USER5> Browned apples aren't bad apples. You can currently splash a little lemon juice over them to the same effect (denaturing the enzyme that causes browning chemically instead of suppressing its expression generically).

<comment><USER16> How do you identify a bad apple, other than browning, without taking a bite?

<comment><USER17> The browning only appears as the apple's flesh starts oxydizing after having taken a bite (or a slice) of it and exposing it to the air.

It helps in no way to assess the freshness, taste, quality or anything about the apple. It just makes the exposed flesh turn brown after a few minutes.

</comment></comment></comment></comment><comment><USER18> I had a Granny Smith apple in the back of my fridge for something like 3 months.

It looked like I just bought it when I found it again.

Realizing that honestly made me uncomfortable.

<comment><USER5> Apples are a great at storage. Some can be extremely hardy if kept in a mostly dry and cold place. It was one reason they became so popular: you could keep them over winter in a root cellar.

This is how we get out-of-season apples. They basically get stored in refrigerated warehouses.

Granted not all apples are like this. Some become mealy pretty quickly.

<comment><USER19> For anyone reading who has an apple tree, quick correction: cold and humid.

My crop easily lasts for 3 months in my storage fridge (and I don't take the time to sort them to properly eliminate bruised fruit, etc), but the key is cold and humid, not cold and dry.

<comment><USER5> Ah, sorry, and I don't seem to be able to edit. I guess I always consider a fridge a dry place, but that's not really true the more I think about it.

</comment></comment></comment></comment><comment><USER20> This disgusts me. I have a right to know what is in the food I (might) eat. If indeed there is no risk from GMO products (plant or animals), or animals given antibiotics, or cows given hormones to increase milk production, etc. then it falls upon those industries to educate and convince me of this point-of-view, not to hide the information or (in some cases) make it illegal to report the GMO/non-GMO status.

<comment><USER2> Antibiotics: don't make it into your beef in an amount that will affect your life. You can consume more drugs by drinking tap water in LA.

Hormones: I guess we should ban birth control as well, correct? Because that's all it is...

But, I believe in a free society, so if people wish to remain ignorant of science, that's their prerogative. But it's important to recongize those are just marketing campaigns: there is nothing "healthier" about eating beef raised antibiotic/hormone free, all other things being equal (living conditions for the animals).

<comment><USER17> > _Hormones: I guess we should ban birth control as well, correct? Because > that 's all it is..._

We don't usually give birth control hormones to male humans. I don't know if they are bad when they are given to animals (it's forbidden here in Europe) but female hormones are _definitely_ not good to developing children or adult males.

They're just good/neutral (well, not functionally neutral of course, but not causing unplanned disruption) to adult females because they're part of their normal physiology.

<comment><USER2> > We don't usually give birth control hormones to male humans.

This comment presents a false premise. The amounts in beef are ridiculously small, especially when compared to other foods. Any "advantages" to "hormone free beef" are pseudoscience and a marketing campaign, and that's it.

<comment><USER17> I did say that I don't know if there's a problem with hormones given to animals.

My point was the original comment implying that hormones are not harmful because they are used for birth control, which is shortsighted and plain wrong.</comment></comment></comment></comment></comment>


Jumprope – Turn your URL bar into command line - <AUTHOR> https://jumprope.ai <comment><USER2> This is already implemented in browsers as search engine macros. What is new about this?</comment>


Ask HN: How to deal with social anxiety? - <AUTHOR> Teamwork makes me extremely anxious. It's a physical pain in the stomach area. Nausea follows most of my human interactions. I 'look fearful' to meetings. I can only discern disgust in other faces. This is bad for my productivity and well-being.<p>Cooperation is a fundamental skill. How can I solve this issue? <comment><USER2> This sounds psychological - have you consulted with a professional on this issue? I'm being serious here.

</comment><comment><USER3> [https://np.reddit.com/r/EngineeringStudents/comments/6h76kn/...](https://np.reddit.com/r/EngineeringStudents/comments/6h76kn/some_dilbert_for_you_guys/diw28zg/)

</comment><comment><USER4> Have you tried working from home and communicating only via email?</comment>


Joe Hewitt - What the web is and is not - <AUTHOR> http://joehewitt.com/post/what-the-web-is-and-is-not/

<comment><USER2> > Hyperlink traversal matters. The Internet being global and decentralized > matters. HTML does not matter.

He gets it.

I think a lot of people misinterpreted his previous blog post as saying that the web is worse as a platform than iOS. No, he's saying that HTML is worse as an API than the iOS frameworks. The two are different, and the difference is crucial.

The web is Wikipedia, Google, Facebook, blogs, and HN --- services that couldn't exist without the concept of the hyperlink. That we currently write web pages in HTML, CSS, JS, and related technologies isn't central to this, and _that_ is what Hewitt doesn't like about the web.

He's not calling for us to stop writing web apps. He's calling us to put some serious thinking into a better markup, presentation, and application language. Now that we have decades experience in writing HTML, we might actually we qualified to do so.

<comment><USER3> I agree with one nitpick. The web is Wikipedia, Google, Facebbok, blogs, HN, and everything because of of the concept of the hyperlink. It couldn't exist without the hyperlink. That everything is written in HTML, CSS, JS, and other related technologies doesn't mater. The hyperlink does, regardless of how it is implemented.

</comment></comment><comment><USER4> The inherent tension between the speed and efficiency of closed platforms and the decentralized power of open standards based platforms seems insurmountable. Except that's sort of what I find so great and so fascinating about Google, because it represents the one singular, powerful, centralized, commercial force whose incentives align almost exactly with the Web at large.[0] And I think it's really great to have such a power innovating on basically every layer of the Web stack, from protocols, to codecs, to browsers, to operating systems.

[0]: I wrote a bit more about that here: <http://blog.byjoemoon.com/post/166900257/why-i-trust-google>

And a bit about the problems around the particular relationship Google has with the web here: [http://blog.byjoemoon.com/post/7590977101/googles- existentia...](http://blog.byjoemoon.com/post/7590977101/googles-existential- crisis)

<comment><USER5> The problem with Google is that Google is pro-web as long as the web is pro- Google.

Take Google+ for instance - they could have at least attempted a decentralized social network, but they didn't. Instead they are requiring real names, because apparently pseudonyms are bad for Google ... and yet being anonymous is something which the web (in general) not only allows, but also encourages.

Yes, you can choose not to use Google+ or Facebook, but for how long will this freedom last when absolutely everybody will be on one of these social networks? How long will it last until email will not be the primary means of communicating at work with your customers or colleagues?

It's a pity that the millions of users with accounts on Facebook haven't discovered the advantages of opening up an account on Wordpress.com or similar services, with their own domain name ; or the advantages of using Google Reader to follow your acquaintances.

<comment><USER4> Your first sentence is right as far as it goes.

I agree with you that G+ would be better decentralized, and based on open standards. But I think they tried that with Buzz and Wave, both catastrophic failures. And I think the strategy this time is to try to nail down the user experience first. I think the real names policy is a part of that, too (though I agree, too, that this is a bad policy).[0]

Could all be wishful thinking, I suppose.

[0]: Some weak evidence for this being the strategy: <http://news.ycombinator.com/item?id=3019052>

<comment><USER6> Actually, Google+ is based on open standards, here is what Evan Prodromou (the creator of <http://status.net>, one of the biggest decentralized open source social network) has to say about the API:

> Activity Streams, PoCo, OAuth 2. I feel like the girl in Jurassic Park. "I > know this!"

[https://plus.google.com/104323674441008487802/posts/jJNsUDPc...](https://plus.google.com/104323674441008487802/posts/jJNsUDPcxkB)

So, you couldn't get more open and decentralized than that. G+ api is read only for now though but the devs made it clear that it won't stay that way.

<comment><USER4> I think what many of us really want is federation or some level of interoperability such that we can run our own services that work transparently with G+ as a peer. More like the way email works.

(As a bonus, this would neatly sidestep the ano/pseudonymity issue.)

So, when I can run byjoemoon+ on my own server and interoperate with G+ users with complete feature parity, I'll be really happy.

Meanwhile, I think the API stuff is great, but only a half-measure.

<comment><USER7> This was the plan with Google Wave; did they not provide people with the ability to set up their own Wave boxes? How'd that turn out?

</comment></comment></comment></comment></comment></comment><comment><USER8> The existence of the HTTP Accept header shows that HTTP was designed with a variety of incompatible user-agents in mind. If you write new user-agent, use Accept to specify what content types you can render. Intelligent web servers can serve the same content in different formats for the same URLs. Your browser that only handles HTML will browse on unimpeded, my browser that also handles NewLanguage3000 will get the newfangled version. Everybody wins.

<comment><USER9> > Everybody wins.

You hand out this ribbon far too easily. Parallel offerings[1] are pretty much guaranteed not to be parallel (or resemble it even enough to fool those who want to be fooled).

1\. Separate-but-equal, or whatever you want to call it

<comment><USER10> I'm not sure I get your point, so I may be arguing against something else entirely here.

That said, the point of parallel offerings is not to provide identical representations of a given resource. Even XML+XSLT versus XHTML might have different semantical implications, so the best assumption is that no two ways of representing a given content can ever be identical.

Well, _that's a Good Thing._ If I'm requesting a given resource and I signal preference for a PDF-encoded response, that implies on some level that I want a print-formatted, print media version of that resource, whereas its HTML counterpart can be hypertext and multimedia.

What you as a server are committing to is that both servings are representations of the same given resource, but without prejudice of putting each format to its best use.

This is also beautiful in that if the HTML stack proves to be a bad idea in the long run, rather than being deprecated, it can fall into disuse slowly alongside the slow rise of its successor(s). In fact, there's absolutely zilch stopping us from having more than one canonical format — any server-side MVC (or MVCish) architecture can probably handle that off the box!

EDIT: to be sure, the question of how expensive it is to develop for two different representation formats is a whole other story.

<comment><USER9> > I'm not sure I get your point

If it helps, it doesn't look like you did. :)

> without prejudice of putting each format to its best use

Doing what you can to the extent of what's possible with multiple mediums (yeah, medi _ums_ , I said it) is real pie-in-the-sky, false promise kind of stuff.

People can't manage today to put the web to anything you could mistake for its best use. Why should it inspire confidence when anyone says it's going to happen when their resources are halved?

</comment></comment></comment></comment><comment><USER11> The power of the web isn't any one technology, but a combination of two very powerful things: the ability to present arbitrary content with an arbitrary look and feel, and the ability to trivially point a user at someone else's content.

We have a (HUGELY successful) first crack at a platform (HTML, CSS, JS) that enables completely custom UI, presentation and generation of content.

Hyperlinks form the other half of this in that my content can send you over to someone else's content (with their own customized UI and presentation) with a single click of a mouse.

The problem is that people are using the first half of the web as a basis for delivering traditional (thick client, local) applications, and that does indeed suck.

We've become focused far more on the experience than the content. I think that focus is misplaced. We've spent a decade now trying and failing to perfectly implement our content for our UI paradigm and now we're paying the price as that paradigm shifts. I expect that paradigm to shift again before we perfect our new implementations.

<comment><USER7> > We have a (HUGELY successful) first crack at a platform (HTML, CSS, JS) that > enables completely custom UI, presentation and generation of content.

Java Swing lets you do this, too. But no hyperlinks.

<comment><USER11> Swing takes a different approach. It is a pluggable widget toolkit rather than a set of lower level constructs used to build primitives.

</comment></comment></comment><comment><USER12> It's strange; I found little to disagree with in this post, but when I went back to read the original, something about it rubbed me the wrong way.

It seems to me that this response was written because people (including myself) get jumpy when the death of the Web is mentioned -- they conflate the Web with the open principles underlying the Internet, and a BDFL there runs counter to those principles.

I don't really have a dog in the fight as far as HTML etc. are concerned, though I do think the benefits of having an open-standards, (mostly) consistent rendering framework and execution environment across all major platforms and architectures, including mobile devices, far (far!) outweigh the drawbacks of our retrofitting what began as a document markup language. I'll stick with it until we -- or if Joe has his way, a charismatic visionary -- can come up with a more appropriate replacement.

</comment><comment><USER13> Yup, it's all about DNS and links.

But let's try to look more than a few years out for once? OKAY?

You could make a very decent web that is made out of many clients, that can all link to each other and maybe even all run in separate tabs of the same browser (or whatever 'process' model you want).

But god help you 50 years down the road when you need to download new client browser for every other web page.

This, among other long-term type trade-offs are the very good reasons why the "open web" as it exists on it's current trajectory are a very good idea.

<comment><USER3> It seems an extreme that the web will in 50 years will require different browsers for every site. The way I read this is that HTML/CSS/JS could be replaced overtime, bit by bit in 50 years by something else. Flash could have done this, though I think their chance has passed them by. Just like Java Applets and Silverlight. Maybe Chrome will add an interpreter for CoffeeScript and in 10 years all new sites will use that instead of JS. Maybe Firefox will introduce something other than HTML to build a page in that works with CSS and JS better and in 15 years, everything new will be in that language.

It isn't that everything will be different, but the implementation of the web is less important than that openness of the web. Fifteeen, twenty years ago, the web was made up of newsgroups, bbs', and email. HTML and browsers were new. Thing have changes, but the web still exists. Something new will come along that will slowly replace what we know as the web. What it is and how it happens is unknown, but I expect it to happen.

</comment></comment><comment><USER14> _"..most of the positive responses were from people who, like me, have a depth of experience on other client platforms.. Then there are the people who reacted negatively to my post. A common theme throughout these responses is complacency."_

So everybody who disagreed with you is complacent. Who's being complacent here?

I enjoyed the original post, but the tone of this one is off-putting.

\---

Between the two articles I built my first iPhone app. It felt like a ghetto. Interface Builder, I christen thee 'click and pray'. Perhaps there's a simpler explanation for these phenomena: we tend to discount the drawbacks in what we know.

</comment><comment><USER15> Thank you for saying it. I have been echoing this sentiment for a long time. Why settle for "good enough" when the root of all progress is "better?" I think one key thing that we will need first is a language to challenge Javascript and HTML. I think C# and Java are good, but they could be a lot better. The language will need native rich media abilities and enough abstraction to run on any device or operating system.

The problem with HTML (to me) is that it is not really driven by capitalism or competition - say what you will about the two, but they do force companies to strive for the best products possible.

</comment><comment><USER16> He doesn't mention 'View source', which I think is pretty important.

As Clay Shirky says: <http://www.shirky.com/writings/view_source.html>

</comment><comment><USER17> "HTML" fails at delivering hot new stuff, but native apps on the other hand give too much control to the developer and a lot of developers abuse it. Having browser limitations can sometimes be a good thing.

</comment><comment><USER18> Lots of words without a message. We don't need someone to tell us HTML sucks...

It's like saying "this API sucks! We'll fix it with a new API"

</comment><comment><USER19> I used to deride web applications by saying we are trying to make DOCUMENTS behave like APPLICATIONS.

However, we should keep in mind that the explosion on the web also happened because of user generated content, and by that I don't mean just silly facebook comments. I mean blog posts, I mean photos, I mean content where the users are able to control the presentation. Or ideally, where users indicate semantic information.

This is what has made Web 2.0 great, if I may :)

And there is one language for this: HTML. It may not be perfect but what we are really talking about is an XML-like language to indicate semantics. It is ubiquitous.

So it's not just about hyperlinks. It is about structured data where you are able to embed the semantic information directly in the data. Sure, you could have the web based around JSON, for example. But why bother, when we already use brackets everywhere?

And once you start using those brackets, everything else follows.

But we would do well if we had this: <http://news.ycombinator.com/item?id=2024164>

<comment><USER7> > However, we should keep in mind that the explosion on the web also happened > because of user generated content, and by that I don't mean just silly > facebook comments.

"Document" in the sense that archivists and other information specialists use also applies equally to things like Facebook comments or random YouTube videos. Any discrete piece of content (and I'm not being rigorous with this definition) is a document and the purpose of the web is basically linking them together.

That these documents are often displayed simultaneously on the same webpage doesn't keep them from being separate documents.

</comment></comment><comment><USER20> Can i get some credit for inspiring this chain of thought haha....<http://news.ycombinator.com/item?id=3024558>

</comment><comment><USER21> _I suspect thaat most of the positive responses were from people who, like me, have a depth of experience..._

What a condescending asshole.

<comment><USER22> I know Joe personally and he is not condescending or an asshole. He's an extremely nice, personable guy who happens to have done some amazing things that have changed the web (like start FireFox for instance).

Perhaps you should think a little before insulting someone you don't know based on half a sentence they wrote.</comment></comment>


BBC Master on Steroids - <AUTHOR> https://retrohax.net/bbc-master-on-steroids/ <comment><USER2> That's super cool! I have an old BBC Micro in a box under a desk somewhere which I want to get back on its feet someday - last time I powered it up I think it was working (made the right boop-BEEP noise!) but I didn't have a screen to test it with.

I also have a box of 5.25" floppies that I want try and read any data off - they've been untouched for decades, is there anything I should/shouldn't do before plugging in the floppy drive and spinning them up?

<comment><USER3> For connecting to a TV, easiest thing might be to buy an RGB to SCART cable from eBay. Less than £15, good picture quality.

Good summary of potential disk/drive issues and cleaning options: [http://www.retrotechnology.com/herbs_stuff/clean_disks.html](http://www.retrotechnology.com/herbs_stuff/clean_disks.html). Spatula-shaped cotton wool buds are handy for cleaning drives, as there might not be much room inside.

As per the article, [http://stardot.org.uk/](http://stardot.org.uk/) is a good resource for all things BBC Micro in general.

<comment><USER4> Purchase a scan converter. There is a popular OpenSource project and many manufacturers are making them. Several support RGB, S-Video, RF, VGA and SCART and can upscale to something a 1080p HDMI TV/monitor can use. Supremely useful for all of those retro consoles and computers in our modern day. Kaicco is the more popular brand for the project, though I don't think that one supports S-Video.

Edit: You can connect a BBC Micro (and many other 8-bit micros) to the standard OSCC. It simply doesn't have the plug on the board, you will need an adapter cable.

</comment></comment></comment><comment><USER5> Very interesting, I did not know you could use a RPi as a second processor. My dad has a 6502 second processor and we were wowed by the hidden line removal and colour on Elite at the time.

Didn't make me play any better though.

I just used to enjoy Chuckie Egg, Mr. EE, Dare Devil Dennis, Exile, Mission Impossible and Firetrack. Brilliant music on Firetrack.

<comment><USER6> There's a cool project that uses an FPGA to allow several implementations of BBC Micro Co Processors (65C02, Z80, 6809, 68000, x86, ARM2, PDP-11, 32016).

And not just vanilla ones. They have a "monster Z80" that does more per clock cycle and a very fast clock, for example.

[https://github.com/hoglet67/CoPro6502](https://github.com/hoglet67/CoPro6502)

<comment><USER7> I wonder whether anyone has since thought of adding the KimKlone to that list.

* [https://laughtonelectronics.com/Arcana/KimKlone/Kimklone_sho...](https://laughtonelectronics.com/Arcana/KimKlone/Kimklone_short_summary.html) ([https://news.ycombinator.com/item?id=16564257](https://news.ycombinator.com/item?id=16564257) [https://news.ycombinator.com/item?id=3070169](https://news.ycombinator.com/item?id=3070169))

</comment></comment></comment><comment><USER8> For those looking for more retro computer restoration, check out the 8-bit guy

[https://www.youtube.com/channel/UC8uT9cgJorJPWu7ITLGo9Ww](https://www.youtube.com/channel/UC8uT9cgJorJPWu7ITLGo9Ww)

<comment><USER9> The 8BitGuy is like a gateway drug to retrocomputers. Thanks to his channel I learned some things I didn't know back in the day, like that the CGA graphics card was capable of better colors in composite mode.

He also convinced me of getting RetroGames' TheC64 maxi: a C64 lookalike running a variant of VICE inside, with full working keyboard, petscii codes and all!

</comment></comment><comment><USER10> I wonder if it would be possible to port the OS interfaces for the bbc computers to RPi directly... putting the keyboard inputs into a modern USB controller interface and just run the whole thing off of an RPi or similar.

TBH about the only hardware I really miss are the better CRT options compared to how limited modern displays are or how much processing power it takes for a level of detail that looks close to as good. A lot of older games look better on a CRT than the same games scaled to 1080p or higher.

</comment><comment><USER11> Neat! One nitpick: never do a voltage switch like that with a toggle, always use a slider. A toggle is way too easy to accidentally trip.

<comment><USER12> Also, the wites leading to the switch seem like 0.05" IDC cable, which is horribly inadequate for mains application. The "jumper" is not some kind of low power config input, it simply shorts the midpoint of DC smoothing capacitor bank to neutral mains wire and thus is both live and conducts significant current.

<comment><AUTHOR> Actually, I was under the impression that it is only config input. I will have to recheck it. This might be a major problem. Thanks!

</comment></comment></comment><comment><USER13> @retrohax Just wanted to say thanks for the blog, it's an entertaining and informative read! Man, that A1200 was in a state...

<comment><AUTHOR> btw. A1200 was a really mild state. Have a look at my "Extreme refurb" series -> [https://retrohax.net/?s=extreme](https://retrohax.net/?s=extreme) Those machines were a bit harder to fix lol :D

<comment><USER13> Excellent, will check them out.

</comment></comment></comment><comment><USER14> very cute, would be interesting to see something like [https://collapseos.org/](https://collapseos.org/) running on it

<comment><USER15> It's an interesting idea. The funny thing is that in the event of a civilization collapse, it might be way easier to find quad cores CPUs and 8 GB RAM modules than antic pieces.

<comment><USER16> But when supplies run out the idea is to restore manufacturing ability. It's hard to bootstrap 7nm fabs in a Mad Max wasteland but we might conceivably be able to get back to 1980s tech.

<comment><USER11> You can get back to 1980's tech easily enough if you have 1970's tech. And so on all the way back to about 1920. Whatever you have + the knowledge remaining will allow you to rise up the ladder a little quicker but not that much quicker because you still need to go through all the motions in between. Skipping steps is really hard, most progress is incremental.</comment></comment></comment></comment>


Is it okay to ask for feedback about my business here? - <AUTHOR> Hi!
I've created a free platform for e-commerce, something like Facebook meets Amazon, except users pay no commissions or anything at all (it's 100% free). Is it okay to ask for feedback here?
Thanks! :) <comment><USER2> Sure! Submit a "Show HN": [https://news.ycombinator.com/show](https://news.ycombinator.com/show)</comment>


Over 680TB of data exposed in MongoDB databases - <AUTHOR> https://www.computerworld.com/article/3016216/over-680tb-of-data-exposed-in-mongodb-databases.html <comment><USER2> this is from 2015</comment>


Verizon Dropping Google Search From All Future Androids? - <AUTHOR> http://thedroidguy.com/20100908/exclusive-verizon-dropping-google-from-all-future-androids/ <comment><USER2> How curious! I wonder what it is that caused this decision - after all, in my experience, Google has always produced more accurate results.

And removing the search bar altogether is surely some sort of anti-trust violation is it not? Especially if users cannot add it back in, which seems to be stated in this article: "[The testers] tried several APK's of the Google Seach bar and have not been able to get those to work either."

I do wonder what the motivations behind this move are? It has certainly dissuaded me from purchasing an Android from them (which I had otherwise planned to), and will be looking elsewhere instead - I cannot be productive without my Google Search!

<comment><USER3> I'm sure Bing is handing cash over to Verizon for this. Bing buys its users.

<comment><USER2> That does seem to be (from past experience) the microsoft way of doing things... I can't say I'm impressed.

</comment></comment></comment><comment><USER4> None of this prevents you from using the Google website. It's my homepage on my Android phone, so search is one tap from the home screen, no apps necessary.

</comment><comment><USER5> How's Virgin mobile's coverage, for those of you that actually have it? If these sort of activities continue, I may very well have to transfer over to an entirely different carrier. Pitty, too. I really liked being on Verizon. I thought they didn't do odd things like this...</comment>


WePay (YC S09): Innovating Where Banks Won't - <AUTHOR> http://www.xconomy.com/san-francisco/2010/07/08/innovating-where-banks-wont-talking-with-rich-aberman-about-wepays-vision-for-group-payments/ <comment><USER2> It's about time they started innovating in this sector.

The banking industry as of late seems like nothing but fraud and arcane outmoded banking policies (i.e. Why the hell do banks still close on Sundays???)

I hope WePay branches out into other services. It'd be a miracle if I could manage my bank account like I manage my other web 2.0 services.. It'd also be nice if the bank I was with gave a shit about having me as a customer.

Banking hasn't fundamentally changed for over a century and as the article points out, Paypal has been pretty lackluster in terms of innovation as well..

Banking is _screaming_ for innovation and I can't wait to hear about more startups innovating in this space..

<comment><USER3> > Why the hell do banks still close on Sundays???

I'm confused. Does your ATM stop working on Sundays? Does your home banking stop working on Sundays?

The closest branch of my bank is 3000 miles away. The last time I stepped inside a branch was probably 4 or 5 years ago. I call them on the phone a couple times a year. The fact that they aren't "open" on Sundays is a complete non-issue for me.

<comment><USER4> My online banking really does close between 2 and 6. No joke.

But I don't want a web 2.0 bank, I want a bank as boring as you can get it, one that only hires people with absolutely no life, with a plain boring website.

In want that because they are not a new and exciting thing, they are a place that should only ever do one thing: take my money, lend it extremly reliable people and give me an interest in the return.

<comment><USER3> To be clear, I don't have a "web 2.0" bank. The only thing non-traditional about my "bank" is that they are actually a credit union. However, they are able to do pretty much everything I need either online, over the phone, or via mail.

</comment></comment></comment></comment><comment><USER5> So... how awesome is it that the founders of this money-handling system are "Rich" and "Bill"?

<comment><USER6> If you've ever met them, the actual awesomeness is just how bad-ass Rich and Bill are.

<comment><USER7> Pretty please describe an anecdote showing how bad-ass and awesome Rich and Bill are.

Thanks, in advance.

<comment><USER8> To make it hard to quit they got a dog together. It's supposed to be the company's dog, not either of theirs individually. The idea being that now the company can't go away or there's no one to take care of the dog. Increased the burn rate a little but turned out to be a net win.

<comment><USER9> I know it's not really the same situation, but this reminds me of couples who have a child to help protect/save their marriage. This usually hurts, rather than helps the marriage.

<comment><USER10> True, but it's not as bad as that. In the end, if you had to, you can give away the dog to a good home with a _lot_ less paperwork. ;)

</comment></comment></comment></comment></comment></comment><comment><USER11> Great article. I particularly liked the discussion about how they took their business through the YC process and to market.

It seems like WePay is a service that has a lot of potential. It also seems like it might have some potential for fraud and money laundering, so I hope that doesn't happen to the service.

<comment><USER12> I read a bit of the history of PayPal. It seems like they spent an enormous amount of time dealing with fraud and security issues.

<comment><USER13> Max Levchin is a WePay investor, though.

Fraud and security will be a headache, but they have access to smart people who have handled these issues before.

</comment></comment></comment><comment><USER14> _Our first 30 beta testers were all Y Combinator founders_

This seems like a powerful feature of YC!

<comment><USER8> We deliberately encourage it. We learned about this technique from Google, who use their own employees to beta test everything.

In fact, this is part of the reason we've grown so fast. As we continue with YC it becomes increasingly clear how valuable the alumni network is (not just in this way of course but in others too), so the bigger we can grow it the better.

</comment></comment><comment><USER15> A great Idea, but there is no secret sauce here. I wonder how difficult it might be for someone like Facebook or Google to rip this.

<comment><USER16> Is there a WePay Facebook app yet?

</comment></comment><comment><USER17> At SxSW this year, there was a session on "Banking 2.0", and they (Mint, LendingClub, etc.) all agreed that their philosophy is to treat banks as dumb institutions - mainly to avoid regulatory pit-falls, etc.

WePay is following the same path, however the risk management side isn't seeing much startup activity at all. This means consumers win in experience, but systemic risk is largely the same.

</comment><comment><USER13> On a single-page: [http://www.xconomy.com/san- francisco/2010/07/08/innovating-w...](http://www.xconomy.com/san- francisco/2010/07/08/innovating-where-banks-wont-talking-with-rich-aberman- about-wepays-vision-for-group-payments/?single_page=true)

</comment><comment><USER18> It does not seem like WePay will compete against Paypal. Why aren't there more paypal competitors? What are the barriers to entry?

<comment><USER19> I think the fact that only big players (Amazon, Google) have had any success at all in this area is illustrative. Regulatory barriers plus ability to deal with fraud at scale sets a very high hurdle. Not the kind of thing you can easily bootstrap.

<comment><USER20> Max Levchin said on Nerd TV that tackling fraud cost Paypal $100,000,000.

</comment></comment></comment><comment><USER21> I wonder how legal it is to accept donations for beer brewing supplies from my friends "in exchange" for the beers I provide for them. The donation jar on top of the kegerator works, but a lot of people don't carry cash these days. I guess I'll find out.

</comment><comment><USER22> Won't or can't? How much of the lack of innovation in banking due to regulation?

<comment><USER23> I don't know about regulations, but I've heard some horror stories from a friend of mine who works for a major bank. Most of the efforts his department has made -- toward rethinking and redesigning online banking -- have been thwarted by office politics.

</comment></comment><comment><USER24> I want a bank with a CLI.

</comment><comment><USER25> Wow, I feel like a total asshat. I did this years ago and called it GroupBuy.

The idea came to me when I was gathering money for a batch of shrooms my friends and I were buying.

Its good for buying large quantities of drugs with friends.

Idea #2 for me that I slept on.

Fuck me.

<comment><USER26> I agree with you, the tone of the article made it sound like the founders (and the VCs that funded them) cured cancer, solved world hunger, and eradicated all disease and unhappiness.

When in reality, they just found a way to take a cut of transactions. Just like every other financial institution. Innovation indeed.</comment></comment>


Go channels are bad - <AUTHOR> http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/ <comment><USER2> This is a frustrating and overly-exasperated post which reaches conclusions that have always been part of the Go canon. APIs should be designed synchronously, and the callers should orchestrate concurrency if they choose -- yes! Channels are useful in some circumstances, but if you just want to synchronize access to shared memory (like the author's example) then you should just use a mutex -- yes! These are well understood truths.

Novices to the language have a tendency to overuse channels. Here is Andrew Gerrand addressing precisely this point two years ago at GopherCon: [https://www.youtube.com/watch?v=u-kkf76TDHE&t=815](https://www.youtube.com/watch?v=u-kkf76TDHE&t=815)

Neither the referenced performance characteristics via Tyler Treat, nor the FUD surrounding channel-based program architecture, invalidate channels generally. One does have to think carefully about ownership hierarchies: only one goroutine gets to close the channel. And if it's in a hot loop, a channel will always perform worse than a mutex: channels use mutexes internally. But plenty of problems are solved very elegantly with channel-based CSP-style message passing.

It's unfortunate that articles like this are written and gain traction. The explicit instruction to [new] Go programmers is that they should _avoid_ channels, even that they are badly implemented, and both of those things are false.

<comment><USER3> > _APIs should be designed synchronously, and the callers should orchestrate > concurrency if they choose_

Wait, why would you say that?

In general, if " _orchestrating concurrency_ " involves guarding access to _shared mutable state_ , then you can't orchestrate it at the callers site. It would be a massive encapsulation leak, because synchronization is not composable, requires special knowledge, plus you don't necessarily know how to synchronize unless you have knowledge about internals. Furthermore, because it is after the fact, your only choice of handling it is by means of mutexes, which has really terrible performance characteristics. Even if you could do ordering by other means, you end up paying the price of LOCK XCHG or whatever mutexes translate to, not to mention that you'll have problems if you want (soft) real-time behavior, because now you can end up with both dead-locks and live-locks.

And this brings us to another problem. If you end up doing such synchronization in Go, then Go's M:N multi-threading ends up doing more harm than good, because if you need such synchronization, you also need to fine tune your thread-pools and at this point 1:1 would be better. On top of 1:1 platforms you can build M:N solutions, but it doesn't work well in the other direction.

> _Novices to the language have a tendency to overuse channels_

Novices to software development have a tendency to overuse mutexes as well.

<comment><USER4> Reading this... only makes me gladder that I'm pursuing work in the Erlang/Elixir space, where messaging "just works" and concurrency "just works" and immutability "just works" (and new processes take a microsecond to spin up) and tearing anything down is basically a nonissue as failure is embraced and logged at every turn and cascading teardowns simply happen automatically depending on how the processes are linked

and all this turns out to be a really amazing system of paradigms when designing apps to work in the real world

<comment><USER5> It "just works" in Go too, minus immutability, but congrats on your technology decision. You don't get type checking but c'est la vie.

<comment><USER4> Restricting input based on type hierarchies can reduce a certain class of bugs, yes, but careful use of guards as well as typespecs and unit test coverage (which you should have, anyway) can accomplish much of what type restrictions can

<comment><USER4> Was something I said factually wrong? User im_down_w_otp put up an example of what I'm talking about (minus the unit testing) so what gives?

<comment><USER2> I suspect dismissing static typing whole cloth with "unit tests and certain guards can give you most of the benefits" comes off badly to some people.

<comment><USER4> I don't see how "can accomplish much of what type restrictions can" is the equivalent of "dismissing static typing whole cloth"

I choose wording carefully for a reason

</comment></comment></comment></comment></comment></comment></comment></comment><comment> david-given I've always really, really liked Ada's rendezvous-based concurrency.

There's more to it than I can really describe here, but in effect it allows you to treat a thread as an object with methods; calling a method on the object sends a message to the thread. The thread's main code can, at any point, block and wait for a message, or combination of messages.

The handling code looks like this:

        ...some code...
        accept DoSomething(value: in out integer) do
          ...some code here...
        end
        ...some more code...

That causes the thread to block and wait for the message. When the message is sent, the caller blocks, the receiver runs the handler, then the caller resumes.

The beauty here is that inside the message handler, you know that the caller is blocked... which means it's safe to pass parameters by pointer[ _]. Everywhere the parameter 's in scope, the parameter is safe to use. The type system won't let the thread store the pointer anywhere without copying the contents first, so you get zero-copy messaging _and* it's failsafe.

You can also do really cool stuff with timeouts, guards, automatic thread termination, etc. Here's a simple multithreaded queue (syntax and logic not guaranteed, it's been a while):

        loop
          select
            when usage < capacity =>
              accept Push(value: in integer) do
                data[usage] := value;
                usage := usage + 1;
              end;
          or
            when usage > 0 =>
              accept Pop(value: out integer) do
                usage := usage - 1;
                value := data[usage];
              end;
          or
            terminate;
          end select;
        end loop;

Multithreaded! Blocks the client automatically if they pop while the queue's empty or push while it's full! Automatically terminates the thread when the last connection goes away and the thread leaves scope! Thread safe! Readable!

I'd love to be able to do this in a more mainstream language.

[*] This is a simplification. Ada's pointers are not like other language's pointers.

<comment><USER6> The older I get, the clearer it is that Ada was the answer to the last 2 decades worth of problems (fast, able to go low-level when you need to, very type safe, easy concurrency primitives) and we all just ignored it because it wasn't fashionable.

<comment> david-given I would _love_ to have a modernised Ada. With case sensitivity. And garbage collection (a lot of the language semantics are obviously intended to be based around having a garbage collector. I'm very surprised that it never seemed to get one). And a less wacky OO system (invisible syntax, ugh).

But those are quibbles, and at it's heart it's still an excellent, excellent language. And there are Ada compilers in Debian, it's still being maintained, it compiles really quickly into excellent code, it interoperates beautifully with C...

<comment><USER6> I don't mind the lack of GC. Storage pools are reminiscent of Objective-C's autorelease pools, which I've always thought were a very nice way of handling a group of objects' lifetimes.

> And a less wacky OO system (invisible syntax, ugh).

Not sure what you mean by this one?

> And there are Ada compilers in Debian, it's still being maintained, it > compiles really quickly into excellent code, it interoperates beautifully > with C...

I came across [http://www.getadanow.com](http://www.getadanow.com) the other day. Really easy way to get Ada going on OS X, too.

<comment> david-given Okay, so I can't duplicate the exact OO syntax issues I was having before. But, from memory, I was finding that by putting the wrong kind of statement between the type definition and the method declaration, I could thoroughly upset the compiler --- there was invisible syntax connecting the two together, and if you I put the wrong thing in between, then things stopped working.

But as I can't duplicate it it's entirely possible I was just hallucinating.

In general I find the OO syntax desperately confusing. It feels like it's been shoehorned in on top of the existing record and procedure syntax, and it's never clear exactly what anything does. e.g. you need to suffix the object type with 'class in methods in order to make them _non_ dispatching, but you need to suffix the object type with 'class in variable types if you want them to dynamically dispatch? That's not a happy choice.

(Case in point: I've just spent 20 minutes trying to refresh my memory by making this code snippet work. And failing. What am I doing wrong? [http://ideone.com/6iPdYF](http://ideone.com/6iPdYF))

Incidentally, re getadanow.com: that's really nice! And it's not pointing at the Adacore compilers, either; beware of these, as their standard library is GPL, _not_ LGPL, which means you can't distribute binaries built with them. (The standard GNAT version is fine.)

<comment><USER6> > But as I can't duplicate it it's entirely possible I was just hallucinating.

There's a thing where if you declare a type A, and then a derived type B, methods on A have to be declared before type B gets declared, because B's declaration "freezes" A. I think it's mostly a single-pass optimization that might have made sense 20 years ago but is meaningless in an era of gigabytes of RAM.

> (Case in point: I've just spent 20 minutes trying to refresh my memory by > making this code snippet work. And failing. What am I doing wrong? > [http://ideone.com/6iPdYF](http://ideone.com/6iPdYF))

The specific error message is: you declared a package, which is basically a header in C parlance. You declare signatures in it, not method bodies. Method bodies go in package bodies. You were conflating the package and the package body.

And then from line 19 onwards you were using the package name where you wanted to be using a class name. I cleaned it up a bit and made it work: [https://gist.github.com/mbarnett/9c6701fe74524a6df522](https://gist.github.com/mbarnett/9c6701fe74524a6df522)

<comment> david-given > There's a thing where if you declare a type A, and then a derived type B, > methods on A have to be declared before type B gets declared...

Yes, that sounds very familiar.

> The specific error message is: you declared a package, which is basically a > header in C parlance.

Oh, FFS. That snippet is not, in fact, pointing at the piece of code I was actually asking about --- ideone changed it when I wasn't looking. The one you saw is unfinished and broken.

 _This_ one is the one I was meaning: [http://ideone.com/skZRIb](http://ideone.com/skZRIb)

The .Foo selector isn't found; changing it to Foo(object) reports that apparently Foo isn't a dispatching method on MyClass1... which makes no sense, because this is the same code as you had. My suspicion is that there's something magic about declaring classes in packages?

<comment><USER6> > which makes no sense, because this is the same code as you had. My suspicion > is that there's something magic about declaring classes in packages?

Yeah.

Dispatching methods on a type consist of the type's "primitive operations". The Ada 95 Rationale spells it out: "Just as in Ada 83, derived types inherit the operations which "belong" to the parent type - these are called primitive operations in Ada 95. User-written subprograms are classed as primitive operations if they are declared in the same package specification as the type and have the type as parameter or result."

It seems like a wart that you're not in an "anonymous" package in situations like your example, but I also guess it probably doesn't come up much in "real" programs.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Good points.

The author points out that channel teardown is hard. He's right. Figuring out how to shut down your Go program cleanly can be difficult, especially since calling "close" on a closed channel causes a panic. You have to send an EOF on each channel so the receiver knows to stop. When you have a pair of channels going in opposite directions between two goroutines, and either end can potentially initiate shutdown, it gets messy.

At least in the original implementation, "select" for more than one option was really slow and complex. The single-input case was handled efficiently with generated code, but for N > 1, a very general library mechanism with several heap allocations for each message was used. This means having both a wait for data and a timeout in a select puts you through the slow path. Not good. Someone did an analysis of existing programs and found that N=1 was most common, N=2 was reasonably common, and N>2 was rare. N=2 needs special case support.

QNX interprocess messaging has a similar architecture. But they don't have the panic on close problem, and timeout is handled efficiently. So you can generally shut things down by closing something. As each process is notified about the close, it closes any channels with which it is involved, even if some other process has already closed them. The closes thus cascade and everything shuts down cleanly. Processes that time out at a message receive check to see if the rest of the system is still running, and shut down if it's not.

Go's "share by communicating" would be more useful if Go had Rust's borrow checker, so you could share data without races. Yes, Go has a run-time race detector, but that's only useful if races are common enough that they occur during testing.

<comment><USER8> > N=1 was most common

Why would somebody use "select" for this at all? I.e., if you were going to write:

      select {
        case send/receive statement:
          statement
          ...
      }

Why not just write:

      send/receive statement
      statement
      ...

What am I missing?

<comment><USER9> I believe the GP was referring to select-with-one-case-and-a-default, like

      select {
        case <- ch:
        default:
      }

</comment></comment></comment><comment><USER10> This was a well-written and entertaining post. It represents the kind of self- reflection every programming community should encourage. Too often are devs zealously supportive of their language of choice without considering thoughtful critiques that could make their chosen language even better, and/or present an alternate way of looking at things that makes one better at programming in general.

</comment><comment><USER11> I didn't get the point of example with Game and Player. The code behaves exactly how it's told to. If you need some logic to handle conditions where all players have been disconnected - you should implement it, no matter how. Maybe you want to wait for some time for a new players and teardown only after this timeout. Or, maybe, you want to reuse this game object, moving to some kind of pool (like sync.Pool). Or, perhaps, you really want to wait forever for returning players. It's not 'mutex vs channels' example in any way.

It's not 'fix goroutine leak' it's "write the logic you want", it's that simple.

Next, channels are slow, really? Send-receive operation on unbuffered channel typically takes around 300ns. Nanoseconds. 300 nanosecond in exchange of nice and safe way to express concurrent things - I wouldn't even call it a tradeoff. It's not slow at all in vast majority of cases. Of course, if you write that software that do care about nanoseconds and channels becomes your bottleneck - congratulations, you're doing great, and you probably have to switch to C++, Rust or even Assembler.

But, please, don't mislead people telling them, that channels are slow. They could be slow for your exact case, but it's not the same.

I don't really get the tone and arguments of the article. Some of the points are totally valid, but they easily falls into the 'hey folks, be careful about this small thing you may misunderstand at the beginning' category. Pity.

<comment><USER12> >* Of course, if you write that software that do care about nanoseconds and channels becomes your bottleneck - congratulations, you're doing great, and you probably have to switch to C++, Rust or even Assembler.*

Thats ridiculous. I could switch my entire language... or I could just use a lock?

First off, looking at Tyler's post, he measured unbuffered channels taking 2200ns vs 400ns for the lock solution - a 5x speed up. That is a large gain, especially when dealing a program that may have high lock contention. Switch from Go to C++ or Rust my not even gain you that much in terms of throughput - they are both compiled code and moving to either language will only mainly alleviate of magic STW pauses - acquiring a lock likely won't be any faster.

Second, in the point of Game and Player, the logic to handle conditions where players disconnect is still simpler to implement with locks - its 2 lines, and there is no need to bring in sync.Pool, or introduce arbitrary timeouts.

Channels are slower than locks. In more complex applications, channels are easier to reason about than locks, but those tends to be in cases where you care more about message passing than state synchronization.

<comment><USER13> > Switch from Go to C++ or Rust my not even gain you that much in terms of > throughput - they are both compiled code and moving to either language will > only mainly alleviate of magic STW pauses

That is not the only performance-related difference between those language implementations. It's not even the most significant one.

For instance, there is a large difference between a compiler with LLVM's optimizations and one without an SSA backend at all.

<comment><USER14> The new Go SSA backend was merged into tip a few days ago:

[https://groups.google.com/d/topic/golang- dev/49VaiLCDbeQ/dis...](https://groups.google.com/d/topic/golang- dev/49VaiLCDbeQ/discussion)

</comment></comment></comment></comment><comment><USER15> Effective Go has always said:

 _Do not communicate by sharing memory; instead, share memory by communicating.

This approach can be taken too far. Reference counts may be best done by putting a mutex around an integer variable, for instance._

[https://golang.org/doc/effective_go.html#sharing](https://golang.org/doc/effective_go.html#sharing)

<comment><USER16> Reference counts are best done using interlocked increment/decrement primitives.

<comment><USER17> I wonder if there are any compilers which can replace

        mutex.lock { x++ }

With a 'lock xaddl x 1' instruction.

<comment><USER18> It's not quite the same thing but recent JVMs can translate synchronised blocks into Intel TSX transactions, which means multiple threads can run inside the lock at once, with rollback and retry if interference is detected at the hardware (cache line) level. So yeah .... almost. But it's fancy and cutting edge stuff.

</comment></comment></comment></comment><comment><USER19> I see channels as an architectural option when it comes to structuring the communication between components of my software. Mutexes are another option that are more effective in situations where multiple threads may access the interface of a single structure. E.g I use channels to distribute os.Signals througout my software and a mutex for making a "context" structure thread safe. Right tool for the right job

<comment><USER20> Even when that's the case, it's rare that fixed-size buffered or unbuffered channels are really the best option for communication between different components of your software. A simple mutex-guarded queue is easier to begin with and easier to evolve when requirements change. You can prioritize queued work trivially and transparently; you can add batch processing, monitoring, and resolve other production issues without any undue refactoring: it can all be encapsulated behind your mutex-guarded queue.

It's really quite a pity that Go's channel syntax treats channels as unique snowflakes, rather just being sugar for calls into an interface that would allow the underlying channel implementation to differ based on software needs.

<comment><USER21> That's an excellent example (in a long list) of things that would be possible with generics, or even parameterized packages. They could have provided an interface Channel[T] with syntax sugar if desirable. But as it is, everything in Go that can handle multiple types has snowflake status.

</comment></comment></comment><comment><USER22> Funny timing for me -- last Friday I rewrote some code from channels to traditional sync primitives (to the code's improvement), and I was musing in my head that while everyone always says "don't communicate by sharing, share by communicating, yada yada," it doesn't seem to work out that way in practice.

I think the article is well-written, and clearly comes from a place of deep experience and understanding. Good stuff.

<comment><USER23> I had a similar experience in the opposite direction. Two weeks ago I moved some code from a mutex-based design (including a map of string to mutex, which itself needed to be behind a mutex) to channels, and I love it, though the result seemed about 10% slower.

I guess the message is: everything has its place; don't make a straight-jacket for yourself.

<comment><USER22> No doubt it's quite easy to go down ratholes using mutexes and whatnot. It's a very low-level way of synchronizing.

The OPs critques of the specific design of channels as implemented by Go seem on-point to me.

</comment></comment></comment><comment><USER24> Offtopic: that animated image is literally nauseating. Consider removing it, or making it animate just once and then halt. It was meant to be "fun" or whatever but, seriously, I wasn't able to read the text when it looped over and over in the corner of the eye.

<comment><AUTHOR> Alright, alright, I froze a bunch of the animated gifs. There were too many, I get it.

</comment></comment><comment><USER25> I think I've just come to accept that sychronization is the pain point in any language. It's callbacks, promises, and the single event loop in nodejs. It's channels in golang.

No one can come up with a single abstraction for synchronization without it failing in some regard. I code in go quite a bit and I just try to avoid synchronization like the plague. Are there gripes I have with the language? Sure, CS theory states that a thread safe hash table can perform just about as well as a none-thread safe, so why don't we have one in go? However...

Coming up with a valid case where a language's synchronization primitive fails and then flaming it as an anti-pattern (for the clicks and the attention, I presume) is trolling and stupid.

<comment><USER26> > No one can come up with a single abstraction for synchronization without it > failing in some regard.

Erlang did. Or at least it's as close as possible.

<comment><USER25> I'm not saying Erlang isn't great, but if you need to pass a large datastructure around between Erlang processes then copy message passing starts to be a lot and you need to share memory. You can do it in Erlang, but I'd hardly call it great, and you're avoiding the sync primitive that Erlang offers.

<comment><USER27> How about Rust's "share by transferring ownership"?

(0) In the general case, whatever object you give to a third party, you don't own anymore. And the type checker enforces this.

(1) Unless the object's type supports shallow copying, in which case, you get to keep a usable copy after the move.

(2) If the object's type doesn't support shallow copying, but supports deep cloning, you can also keep a copy [well, clone], but only if you explicitly request it.

This ensures that communication is always safe, and never more expensive than it needs to be.

\---

Sorry, I can't post a proper reply because I'm "submitting too fast", so I'll reply here...

The solution consists of multiple steps:

(0) Wrap the resource in a RWLock [read-write lock: [http://doc.rust- lang.org/std/sync/struct.RwLock.html](http://doc.rust- lang.org/std/sync/struct.RwLock.html)], which can be either locked by multiple readers or by a single writer.

(1) The RWLock itself can't be cloned, so wrap it in an Arc [atomically reference-counted pointer: [http://doc.rust- lang.org/std/sync/struct.Arc.html](http://doc.rust- lang.org/std/sync/struct.Arc.html)], which can be cloned.

(2) Clone and send to as many parties as you wish.

\---

I still can't post a proper reply, so...

Rust's ownership and borrowing system is _precisely_ what makes RWLock and Arc work correctly.

<comment><USER25> What if you want multiple readers at once, and a writer thrown in once in a while?

Edit:

Okay, my point was that the sync primitives of most languages alone can't save you and you're using RWLock in your example, so clearly ownership by itself doesn't solve everything, right? That's the point I'm trying to make.

Edit2:

Hmm, I'll have to check that out. I don't know that I would call Rust's ownership model super easy to reason about, but it is nice that the compiler prevents you from doing so much stupid $#^&.

<comment><USER28> > Hmm, I'll have to check that out. I don't know that I would call Rust's > ownership model super easy to reason about, but it is nice that the compiler > prevents you from doing so much stupid $#^&.

It's much better get compile time errors than deal with very hard to reproduce data races.

<comment><USER29> Only, as usual, in situations when all else is equal.

By the way, on a related note, data races themselves are easier to reproduce than the _visible negative consequences_ of those races on the execution of that program. That's the basis of tools like the "Helgrind" tool in Valgrind. That is to say, we can determine that some data is being accessed without a consistently held lock even when that access is working fine by dumb luck. We don't need an accident to prove that racing was going on, in other words. :)

<comment><USER27> > By the way, on a related note, data races themselves are easier to reproduce > than the _visible negative consequences_ of those races on the execution of > that program.

Perhaps, but a data race by itself isn't sufficiently loud to catch my attention (no idea about yours), unless it _consistently_ has visible consequences during debugging - preferably not too long after the data race itself takes place.

> That is to say, _we can_ [emphasis mine] determine that some data is being > accessed without a consistently held lock even when that access is working > fine by dumb luck.

By "we", do you mean human beings or computers? And, by "can", do you mean "in theory" or "in practice"? Also, "only when we're lucky" or "reliably"?

> We don't need an accident to prove that racing was going on, in other words.

What I want to prove is the opposite - that there are _no_ races going on.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER30> The article presents very similar arguments to those that I read in a book from 1982 or so. It discussed channels in Ada and pointed out that without super smart compilers that would turn channels into mutex operations the code using channels would be slower and more complex due to the need to create an extra threads.

Base on that I can predict that in 2050 I will also read an article discussing channels in yet another language and advocating using mutexes instead...

</comment><comment><USER31> I am not a Go veteran, but can see where this article is not helpful. Yes, channels are not a solve-everything. That is, why the Go library also contains mutexes etc. The game serving example could have been fixed by adding a channel to signalize that the game is finished. The game runner function should listen on the "scores" and the "done" channel with a select. Or, not use a channel at all. The channels are great, when you just want a completely safe method of communicating between goroutines, as long as the communication reasonably falls in the "streaming" behavior of the channel model.

</comment><comment><USER32> I find it hard to read something when the language used is so patronising.

<comment><USER33> The language is one thing. I am so tired of trying to read articles riddled with gifs.

<comment><USER34> I'm so tired of reading negative comments about entirely subjective (others might appreciate the gifs) and totally skippable if one doesn't like them (you can also ignore them) elements of a good post.

<comment><USER32> Criticising how information is communicated is wholly valid.

<comment><USER34> Criticising how information is communicated yes.

But saying "I hate articles riddled with gifs" is far from Marshall McLuhan and Edward Tufte.

Especially since it's not some shallow Buzzfeed post, but a detailed technical explanation of a programming-related issue that the author took time and effort to write -- which makes complaining about its presentation petty.

The author obviously wanted to lighten it up and add some fun elements. And he provided his opinion and expertise for free. These kind of comments can mainly serve to discourage him from writing more, not get him to "improve" his communication.

<comment><USER32> alright, point taken.

</comment></comment></comment></comment></comment></comment><comment><USER35> From [http://go-proverbs.github.io/](http://go-proverbs.github.io/):

Channels orchestrate; mutexes serialize.

</comment><comment><USER25> Should have been titled, "Interesting Cases Where Go Channels Fail"...

</comment><comment><USER36> In non-critical things (not important to execution speed), is it still acceptable to use go channels? I'm always weary of using a mutex because then I have to spend a much larger amount of time checking to see if it will lock.

</comment><comment><USER37> Saving the highscore in a goroutine becomes more interesting if that action can block or simply take a while, both more realistic occurrences than such minimalistic examples.

</comment><comment><USER38> Non Go programmer here. Can someone explain the initial goroutine leak that is being addressed? I don't see the issue.

<comment><USER11> It's not actually a leak. It's a program explicitly doing 'run goroutine and don't care of it anymore'. If the program logic wants this - it's ok. If author wants it to finish on some condition, but didn't write the condition code (like in this article) - it's a leak, but it's purely author's mistake.

<comment><AUTHOR> There is a _deliberate_ leak in the example program. The author was attempting to illustrate that fixing the leak using just channels would be a challenge.

<comment><USER39> Synchronizing access to a memory address isn't really the use-case for channels. I think that's fairly well understood by the Go programmers I work with. This example demonstrates why, but it prefaces the discussion by implying this is the standard practice, which I think is misleading.

<comment><AUTHOR> I perhaps communicated poorly, but the point of that section was to try and explain that the CSP model ( _only_ using channels) was untenable in Go (even though it doesn't necessarily have to be in general), and that you'd almost certainly end up not just using channels in a real program, which it seems you agree with.

</comment></comment></comment></comment></comment><comment><USER40> You can express unbounded buffered channels in Go straightforwardly with the stacked channel idiom.

</comment><comment><USER21> I enjoyed the article and nodded along as I read it. But after, I felt like it was overstating its case a little. It puts up a toy implementation that kinda works, and then explains that to make it act correctly in the real world you have to add uglier code. I can't really see blaming the language constructs for that... show me a language where that doesn't happen!

I do appreciate that the article tries to deflate some of the hype about channels that you see when first investigating Go (I know I bought into it at first). After a little experience, I settled into a pattern of using channels for large-scale and orderly pipelines, and more typical mutexes and conditions for everything else. They have strengths and weaknesses, like all tools.

</comment><comment><USER41> the Clive[1] system uses a fork of the Go language which allows readers to close channels (I think it's the most significant difference between the languages, if not the only one):

[http://syssoftware.blogspot.com/2015/06/lsub-go- changes.html](http://syssoftware.blogspot.com/2015/06/lsub-go-changes.html)

\--

1: [http://lsub.org/ls/clive.html](http://lsub.org/ls/clive.html)

</comment><comment><USER42> Channels are great, but I prefer lazy lists.

</comment><comment><USER43> How can I play the gifs again?

</comment><comment><USER44> a nice feature of this post would be the ability to click on images to hide them.

Normally I have ublock to remove distracting elements.

</comment><comment><USER45> There is probably a large number of developers who think "OMG my Go code doesn't have any channels and goroutines. Am I doing this right?" If you try to force a solution that isn't quite right for the given problem, then well, have fun. Case presented by the author I would naturally program with Mutexes, as me thinks using channels / goroutines is an overkill for this task.

</comment><comment><USER46> Pixie dust that makes concurrency problems go away is an antipattern.

</comment><comment><USER47> This article should have been titled: "Go channels considered harmful" :)

<comment><USER48> Thankfully it wasn't, and we were spared the ensuing discussion about how "..considered harmful" is good/bad/overused/misunderstood/causes cancer.

<comment><USER49> Instead we get the debate of whether "and you should feel bad" is appropriate in a title.

I don't believe it is, but ultimately click bait is click bait.

<comment><USER48> Eh, I don't mind click bait titles as long as the article delivers, and the title isn't too egregious in its manipulation. In this case, I think it's pretty well understood by most that the title is poking fun, since taking it truthfully is fairly ridiculous.</comment></comment></comment></comment>


An open letter to Valleywag: Why your snark is going to get us all killed - <AUTHOR> https://medium.com/one-world/an-open-letter-to-valleywag-why-your-snark-is-going-to-get-us-all-killed-b2d719a52f3c

<comment><USER2> Is this like A Humble Proposal? If not, it's pretty much the most ridiculous (and disjointed) thing I've ever read. Just really, really badly done.

</comment><comment><USER3> Like I just said in another thread: most of America is in something resembling a depression.

To those who see no opportunity and no future, optimism is an insult. The Valley's optimistic self-helpy "follow your dreams" zeitgeist sounds like "and why do they not eat cake?"

Outside the alpha cities of the coasts, there is no future in America.</comment>


What sort of salary would a security arch get in the bay area - <AUTHOR>

Hi *,
I have taken in interest in the bay area as of late do to a change in personal circumstances. I am actually a brit, so this would be a migration for me.
I have worked in security for 10 years +, and my focal areas at the moment are sdn / nfv. I am currently a senior architect one of the big three telco vendors.
What sort of salary would you expect to get? I ask this as the real estate prices look like they might be a showstopper (most 3 beds are between 700k to one million!). I have a wife and two kids in tow. <comment><USER2> Anywhere from $170k to 250k I would say.</comment>


Show HN: Suvie – The cool-to-cook multi-zone kitchen robot - <AUTHOR> https://www.kickstarter.com/projects/1483909118/suvie-kitchen-robot-with-multi-zone-cooking-and-re <comment><AUTHOR> Hey everyone, thanks for taking a look at my team's project. I'm an ex-apple Software Engineer, mainly with Ruby chops. This project has really stretched me. C++ firmware, React Native mobile app, Ruby on Rails backend with React front-end, and Particle.io for the IOT glue. Our team is based out of Cambridge, MA and we even have one in China now. Let me know if you have any questions, happy to discuss.</comment>


A tcpdump Tutorial and Primer - <AUTHOR> http://danielmiessler.com/study/tcpdump <comment><USER2> It is not only useful for security professionals. Anybody doing any kind of network programming should have it under their belt. Application level debugging only goes so far. Sooner or later you'll hit a problem like a network card sometimes sending super jumbo frames which the switch cannot handle or some weird performance problems. Packet level debugging is a must in such cases.

<comment><USER3> As a sysadmin, I find it's great for problem localization. Usually an application has a pile of services behind it. Where is it going wrong? Appserver? Backend database? Name resolution? network contention? misrouted? blocked by a firewall?

You can cut away huge swaths of troubleshooting areas just by watching what is on the wire. There are problems you just won't find without knowing how to use a sniffer. I once had a core router dropping packets because of a flawed ACL implementation (It would treat fragmented packets as if they had port numbers at the matching payload offset).

Knowing how to use a packet sniffer makes hard problems so easy it feels like cheating.

<comment><USER4> Exactly the points I was coming to make. People I work with think I am some sort of addict when my default answer when someone asks me about a problem is to fire up a packet capture. Between tcpdump, nc, and burpsuite, seems like few network gremlins can hide.

</comment></comment></comment><comment><USER5> A good tutorial but there some missing options or remarks that are very handy like:

\- -A is equivalent to -X displaying the payload of the packet in ASCII format. If you want to do some scripting based on a payload, that's very handy for matching specific pattern (don't forget offset notation '[a:b]' is limited to 4 bytes block in the bpf filter)

\- -tttt if you want to print the complete time-stamp per packet

\- Don't forget that TCP offloading might have an impact when doing packet capture (and analysis) [http://sandilands.info/sgordon/segmentation- offloading-with-...](http://sandilands.info/sgordon/segmentation-offloading- with-wireshark-and-ethtool)

\- When capturing on a long period of time, the -G or -C helps to rotate capture files while capturing. tcpdump -i en1 -s 0 -G 60 -w tst%y%m%d%H%M%S.cap (if you want to rotate the file every 60 secs) or -C to do the rotation based of the size of the capture file.

\- There are many tcpdump forks (OpenBSD tcpdump is slightly different than the tcpdump on Debian)

<comment><USER3> The power of a ring buffered capture should not be underestimated. Having an intermittent problem that you can't seem to catch while it's happening? Just let the capture run saving the last 2hrs of traffic. When the problem happens, pull the capture files.

Personally I prefer dumpcap and wireshark for this, but it's similar.

</comment></comment><comment><USER6> Also remember if you're filtering ip/port you may need to add the _vlan_ filter to see packets that are vlan-tagged.

</comment><comment><USER7> Yes, please use tcpdump. To capture stuff. Then you put it into Wireshark for analysis.

What is peoples obsession with stretching command line tools? Wake up! We have retina displays now. To display stuff.

<comment><USER8> Wireshark is really useful, but it's also had security problems (I think I'm not being unfair here) continuously over its entire existence. I started using it over 10 years ago back when it was called Ethereal, and I feel like I've seen probably hundreds of Ethereal/Wireshark security advisories in that time.

<comment><USER9> Not all of them were just in wireshark. Sometimes the root of the issue was in libpcap which is common code between wireshark and tcpdump.

</comment></comment></comment><comment><USER10> Nice, bookmarked.

This might be a useful addition to the links at the bottom of your page:

<http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf></comment>


Pokémon no-go: game's exercise effects short-lived in most players - <AUTHOR> http://www.nhs.uk/news/2016/12December/Pages/Pok%C3%A9mon-no-go-games-exercise-effects-short-lived-in-most-players.aspx <comment><USER2> This was me, when it first came out I was walking multiple kilometers a day but since the novelty wore off I haven't touched it at all.</comment>