Swimming in OpenCL - <AUTHOR> http://www.supermegaultragroovy.com/blog/2009/11/12/swimming-in-opencl/

<comment><USER2> Always great to hear about parallelization becoming more widely adopted. The only thing that I don't get is the part about the GPU - it takes a _lot_ of computation to tie up an 8800GT for a full minute. Also, it shouldn't take the 1-3 seconds he described to send a 45 sec .wav file over a PCI Express 2.0 x16 bus (~3-4 GB/s bandwidth IIRC).

I'm not sure what's causing those runtimes, but the fact that it spread over 8 cores that well suggests that it almost qualifies as embarrassingly parallel, which a GPU really should be great for. This makes me really wonder about the maturity of Apple's / nVidia's OpenCL implementation.

EDIT: I just ran a few of the OpenCL SDK demos and can confirm that it is 1-2 orders of magnitude slower than the same demo running in CUDA. The bandwidth for copying memory to / from the device should still be high, though.

My OpenCL Bandwidth Test results: ~/NVIDIA_GPU_Computing_SDK/OpenCL/bin/linux/release$ ./oclBandwidthTest

./oclBandwidthTest Starting...

Running on...

Device GeForce 8400M GT

Quick Mode

Host to Device Bandwidth, 1 Device(s), Paged memory, direct access

       Transfer Size (Bytes)	Bandwidth(MB/s)

       33554432			1600.9

Device to Host Bandwidth, 1 Device(s), Paged memory, direct access Transfer Size (Bytes) Bandwidth(MB/s)

       33554432			1235.1

Device to Device Bandwidth, 1 Device(s) Transfer Size (Bytes) Bandwidth(MB/s)

       33554432			6069.7

TEST PASSED

Press <Enter> to Quit...

<comment><AUTHOR> It's probably the algorithm in question that's to blame, in conjunction with the slow OpenCL implementation for the 8800GT, as you found.

On my machine (I'm the article's author), even Apple's GPU-tuned version of Galaxies runs much faster on the Mac Pro's CPUs than the GPU. So, something's up. I think only the GTX285 for the Mac Pro beats out the CPUs on that test, but I could be wrong...

The 1-2 seconds of overhead could also be contributed to by the compilation of the OpenCL program for the GPU, as I do a compile of the .cl kernel on each run of the program.

Furthermore, I wasn't very scientific about the GPU case, because I wasn't planning to ship a GPU-tuned algorithm. To actually pull this off for a consumer app is easier said than done.

For instance, I'd prefer not to ship the .cl kernel in the application, and would rather provide binary-compiled kernels. Doing this for >1 flavor of GPU is nontrivial, from what I gather, as I'd have to actually own the GPUs in question to get compiles for the different targets (I could only cover the GeForce 9400M, and 8800GT from my own collection of hardware).

That said, I still want to stay open to the idea in the future as I play around with the algorithm, and understand it further.

Thanks for the nudge, though. I really should dig deeper.</comment></comment>


As NASA Aims for the Moon, an Aging Space Station Faces an Uncertain Future - happy-go-lucky https://www.npr.org/2019/07/07/734474121/as-nasa-aims-for-the-moon-an-aging-space-station-faces-an-uncertain-future <comment><AUTHOR> i wonder if it would be any where near efficient to load the station up with materials and supplies and send it off to a lunar orbit or even mars.</comment>


How Zynga Survived FarmVille - <AUTHOR> http://gigaom.com/2010/06/08/how-zynga-survived-farmville/ <comment><USER2> He mentions that FarmVille maintains both their own servers and EC2 servers. That's an interesting approach to maintain some baseline capacity locally and use the cloud for scaling. I suppose its obvious, but usually with the cloud I hear about all or nothing (well or just some specific task in the cloud).

<comment><USER3> The article is somewhat confusing, for FV we didn't split our servers across ec2 and a data center. games are either fully on ec2 or fully in the data center.

<comment><USER4> The crux of the problem is data and latency, right? I imagine it's infeasible to have a hybrid architecture the way cloud providers structure their networks and pricing today.

<comment><USER3> exactly. its the same reason you want to have your databases and application servers in the same data center.

</comment></comment></comment></comment><comment><USER5> The story is interesting, but I still can't figure out why having both their own servers and EC2 splitting 50/50 is a good idea. If EC2 dies the private server won't be able to handle all the traffic and FarmVille will stop working. If the private servers die, they will have a little hiccup until they manage to rescale EC2 and everything will be back to normal. With this system, in practice they already fully depend on EC2 and have an extra point of potential failure. What am I missing?

<comment><USER6> EC2 is actually broken down into a few completely different clouds. If they only used one EC2 location they would be silly.

I agree, they really shouldn't use/need their private servers, but I suspect its a data control issue.

<comment><USER7> I doubt it's a question of data control.

EC2 is significantly more expensive than running your own servers so it's a good idea to keep close to your base load on your own servers and then just scale up/down as necessary with EC2. This way you're optimizing your cost per player.</comment></comment></comment>


Every Time I Try To Embrace Twitter, They Push Us Away - <AUTHOR> http://www.louisgray.com/live/2009/01/every-time-i-try-to-embrace-twitter.html <comment><USER2> The company is not "treating them like leeches" just because they put a hard cap on API usage. 100 requests per IP address is plenty for any client-based application, and they have to put some sort of limit in place.

Maybe Twitter could seed torrents of all tweets in a given time period, putting up new torrents as soon as possible. It seems like that could scale indefinitely, although it might be crazy for Twitter to give away so much of its data.

<comment><USER3> Ironically, isn't most, if not all, of their data available via web pages? You'd just need to scrape them. It would be odd if using the API was made so difficult that scraping was considered the easier, legitimate route.</comment></comment>


Air Force Blocks Access to Many Blogs - <AUTHOR> http://blog.wired.com/defense/2008/02/air-force-banni.html

<comment><USER2> This is an overreaction to the extraordinary amount of time wasted by the desk jockeys in the chair force, albeit it's present in all branches. People waste exorbitant amount of time while on the work clock going to myspace/facebook or trolling to chat with girls on yahoo.

It doesn't restrict personnel/private Internet, ie. when you go to a comm center to pay for the Internet or if you install cable into your barrack room. It's not so much censorship as increasing productivity like all major corporations.

Maybe RescueTime should pitch to the Pentagon.

<comment><AUTHOR> I doubt whether this "censorship to increase productivity" would apply to places like Iraq and Afghanistan where soldiers cannot provide their own Internet.IMHO that is where the military would want to really want to clamp down on posting of "sensitive" information.

Even in ordinary companies I doubt whether restricting internet access leads to improved productivity. A worker intent on wasting time will find a new way of doing it if you restrict his internet.

<comment><USER2> Internet access in Iraq is a whole different ball of wax.

</comment></comment></comment><comment><USER3> Welcome to China.</comment>


Bill Gates Will Grant You $100,000 to Invent a Next-Gen Condom - <AUTHOR> http://betabeat.com/2013/03/bill-gates-will-grant-you-100000-to-invent-a-next-gen-condom/

<comment><USER2> Quote: "If you manage to develop a condom that guys won't complain about having to wear, you will win $100,000 from the Gates Foundation ..."

This is misleading, verging on false. What's being offered is not a prize for a successful design, it's a grant to support development of a promising idea. You don't submit a finished design and wait for your $100K "prize", you submit a proposal for a research program and hope it merits support.

In other words, it's not a lottery, it's science.</comment>


Virtual Course with Venture Partner @ AV8 Ventures and Angel @ YC Demo Day - <AUTHOR> https://flatwyse.com/venture-startup-formation <comment><AUTHOR> Hi everyone,

We're launching a live course on software startup formation with Shawn Kung, Venture Partner at AV8 Ventures, a VC firm based in Palo Alto. He's also an angel investor at Y Combinator Demo Day as well as a Stanford Adjunct Lecturer.

The course includes:

\- 6 weekly live lectures with Shawn and all the other students

\- guest speakers (founders & investors from Shawn's network)

\- 1-1 office hours

\- unlimited Q&A on our private Slack channel

\- startup mini project where students will form teams and pitch a business idea to Shawn

\- lifetime access to Shawn's Slack channel & private LinkedIn group for alumni

Alumni are from Google, Facebook, Brex, Snapchat, LinkedIn, Pinterest, Palantir, etc.

We will kick off on July 23. Class is capped at 50 students.</comment>


Designing an email-only Slack interface - <AUTHOR> https://kevinlynagh.com/stop-slacking/ <comment><USER2> Hi friends!

Keep in mind that this project was a lark that Nicki ([http://www.nickivance.com/](http://www.nickivance.com/)) and I literally made in the back of a van for her exact use case.

My article is a fun writeup of the design considerations and challenges of an email-only UI. It's not supposed to be a marketing piece, to convince you to (not) use the service, or to pass moral judgment on anyone's preferred communication medium.

I should also point out that emailing the app a Slack token is the same as emailing it a password, since the token allows it to read/write messages on your behalf (which is, of course, the whole point). Sending passwords around via email has security implications, which I'm sure you (a thoughtful, attractive, and considerate HN reader) can come to your own conclusions about based on your personal needs and risk preferences.

<comment><USER3> on the stop slacking site, I think the "captions" should appear before the images. It was initially confusing because the first caption doesn't show under 800px height screen. If I hit spacebar and scroll a page, then I see "you get mentioned on slack" and the following picture that looks like an email client, which is confusing.

<comment><USER4> Thanks for the feedback! My screen is usually under 800px height as well, but it helps to have a fresh view on how it reads.

</comment></comment></comment><comment><USER5> There are just so few instances where synchronous group communication (like Slack) makes sense in a workplace. If you need to talk to a large group of people about a project, it'll be more efficient to (gasp) have a meeting. Recording/itemizing data in a slack channel is horrible and basically unsearchable after a few days.

The nature of slack forces people to always "watch" for pings and channel updates, lest they get labeled a slacker for not responding. It's a 24-hour long meeting with no agenda, no guidelines, no leadership, and the occasional guy who jumps into the room with a bad joke.

Total mess.

<comment><USER6> I agree with most of what you're saying here, but this didn't resonate with my experience:

> _basically unsearchable after a few days_

Recently, a coworker asked me for more context about a pull request I had authored 14 months ago. Within minutes I was able to search Slack for relevant discussions, stakeholders, and reasoning.

<comment><USER7> I find slack's search to be absolutely abysmal. If it at least logged to disk, I could grep/awk/sed it.

<comment><USER8> If you're a Slack admin, you can export a dump of the chat history. Such dumps are _nominally_ for import into another group-chat system, but—given that the dump is just a tarball of newline-delimited JSON events, one file per channel—it's very easy to parse through in pretty much any language.

And, of course, if you have a _public_ Slack community, there's nothing stopping you from taking regular dumps and baking them into one-per-day HTML pages, and then putting the HTML files up somewhere where Google can find and index them...

<comment><USER9> > there's nothing stopping you from taking regular dumps and baking them into > one-per-day HTML pages, and then putting the HTML files up somewhere where > Google can find and index them...

Is there a reason why Slack doesn't just have a setting that enables logging to a local file on disk?

</comment></comment></comment></comment></comment><comment><USER10> Neat idea for a minimal slack experience.

However if all you want is a low bandwidth text only slack alternative to use with slow and glitchy cellular I've got an excellent alternative:

wee-slack + mosh

[https://github.com/wee-slack/wee-slack](https://github.com/wee-slack/wee- slack)

wee-slack gives you a minimal terminal based slack client within weechat and mosh handles ssh connections over low bandwidth, high latency connections.

Using this set up I've been able to reply to messages at times a ping to 22.214.171.124 resulted in >90% package loss.

<comment><USER11> It is because of projects like these that I hope Slack won't disable API access the way other big social network companies are doing.

<comment><USER12> Other big social networks have a very different business model. Because they ask users to pay directly for the service, as opposed to ads on UI, using Slack via API or UI shouldn't really matter to them.

<comment><USER13> Didn't stop them from disabling the official IRC gateway they had.

<comment><USER12> yes, you're right. However, the slack RTM API can still support IRC clients (with a little more work - need to setup the IRC server, like [1]). The API is like a superset that way.

[1] [https://github.com/insomniacslk/irc- slack](https://github.com/insomniacslk/irc-slack)

</comment></comment></comment></comment></comment><comment><USER14> Great write-up, however I have concerns over the security of this product, especially the part where they submit a Slack token directly over email.

Email itself is not secure, but at the very least an attacker intercepting a single message will only get the content of that message. An attacker intercepting the token will however gain persistent, remote access to _all_ their current & future Slack messages with no way for the user to even know they've been compromised.

<comment><USER15> Totally agree. The intent may be for good but this is the textbook example of "how not to acquire sensitive information".

</comment></comment><comment><USER16> Of course, the irony is that Slack was supposed to replace email…

<comment><USER17> Personally I prefer slack over email. I basically don't read emails anymore and just mass delete them once a month. I get so many auto generated ones I barely even check.

The quality of email has such a low signal to noise it is becoming a waste of time to even check.

Off topic but related to communication. I wish voicemail could be an opt out thing, I haven't listened to a message in a decade.

<comment><USER14> Auto-generated emails are not the fault of email itself. Just avoid signing up for shit and if you _need_ to sign up then take 5 minutes to visit your account settings on that platform and uncheck any notifications/spam-letters you don't care about.

I personally have only one or two auto-generated emails a week, at most, and all of those actually require my attention (expired credit card, etc). The other ones are either disabled or filtered away at the server level before they even reach my client (thanks to rules in Office 365).

> I wish voicemail could be an opt out thing, I haven't listened to a message > in a decade.

Does your carrier not provide it? Here in the UK every single carrier allows it. If not, try the following USSD codes - the "cancel & deregister" ones: [https://en.wikipedia.org/wiki/Call_forwarding#Mobile_(cell)_...](https://en.wikipedia.org/wiki/Call_forwarding#Mobile_\(cell\)_phones)

</comment></comment></comment><comment><USER18> Both slack and email are awesome and horrible in their own way. The same goes for IM, WhatsApp, Intercom etc etc. Most productivity is actually lost by cross channel communication.

As mentioned in the article "... that company communicated almost entirely via Slack" So where do I digg up the rest? It might be in a voicemail of a colleague.

If slack would implement a push-IMAP api. I could at least drop one app :)

<comment><USER19> I don't see anything wrong with the majority of asynchornous communication methods. Mind you, I'm a fan of slack and a lot of people aren't. The issue though, I think, and the reason why slack is so widely used despite the fact that most users tend not to like it is because of the UI. It's friendly and easy, for surface level tasks, and that's far more important to people than the fact that it's synchronous (based off of my own experience, can't cite any stats so I'm not making a claim here). Email could very well work for this, and several apps have tried to "IM-ify" email, but none have really caught on. It's a UI and UX issue fundamentally, not a capability issue, once again according to my experience.

</comment></comment><comment><USER20> Reminded me of Stallman's approach a little :D (I fully get why this would be necessary with slack, low bandwidth hotel/train wifi etc make the desktop app basically unusable here in the UK whilst travelling). [https://stallman.org/stallman-computing.html](https://stallman.org/stallman- computing.html)

</comment><comment><USER21> This was a cool project - I'm impressed. Just wanted to point out that [http://topicbox.com](http://topicbox.com) offers similar functionality. Topicbox won't interface with Slack but rather replaces it. Run by the folks who do Fastmail, it's a modification/upgrade of old mailing list functionality. If you can get your team to use it, you can do most of what you did with Slack over an email interface that also offers perpetual archiving. I checked it out as a solution for archiving important project emails late- arrival employees would need to read to understand a project. Topicbox and this are slightly different, but both solve the high-bandwidth/low- availability problem in a way.

These products that require always-on internet connectivity on robust connections really tire me out.

<comment><USER4> Thanks for sharing Topicbox, that hadn't come across my radar. I've been pleased with Fastmail.

I can see why it would be helpful for onboarding employees. That's an important use case. Having jumped on multiple teams mid-project, it's tough trying to review a Slack channel history to get context.

</comment></comment><comment><USER22> The best slack interface I've found is appearing online with the tab closed. It's the best of both worlds: no distraction while appearing available. If someone messages you and you don't respond right away, they'll assume you are tending to more important matters.

</comment><comment><USER23> Imagine, there's an app with Slack's functionality that already has such interop with email as you've built here :) Fleep: [https://fleep.io/](https://fleep.io/)

Anyone who does not want the group chat experience can be included in conversations via email.

Currently, that does mean getting all messages via email, and not @mentions (nice idea, worth considering for Fleep's product team). But idea is similar:

Full disclosure: I do work at marketing in Fleep :)

</comment><comment><USER24> I have always wanted to create a Slack alternative that is built upon email. Everything happens on emails (and hidden headers), standards-compliant since day 1 and low barrier to use.

<comment><USER25> Here are some clarifying questions:

* Is the client IMAP? Are there any protocols that would be required on top of it? Would there be an advantage to a separate client?

* Are the contents encrypted? Will it work with other encryption strategies in other clients? How will you share the keys? If it's not encrypted, how will you share anything that cannot be public?

* How do you handle who is allowed to use and who isn't? When someone is stripped of access, what happens? Does that restrict it to business applications where someone controls the email account?

* How does a new individual to the chat acquire the history of the conversation? Is there some sort of mail API behind the scenes?

I'm sure it's possible but I think you'd end up with a separate server and client solution and the protocol wouldn't end up making much of a difference, mostly because of encryption requirements.

</comment></comment><comment><USER12> This is neat. Have you seen any issues with using legacy tokens instead of normal OAuth? I made an extension[1] for using Slack inside VS Code during pair programming sessions - and it doesn't seem to work for enterprise users with legacy tokens.

[1] [https://github.com/karigari/vscode- chat](https://github.com/karigari/vscode-chat)

</comment><comment><USER26> As a full-time remote worker in a primarily office-based environment, Slack has been my main reason for success in working across teams.

</comment><comment><USER27> If you're having Slack fatigue and a less interruptive approach sounds appealing, a friend is working on something you might like: [https://level.app](https://level.app).

<comment><USER28> And its open source. Thanks for the share.

</comment></comment><comment><USER29> Have you heard of Front([https://frontapp.com/](https://frontapp.com/)). I know it's not exactly the same but I think Front saw similar pain points :)

</comment><comment><USER30> > "...interact via email with the poor souls trapped in the endless, no-agenda > meeting that is Slack."

Most of us agree that email __as a collaboration tool__ sucks.

Slack has its (growing?) contingency of haters and dismissers.

But there's so something common to both:

\- Us \- Work

Perhaps it's time to come to terms with the fact that while work has its place - in the context of modern culture / society - we humans just aren't wired for such work.

Tool after tool tries to solve "the problem" but time and again they "fail." As if the sky being blue is a failure.

</comment><comment><USER31> I hate slack with the fire of a thousand suns. That's all.

</comment><comment><USER32> You should call it listserv.</comment>


The Information: How the Internet gets inside us. (2011) - <AUTHOR> http://www.newyorker.com/magazine/2011/02/14/the-information

<comment><AUTHOR> This is one of my favorite essays I've ever read, and I'm sharing it with HN in response to "Why can't we read anymore?" I'll edit this comment as I go with all my thoughts, and a sort-of summary.

First some quotes:

> CONTEXT: The set subject of our novelists is information; the set obsession > of our dons is what it does to our intelligence.

> TECHNOLOGY'S IMPACT: When the electric toaster was invented, there were, no > doubt, books that said that the toaster would open up horizons for breakfast > undreamed of in the days of burning bread over an open flame; books that > told you that the toaster would bring an end to the days of creative > breakfast, since our children, growing up with uniformly sliced bread, made > to fit a single opening, would never know what a loaf of their own was like; > and books that told you that sometimes the toaster would make breakfast > better and sometimes it would make breakfast worse, and that the cost for > finding this out would be the price of the book you'd just bought.

> CAUSALITY: Of course, if you stretch out the time scale enough, and are > sufficiently casual about causes, you can give the printing press credit for > anything you like.

> READING AND EMPATHY: But if reading a lot of novels gave you exceptional > empathy university English departments should be filled with the most > compassionate and generous-minded of souls, and, so far, they are not.

> OLD ARGUMENTS: The odd thing is that this complaint, though deeply felt by > our contemporary Better-Nevers, is identical to Baudelaire's perception > about modern Paris in 1855, or Walter Benjamin's about Berlin in 1930, or > Marshall McLuhan's in the face of three-channel television (and Canadian > television, at that) in 1965. When department stores had Christmas windows > with clockwork puppets, the world was going to pieces; when the city streets > were filled with horse-drawn carriages running by bright-colored posters, > you could no longer tell the real from the simulated; when people were > listening to shellac 78s and looking at color newspaper supplements, the > world had become a kaleidoscope of disassociated imagery; and when the > broadcast air was filled with droning black-and-white images of men in suits > reading news, all of life had become indistinguishable from your fantasies > of it. It was Marx, not Steve Jobs, who said that the character of modern > life is that everything falls apart.

> RESTLESSNESS: Everyone complained about what the new information > technologies were doing to our minds. Everyone said that the flood of books > produced a restless, fractured attention. Everyone complained that pamphlets > and poems were breaking kids' ability to concentrate, that big good handmade > books were ignored, swept aside by printed works that, as Erasmus said, "are > foolish, ignorant, malignant, libelous, mad." The reader consulting a card > catalogue in a library was living a revolution as momentous, and as > disorienting, as our own.

> FAMILY: ("Can you please turn off your damn computer and come watch > television with the rest of the family," the dad now cries to the teen- > ager.)

> METAPHORS: When mainframe computers arrived and television was what kids > liked, the mind was like a mainframe and television was the engine of our > idiocy. Some machine is always showing us Mind; some entertainment derived > from the machine is always showing us Non-Mind.

> COLLAPSE: "Oh, they always say that about the barbarians, but every > generation has its barbarians, and every generation assimilates them," one > Roman reassured another when the Vandals were at the gates, and next thing > you knew there wasn't a hot bath or a good book for another thousand years.

<comment><AUTHOR> Now I'll ramble a bit for why I love this essay so much– it's such a powerful reminder that so many of the bloody conversations we're having all the time about what the Apple Watch is going to do or what AR is going to do, and how our kids are going crazy with texting and lolcats, etc– it's been played out over and over and over throughout the generations, and this time isn't particularly unique.

I guess I often am hopeful to encounter other people who realize that we're in this loop of entertainment, that everything fits within a broader context, and that we don't need to get so worked up over little details about little thing so often. [1]

I wish we could spend more time getting to the end of these conversations quicker, because the end of each conversation is the start of a new one. It feels so tiresome and tedious to have to go through all the details over and over again.

I suppose that's a necessary "evil", or just human nature– we're always going to want to talk about current affairs as though they're somehow Truly Novel And Significant– and I suppose at the opposite end of the spectrum, nothing is, so... what then?

I don't know. The more I read, the less I know. I just feel like there ought to be an alternative between becoming apathetic/nihilistic, and getting caught up in every "new" piece of news. I think this essay sorta-implies it, but stops there.

Would LOVE to hear from anybody who's grappled with this themselves– I'm sure there are some of you!

___

[1]I'm aware of the possibility that something might actually be of dramatic significance– see quote about Romans talking about Barbarians– but I'm thinking "I read 4 books this year, ohnoes" isn't all that crazy/groundbreaking. "I spent a year away from social media"– ugh, seriously? Can't we get past that stuff? What comes after that?</comment></comment>


3D printed zoetrope based on "Massacre of the innocent" painting by Rubens - <AUTHOR> https://vimeo.com/125791075

<comment><USER2> amazing, shame it didn't get more upvotes</comment>


AI needs a new developer stack - <AUTHOR> https://blog.fiddler.ai/2019/06/ai-needs-a-new-developer-stack/ <comment><AUTHOR> We wrote this blog for anyone who wants to take a quick peek at how AI/ML Engineering is shaping up and what some of the essential components of this new stack are.</comment>


Maybe you don't need Rust and WASM to speed up your JS - <AUTHOR> http://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html <comment><USER2> I think this is an interesting exploration because I really enjoyed the description of profiling and improving performance, but I came away feeling exactly the opposite of the title. I think it's really cool that JS optimization can provide so many wins, but this article makes it seem fairly fickle and if they're not familiar with VM internals I would not expect most developers to complete this journey. Using wasm+rust/c++ is interesting in part because you can get so much more predictable performance out of the box. When the performance comes from language features instead of VM-specific optimizations the performance might be easier to maintain across revisions and hopefully will be less subject to regression from VM changes.

<comment><USER3> [Thank you for reading the post! I am glad you enjoyed it]

All optimizations in the post can mostly be divided into three large groups:

1) algorithmic improvements; 2) workarounds for implementation independent, but potentially language dependent issues; 3) workarounds for V8 specific issues;

You need to think about algorithms no matter which language you write in, so we don't need to talk much about the first group. In the post it is represented by sorting improvements (sorting subsequences rather than the whole array) and by discussions of caching benefits (or lack of them there- off).

The second group is represented by a monomorphisation trick: the fact that the performance suffers due to polymorphism is not really a V8 specific issue and it is not even JS specific issue. You can apply this approach across implementations and even languages. Some languages apply it in some form for you under the hood.

The last group is represented by argument adaptation stuff.

Finally an optimization I did to mappings representation (using typed array instead of an object) is an optimization that spans all three groups. It's about understanding limitations and costs of a GCed system as whole.

Now... Why did I choose the title? That's because I think group #3 represents the issue that should and would be mostly fixed over time. While groups 1 and 2 represent universal knowledge that spans across implementations and languages.

Obviously it is up to each developer and each team to choose between spending N rigorous hours profiling and reading and thinking about their JavaScript code, or to spend N hours rewriting their stuff in a language X. What I want is:

a) that everybody was fully aware that the choice even exists; b) language designers and implementors worked together on making this choice less and less obvious - which means working on language features and tools and reducing the need in group #3 optimizations.

<comment><USER4> > _monomorphisation trick_

Here's a crazy thing I recently learned: apparently monomorphism isn't just "object with identical keys", apparently (at least in Chrome), _the order in which you declare those keys matters_. According to this presentation from 2015[0], adjusting the following lines in the Octane/Splaytree benchmark so that node.left and node.right are always assigned in the same order resulted in 15% better performance:

        var node = new SplayTree.Node(key, value);
        if (key > this.root_.key) {
          node.left = this.root_;
          node.right = this.root_.right;
          ...
        } else {
          node.right = this.root_;
          node.left = this.root_.left;
          ...
        }

Now, I assume that this out-of-order thing was actually done on purpose, to benchmark how the JIT handles code like this. Further evidence for that is that the SplayTree constructor[1] does not feature a _left_ and _right_ key either:

        SplayTree.Node = function(key, value) {
          this.key = key;
          this.value = value;
        };

Still, I wouldn't be surprised if it was common for real-life code to accidentally have objects that _should_ have the same hidden class end up with different ones because of this.

[0] [http://mp.binaervarianz.de/fse2015_slides.pdf](http://mp.binaervarianz.de/fse2015_slides.pdf)

[1] [https://github.com/chromium/octane/blob/master/splay.js#L390](https://github.com/chromium/octane/blob/master/splay.js#L390)

<comment><USER5> Yes, this is because the JS spec requires that object keys are iterated in insertion order (with a bizarre exception for arrays).

<comment><USER6> Wait what? Since when? That wasn't the case at all 5 or 6 years ago (I got bitten in the arse by Rhino not implementing it that way)

<comment><USER7> Most browsers already did, and some (not all) of the ES2015 stuff requires property ordering. Probably easier to just keep everything ordered since it could be needed by those methods.

</comment></comment></comment></comment></comment></comment><comment><USER8> The problem with these tricks is that they're dependant on V8 internals, which means that there's no guarantee that it will be fast on Firefox (or edge, or even Safari).

So now if google changes the back end, websites will slow down, which means that Google has to ossify implementation details, furthering this sort of black magic into CS lore forever.

This, honestly, is what I hate with modern dev. A few days back there was a discussion on how programming is hard nowadays.

Really, programming is more accessible than ever. What is hard is the "black magic" that's becoming more and more prevalent, most of which is implementation defined, that everyone is expected to know (and really, most don't really know anything. They just repeat rumors they read about online, often years out of date).

<comment><USER9> The article does mention SpiderMonkey, though not Safari or Edge, and the point does stand that profiling four different JS JITs to guarantee that you trigger their optimizations is always going to be more work than profiling one C++/Rust program generated by a single compiler toolchain (though it remains to be seen how much individual browsers' implementations of WASM will diverge in runtime optimization potential).

<comment><USER10> They will diverge about as much as JS does, that will hardly be a surprise

<comment><USER9> I doubt it. If further optimizing pre-optimized assembly were that easy (or that valuable), then we'd also expect to see more tools for postprocessing compiled binaries. (Just because WASM is a bytecode format doesn't mean it's comparable to Java bytecode and Java's JITs; javac isn't an optimizing compiler.) I'd be happy if anyone actually working on a WASM interpreter could chime in regarding expected optimization potential.

</comment></comment></comment></comment><comment><USER11> > Is it better to quick-sort one array with 100K elements or quick-sort 3333 > 30-element subarrays?

> A bit of mathematics can guide us (100000log100000 is 3 times larger than > 3333×30log30)

You have to be careful doing this kind of analysis. Big-O is explicitly about what happens for large values of N. It is traditional to leave off smaller factors, because they don't matter at the limit of N going to infinity. There is implicitly a constant coefficient on each component, and that might matter more at small N.

So e.g. I've seen cases that were O(N^2 + N), and which of course you'd traditionally write as O(N^2), but where the O(N) factor mattered more at small values of N because of constant factors. Depending on whether you cared more about small or large values of N, would guide whether you'd actually want to go after the O(N^2) factor or not. If you just blindly went for the larger factor, you could waste a lot of time and not actually accomplish anything.

</comment><comment><USER12> The problem with this kind of deep dive optimization is the cost of maintaining it in a long-lived project as the underlying javascript engines keep changing. What was optimal for one version of V8 can actually be detrimental in another version, or in another browser.

It's precisely the unpredictability of JIT-driven optimizations that makes WASM so appealing. You can do all your optimizing once at build time and get consistent performance every time it runs.

It's not that plain Javascript can't be as fast -- it's that plain Javascript has high variance, and maintaining engine-internals-aware optimization in a big team with a long-lived app is impractical.

<comment><USER13> It seems to me there is no reason we shouldn't be able to create an "optimizing babel" that could be doing performance optimizations based on the target JS engine and version, as a build step. I don't think we need to go to a completely different source language and a compilation to WASM in order to get permission to create such an optimization tool.

Such a tool would give you the benefits you're praising about the WASM compilation workflow: Separately maintained, engine-specific optimizations that can be applied at build-time and don't mess up the maintainability of your source code.

<comment><USER14> JS engines already do insane levels of optimization, and they do it while watching the code execute so they understand the code better than any preprocessing tool can hope to.

What could a tool like you're describing do that the engines don't do themselves?

<comment><USER15> I assume that JITs don't do very expensive optimizations because they have to do a trade off between execution speed and compilation time. JITs are also fairly blind on the first execution of a piece of code. Static optimizations are not made obsolete by the existence of JITs.

<comment><USER14> Expensive optimizations like what? Can you give a before/after example of something such a tool might do?

(Note: I'm glossing over the case where one is using bleeding-edge syntax that a JS engine doesn't yet know how to optimize. In that case preprocessing out the new syntax is of course very useful, but I don't think this is the kind of optimization the GP comment was talking about.)

<comment><USER13> JIT engines usually don't do static analysis. I'm not sure if that is because the cost for that is that much higher, but a hint towards why could be that the engine simply does not know which parts of the (potentially huge amounts of) code that was loaded is actually going to be needed during execution, so analysing all of it is likely to bring more harm than gain.

As an example for something that static analysis could have caught, take the example from the article about the "Argument Adaptation"[0]. Here the author uses profiling to learn that by matching the exact argument count for calling a function, instead of relying on the JS engine to "fix that", the performance can be improved by 14% for this particular piece of code. Static analysis could have easily caught and fixed that, essentially performing a small code refactoring automatically just like the author here did manually.

[0] [http://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust- to-...](http://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up- your-js.html#optimizing-sorting---argument-adaptation)

<comment><USER14> I replied in main to your other comment, but regarding the "Argument Adaptation" issue it's maybe worth noting that I'm 90% sure V8 would have optimized this automatically if not for the subsequent issue (with monomorphism). I'm dubious that the former issue could be statically fixed as easily as you suggest, but either way I think it should be considered a symptom of the latter issue.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> This is a great article and goes to show that statements like "X language is fast" are a little blurry when you put the language in the hands of a skilled developer, who can go beyond the standard idioms and surface level understanding of a language to use it like it's another language.

At the end of the article, the author wisely chooses to move some objects out of the control of the GC:

 _We are allocating hundreds of thousands Mapping objects, which puts considerable pressure on GC - in reality we don't really need those objects to be objects... First of all, I changed Mapping from a normal object into a wrapper that points into a gigantic typed array..._

This suggests to me that we are no longer programming the way one usually does in a dynamically typed, garbage collected language -- and thus it might still be the right decision to move to something like Rust (or Swift or Go) where there is considerably more control over allocation.

The author is able to achieve a speed-up of ~4x which is close to the 5.89x achieved by the Rust implementation. There are benefits to having all ones code in the same language; but there are also benefits to switching languages to obtain better ergonomics and safety properties.

<comment><USER17> > The author is able to achieve a speed-up of ~4x which is close to the 5.89x > achieved by the Rust implementation.

This is not a fair comparison because the author made algorithmic improvements that would also improve the wasm version if applied to the Rust code. Source: [https://twitter.com/mraleph/status/965616993310265344](https://twitter.com/mraleph/status/965616993310265344)

<comment><USER3> FWIW, quick look at Rust code actually reveals that that implementation is also different algorithmically from what I was optimizing, e.g. it only sorts generatedMappings array.

In reality it means that performance of my code should not be that far from what WASM is showing because sorting of originalMappings (which I do eagerly and WASM version does lazily) is one third to one half of the overall runtime.

I will try to measure and update the post tomorrow or Wednesday.

</comment></comment></comment><comment><USER18> I wonder if the performance gain is worth the effort. Surely you can always squeeze more performance from JS like from any other language but what's the point if you spend hours to match the performance you get for "free" from other languages?

As far as WASM is concerned I'm more excited about the possibility to run any programming language on the web than the raw performance gains. So far it is still year(s) away from this goal(i.e. lack of web APIs/DOM access makes it useless for web dev).

<comment><USER19> > hours to match the performance you get for "free" from other languages?

In a sense, you pay those hours that you saved up by using an easier, more intuitive language like JS. Or you can choose not to and still have pretty good performance and blazing fast dev cycles.

<comment><USER20> I believe there are other languages easier and more intuitive than JS. The lack of DOM and GC support in WASM is the only reason JS is still ruling the web.

As far as the performance is concerned I believe profilling the internals of the VM(as the author does) is not a good fix on the long term.

<comment><USER21> I agree regarding JS not being the easiest or most intuitive language, but I don't see JS going away any time soon and I don't think that's a bad thing. The last 5 years or so have seen JS transform from one of the most frustrating languages to one of the better ones. I think Typescript is where the future of web dev lies. Typescript for your main logic and WASM for optimising the parts that need it.

<comment><USER20> Yeah, JS is better now but I bet we could do even better starting with a clean slate. Web dev shouldn't be tied to a single programming language. How would you like using PHP and its derivates(i.e. Hack) for everything web APIs/back- end? I could tell you that it made great progress since PHP 4.

<comment><USER21> Oh I'm sure we can do better. Would it be worth throwing away decades of libraries, many of which have ironed out many subtle logic bugs over time? That's a different argument. Not going to say it's not worth it (there is a lot of mess that could be removed if we started from scratch).

It's the same argument any junior engineer makes when they start at a company with a legacy codebase. They always want to start from scratch but don't realise the cost or the fact that while they'll avoid 100 mistakes of the past, they'll also make 100 new ones. Why not just make JS better? It's already happening year by year.

</comment></comment></comment></comment></comment></comment><comment><USER22> I'm excited about compiling to WASM not for performance but for correctness. Typescript is better than nothing but it really can't compete with the safety and ease you get from a language with a really good type system.

<comment><USER23> One thing I've been confused with about transpiled languages is how does correctness transfer? How do types or lifetimes etc. transfer to WASM, for instance? Or does it just depend on the correctness to be verified in the pre- compilation/transpilation stages?

<comment><USER24> Correctness is typically checked long before code generation happens. This does mean the code generation backend must be trusted, whether the target be x86 or wasm. Just as you have to trust CPUs to not expose processes' memory to each other (oops).

<comment><USER25> Typed assembly is a thing - it's mainly to ensure the compiler itself is correct, but it does give stronger guarantees. I think Frank Pfenning at CMU has written a language that's dependently typed all the way down - so it's IR and assembly are both dependently typed.

</comment></comment></comment></comment><comment><USER26> So...

I'm a (junior/so-so) react dev. I like the language, I probably could get better at it but I've gotten to the point where I like the sound of my own music.

That said, my question is the following. There seems to be a lot of resources on the web of the type "Hey Rust and WASM is a thing! You can make webpages with it". Ok, fine. However, I don't see a lot of the things that are in libraries like Vue and React that offer me SPA, fast development time and component (OR!) functional pattern design (I won't mention the ability to add npm packages, because yeah, Rust/WASM doesn't have an ecosystem yet, so that might be punching a bit below the belt). Is there anyone out there making a React like or "eco-system builder"-esque platform that would give me a lot of the benefits I'm seeing with React but with increased performance?

Also, I've done some low level programming before and think that Rust is very cool for that (yay memory safety! yay error messaging (no _seriously_ yay)!). However, and I may be betraying my ignorance here, if I want to animate a div to fly across the page, am I going to have to write _lots_ of low level code to do that? If that's the case, and development time suffers to eek out that extra bit of performance, I can't see this as having much utility outside of niche fields like game development.

I don't mean to be overly critical mind as I'm still (and probably will always be) a bit of a n00b. I'd love it if somebody would point me at some resources that I could burn a weekend on, if I thought the juice was worth the squeeze. I'm just not sure I know enough to know if this is something that I could be productive in (some day).

<comment><USER27> > "Hey Rust and WASM is a thing! You can make webpages with it". Ok, fine.

It is very early days. More to come...

> However, I don't see a lot of the things that are in libraries like Vue and > React

Yes. There's not too many of these yet; there are some though. For example, [https://github.com/DenisKolodin/yew](https://github.com/DenisKolodin/yew)

There's also the inverse: can we re-write parts of libraries like Vue or React in something that compiles to wasm, so that you get better performance as the user? I know of at least one major SPA framework that's doing this. Don't want to spill the beans too much, even though it is technically public knowledge.

That said, that's how I think wasm will impact the lives of most JS programmers: as technology that underpins the libraries they use to make them better. Unless you want to, or unless you want to write a high-performance library, I wouldn't expect wasm to really change the way most JS programmers operate. It's abut augmenting JS, not replacing it.

> if I want to animate a div to fly across the page, am I going to have to > write lots of low level code to do that?

That depends entirely on the library!

> I'd love it if somebody would point me at some resources that I could burn a > weekend on

They're sorta scattered all over the place right now. Such is life for early adopters. More will come as stuff matures. Don't under-estimate how much this will change as the tooling gets built out, for example.

<comment><USER28> > Can we re-write parts of libraries like Vue or React in something that > compiles to wasm, so that you get better performance as the user?

For React, we would love to do this although it's not clear what parts of React would benefit from being moved to wasm right now.

<comment><USER27> Yeah, that's what I've been hearing through the grapevine. We'll see! I'd love to see it.

<comment><USER28> Call us up if you have any advice!

</comment></comment></comment></comment></comment><comment><USER29> I thought all the benchmarks indicated that WASM is still slower than JS. That being said the only performance improvements offered by WASM is if it doesn't for garbage collection for consistence execution.

WASM isn't about performance. It is about writing applications in any language and importing those applications into an island in a web page.

<comment><USER30> > WASM isn't about performance. It is about writing applications in any > language and importing those applications into an island in a web page.

You don't really need wasm for that, do you? Anything compiles to JS nowadays and you'd actually get easier access to the DOM and GC and support for source maps (are those working for wasm yet?)

<comment><USER29> Flash has always been better for media and games than JavaScript. WASM fills that niche.

</comment></comment></comment><comment><USER31> So much work to achieve what should be default behavior :-/

How did we end up in wasting so much time on trivialities?

<comment><USER32> When JS came out, it was poorly designed, but nobody cared because we used it only to make snowflakes appear on the web page.

Then MS gave us AJAX and 37 signals made it popular, until apps like gmail made it so mainstream it was impossible to go back to old static pages.

But it was too late. The shitty language we had was the only one available everywhere to do dynamic web pages now.

IE would not move, and Firefox and Opera were the underdog, spending their resources on more important things. So nobody tried to implement a better existing language.

When Google faced the challenge of creating chrome, they had to be compatible. So instead of implementing a better language, they also used JS, and injected millions of dollars into making the V8 so it has decent performances.

After that, JS was usable, and so we moved on.

<comment><USER33> > So instead of implementing a better language, they also used JS

They did implement a better language, Dart. But it was too late, like you said. Maybe we'll have a change of using it for mobile apps with Flutter.

<comment><USER32> Dart came way, way later. And it was a new language, while they could have just used an existing one. They could have implemented lua, ruby, Python, anything with a good track record. With the millions spent on V8 with those geniuses working on it, can you imagine how fast one of those language would have become ? The tooling it would have had ?

<comment><USER34> Actually, Google tried to make Python faster, with Unladden Swallow project.

They failed miserably.

And several other projects failed miserably at the same thing as well.

Either way, speed was not the main reason they created Dart.

Dart was designed for writing large web apps.

Dart's top design constraints was good interop with JavaScript meaning transpilation of Dart to decent JavaScript and consumption of existing JavaScript libraries from Dart.

I repeat: top design goal.

You can't take a language (be it Python, Ruby or Lua) that was not design with that constraint in mind and magically make it work.

There are transpilers from those languages to JavaScript but they are toys.

You just can't reconcile Python semantics with JavaScript semantics in a reasonable way.

So they did the next best thing: they designed a better Java/C# while keeping JavaScript interop as a priority.

Now Dart is morphing because the top design goal is to make it the best language for cross-platform mobile (i.e. iOS and Android) apps, which requires different trade-offs.

<comment><USER32> Pypy is proof that you can speed up Python considerably. And it's written in Python. Imagine what could be achieve if one would write something like that in, say, Rust ?

My guess is that they didn't invest anywhere near the resources on unladden shallow (which was probably a side project) than they invested on chrome vm (which was a core project).

Actually, I spend quite a lot of time on the Python mailling list, and here you can see they regularly find things to improve, perf wise. They just have terribly low resources.

I've rarely seen a project as popular as Python, used by so many rich huge corporation, which such little resources actually. It's heart breaking.

</comment></comment></comment></comment></comment></comment><comment><USER35> This is a well written article, and I absolutely agree with the idea that profiling and analysis is more important than language choice in order to eke out performance wins.

That being said, some of these optimization techniques completely took me by surprise. Defining the sort function as a cache lookup that converts the sorting template to a string and then builds an anonymous function out of that string which is finally used as the exported function seems, to me, like an extremely roundabout way to achieve inlining the comparator. And the argument- count adapter having such high overhead on V8 seems like something that should generate a warning for the developer.

The cache analysis and algorithmic improvements seemed fairly straight forward, but when you're at the point of having to manually implement memory buffers to alleviate GC pressure, you're diving below the level of abstraction that the language itself provides you. At that point, I think the argument to switch to a language designed to operate at that level of abstraction holds some sway.

</comment><comment><USER36> What a well-designed and well-researched article!

</comment><comment><USER37> We should be more wary about premature optimizations, like in the article where caching in the original code made it slower! Always measure! Write _naive_ code and measure, the JavaScript engines are very good at optimization, especially V8 and the others are catching up.

However when I do optimize JavaScript code I often get 10-100x performance. Usually by writing _better algorithms_. Eg no "black magic". So the original code in the article is not that bad, considering he "only" got 4x performance.

Moving to another programming language / WASM for less then 2x performance _is not worth it_ \- unless you hate JavaScript.

<comment><USER38> > like in the article where caching in the original code made it slower!

Caching could have been originally faster, but became slower thanks to the continual improvement of the Javascript VMs.

</comment></comment><comment><USER4> Tangent: I see that the author focused on improving sorting algorithms, and also at some point switches to a Uint8Array (although not in the sorting part).

I recently discovered that a JavaScript implementation of radix sort up to four times faster than the the built-in sorting algorithms for TypedArrays[0][1][2]. Imagine how much faster a good WASM implementation could be!

It also makes me wonder why browsers don't make use of the guaranteed memory layout of typed arrays to use faster native algorithms. Sure, Typed Arrays have to support the sorting API, which is comparison based and works with closures. But why not detect when someone calls sort() without any further arguments, and make that very common case use faster native code?

Because for me, this difference in performance made a difference: I am animating plots where I need to sort more than 100k elements each frame, and sort eating up 5ms or 20ms is the difference between choppy and smooth animations.

[0] [https://run.perf.zone/view/radix-sort-uint32-1000-items- type...](https://run.perf.zone/view/radix-sort-uint32-1000-items-typed-and- plain-array-1510082514775)

[1] [https://run.perf.zone/view/radix-sort- uint32-1000000-items-t...](https://run.perf.zone/view/radix-sort- uint32-1000000-items-typed-and-plain-array-1510082642142)

[2] [https://run.perf.zone/view/Radix-sort-Uint8Array-loop-vs- fil...](https://run.perf.zone/view/Radix-sort-Uint8Array-loop-vs-fill-in- place-1510007933053)

<comment><USER39> On my OnePlus 5T the standard sort() was twice as fast as the radix sort for the UInt8 array, but it was only 30% slower for the Float64 and regular arrays, whereas sort() was hundreds of times slower - strange...

</comment></comment><comment><USER40> This is a broad, naive question, but the number of responses and upvotes on this post suggest to me that many people actually _need_ to speed up their JS. I've never once come across this problem in web app development. The bottleneck is always DOM rendering like layout changes, networking, handling large WebGL vertex buffers for video games, etc. In which use cases is JS performance significant?

<comment><USER41> In this case, the sourcemaps library isn't normally running as part of user application code. It's primarily used by the browser's DevTools, and server- side build tools like Webpack and Gulp.

The faster sourcemaps can be parsed and manipulated, the faster the DevTools and build tools will execute.

</comment></comment><comment><USER42> I rely heavily on a decent JS performance baseline for [http://8bitworkshop.com/](http://8bitworkshop.com/), and I also rely on asm.js / WASM. But I need different things from them.

For JS, I need consistency and stability, because I'm dynamically generating code. Usually I'm pretty satisfied, but sometimes after recompiling code I get a huge performance hit for no reason.

For WASM, I know I have stability, but I need faster load times. On my Chromebook, for example, it takes 10-20 seconds just to load the WebAssembly. If this problem is solved, I might move everything performance-sensitive over to WASM eventually.

</comment><comment><USER43> Awesome. I think it makes a lot of sense to explore new algorithmic approaches before choosing to reimplement in a new language - and thankfully these are not mutually exclusive.

To those saying "these are implementation defined optimizations" etc - you do the same exact thing in rust. I know some rust code is 'fast' and some is 'slow' and I have to understand rust and to some extent the state of llvm + rust. This is simply part of writing fast code, no matter the platform or language.

Nice writeup!

</comment><comment><USER44> I'm continually surprised by the Rust -> WASM pressure. I see projects like Redox and Servo and ripgrep and Tokio and, well, native or systems level things being it's true calling.

I don't want to write a webapp in Rust. It'll always be second class (though maybe that won't be a problem if the WASM apis get good enough...).

<comment><USER27> Think of it this way: wasm is pretty similar in many ways to an embedded platform. Rust wants to be good at embedded, so making Rust good at wasm fits. A lot of the work is identical.

<comment><USER44> I think that is a very post-hoc rationalization to justify the silliness that is/has been eating the JS world (emscripten and asm.js show that this sort of thing has been going on for a while), but is an entirely valid reason to indulge it for free interest and experience.

+1

<comment><USER27> I don't think it's a reason that wasm exists, but I do think it's one of the (multiple) reasons for us to invest in making Rust -> wasm an excellent experience.

</comment></comment></comment></comment><comment><USER45> Maybe there should be a tool from linters or VMs to warn against arguments adaptation, monomorphisation. For the rest it is a lot of know how is JS that is for free in with more performance minded languages. At the end with the optimized JS is is 4 times faster, but still 6 times faster in WASM it seems.

<comment><USER46> It's only necessary in edge cases of super-hot code, avoiding argument adaptation "because performance" is a bad idea.

It's also a v8 specific weakness, it's not hard to imagine a small fix getting rid of the performance penalty.

<comment><USER34> Given that this contrasts a JavaScript implementation with Rust implementation compiled to WASM: my 5 minute investigation shows that Rust doesn't have optional arguments at all.

So in Rust you would be forced to write it the way you consider to be "bad idea".

Many people think that default function arguments are a bad idea and languages like Rust or C or Go or Java don't even have them.

<comment><USER47> you get creative, passing map, passing Option. it's very trivial to do.

</comment></comment></comment></comment><comment><USER48> Next steps: leverage web workers and GLSL?

</comment><comment><USER49> Irrelevant and maybe a bit small-minded, but the font of the article is too squished to be pleasantly readable.

<comment><USER3> Not irrelevant. Question for you, is this more legible:

[https://twitter.com/mraleph/status/965686742614462466](https://twitter.com/mraleph/status/965686742614462466)

I can update CSS if that helps.

UPD. Updated CSS to use non monospace fonts for the body.

<comment><USER49> This is better by far. I'd be interested if there's a better combination of code + paragraph font, but otherwise the only other minor adjustment I'd make is increasing the padding / margins between text and code.

Thanks for taking criticism in a healthy way.

</comment></comment></comment><comment><USER50> For writing high-performance JavaScript, I'm really hoping that AssemblyScript takes off[1]. The project is still a bit in early stages, but theoretically, it can have the same role as Cython: you write JS/TS code, find the slow parts, and get perf improvements by adding stricter types to your code and changing your code to not use dynamic JS features. You can stay pretty much in JS rather than having to switch to a completely new language to get predictable fast performance.

[1] [https://github.com/AssemblyScript/assemblyscript](https://github.com/AssemblyScript/assemblyscript)

</comment><comment><USER51> For me the purpose of wasm would not be just performance, but to let me avoid javascript entirely.

Javascript is already very fast, but compiling to javascript feels awkward.

<comment><USER3> I don't think you can avoid JavaScript even with WASM - and WASM in it's current form is, for some languages, a worse compilation target than JavaScript.

<comment><USER51> Well sure it doesn't support the DOM yet, but I think the design goal of WASM is to do just that.

Since the beginning of computers, it should be trivial to distribute programs online efficiently.

The web is already platform dependent, but it also need to be fast and language independent.

</comment></comment></comment><comment><USER52> I can't see any numbers comparing the rust implementation and the optimised javascript. Did I miss them in the article?

<comment><USER27> A comment upthread did the math:

> The author is able to achieve a speed-up of ~4x which is close to the 5.89x > achieved by the Rust implementation.

<comment><USER3> The math is not that obvious because Rust implementation does not match 1-1 what baseline JS version was doing (e.g. it sorts only generatedMappings and not originalMappings).

I will do measurements later to compare and update the post.

<comment><USER27> Sounds good!

I enjoyed the article :)

</comment></comment></comment></comment><comment><USER53> It's not just speedup it's also about writing backend and front-end in one language. But the speedup is real too.

</comment><comment><USER10> I'm confused as to why people think this isn't generally applicable to JS here.

Very few of these changes are VM specific or likely to change (or any more so than WASM implementations)

\- choose your algorithm carefully \- make sure you're paying attention to the data you're applying the algorithm to is a good fit \- pay attention to arity & GC pressure.

None of these are hard to do in JS & most of the VM debugging was to help identify problems in _existing_ unoptimized code.

The rest are lessons you can take into ANY JS data processing.

</comment><comment><USER54> Source maps are a debug tool. Why does the performance matter?

(And if you're shipping so much JavaScript to your site users that you need to "minify", maybe you're doing it wrong.)

<comment><USER55> Tools like Sentry parse them, and need consistent fast performance in this area. Other debugging tools use them.

Your statement in brackets seems very "those damn kids"-ish. You need to "minify" your JS files even if you're shipping a small amount of JS, because loading performance matters and JS minifies very well.

<comment><USER56> Browsers also use them do display "expanded" code in the console and debugger.</comment></comment></comment>


Kernel Address Space Isolation to Prevent Data Leak from Hyper Threading Attacks - <AUTHOR> https://www.phoronix.com/scan.php?page=news_item&px=Kernel-Address-Space-Isolation <comment><USER2> Is the next step going to be bringing back motherboards with 16 or 32 ram sockets so that each processor thread can have it's own bank of RAM to play with?

I'm not sure that'd be a bad thing really, but the DRC of that many high speed signals would probably be a nightmare.</comment>


Linux System Monitoring Tools - <AUTHOR> http://www.cyberciti.biz/tips/top-linux-monitoring-tools.html

<comment><USER2> Another major player I find the list missing is collectd and the plethora of various other RRD tools (even though Cacti and Nagios are there). But to be fair, his list seems ore of 'current snapshot' stats instead of logging and monitoring over long periods of times.

<comment><USER3> My collectd daemon on Ubuntu 8.04 dies almost once every two days -- anyone experiences the same (and happens to have a fix)?

<comment><USER2> Odd, it's running on all my servers for months straight. Could be a million possibilities, check the collectd log. If nothing, run it in non-daemon mode and have it write everything to a file manually.</comment></comment></comment>


Sinatra clone in Scala - <AUTHOR> http://github.com/alandipert/step/tree/master

<comment><USER2> Is the whole thing really just the one file (110 lines)? [http://github.com/alandipert/step/blob/42cee9ecd360205def359...](http://github.com/alandipert/step/blob/42cee9ecd360205def359ce2719f34120edee499/src/main/scala/Step.scala) I know it describes itself as "tiny", and sinatra is also tiny, but that seems... small. (I don't know anything about Scala - is it especially concise?)

I like how the HTML seems to be a first-class datatype in the example (is that a Scala thing? I'd better do some research):

        get("/date/:year/:month/:day") {

Year: {params("year")}

Month: {params("month")}

Day: {params("day")}

      }

<comment><AUTHOR> Yeah it's pretty small. With Scala you basically get free HTML templating because of XML literal support. It's missing a lot of Sinatra stuff though: 'splat' and regex URI pattern matching, file uploads, sessions...

<comment><USER3> Maybe leveraging pattern matching could improve.

Actually - we can be able to implement our own methods get(), post(), etc. via pattern matching... So inspiring - on my way to fork it. ;)

</comment></comment></comment><comment><USER4> Awesome. I actually fired up Sinatra on JRuby for a micro-app that needs to talk to some Java stuff last week. All of the existing stuff in Scala was way too heavy for the purpose. (Clojure/compojure has comparable overhead to Sinatra assuming you're familiar with Clojure, but it was untenable in this particular circumstance.)

At least half the magic of Sinatra is that you can write a single Ruby script, exec it and not have to fool around with build/generate/scaffold script or web server configuration to get something useful. It seems like you're pretty close, given that Java has no standard dependency retrieval system.

</comment><comment><USER5> Amazing conciseness. Don't forget to check out lift web framework <http://liftweb.net/>. It's written in Scala too and uses similar techniques.

</comment><comment><USER6> Very cool. I notice that you're using sbt to build. I'm using maven to build a scala project. I'd be very interested to know how sbt compares to maven if you have experience with both build systems.

<comment><AUTHOR> I haven't used maven (the first version of this thing used ant+ivy), but it was pretty messy compared to what I have going now. I'd say if you have the luxury of working with a Scala-only project, sbt is definitely the way to go.

</comment></comment><comment><USER7> It looks like there is no separation between view and controller. Mixing HTML into your controller methods seems like a step backwards.

<comment><USER8> If this is a port of Sinatra that is an option to make a very small concise webservice. You can choose to do seperation, but if you want something very simple and compact a single file can be easier. We have a Sinatra app that has the model,view,controller, and tests in a single file that is less than 250 LOC. It would be more obfuscated to have 5 files of less than 50 LOC each (Some with as little as 4 lines).

If it doesn't provide any option for separation that is bad, but for micro services it can be really nice.

<comment><AUTHOR> For sure. I'm just using XML literals in the example because it looks cool. But I'm also using this for a client job, and it's producing JSON.

It's not nearly as powerful as the real Sinatra, but it saves me the shenanigans of warbling Sinatra apps for servlet deployment.</comment></comment></comment>


Frequently Forgotten Fundamental Facts about Software Engineering - <AUTHOR> http://www.computer.org/portal/web/buildyourcareer/fa035?utm_source=bronto&utm_medium=email&utm_term=Forgotten+Facts+About+Software+Engineering&utm_content=andrew%40badera.us&utm_campaign=BYC-Issue+38-December+3 <comment><USER2> Robert Glass writes consistently interesting stuff, and this was no exception.

I wish he had a higher profile (similar, say, to Spolsky and Atwood, for example)....

<comment><USER3> Most of his stuff is excellent. ComputingFailure.com is a rip-off. It is a compilation of articles (not by Glass), mostly very shallow from newspapers about dot-com business failures, the only thing about computers in the book is that the businesses used them.

</comment></comment><comment><USER4> This article is really crying out for footnotes. It cites a lot of studies and facts, but provides no references at all.

<comment><USER5> InclinedPlane's comment already says it, but I think it's worth putting more strongly. The OP is nothing but a synopsis of Glass' book _Facts and Fallcies of Software Engineering_ , which is remarkable precisely for the fact that it _does_ provide supporting references for every one of its claims. Glass' meticulousness in this respect is nearly unique in the space (Steve Mcconnell also comes to mind) and he deserves to be better known for it.

That being said, the effect of all those references (on me anyway) was more to highlight the weakness of the research literature than to make a convincing case. But that's not Glass' fault. He does a great job of reporting what the literature says.

</comment></comment><comment><USER6> From now on I'll show this:

 _RES1. Many software researchers advocate rather than investigate. As a result, (a) some advocated concepts are worth less than their advocates believe and (b) there is a shortage of evaluative research to help determine the actual value of new tools and techniques_

to a researcher friend of mine every time he advocates the use of Lisp in commercial projects claiming that such a great language will just inevitably bring more productivity to the team in comparison with such a poor language like Java (or any other Blub.)

<comment><USER7> There have been a few studies (too few, to back up your point) of actual software productivity. And I am one of the guilty ones (not that I am a researcher--I am a practitioner). One that I recall says that there is more variance by programmer than by language.

And look at who ycombinator chooses--it is more about the people than anything else.

</comment></comment><comment><USER8> Wow. I feel like I need to go smoke a cigarette after reading that list. I also want to print off 10,000 copies and throw them like confetti around several of my previous jobs.

"in a room full of expert software designers, if any two agree, that's a majority!"

</comment><comment><USER9> _"P2. Good programmers are up to 30 times better than mediocre programmers, according to "individual differences" research. Given that their pay is never commensurate, they are the biggest bargains in the software field."_

P3. Good programmers are defined as those programmers that produce good products. If you focus only on coding speed or analytical skill, you may miss out on the best programmers.

P4. If you are paying your good programmer less than you know s/he is worth, count on them leaving soon. You will deserve the loss.

<comment><USER10> "Good programmers are up to 30 times better than mediocre programmers, according to "individual differences" research. Given that their pay is never commensurate ..."

Why is this a given? What are the forces which prevent the pay getting commensurate with ability? Is this unique to programming profession, or is this widely observed in other fields too?

<comment><AUTHOR> How many run of the mill $50k average-or-less developers or programmers do you know?

Now, how many $500,000 programmers do you know? Outside finserv quants & algos, not many. But THEY can make millions and tens of millions.

Unfortunately our industry tends to grant incremental compensation increases against geometric performance & value increases. Which is true in a lot of engineering fields. And the same can probably be said in design fields as well.

</comment></comment></comment><comment><USER11> I'd like to highlight this particular gem:

 _RE4. Even if 100-percent test coverage (see RE3) were possible, that criteria would be insufficient for testing. Roughly 35 percent of software defects emerge from missing logic paths, and another 40 percent are from the execution of a unique combination of logic paths. They will not be caught by 100-percent coverage (100-percent coverage can, therefore, potentially detect only about 25 percent of the errors!)._

Given the fanaticism for TDD today, this is a fact well worth remembering.

<comment><USER12> TDD is not about finding defects, its about minimizing work (you code to pass tests and no more - as a side effect, you should always have 100% coverage) and about preventing working code from being broken through bug fixes, refactoring, or extension because your existing tests will then fail. Its a guarantee that _what works now will still work later - or the test will fail_ , not _the test will find bugs_.

<comment><USER13> I wish all TDD proponents understood this. Coverage != Tested. 100% coverage does not mean you have have exercised all possible execution paths through the code.

Also, passing all tests does not mean there are no bugs. Assuming you have tests for all your requirements, passing the tests means only that software can perform those requirements. It does not mean that it will be bug-free, especially if the users try to do things the requirements didn't anticipate.

TDD has the great benefits you mention but it is not the magic bullet so many of its advocates make it out to be.

<comment><USER14> Yes. Neither is having a versioning system a magic bullet. Both can still be good ideas.

</comment></comment></comment></comment><comment><USER15> I agree with the general thrust, but can we avoid pseudo-numeric language, like "for every 10% increase in $NEBULOUS_THING_PROGRAMMERS_FIND_ANNOYING, $HARD_COST_NUMBER goes up by 100%". Really, we can do better.

There was an article about this on HN a while back, but I can't find it right now.

</comment><comment><USER7> He gives a summary here of good points. He has often given very practical advice about software engineering.

However, a minor quibble: _REU2. Reuse-in-the-large (components) remains largely unsolved, even though everyone agrees it is important and desirable._ Not everyone agrees about reuse-in-the-large as being desirable. In Coders At Work, Knuth goes so far as to suggest taking apart other "reusable" libraries and rewriting them. Rumbaugh (of the Three Amigos) has said that reuse-in-the- large is overrated as a goal.

<comment><USER15> We do have reuse in the large. The components are just so familiar we rarely even notice them. Web servers are an example.

</comment></comment><comment><USER16> The estimation section really hit home for me.

It seems like the harder we try to improve estimate accuracy the worse it gets. Are there any great examples of successful software estimation?

<comment><USER17> I found this book to be really helpful in learning different approaches to estimation at different points in the project.

[http://www.amazon.com/Software-Estimation-Demystifying- Pract...](http://www.amazon.com/Software-Estimation-Demystifying-Practices- Microsoft/dp/0735605351)

</comment></comment><comment><USER18> Yep, I'm only going to pay attention to the ACM's stuff rather than IEEE. Look at the obsession with percentages and pseudo-mathematical formulas like this: "User satisfaction = quality product + meets requirements + delivered when needed + appropriate cost."

<comment><USER19> It's less offensive if you just read it as

> User satisfaction is related to a combination of quality product, meet[ing] > requirements, delivered when needed, and appropriate cost.

A lot of code I have seen has weaker mathematical roots, so I got no problem with him stating it how he did.

</comment></comment><comment><USER20> You gotta love forced alliteration!

<comment><USER20> I get my first 0-point comment in nearly 2 years for that? You really think "frequently forgotten fundamental facts" was unintentional/necessary? It could have just as easily been:

      Overlooked truisms
      Oft-forgotten truths
      Commonly forgotten fundamentals

"Fundamental facts" is a stupid phrase anyways since "fundamentals" is basically the same thing.

This was obviously a case where the author was thinking, _Ooh, I will look clever and poetic by starting off my blog post with a pointless tongue twister._

</comment></comment><comment><USER21> "I don't expect you to agree with all these facts; "

Well, not unless you provide links to references.

In fact, here's one fact that was left out: merely asserting something in a technical article does not make it a fact. It's opinion until you back it up with data.</comment>


Snapchat COO Emily White to Depart - <AUTHOR> http://recode.net/2015/03/13/exclusive-snapchat-coo-emily-white-to-depart-ephemeral-messaging-phenom/ <comment><AUTHOR> Does someone know what is going on at this place?</comment>


James Hague - <AUTHOR> http://debuggers.co/c/games/2014/07/01/James-Hague.html

<comment><USER2> I read the original erroneous code, the mistake and attempted to write a correct solution. I ended up with '(2048 - (size % 2048)) + size', the same expression as the original :/.

Us humans just don't do well with edge cases in ranges/bounds. Another seemingly simple task which is easy to trip over is : determining if a time interval overlaps another.

<comment><USER3> His corrected version

      padded_size := (size + 2047) & ~2047

may be correct or it may not be, I can't really tell quickly because it's so oblique to me. Combining decimal and binary arithmetic like that is a bit too old school for me -- of course I still use it on occasion but I try to avoid it. I guess it's second nature to game devs.

What's wrong with

      padded_size := ceil(size / 2048) * 2048

apart from the fact that it's much much slower but still really really fast in what I can only assume is a part of the source where performance doesn't matter, anyway.

<comment><USER4>
       padded_size := ceil(size / 2048) * 2048

... may be wrong if size is large that can't be store in mantissa of double/float.

Assuming C (or equivalent), I usually do this:

        padded_size = ((size + 2047) / 2048) * 2048;

<comment><USER5> this is generic. You can also take into account that 2048 is a power of 2. So you can shift right and then left again.

<comment><USER4> All relevant compilers do that automatically.

</comment></comment></comment></comment></comment><comment><USER6> I work on protocol engineering and one of the protocols I support requires fields to be padded at 4-byte word boundaries. The code I inherited uses a grungy macro to solve this problem:

#define WORD_ALIGN_LEN(l) (l % 4 ? (((l/4)*4) + 4) : l)

So for all you complaining about his solution being difficult to mentally parse: it could be worse.

(Our code will divide by 4 and then multiply by 4, truncating the remainder, and then add 4. So if we're sending 6 bytes, we'll divide by 4 to get 1, multiply to get 4, then add 4 to get 8.)

</comment><comment><USER7> This was a classic that I ran across: [http://blog.jgc.org/2009/01/single- line-assignment-filled-wi...](http://blog.jgc.org/2009/01/single-line- assignment-filled-with-epic.html)

</comment><comment><USER8> Code should be written for humans and compiler should optimize the algorithm. If the compiler can't optimize properly then I think one should still write the original algorithm into an adjacent comment.

So I would've rather written:

      int padded_size(int size)
        int remainder = (size % 2048);
        bool needsPadding = (remainder > 0);
        if (!needsPadding) {
          return size;
        }
        return size + (2048 - remainder);
      }

<comment><USER9> Really? This is like using addition in a loop to multiply numbers, I'd say. Nothing wrong with the result, it's just a weird, roundabout way of doing it.

Do (size+2047)/2048*2048 if you really can't stand the bitwise operations, though in most cases the fact it's a power of two is important and avoiding bitwise operations obscures that.

<comment><USER10> I consider (size+2047)/2048*2048 to be an optimization. If I was to explain the process to another person, I would use the algorithm I wrote above; I would literally say, "If size is already a multiple of 2048, just use that, otherwise, add on enough to make it a multiple of 2048."</comment></comment></comment>


Sony CEO Accidentally Reveals Secret Details About iPhone 5 - <AUTHOR> http://mashable.com/2011/04/02/stringer-iphone-5/

<comment><USER2> Why is it newsworthy that the iPhone 5 will have a camera?

<comment><USER3> It isn't. It's newsworthy that the iPhone 5 will have an 8Mpixel camera. Why? People love to gossip about secrets.

<comment><USER4> The article never says that the Sony CEO mentioned the 8 megapixel part. As far as I can tell, that's still just speculation.

</comment></comment></comment><comment><USER5> Anyone want to bet that the iPhone 5 ends up not having a Sony camera in it? This reminds me of the CEO of the publishing company that blurted out about the iPad days before it was going to be released.

<comment><USER6> Maybe Stringer doesn't really want to sell Apple these parts and is hoping Apple will switch manufacturers.

They probably didn't refuse right away to protect Sony's reputation as a supplier to other companies. The OEM and components market seems very politicized.

</comment></comment><comment><USER7> The problem I have with this idea is that Apple made such a big deal last year about the fact that the camera on the iPhone 4 was backlit. Presumably, the company making those image sensors patented the technology, and wouldn't license it to SONY. So won't the camera be a step back for Apple? It would probably be wiser if they kept the camera they use now,(after all, they used that cheesy 2MP in the original as well as the 3G) and update once the factories are back online?

<comment><USER8> Everyone is doing backlit CMOS sensors these days. More importantly, Sony invented the technique in the first place. Thus, it is pretty likely that if Sony is doing the camera in the iPhone 5 it is still backlit.

</comment></comment><comment><USER9> The link to the iPhone5 seems pretty tenuous to me. Apple has cameras in virtually all of its desktop, notebook, palmtop and tablet range.</comment>


Introducing Fowndr: A private network for startup founders (invites) - <AUTHOR> http://stugreen.com/blog/2011/03/introducing-fowndr <comment><USER3> I hope, for your sakes, this isn't your business but just a side project. There are several reasons why I say this:

1\. The name "fowndr" makes you look cheap. Why? Because the domain name was no doubt unregistered. Basically it looks like you went looking for a domain name that you could get for $10 for a year;

2\. What defines a founder? As HN bears witness, anyone with a weekend to spare on a pet project can (and do) declare themselves a founder, some rightly, many not. But with the barrier to entry for starting an Internet business being practically zero, "founder" doesn't really mean all that much.

3\. What value proposition are you providing founders? YC provides benefit by the connections, the social proofing and mentoring of PG & co and the brand, which has come to mean quite a lot. Quora seems to be the place to go for the Valley insiders to talk to each other.

The motivation behind invite-only seems to be to create this air of exclusivity, like a private club. Creating that pedigree such that people will want to be a part of your exclusive club and derive some benefit from it is incredibly difficult.

At this point I think it would take some serious names on it or behind it or some other similar form of momentum, which I just don't see.

<comment><USER4> _The name "fowndr" makes you look cheap. Why? Because the domain name was no doubt unregistered. Basically it looks like you went looking for a domain name that you could get for $10 for a year;_

This reminds me of the old argument that you need to wear a suit when demo-ing your app. If you show up in khakis and a polo shirt, people might think you're too cheap to buy a suit. Sure, we know that the suit has nothing to do with your app or your business, but still we care about it. It's a little like being a peacock. No, these feathers don't help me catch more food, but carrying them around must prove that I'm the Alpha cock.

Interesting in a way: It's easier and cheaper than ever to launch new businesses, so now that simply getting the code running no longer costs $1,000,000, we ask founders to spend their money on something else just to prove that they're spending money!

<comment><USER5> "This reminds me of the old argument that you need to wear a suit when demo- ing your app. If you show up in khakis and a polo shirt, people might think you're too cheap to buy a suit."

Weird analogy - I don't see it. I don't know anyone who would think that way in 2011, particularly if we're talking about founders, and double-particularly if we're talking about founders making a pitch.

I agree that "fowndr" is goofy but, to me, it's goofy in a way that might appeal to 15 and 16yos. Not my thing but I don't think it's meant to be so no problem.

<comment><USER4> I'm not saying you should pitch in a suit today, but I am saying that picking a domain name on the basis of projecting that you spent money on it _today_ is like wearing a suit _used to be_. That's why I called it an old argument. I'm also not saying that this would be a bad choice. There has been much talk of someone spending $350,000 on a domain name, and one of the interesting arguments in favour was that the domain could easily be resold if necessary. You can't do that with a suit.

</comment></comment></comment></comment><comment><USER6> Got to say, i'm aware of Stu and followed one of his earlier startups, projectbubble, he did really well with it and developed it by listening to the users. I expect Fowndr to be successful as well.

</comment><comment><USER7> Honest question -- what's the real utility of a founder network like this above, say, actively participating on HN regularly?

Forrst is so useful because it's specialized. I don't see that (yet) here.

<comment><USER4> HN is growing, and with growth comes a dilution of focus. Inevitably there will be subsets of the community who feel their needs aren't being met on HN.

For example, if HN has 99 employees for every one founder, what do you think will happen if you try to discuss how to set up options and vesting such that in a liquidity event, the employees are still bound to the company and won't quit when they discover they have new bosses?

You aren't going to get the same conversation as if you just discuss the question with other founders. I'm not saying the HN discussion will be less valuable, but can we agree that some conversations will be different?

<comment><USER7> "some conversations will be different?"

...and that's worth building an entirely new product and trying to move select people from HN to it?

<comment><USER4> I have no idea if it's "worth it." What you see is the sweat of Stu's brow, not mine. All I can say is this: If you celebrate the idea of founding things, then you celebrate the idea of building entirely new things and finding out if it's worth it, and dealing with people who complain that the old thing is good enough.

Also, I could be wrong about this, but I don't see people moving to it any more than people moved from HN to Facebook or vice versa. Different communities for different purposes.

</comment></comment></comment></comment><comment><USER8> Fowndr: Putting the 'own' into 'founder'? ;)

Good luck, anyway.

</comment><comment><USER9> The challenge with a group for startup founders is that it's a very heterogeneous group, and there is little to "qualify" members (I don't think invites will cut it)

On the other hand, something like Forrst for developers and designers is for a group that is more likely to have some more commonality which is useful in creating a community.

One thought is to do this vertically. So for me as an example, I'd love to connect with founders of B2B information services. Yes, that maybe too niche, but I have a lot more in common with those founders than a mobile gaming company founder.

Look forward to seeing how this evolves. Good luck.

</comment><comment><USER10> Building a tool that just enables further development of cliques seems not so great. Of course it's great for you, since you get to be in on all the cliques, one way or another, if not by membership, by having a birds-eye view of all the data. Personally cliques rub me the wrong way, not just because of jealousy, but also because open exchange with others outside your comfort zone leads to more opportunities.

<comment><USER11> It's only a problem when people confine themselves to their cliques. I'm in a few invite-only communities online but I don't define myself by my membership and I take part in so many _other_ communities that I get the bigger picture and the "open exchange" you mention too. You really can have the best of both worlds.

Some things benefit from being slightly locked down. For example, I'm a member of a paid marketing and SEO forum where people share ideas, tips, and observations that often takes months to hit the blogs (or never at all). While anyone can join, merely having that "curtain" encourages people to say and share things that they don't want coming up in Google.

</comment></comment><comment><USER12> It's all well and good having people invite people they know, but isn't the hardest part of starting out the problem of not knowing people? Are people starting out not your target group? If so, will active founders who are running their business really share that much interesting chatter rather than just links a la HN?

Also if like-minded people invite like-minded people isn't there a massive groupthink effect?

<comment><AUTHOR> I would imagine that founders already in the network would want to encourage young, new and ambitious founders by inviting them in to the network. There they would be able to share their startup with the community and learn a lot in the process.

<comment><USER10> We already have HN for that, though it's less exclusive and cliquey, and, dare I say it, less ageist than what you are suggesting.

</comment></comment></comment><comment><USER13> Could be interesting. Looking forward to seeing it when it's live.

</comment><comment><USER14> Great job on the design (based on the screenshot). It looks very elegant.

How are you going to differentiate between a "startup" and a "weekend project"?

<comment><AUTHOR> Thanks. Well, I guess that will be up to the people handing out invites - <USER2> will be up to the community to decide 'who gets in', but the fundamental requirements would be that they are founders or co-founders of a Startup that is less than 3 years old and is actively committed to building a business. Thoughts welcome.

<comment><USER15> I would err on the side of vigilance first like Forrst did.

It's easier to let it be more open then to try to close it up.

</comment></comment></comment><comment><USER16> I think it has potential, though not surprisingly quite a few sites have recently launched with similar objectives.

</comment><comment><USER17> 8:04am EST:

Slight problem...

Something is wrong with the database, please bear with us.

Unable to connect to your database server using the provided settings.

<comment><AUTHOR> Where are you getting this message? I'm not seeing it.

<comment><USER17> stu, i got it when trying to click through the HN link.

8:07am: tried it again because i saw your response and it worked. the upside: nice tight 3 min window to check your apache logs?

</comment></comment></comment><comment><USER18> I think I saw this on Quora the other day.</comment>


Confessions of a Xinjiang Camp Teacher - <AUTHOR> https://thediplomat.com/2020/08/confessions-of-a-xinjiang-camp-teacher/ <comment><USER2> I find it difficult to even read about it. Why does China get a free pass on this? Other than avoiding any products of Chinese origin, and contributing to organisations that are working with Uighurs and Tibetans, how else can I contribute?

</comment><comment><USER3> I wonder if this ongoing genocide is mostly unknown by the general public, or if it's known and not regularly on the front pages of mainstream media (and therefore perceived as unimportant).</comment>


Intel Unveils JavaScript Extension that Adds Parallel Processing Capabilities - <AUTHOR> http://www.infoq.com/news/2011/09/javascript-parallel-processing <comment><USER2> Javascript has at least 2 ways to do parallel processing without any extensions

1) Worker threads

2) WebGL shaders

Anything else has almost no chance at taking off.

<comment><AUTHOR> Also Rhino has access to the JVM, which means it can do Parallel processing just fine as Scala's parallel collections[1] can be used on any of these languages.

You can even use ForkJoin Parallel Array[2] implementation, which is the engine that powers Scala's parallel collections.

[1] [http://dcsobral.blogspot.com/2011/05/scala-29-and- parallel-c...](http://dcsobral.blogspot.com/2011/05/scala-29-and-parallel- collections.html)

[2] <http://www.infoq.com/news/2008/03/fork_join>

<comment><USER2> JVM execution (a Java applet I assume) now requires a confirmation, at least in Chrome.

<comment><AUTHOR> As nodejs showed us, Javascript is not limited to the browser. I've talked a bit about it recently (it is not even limited to browser our server): <http://bit.ly/phxe16></comment></comment></comment></comment>