Contributing to the Mozilla code base - <AUTHOR> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction <comment><USER2> Several years ago I did want to fix something in Firefox, and it was far easier to just patch a few bytes in the binary (I think it might've been a string constant) than go through the whole build process with all the resources that takes, including trying to find where in the original source to actually make the change, and then still have a totally different binary than the one you wanted to fix, with other (bug-causing) changes you _didn 't_ want due to the different environment you built it in.

Of course, if you try to fix/revert something that was purposely broken or removed for some Mozilla reason, it is not going to accept your changes either.

One of the ideals of open-source was to make it easy to modify and share software. For a lot of the larger projects, I feel like that has missed the mark. I write (mostly small and always portable) software, yet the "build bloat" is a huge turn-off. On the other hand, I've had good experience with the smaller open-source projects, those that need a minimal amount of tooling and resources to build. Some examples I can think of include libpng, zlib, and even OpenSSL.

<comment><USER3> Honestly, this shows why projects of major complexity need professional full- time developers.

I think it also shows a very minor flaw in the open source / pull request process: Expecting _casual_ and _amateur_ contributors to work at the same level as a professional who works with a given codebase on a daily basis is unreasonable.

In my day-to-day job, sometimes I can fix a bug in an hour, but then I need the rest of the day to update tests, avoid regressions, and think through my fix to make sure it's long-term maintainable / readable / performant. Even more important, if I'm working with code that I don't usually touch, I have to make sure I follow the expected conventions that everyone else expects; and I have to be much more careful about assumptions that I haven't learned yet.

So, a 1-hour fix easily balloons into 5-15 hours!

Perhaps the easiest way to encourage new contributors, who are assumed to be casual, is to encourage incomplete and partial fixes that the main team completes?

<comment><USER4> > Honestly, this shows why projects of major complexity need professional > full-time developers.

I think the opposite, it shows why projects that care about the practical side of open source and free software should always have in mind their "hackability" from regular developers.

I remember a case where RMS didn't want to make some change in a project (i think it was Emacs) because it would make the project harder for people who didn't work on it to understand it.

And it makes sense, if you believe that what makes FLOSS good is that anyone could change and/or improve it, then it follows that you should try to maximize the pool of that "anyone".

<comment><USER5> You could easily make an argument that the same philosophy will benefit rapidly growing projects for full time devs. The less "arcane" knowledge needed to work effectively in the code base, the faster new engineers can onboard, the faster old code can have small changes made without breaking something else unexpectedly, and the list goes on.

<comment><USER6> Wouldn't it be inversely proportional to the complexity allowed in the project ?

I imagine for instance a situation where for instance the project starts with a clear REST approach where GET requests are purely idempotent with no side effects whatsoever.

Then people start adding internal side effects (e.g. tracking, behavior scoring, suggestion building, and so on).

It's harder to explain to a new dev that from some angle these requests are read only and nothing changes, and from another angle they change a lot of things.

But it would be counter productive to give up on features because it makes things less simple and brings a learning curve.

</comment></comment></comment></comment></comment><comment><USER7> Some shameless begging: if anyone picked up [https://github.com/tridactyl/keyboard- api](https://github.com/tridactyl/keyboard-api), it would make Vimperator- style WebExtensions much better as we'd be able to respond to user input everywhere in Firefox. We haven't been able to find the time to work on it. I'd be delighted to help anyone who was interested get started.

<comment><USER8> Same here [https://github.com/imvetri/ui- editor](https://github.com/imvetri/ui-editor)

</comment></comment><comment><USER9> Is this article a bit outdated? I have noticed some projects not only switched their repositories but also programming languages i.e.:

> If you know Python, you can contribute to our web services, including > Firefox Sync, or Firefox Accounts

Not quite recently (about 6-7 months ago), the syncserver got rewritten to Rust [0], while the Python codebase it's a bit stalled [1]. I guess Mozilla is going to switch to syncserver-rs soon, because they started implementation of Google Cloud Spanner and this looks like a green-light for future deployment.

> If you know Java, you can contribute to Firefox on Android, Firefox Focus > for Android and Firefox for Fire TV.

There is new Firefox Preview on Android, which might disrupt the mobile browser market share soon (if it gets addons support). Some mozillian also worked on projects like Lockwise [2] or Firefox Notes [3] which are written in Kotlin, not Java.

Please, do update this article.

[0]: [https://github.com/mozilla-services/syncstorage- rs/commits/m...](https://github.com/mozilla-services/syncstorage- rs/commits/master)

[1]: [https://github.com/mozilla- services/syncserver/commits/maste...](https://github.com/mozilla- services/syncserver/commits/master)

[2]: [https://lockwise.firefox.com/](https://lockwise.firefox.com/)

[3]: [https://addons.mozilla.org/en-US/firefox/addon/notes-by- fire...](https://addons.mozilla.org/en-US/firefox/addon/notes-by-firefox/)

<comment><USER10> The article is maintained by volunteers and there is a large edit button that anyone can click.

</comment></comment><comment><USER11> I got interested in contributing to Firefox in the hopes that it would lead to a job.

My thought was since obviously I could do the job, then they would hire me without having to go through the usual interviewing steps.

Every time I have applied, I never got pass the recruiter. Never got a call to talk about my patches, just a generic rejection response.

Then I realized that I was spending too much effort on a single company, so I stopped contributing and applying. Seems leetcode grinding would be a higher reward for the effort.

<comment><USER12> Depending on how significant your patches are (No hello-world-123/typo/style fixes) putting 'Contributed to the Firefox Browser' on your CV/Cover letter and I find your email in the source code or AUTHORS file is a instant on-site from me. You don't need to show me that you can program/write tests or use version control. This saves me lots of time on finding candidates that are experienced, rather than throwing a leetcode/hackerrank puzzle which can be easily cheated or plagiarized.

I think I might have said this before on another HN thread, but of course as an interviewer, I sometimes double-check the CVs and candidates to look for 'hidden qualities' such as open-source contributions. If one recruiter overlooks a candidate, I really ask them why and if the candidate DOES have significant and relevant patches, I actually bypass their decision and I bring them in onsite.

I find these technical programming tests useless for finding qualified candidates unless you are preparing for a programming olympiad or some other competitive programming competition. But open-source contributions allows me to find the patches you made on code reviewing tickets and see it in the open.

It would be better if more companies used open-source contributions as acceptable evidence of relevant experience these days.

<comment><USER13> Unfortunately, that's not how big company recruitment processes work: [https://twitter.com/mxcl/status/608682016205344768?lang=en](https://twitter.com/mxcl/status/608682016205344768?lang=en)

<comment><USER14> (disclamer: I'm a noogler, and I failed google on-site once).

I think that citing this example every time "hiring at Google/Big tech" is discussed on HN is useless.

We know that there are a lot of false negative and and lot of chance in the hiring process (so many things can fail in a process involving so many steps and people).

There are also legitimate rejections, like hm, bold statements ("90% of your engineers use my software"), fingerpointing or not being able to seek for assistance when you don't know something.

I discussed interviews with many people, and I'm convinced that solving the problem with the theoretically-optimal solution is not the only way to get a positive review. Being open about things I didn't know helped me: for instance "Hm, I'm not sure about how to do this exact thing, I'll use the function do_this_thing() and implement it later if I still have time, if that's OK for you" buys you time and allows to keep the discussion focused on the main problem.

<comment><USER15> I don't think his statement, while bold, is at all unfounded. If he truly was rejected for not being able to invert a binary tree on a whiteboard, but has a proven track record of writing excellent software, I would agree with him that there are some serious issues with the Google/Leetcode/2nd-year-CS-trivia style of interviews.

<comment><USER16> >I would agree with him that there are some serious issues with the Google/Leetcode/2nd-year-CS-trivia style of interviews.

I think both you and your parent are in violent agreement.

It's not as if many people who were in FAANG haven't admitted there are serious issues with the interview process. Even advocates of the process are open about it.

No one has found an interview process that lacks serious issues. Hiring people solely on the basis of major contributions to software has its own serious issues.

</comment></comment></comment></comment></comment></comment><comment><USER17> Definitely recommend contributing to their codebase. It's a great experience. I wrote about my experience contributing to Servo here: [https://brainlessdeveloper.com/2017/08/12/my-experience- cont...](https://brainlessdeveloper.com/2017/08/12/my-experience-contributing- to-servo/)

<comment><USER13> But did it helped your carrier)?

<comment><USER17> I haven't changed jobs since I started contributing two years ago. So it hasn't, really, but I learned a lot. It probably will help in the future.

</comment></comment></comment><comment><USER18> One great resource for those interested in contributing to Mozilla, is mikeconley's live coding sessions[0], which are cataloged here[1]. These can be used to help understand internals.

[0] [https://www.youtube.com/playlist?list=PLmaFLMwlbk8wKMvfEEzp9...](https://www.youtube.com/playlist?list=PLmaFLMwlbk8wKMvfEEzp9Hfdlid8VYpL5)

[1] [https://mikeconley.github.io/joy-of-coding-episode- guide/](https://mikeconley.github.io/joy-of-coding-episode-guide/)

</comment><comment><AUTHOR> Chrome is a dangerously slick browser, I found it takes a determined effort to switch and eventually get comfortable with Firefox as your primary browser. But we should support Firefox and give efforts and user feedback where we can to get it to the same competitve level.

<comment><USER19> Can you elaborate on what you found most unconfortable or difficult to adapt to?

I switched to Firefox ~1.5 years ago and it does everything I need, actually never picked chrome up again. The android version is very good as well, but I just switched to iOS and it's not a very smooth experience there.

<comment><AUTHOR> To be fair, Firefox actually has a lot of good stuff and you can get its UI to match the Chrome experience quite easily. The Developer Tools are also quite good.

Biggest issue for me is not being able to import passwords from Chrome. I have to switch back to Chrome if I need to access some web services quickly, so building up saved passwords in a browser makes it more sticky. There's probably a reason for not being able to do this though.

It also starts to get a bit sluggish when you have a couple (6-7) heavy JS/DOM tabs open.

File download UI could be better. Skip the confirmation dialog, show file and progress at the bottom of the browser window.

<comment><USER20> Firefox developer tools are awesome and they get better with every release! Lots of cool stuff recently added for debugging CSS related issues.

JS sluggishness might be because of a recent Firefox Pioneer study. I've experienced it for the past week and in the end I uninstalled Firefox Pioneeer completely because of it.

imho, file downloads are actually great. When you have active or recent downloads - you'll get a nice litle icon on the right from the URL bar. For active downloads it'll show the total progress for all downloads. Once clicked, it will open a small menu with your downloads. When you don't have any recent/active downloads it just gets out of our way. Much better than that ugly bar at the bottom of the window.

<comment><AUTHOR> I didn't know about that download icon. I must have removed it when customising the UI. Thanks!

</comment></comment></comment></comment></comment><comment><USER21> I'd really like to work for Mozilla on Mozilla products, but somehow the interview process is broken.

I've managed to go through 3 interviews (2 technical, one with the team- coordinator) but then was rejected because they've found some other with more years of relevant (?) experience on the topic for the position.

Now they write this. So my question is: why don't you open more positions, letting people be hired (and paid) to work on products, instead of looking for charitable work from volunteers?

<comment><USER22> Because hiring more people costs money and volunteers are free?

<comment><USER23> yeah but then don't bother us with missing contributors.

Somehow someone has to live and code for food. Not everybody has the luxury of working as volunteer.

<comment><USER24> No company has the luxury of paying employees with money they don't have.

</comment></comment></comment></comment><comment><USER25> > Mozilla uses Phabricator for code review. Either use Mozilla's Phabricator > instance (preferred) or attach a patch as an attachment to Bugzilla.

Oh neat, they're using Phabricator, the self-hostable open-source github/gitlab-like repo host/code review system spun out of Facebook. I use this in the office and everybody loves it.

Example review: [https://phabricator.services.mozilla.com/D40365](https://phabricator.services.mozilla.com/D40365)

</comment><comment><USER26> Where is built-in support for all the decentralized protocols, such as torrent://, magnet://, dat:// ipfs:// etc?

<comment><USER27> Have you searched the bug tracker for proposals to implement this? Have you submitted these requests? Did you review any guidelines or outlines of features that Firefox should support?

Leaving a comment on HN to (what seems to me) complain is easy; actually going to the issue tracker and mailing lists would be a lot more productive.

I suspect you'll find that it has been proposed but rejected. I suspect it's because support can be easily added via addons, keeping the core more lightweight and extensible.

<comment><USER28> > keeping the core more lightweight and extensible

I'm not sure if that's sarcasm or not, considering the countless issues with CliqZ and Pocket

<comment> dao- > CliqZ and Pocket

Cliqz made their own browser based on Firefox, and a Firefox extension. Pocket started as a Firefox extension and even when it got integrated into Firefox it was technically still an extension. If anything these cases seem to indicate that the core is lightweight and extensible. What's your point?

</comment></comment></comment></comment><comment><USER29> > _If you know JavaScript or HTML /CSS, you can contribute to the front-end of > Firefox_

Huh? I'm interested in that, but I'd think most of the GUI's behavior is in C++ and hopefully threaded for responsiveness? And only the top 'fluff' layer is styleable, possibly being made with XUL.

Alas, links in that post don't seem to lead to architectural overviews of the components.

<comment><USER30> That's not true. Majority of the front end is in html+js+css these days. Most of it is /browser and /toolkit directories. The rest is Gecko engine and it's written in a mix of Rust, C++ and JS. We're moving more to Rust with the back end but staying with JS on the front end.

You can develop almost any feature of Firefox without ever leaving JS.

<comment><USER29> Interesting, thanks! Will try poking things in there. Though this might explain why parts of the GUI sometimes get held up by each other...

Is there, by any chance, an intro to the moving parts in the GUI code, for newcomers?

</comment></comment></comment><comment><USER31> Wasn't the story of Stuart Parmenter being flown out to California to help with the browser based on his open-source contributions from his parents house in some midwstern town?

Was that Mozilla or Netscape at the time?

<comment><USER32> It was Netscape in 1999 he got flown out. Documented in Code Rush, which is an awesome documentary for anyone interested in the history of the Web:

[https://youtu.be/4Q7FTjhvZ7Y?t=3037](https://youtu.be/4Q7FTjhvZ7Y?t=3037)</comment></comment>


Skip the Soylent, Make a Meal Instead - <AUTHOR> http://abraintrust.com/strive-to-make-food-more-difficult/ <comment><USER2> While I can see that some set of people don't agree, I really love cooking. Love eating out at all sorts of restaurants too.

Cooking gives you a unique opportunity to be experimental, algorithmic, and potentially experience a small part of a variety of cultures. The programming mindset maps very well to it. It's also great SO/family time when done jointly.

For people who hate cooking, I recommend trying to find a recipe that seems out of your league. That's what really got me going originally. Nowadays I'm pretty confident trying to whip up nearly anything (though I'm not making fancy, artistic-looking dishes certainly).

Home cooking has it's own challenges. Less space, still have a lot of cleaning, and can't magically divine all sorts of cooking oils and what have you because the scale makes it impractical.

That said, cooking for 1 is a lot less exciting for me than cooking for 2+. If I were living alone I'd probably still eating packet Ramen a bunch.

<comment><USER3> As many of my friends, I love to eat and I love to cook, but unfortunately, my time, kitchen room and budget is limited. So I prefer by far for the same time/budget having let's say 3 poor (joylent/queal) meals and 1 excellent meal than 4 passable meals.

<comment><USER2> Yeah, I definitely realize there's a big tradeoff here. I try to cook extra for each dinner, so that my lunch the following day is leftovers. (3 sameish- meals in a row is rough but 2 is fine by me).

Another thing that's been helpful is big roasts. turkey breast, pork shoulder, etc are very easy to toss a quick seasoning on throw in the oven for 2-6 hours, plus are pretty cheap ($2-$3 a lb, though a bit of that is bone). Gives you some meat to work into all sorts of things for the week with pretty low effort cooking.

With that, a carb staple and random sauteed veg you can get pretty far.

</comment></comment></comment><comment> squeaky-clean I saw an ad for a kickstarter the other day. It was some durable, spill- resistant, stain-proof, neutral colored shirt that you were meant to wear most/all days of the week, instead of needing to choose your clothes or manage a big wardrobe.

It used lines like "Don't you hate wasting 10-20 minutes every morning choosing your outfit?", "Don't you hate shopping and trying on clothes that probably won't fit?". And no, I can't say I've ever felt like that. I enjoy the time spent dressing myself. I like shopping for clothes and thrifting. That shirt basically wants to take away everything I like about clothes.

I guess this is how other people feel about me "eating" mostly Soylent. They love food and don't understand how someone else would want to not spend their time choosing or preparing food, or how someone could eat the same thing every meal. Someone who would be interested in this shirt doesn't really care about changing up their looks everyday or their clothes looking unique. Just that they look decent and clean, and don't waste too much time or money doing so. And I don't necessarily care about my food being varied or flavorful, as long as it isn't unhealthy and is simple to prepare.

<comment><AUTHOR> My wardrobe consists of 1 pair of jeans, 5 t-shirts, 1 sweater, wear the jeans and sweater everyday, change the shirt.

<comment><USER4> Do you do laundry every 5 days? Maybe buy 5 more and stretch that to every 10 days.

<comment><AUTHOR> Wear them at least twice before washing.

</comment></comment></comment></comment><comment><USER5> I can't tell if this is satirical or not. Is knowing how to shop and prepare a basic meal really such a problem today?

<comment><USER6> Speaking for myself

I don't hate cooking meals

I hate all the fuzz around it - getting ingredients - do I buy "organic"? is that expensive? how cheap should I go?; finding the right recipes - how do I compare 20 different ones from the web? Which are more healthy? Dietary recommendations are all over the place - high carb / low carb / high fat / low fat / vegan / paleo / I don't know what all is there.; finding out what I forgot to buy, throwing out the old stuff that are starting to rot in my fridge, then spending another hour cleaning all the mess...

The cooking part is - at least for me - always the easiest - just follow the recipe. I hate the worrying before and after.

<comment><USER7> A lot of this fuzz would be tempered as you become more accustomed to cooking. In some ways what you're describing is similar to picking up a new computer language or learning a new system. Once you've been through the decision tree enough times, you've built yourself a well-worn path.

If cooking is something you're interested in picking up, I'd recommend starting simply. Pick a couple of meals (maybe a breakfast and a dinner). Get used to them, then start cooking variations, then move on to other dishes. I'll admit, I can be satisfied eating the same meal on a regular basis. And this doesn't prevent you from going out, either.

I've heard of people having good success with the Ti Ferriss' "The Four-Hour Chef". I'm sure there are other good references, either bound or online.

<comment><USER8> I like The Four Hour Chef, but I don't feel like it's a great cookbook to learn from. It's more a book about learning a skill with food as a metaphor.

<comment><USER7> Considering that was the author's stated purpose, sounds like he achieved his goal :)

</comment></comment></comment></comment></comment><comment><USER9> This article is complete and utter bullshit.

"But think about the benefits, when you make your own meals you are saving money, rather than paying a chief, tip, delivery fee and markup, you only pay for the ingredients."

If you think even a little bit, it is obvious, that producing prepared food at scale is more efficient than cooking it for yourself.

"as you learn to cook you gain an important skill, you gain independence ... being self-sufficient"

Right, drive yourself to work instead of using mass transit, make your own clothes, furniture, assemble your own microchips (you surely can't be a developer/admin without a microchip, so that one is very important to be self- sufficient). Don't forget to dig a hole and pump your own water!

Fallout is coming, we all need to cook right now!

Oh, and also it is much more interesting, than spending the same time on reading news/books or making something for other people!

<comment><AUTHOR> Being a little self-sufficient is better than not being self-sufficient.

You've read one article with one suggestion and made a massive sweeping assumption about the authors intentions, good job.

<comment><USER9> Your statement about self-sufficiency is universally correct, but does not make sense in the context in its current form, because noone is 100% self- sufficient, but everyone is self-sufficient to a degree. The statement you actually meant (assuming you had thought settled), which is: "it is always better to be a little more self-sufficient" is definitely technically incorrect or at least extremely dubious.

Also, irrespective of any assumption I might had (or not) about the author from a long post, you go much further assuming you know I had one, and that you know it from my single small comment half of which is original author's quotes.

<comment><AUTHOR> I was a reductio ad absurdum argument.

</comment></comment></comment></comment><comment><USER10> 100% agree.

I like having a smartphone with me because it allows me to do things I couldn't reasonably otherwise do -- but it can also be used as a crutch for things you don't really need a smartphone for. I've started looking for ways to solve problems that DON'T involve popping open a google window or launching yelp. Simple stuff like memorizing routes I want to take before I start so I can navigate with my eyes ahead rather than in my phone, asking friends for food recommendations, keeping eyes out for posters advertising upcoming events. For me, making life less convenient and reducing instant-gratification is helping me enjoy the ride more.

(yes, this is 100% a first-world-problems comment)

</comment><comment><USER11> Or alternatively, consider that other people may not have the same priorities as yourself. I say this as someone who cooks and prepares most meals from raw, fresh ingredients: it is time consuming, tiring and often boring. If you're a two parent household with very limited time, and you have to choose between spending that time with your children or spending it cooking - why is the virtuous choice necessarily to cook?

To make tasty, varied, high quality food is not even always as cheap and healthy as one might imagine. Fresh ingredients go bad quickly, and can sometimes be difficult to source, so you have to plan carefully. Many of us live in small apartments with limited space for preparing food and small refrigerators. We work long days, and both adults need to work now. Saving time on planning, buying ingredients, cooking and washing dishes is very appealing.

Why do many people think food should be immune from innovation? We have replaced manual clothes washing with automated washing machines, most people now take their car to a mechanic rather than mending it themselves.

<comment><USER12> Why is it a choice between spending time with children and cooking? I use shopping as a chance to take a kid with me and get some time together. They help me prep the food and cook it, too.

Sure, when they were babies and toddlers, it wasn't practical. But I've found that both your life, and the life of your children is better when you integrate them into the work that needs done and the life you want to live, and do not treat spending time with them as a separate activity.

<comment><USER11> Surely that depends on the age of the child, what you're cooking, and the size/accessibility of your kitchen?

Personally, I live with a kitchen that can't reasonably fit more than one person, and all the counters are inaccessible to children.

<comment><USER12> Yes, of course, tiny children are limited in how much they can participate. But not as much as you might think at first glance. We built platforms for them to stand on, so as soon as they were on their feet, they could access the counters. And we could slide the platforms away when we were working with anything that might harm them. As they grow up, simple footstools work, then eventually they are tall enough to work with you just as an adult would.

Likewise, when they are tiny, you don't really give them knives or anything. But they can see what is going on, you can talk to them. They learn quickly. My kids have been making their own lunches since they were 6, starting with simple thigns like sandwiches or nachos. My 10 year old frequently cooks breakfast for the family -- eggs, pancakes, waffles, etc. My 8 year old does simpler things - grilled cheese, mostly.

Give kids a chance - they may surprise you.

As far as working in small spaces where people do not fit, that does sound like more of a challenge. But parenting is full of problem-solving opportunities.

<comment><USER11> I am glad you have found a way to incorporate your children into your lives in this way. And I would hope many parents attempt to do the same thing. When growing up, I cooked from a young age (about 7) simply because both of my parents worked two jobs, so if I didn't cook, I wouldn't get fed.

But I think many people lose perspective on this. There are a large number of people who, once they have finished their long hours at work, finished their >1hr commute home, washed the clothes, taken the kids to their activities, picked them up from school, cleaned the house, helped with the homework, etc. find that they do not have time to dedicate to cooking. Often, these are poorer people, they may live a long distance from a good supermarket, and simply buying fresh groceries is a challenge.

Knowing people in this situation personally, they feel extremely guilty and regretful over the fact they can't make their kids nutritious home cooked meals every day. People not in that situation often don't realise that buying a freezer full of frozen meals and a cupboard full of tinned pasta/beans is often more cost effective than trying to plan buying fresh food such that it doesn't spoil - given the inherent variability in how long fresh food tends to last. And arguably, more importantly to individuals with cashflow issues, is the stability. When you buy that frozen Mac & Cheese dinner, you know that $1 is going to feed your child for an evening. And that meal is going to cost the same next week, and the week after. It's simpler to budget that way. If you buy locally sourced, organic head of lettuce at the farmers market - it might last two days, it might last two weeks - there's not really any way of knowing.

I know many people who take great pleasure in cooking with the family at the weekend, but don't have time in the week. So from Monday to Friday, they live from prepackaged frozen food, takeouts. Innovation in this space would be welcome - but simply telling people to "make time" to cook isn't going to change anything. Making Mon-Fri cheaper and healthier might make room for higher quality food at the weekend, though.

</comment></comment></comment></comment></comment><comment><USER13> I gave up Soylent a couple weeks ago because of how many carbohydrates it has (33g per bottle). I would drink a bottle and the hunger would subside, but two hours later the appetite was much stronger. Since preparing my own meals, choosing low-carb, I'm hungry less and can go 4-5 hours between meals. Have never felt better.

<comment><USER14> This was a little hard for me to figure out,but somehow I'm losing weight by eating fewer carbs. It's hard sometimes to figure out exactly what I'm hungry for. If I eat veggies the hunger subsides, but then I get very hungry, fast. If I eat fats, the hunger doesn't go away, but I feel like it helps prevent hunger in the future.

I've been eating to be satiated, because I know I have enough calories to live.

I just found [this article]([http://www.sciencedirect.com/science/article/pii/S0924224414...](http://www.sciencedirect.com/science/article/pii/S0924224414002386)) and it seems to reflect what I personally experience.

</comment></comment><comment><USER15> Soylent (or more particularly Coffiest) has been perfect for filling the 3pm spot at work when I'm both tired and hungry. I used to head out for a $5 coffee and stay hungry, but now I can use Coffiest to do a decent enough job of satisfying both cravings while saving some money.

That being said, I would never replace any of my other primary meals with it because I love cooking too much. I typically spend an hour or two on Sunday making two meals of 4 - 6 servings that will last me through the entire week and then I take off Friday and Saturday and eat out.

</comment><comment><USER16> Soylent exists because people don't want to cook. Don't want the time sliced out of their day. Don't care about variety and flavour. Would be happy to ignore food as an issue.

Telling them to cook really just amounts to ignoring their priorities.

</comment><comment><USER17> I have not been tempted by such products in the least. I frankly find it personally unappealing in the extreme. The easiest thing in the world to cook is eggs, which I could eat all the time. I also live within walking distance of not one, but two grocery stores. My wife likes to cook and pick out her favorite organic foods. I prefer to look at the unit price and go for the lowest. Restaurant food is nice, but it ends up being very much more expensive on a monthly basis if you eat it too much. Today is our anniversary and in the break between conference calls this morning, I've already been to the store and back with fresh cut steaks to put on the grill after work. We're going to eat so good tonight and at a fraction of the cost of a eating out for our special night which is appealing to both my wife and me.

</comment><comment><USER8> What bothers me about this anti-convenience backlash is that it comes from a "stop being lazy and make the time for something I think you should find important" approach.

If people find value in it, they will take the time to cook. I learned to cook because I found value in it. Others don't, and that's okay. I really like that I can bring something to a pot luck and everyone likes it, or that I can bring joy to a friend for a meal -- that's something I value.

If you don't value that, it's fine. We make choices.

If you are on this site and value it but don't know how to start, take a class. Most people here are in a place where they can afford six weeks of classes to learn the basics. But doing it out of guilt is silly.

<comment><AUTHOR> Good advice on taking a class.

What if people haven't thought of the benefits that this article is suggesting?

<comment><USER8> It's entirely possible, but I've shared my story with hundreds of people and talked with them about cooking. This is less impressive than it sounds -- I've done a fair number of pot lucks and been in a fair number of conversations where I shared the story of how, why, and when I learned how to cook. It happened in multiple stages, but all of them happened when I was out on my own and got tired of eating out. First, with roommates, I learned how to cook the absolute basics. Then, I had another roommate that helped me expand my horizons. He was vegetarian, so I had to learn another set of cooking techniques I hadn't before. Then, I moved into my own apartment where I realized that I couldn't make the food I really wanted to eat. I started watching the food network obsessively, learning everything I could, and trying new things.

However, it happened at the phase of life when I was ready for it. And when I've mentioned this in conversation, I don't remember anyone saying, "I don't need to know how to cook" or "I don't need to learn to cook more than the basics." It's "I don't have time," or "I don't enjoy cooking/cleaning," or "I'm too afraid to mess up."

As I've grown older, it's changed. I'm around mostly people in their thirties and most people had the same experience as I did where they realized they had reached a point in life where they needed to learn to cook.

Now, _I_ realize that I'm a mediocre cook and anyone with a mere week in a decent restaurant is likely a better cook than me. However, I acquired a reputation of a good amateur cook in some circles. I couldn't imagine being in a place where I didn't cook well - it brings so much to my life. I just think the shaming over it all doesn't work because the motivations don't line up.

</comment></comment></comment><comment><USER18> A couple of tomatoes, 1 cucumber, 2 peeled carrots, a lump of cheese, sweet potato microwaved for 5 minutes, tin of tuna or some lumps of beef or bacon quickly fried. Drizzle in olive oil, sprinkle a little salt.

Preparing your own food doesn't have to be that complicated.

<comment><USER19> Open can, deposit contents in pan, heat in microwave for 5 minutes.

Open box, deposit in container, add milk

Take sandwich, apply peanut butter

</comment></comment><comment><USER20> I'm a pretty reasonable cook, actually. I spent a couple of years challenging myself to improve: I can make a reasonable pizza with home-made base and sauce (albeit American deep pan style rather than Italian), I'm fond of cooking Chinese food (because in the UK takeaway Chinese is very hit-and-miss), and I enjoy baking.

I haven't done any of that for years, because now I'm living with crippling depression, and I often face the choice of spending my energy for the day on work, on housework, on life maintenance, or on eating well. I only get to choose one at the most. So most days I live on ready meals, supermarket pizza, pasta, etc. I buy Joylent (EU version of Soylent) because I reckon it's got more nutritional value than most of the ready meals I'm eating, and it's very quick to make - useful on days when I have to drag myself out of the house and don't have time for breakfast. It's also cheap - which is good, because depression means that I don't get many billable hours worked these days.

So, yeah. I'm probably nowhere near the common case here, but I just wanted to present a case study to show that not all of us meal-replacement users are just "people who haven't learned to cook properly yet" or "people who don't care about food". We're a diverse bunch.

<comment><USER20> Forgot to point out: I'm piscetarian as well. Which seems like a ridiculous self-imposed challenge ;)

That makes getting ready-made food harder, too: my supermarket only does a couple of vegetarian/seafood ready-meals per category (two curries, three italian meals, no Chinese meals at all!) so I find myself eating a very monotonous diet anyway.

Nevertheless, I don't use Joylent full-time: I just have a box in my cupboard for when I need an emergency meal or just can't face another plastic tub of macaroni cheese.

</comment></comment><comment><USER21> Skip the grocery store. Are our lives really getting better if we depend on other farmers for our most basic food requirements? In fact, skip agriculture entirely. Let's all become hunter gatherers again and return to our true human nature.

Thought experiment: what do you imagine the diet of the average human will look like 100 years from now? 200? I'd wager that if your answer involves a grocery store, fresh produce, slaughtered livestock, etc. then you're mistaken.

<comment><USER22> There's a big difference between grocery shopping (where even within one store - let alone multiple stores - you have access to a mind-boggling variety of foods, brands, etc.) and a pre-packaged service like Soylent or Hello Fresh / Blue Apron / whatever else is out there. Not only is the number of available options significantly greater, but the price is significantly lower.

I'd wager that if _your_ answer to the future human diet in that timescale relies primarily upon such pre-packaged subscription services, then you're even more mistaken.

</comment></comment><comment><USER21> Skip the grocery store. Are our lives really getting better if we depend on other farmers for our most basic food requirements? In fact, skip agriculture entirely. Let's all become hunter gatherers again and return to our true human nature.

Thought experiment: what do you imagine the diet of the average human will look like 100 years from now? 200? I'd wager that if your answer involves a grocery store, fresh produce, slaughtered livestock, etc. then you'll be wrong.

<comment><AUTHOR> Lets keep the dream alive!

</comment></comment><comment><USER23> I'm amazed at how many people use Soylent. IMO its a very poor meal replacement. Their key ingredient is Maltodextrin which is a heavily processed sugar that is often marketed as a healthy complex carbohydrate. You may as well be pounding back dextrose (corn syrup).

I urge any HN users that use Soylent to really give meal preparation a try. You can prepare a dozen health meals in half an hour on Sunday night and your lunches and snacks for a whole week will be good to go.

</comment><comment><USER24> Or consider nature's meal replacements: milk and fruit juice. Believe it or not, this would be less hypoglycemic-prone than Soylent, since fructose is less insulinogenic than starch, and have a better micronutrient profile. Check out the work of Ray Peat if interested in learning more.

<comment><USER25> I'm no where near an expert on the subject, But I have heard convincing arguments[1] that fructose is very bad for you (especially when concentrated in a fruit drink).

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

<comment><USER24> I'm not a biochemistry expert either, so I have to defer to the arguments of others. I find Ray Peat more convincing than Lustig. It also makes sense to me that fructose, especially from fruit, is incredibly healthy to humans, since pretty much every ape gets a good chunk of their calories from fruit.

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

</comment></comment></comment><comment><USER26> Making a meal is a science. Making a good, balanced, healthy meal is something everyone should know but I don't think everyone is willing to do so. It takes time, practice and patience.

"There is a difference between knowing the path and walking the path" and cooking your meal every time!

</comment><comment><USER27> I don't agree with the premise of the article. I bake my own bread and it's no more difficult than making pancakes. Also much healthier since I use less than half the salt that's put into what you can get at the store.

</comment><comment><USER28> Say Jack choose to make a meal everyday, while Jill chooses the Soylent. If both Jack and Jill start at the same baseline weight and both eat the same number of calories via meal or via Soylent, who is going to lose weight faster ?

</comment><comment><USER29> Get an electric pressure cooker and cook once a week.

<comment><USER30> Meal prepping can be lots of fun. If you're in to that sort of thing, /r/MealPrepSunday has some pretty good suggestions.</comment></comment>


A Pacific Culture Among Wild Baboons: Its Emergence and Transmission (2004) - <AUTHOR> http://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.0020106 <comment><USER2> Sapolsky is a brilliant teacher. Lots of his lectures on youtube, all worth watching.

</comment><comment><USER3> TL;DR: A bunch of aggressive male baboons died in an accident many generations ago and the group was better for it due to the culture and genes that passed on as a result.

A good argument for Eugenics if ever there was one -- I tend to be against it in principal, but sometimes I look at the war and devastation in this world caused primarily by aggressive greedy men (and occasionally women), but I like to think there are better solutions, especially because it opens the door to people being sterilized for stupid reasons like scoring low on an IQ test or getting on the wrong side of some politician [1] (interestingly, Eugenics is still 100% legal in the United States [1])

[1] [http://www.npr.org/2016/02/26/468297940/imbeciles- explores-l...](http://www.npr.org/2016/02/26/468297940/imbeciles-explores- legacy-of-eugenics-in-america)

<comment><USER4> It's not genetic; it's entirely a cultural change. (Hence the title of the article!) This is specifically addressed in the text:

> A decade after the deaths of the more aggressive males in the troop, Forest > Troop preserved a distinct social milieu accompanied by distinct > physiological correlates. _Critically, as noted, no adult males in F93–96 > had been troop members at the end of the tuberculosis outbreak. Instead, > these males had subsequently transferred in as adolescents, adopting the > local social style._</comment></comment>


Was high school terrible for kids who become entrepreneurs and hackers? - <AUTHOR>

I am just curious whether entrepreneur/hackerish guys have it rougher because we probably think very differently from most people. High school was certainly terrible for me.
Despite being good at sports and being excellent in school, I was probably the most miserable kid in high school.
It was too long ago, but my vague memories includes posing all sorts of weird questions to my teachers which people laughed at, and being absolutely outlandish in my ideas on how to do things.
It was really bad last time, but looking hard, these are very much the same "heck it" traits that made me start the various projects I did. Just curious - did any of you share the same experience? <comment><USER2> As a hacker I solve problems and do not believe in simply regurgitating facts for the hell of it.

High school was horrible. I left early to work for a startup and it was the best decision I ever made.

</comment><comment><USER3> I had a graduating class of 531, which means there was more than enough outcasts to form an outcast clique.

</comment><comment><USER4> I didn't hate high school, but I certainly don't miss it.

</comment><comment><USER5> Hated it. Looked in to leaving early. It didn't work out.

(Not sure I qualify as a hacker, though. I code my websites by hand but that's it.)</comment>


Squarespace Raises $38.5 Million From Accel, Index Ventures - <AUTHOR> http://techcrunch.com/2010/07/13/squarespace-raises-38-5-million-from-accel-index-ventures/ <comment><USER2> SquareSpace was a 'single founder' startup founded well before that phrase was the meme it is today. I've used their service off and on since their early days, and can recommend it highly for its clean design and ease of use, if you can live within the limits of a managed CMS.

One thing they've always been stellar on is customer support. Even in the early days if I ever had a question or problem support tickets were taken care of promptly and expertly.</comment>


For Entrepreneurs, Every Day is Game Day - <AUTHOR> http://blogs.harvardbusiness.org/cs/2009/09/when_youre_an_entrepreneur_eve.html

<comment><USER2> In response to "Learn to Relish the Door Slam", a setback is a setup for a comeback. Keep plugging at your entreprenurial dreams, and you will get there. Use those door slams as a learning experience. Each time someone says NO, implement their advice, and submit again.</comment>


GAE Bounced Mail Bug not fixed for 3 years - <AUTHOR> http://code.google.com/p/googleappengine/issues/detail?id=1800

<comment><USER2> Everybody moving over to Amazon SES</comment>


Show HN: A cross platform .Net library for pinboard.in - <AUTHOR> https://github.com/shrayasr/pinboard.net <comment><AUTHOR> Author here. In case any of y'all have any questions/suggestions, I'd be more than happy to address them :)

<comment><USER2> Great job!</comment></comment>


A New Way to Get Money for Group Events: WePay (YC S10) - <AUTHOR> http://bucks.blogs.nytimes.com/2010/06/28/a-new-way-to-get-money-for-group-events/?partner=rss&emc=rss

<comment><USER2> I've been using WePay to manage sponsorship payments at <http://hackersandfounders.com>. I love the service, and if I could, I'd buy stock in the company.

<comment><USER3> Really appreciate the compliment, Jonathan. It means a great deal coming from you.

BTW - Hackers and Founders is awesome. At least one person from WePay will be at the SF meetup tomorrow.

</comment></comment><comment><USER4> Out of curiosity, does YC give have a marketing team that helps the startups get this kind of publicity?

<comment><AUTHOR> We do introduce startups to reporters, but we weren't responsible for this one.

<comment><USER3> Perhaps you were not the proximate cause...

</comment></comment></comment><comment><USER5> Interesting formulation of the group payment problem (we are a group of people, and we want to keep track of our payments).

Nice constrast to for example Eventbrite (I want to sell tickets to an event) or SimpleSignup(I want people to be able to sign up to my event(s)).

</comment><comment><USER6> Totally recommended for any college student. Anyone who has lived with roommates knows the pain of fronting a bill and having to collect later.

</comment><comment><USER7> If you want to go international you should get in touch with these guys: <http://www.gluepay.com/>

They do instant withdrawals/deposits to bank accounts, AFAIK they currently cover most of Europe. I have no affiliation except a former colleague works there now.</comment>


Is gmail down for anyone else? I am not able to login. - <AUTHOR> http://mail.google.com

<comment><USER2> It's up for me. I logged in this morning, and when I reload the site it loads correctly.

</comment><comment><USER3> Works fine for me.

</comment><comment><USER4> Fine here, UK

</comment><comment><USER5> just loaded in the midwest ok</comment>


Yale's 'happiness' course is available free online - <AUTHOR> https://edition.cnn.com/2020/03/23/health/yale-happiness-course-wellness/index.html <comment><USER2> The link to the course is in the article, but I will post it here too: [https://www.coursera.org/learn/the-science-of-well- being](https://www.coursera.org/learn/the-science-of-well-being) .

<comment><USER3> It looks like it's also available on YouTube (if you don't want to register on Coursera):

[https://www.youtube.com/playlist?list=PLVext98k2eviHGwrB6tNN...](https://www.youtube.com/playlist?list=PLVext98k2eviHGwrB6tNNbvoGB3dUWk0F)

<comment><USER3> Correction: This YouTube link is just the first lecture of the course.

</comment></comment></comment><comment><USER4> The world is a vast meaningless cruel existence that cares nothing about your accomplishments, trials, laments and accomplishments. The important thing is to set an endless string of arbitrary goals to distract yourself until you die.

<comment><USER5> I care about you and your delightful sense of sarcasm, friend.

</comment></comment><comment><USER6> Lol, as if the unhappy bastards at Yale have any business teaching happiness.

Look up how many of their students are on SSRI's

<comment><USER7> As they say, "Those who can't do, teach".</comment></comment>


Curebit (YC W11) Wants To Optimize Your Referral System - <AUTHOR> http://techcrunch.com/2011/10/17/y-combinator-alum-curebit-wants-to-optimize-your-referral-system-to-turn-your-customers-into-marketers/

<comment><USER2> This is the kind of thing that you really need, but that would take way too much time / skills you don't have to do well (or as well as people whose job it is do t his well).

Would much rather plug-and-play this kind of solution than build it ourselves. And for a ~15% increase in sales, its kind of a "no brainer". Launching our webapp in December, looking forward to implementing this.

</comment><comment><USER3> Good stuff. How bout accumulable premium/discount rate for each user based on his or her gross referral sales? wait, I smell Amway in the air.

</comment><comment><USER4> Genuinely excited about these guys. Referral systems are _hard_, social referral programs are potentially worth a lot of money.

</comment><comment> old-gregg Congrats on launching, guys!

</comment><comment><USER5> So stoked...!!!

</comment><comment><USER6> Nice job Allan.</comment>


Show HN: Commute Time Calculator - <AUTHOR> http://pminkov.github.io/commute/ <comment><USER2> This is pretty neat. Can you explain the time zone debug output? Is 6am in the table actually 6am in my local time when I run it?

<comment><AUTHOR> Thanks. 6AM in the table is 6AM where your location "A" is. This way, you can be in the Bay Area and query for commute times in New York, if you need to.

It prints: Monday, 6am (target) is the same as following local time: Mon Mar 27 2017 03:00:00 GMT-0700 (PDT)

Indeed, I'm in the Bay Area and I have to pass 3AM PDT to Google's API in order to get traffic for 6AM New York time. There might be a way to change the timezone with JS, but I didn't find it, so I'm just passing adjusted times from the local time zone.

<comment><USER2> Thanks for the quick reply and the explanation!</comment></comment></comment>


The Next Graphene? - <AUTHOR> https://www.sciencemag.org/news/2019/11/next-graphene-shiny-and-magnetic-new-form-pure-carbon-dazzles-potential <comment><USER2> It's not terribly hard for something to be the next graphene, being that graphene's main characteristic is that it generates good clickbait headlines for things it can do under very specific lab conditions but decades after discovery still has no significant practical applications.</comment>


Who Says C is Simple? (2010) - <AUTHOR> http://www.eecs.berkeley.edu/~necula/cil/cil016.html <comment><USER2> All of the examples here are _really_ horrible code. This is the second article in a few days on Hacker News to list out a few examples of how hard C is. And for little reason; there's _absolutely no value_ in being able to write something like:

        return ({goto L; 0;}) && ({L: 5;});

It probably has a bug, will be hard to debug, and isn't more performant than writing it in a clearer way. And unfortunately, while the examples here are probably all contrived, there are plenty of real-life cases where code as bad as this gets into production systems.

So why are we still writing code like this?

The answer is reverse compatibility. Not just of compilers, but of tools and skillsets: people are unwilling to support multiple versions of C and want their code to run forever.

Objective-C and C++ do things to add functionality to C, but they don't remove the functionality of C that allows these kinds of problems.

This points to a need for a new language that avoids these issues. I think Rust is the answer, but I would like to see more languages try to fill that gap--competition is healthy.

<comment><USER3> > This points to a need for a new language that avoids these issues. I think > Rust is the answer, but I would like to see more languages try to fill that > gap--competition is healthy.

Programs written in C and C++ may have issues because the languages assume the programmer knows what they are doing. This assumption leads to some great solutions to hard problems because the programmer is essentially free to do what they want.

Of course, this assumption, as with most others, doesn't always hold true. This doesn't mean there is a problem with the language. The problem is with the programmer.

If you're going to write something like "return ({goto L; 0;}) && ({L: 5;});", no language is going to save you.

C and C++ are still used today, in part, because modern languages try to restrict the programmer. Rather than assume the programmer knows what they are doing, they assume the programmer is stupid and needs help to cross the road. By assuming stupidity, the restrictions modern languages put in place prohibit certain solutions and as such C and C++ will remain the go-to systems languages.

We do not need new languages. What we need is programmers who won't abuse the languages we already have.

<comment><USER2> > Programs written in C and C++ may have issues because the languages assume > the programmer knows what they are doing. This assumption leads to some > great solutions to hard problems because the programmer is essentially free > to do what they want.

There's an assumption here that it would be impossible to design a language which would make these solutions available without being as error prone. Existing languages may be less capable than C, but that's only because equally capable languages with less risk haven't been created (Rust may be a solution, I'm not sure yet).

What exactly do you think _can't_ be done in a language that is less error- prone?

> We do not need new languages. What we need is programmers who won't abuse > the languages we already have.

You're part of the problem. It takes incredible hubris to say something like this, to think that it's even possible for a human to do this.

Every nontrivial networking program written in C has security holes caused by memory management issues. If you're going to claim that these errors are caused by bad programmers, then every C programmer is a bad programmer, because every C programmer has written bugs like this. If you're claiming that bugs caused by C's error-prone semantics are programmers abusing the language, then _using C is equivalent to abusing C_. The very best programmers writing C write bugs in C that they wouldn't write in a language like Rust.

A system which depends on humans being perfect is bound to fail. There's simply no way you can reasonably debate this fact.

Every other engineering field has redundancy, multiple layers of error checking that catch errors.

Until you see this as a problem then you're a danger to any mission-critical product you work on. Not understanding that using C is a risk displays a shocking level of naiveté for a professional in this field. I'm not saying C is never a good choice. I write a lot of C myself, but I do so with the awareness that my code is not being checked adequately and that I have to take extreme measures to ensure that my code is well-validated.

</comment></comment></comment><comment><USER4> C is simple to compile into nearly-optimal code, or at least it was back in the 1970s, when computers had single-opcode dispatch or trivial pipelines, no SIMD hardware, no other parallelism worth mentioning, and it wasn't worth worrying about cache too much. (Running in the registers was a neater trick.)

That meant it was relatively simple to 'see' the assembly language 'behind' a given C function or stretch of code; it didn't take much to get inside the head of a C compiler, so you could be reasonably sure that a simple piece of C would result in a similarly simple piece of assembly out the other end.

That, of course, was well and good when it was reasonably simple to predict actual performance from glancing at assembly code, which assumes opcode performance (as opposed to, say, cache performance) dominates how fast the code runs.

Now... how many of those things still hold true on desktop and server class hardware?

<comment><USER5> But everything that came after C hasn't improved on this, at all. In fact, languages now dominate that aren't compiled.

So as it stands, C is still your best bet when you are looking for that optimal translation. Intel has recently made some effort to augment it in ways to fully utilize new CPUs various parallel pipelines and specific functionality:

[https://ispc.github.io/](https://ispc.github.io/)

<comment><USER6> ISPC is cool, what it helps out with (writing the SIMD kernel) has never really been the bottleneck in my experience.

The data still has to be arranged optimally for the hardware in order for SIMD code to have any benefit (and at this point, writing SIMD code is straightforward). You also still need to be experienced with the capabilities of the hardware if you have any chance of writing good ISPC code (although this is true of C, as well as any shading language).

That said, using it to target SSE and AVX with the same code is attractive.

</comment></comment></comment><comment><USER7> The first two invoke UB and are thus completely illogical.

<comment><USER8> UB? I don't get the first one.

<comment><USER9> Reading an uninitialized variable is UB.

<comment><USER10> Is it a local? I think the int declaration is for showing the type of x. It's just a code fragment as is.

<comment><USER9> Fair point, we don't have context.

</comment></comment></comment></comment></comment><comment><USER11> I stopped reading after the explanations about _return ((1 - sizeof(int)) >> 32);_

Unless size_t is wider than 32 bits, it has undefined behavior. That's why it returns 0; it could as well be 42, or the program could terminate with or without a diagnostic message, etc.

</comment><comment><USER12> Who says simple things always yield simple results?

<comment><USER4> Depends on how you define simple:

If something is simple for the compiler-writer, then simple things do yield simple results.

If something is simple for the programmer, simple things often yield quite complex results.

For example, in a language that's simple for the compiler-writer, (1/10) times 10 is only very rarely 1. 0 is a common answer, as is some fraction which is almost, but not completely, unlike 1.

In a language which is simple for the programmer, Heaven, Earth, and minor deities will be moved to make (1/10) times 10 come out to the obvious, simple answer.

<comment><USER12> It really only depends on if you define simple as "can only derive simple results."

And, you do realize that one of the simplest languages for compiler writers, lisp, doesn't have to move heaven/earth to make that calculation work out how you want it.

<comment><USER2> > And, you do realize that one of the simplest languages for compiler writers, > lisp, doesn't have to move heaven/earth to make that calculation work out > how you want it.

I've written a C compiler and am currently writing a Lisp compiler, and I'm not sure where you get the idea that Lisp is a simple language for compiler writers. Lisp's simple representation belies a very complicated runtime, to the point that the majority of Lisp implementations don't support compilation at all--they're interpreted only.

<comment><USER12> This seems to get back to the other debate that crops up with "simplest." Just because I posit that it is one of the simplest languages, does not mean I imply it is by definition simple.

<comment><USER2> I'm pretty comfortable with asserting that there's no reasonable definition of "simple" which would make a mature Lisp compiler simpler than a mature C compiler.

<comment><USER12> Fair, though I am focusing on the less mature situations. Specifically, a naive lisp evaluator is much easier than a C compiler.

Are there any mature compilers, for any language, that would qualify as simple?

<comment><USER2> > Specifically, a naive lisp evaluator is much easier than a C compiler.

That's true, but a naive Lisp evaluator is a) not a compiler, and b) not correct. A naive implementation of Lisp leaks memory very rapidly, and obvious memory management schemes fail. Garbage collection was invented for Lisp to deal with these problems, and even assuming an immature implementation, GC isn't trivial. The simplest implementation of mark-and-sweep garbage collection requires a lot of discipline to make sure that objects are correctly allocated so that in-scope objects are kept live and out-of-scope objects are discoverable as dead. Even if you're writing your own allocator for C, that allocator is pretty trivial in comparison.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> who said C is simple? :S

<comment><USER9> C _is_ simple, but that doesn't mean it's not powerful, and with power comes... yada yada yada. There are many edge cases to be sure, but as a language, its constructs and features are very simple.

</comment></comment><comment><USER14> Can anybody figure out the year on this one? Internet Archive says 2011 but it seems it might be earlier.

<comment><USER15> This URL [http://www.eecs.berkeley.edu/~necula/cil/cil002.html#toc1](http://www.eecs.berkeley.edu/~necula/cil/cil002.html#toc1) mentions cil version 1.3.7. Changelog [http://www.eecs.berkeley.edu/~necula/cil/changes.html](http://www.eecs.berkeley.edu/~necula/cil/changes.html) says 1.3.7 was released on 2009-04-24.

<comment><USER14> But 2010 may just have been when they stopped updating a version number. It looks like early 2000s material to me, based on nothing in particular. There's also this:

 _When I (George) started to write CIL I thought it was going to take two weeks. Exactly a year has passed since then and I am still fixing bugs in it_

The CIL paper was published in 2002. Actually the whole project looks interesting—arguably more so than the currently posted page. It should have its own HN thread sometime. [https://news.ycombinator.com/item?id=836735](https://news.ycombinator.com/item?id=836735) was a while ago!

</comment></comment></comment><comment><USER16> I've been looking for this for months, I wanted to link this to my friend who said he prefers C to Java for his CS classes.

<comment><USER17> Come on, almost any language I can think of is a better fit for CS classes than Java.

<comment><USER16> But get this, he said Java was HARD. Compared to C?</comment></comment></comment>


Microsoft Teams passes 44M daily active users, thanks in part to Covid-19 - <AUTHOR> https://venturebeat.com/2020/03/19/microsoft-teams-passes-44-million-daily-active-users-thanks-in-part-to-coronavirus/ <comment> frosted-flakes The real-time noise suppression seems like a really neat idea if it works well. Opening a chip bag or typing on a loud keyboard is one thing, but I wonder how it would handle intermittent or one-off noises like opening a pop can?</comment>


Looking for a Sign: Hobo Communication in the Depression - <AUTHOR> https://www.nsa.gov/about/cryptologic_heritage/museum/virtual_tour/museum_tour_text.shtml#hobo_communication

<comment><AUTHOR> See samples of hobo signs. [https://www.nsa.gov/about/_files/cryptologic_heritage/museum...](https://www.nsa.gov/about/_files/cryptologic_heritage/museum/library/hobo_signs_definitions.pdf)</comment>


NSA Rejection of Digital FOIA - <AUTHOR> http://blog.jarrett.io/post/53847082072/nsa-response-to-foia-request

<comment><USER2> If you are the sort of person who is surprised by this, you need to get out from under the rock you live under. This is what any self-respecting intelligence gathering organization is going to say. Not revealing whether or not information exists (let alone the actual information itself) has been a staple of the trade from the very beginning of the intelligence community. This response would be identical regardless of current events.

edit: typos

<comment><USER3> Here's how I interpreted the letter: "We cannot confirm or deny the thing you requested exists because that thing you requested is classified". Unless all FOIA fail, it seems to me, in some broad sense, that they just confirmed the existence of the requested material.

<comment><USER4> Read as "We cannot confirm or deny the thing you requested exists because if it exists/existed it would be classified, and that includes your request of whether it exists."

<comment><USER5> I read it this way: "we are asserting our 5th amendment right to neither confirm or deny we violated your 4th and 5th amendment rights so you can't sue us and have some uppity judge make us follow the law."

</comment></comment></comment></comment><comment><USER6> This what's known as a Glomar response: [http://en.wikipedia.org/wiki/Glomar_response](http://en.wikipedia.org/wiki/Glomar_response)

That developed in law thanks to the press uncovering a secret, massive sunken- sub-raising boat built by Howard Hughes for the CIA to retrieve a lost Soviet sub (yes, the very thing that The Hunt for Red October was based on).

<comment><USER7> > Lower court precedent has thus far ruled the Glomar response to have > potential merit, _if the secretive nature of the material truly requires it_ > , and only if the agency provides "as much information as possible" to > justify its claim. Otherwise, the principles established in FOIA may trump > claims to secrecy.

Is it required if they have no data collected and the subject isn't under investigation?

<comment><USER8> Is what required?

</comment></comment></comment><comment><USER9> We can't tell you if we are monitoring you. Or what capabilities for monitoring we have. Despite you being a US citizen which we would have no reason to monitor.

Scary stuff folks.

<comment><USER10> You can't expect the secret police to divulge their secrets.

<comment><USER11> Ooh gestapit..

</comment></comment></comment><comment><USER12> Last week: We'd be happy to respond to requests submitted via the handy dandy online form - these paper copies are invalid.

Today: We're sorry, if we told you of the existence or non-existence of data about you it would help terrorists.

<comment><USER13> "I know," says spook1 to spook2, "We'll put up a web page where the rubes can enter their address, and have it automatically send them a FOIA_GLOMAR_GO_JUMP_IN_A_LAKE_HA_HA.pdf"

</comment></comment><comment><USER14> I cannot confirm or deny the existence or non-existence of a sense of humour, irony or shame on the part of the poor functionary who had to send out that response.

<comment><USER15> One of my favorite lines from Men In Black: "We at the FBI do not have a sense of humor that we are aware of."

</comment></comment><comment><USER16> I received pretty much the exact same response in the mail yesterday.

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

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

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

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

</comment><comment><USER17> Absolute crap. Denied by an executive order, which is not legislated law and definitely does NOT supersede the law that put the FOIA process into place. This is garbage.

</comment><comment><USER18> tl;dr:

Dear FOIA requestor,

You get nothing, by law. It's for your own protection.

Sincerely,

NSA

</comment><comment><USER19> Jarrett, can you post higher res images or an OCRed version? Those images are so small the text is about 4pt on my screen.

<comment><AUTHOR> Sure thing, gimme a sec

<comment><AUTHOR> [https://www.dropbox.com/sh/b8d4bb9pfgryj3t/mGBrXRzkkY](https://www.dropbox.com/sh/b8d4bb9pfgryj3t/mGBrXRzkkY)

Lmk if this helps

</comment></comment></comment><comment><USER20> I'm surprised they actually replied to you. A reply is admitting they exist, which they can not confirm nor deny.

<comment><USER21> A reply does no such thing. They can say that your request is denied without even looking to see if the information exists first.

They're not saying, "It's there, we're just not going to admit it." They're saying "We're not even going to begin looking for it."

<comment><USER22> I think gp was saying: to reply to your letter is to confirm the existence of the body, the NSA itself, who received and replied to your request.

Now we know they exist!!!

<comment><USER23> We always knew NSA existed. Some of the other guys, however...

</comment></comment></comment></comment><comment><USER24> When did the NSA start using Georgia? I always thought Times New Roman was more "official".

<comment><USER25> Awesome. A comment on typography. :)

<comment><USER24> Well, it's not like there's any _content_ in this letter to look at :p

</comment></comment></comment><comment><USER26> I hope that someone fights this. :) Just because the NSA determines that something is exempt from FOIA doesn't mean that their determination is lawful. I belive a court will rule that since it is entirely public that they've collected the information, as well as how they've collected it, and there have been government officials who have admitted to the program, their claim of exemption is improper.

</comment><comment><USER27> Hmm what would happen if the entire (US) Hacker News readership sent in an FOIA request at the same time. Maybe we can destroy their photocopiers?

<comment><USER4> Taxes on American HN readers would increase accordingly to cover costs of buying & operating new copiers.

<comment><USER28> Debt, rather. Expenses and taxes are divorced: it's the deficit!

</comment></comment></comment><comment><USER29> The logic makes sense if you assume that the NSA is only using the data to target terrorists. In that scenario, the danger isn't that they will reveal to innocent civilians that they have your data. The danger is the precedent. Want to know if you are on their target list? File a FOIA. If they grant it, you're okay. If they deny it, you're in their sights.

But since we already know that they are collecting this metadata on absolutely everyone, I don't see what good it does to refuse to send it to you, whether you are a suspected terrorist or not. ...I suppose you could be fretting about whether you had slipped up and called Cousin Guido on your regular cell instead of a throw-away prepaid phone.

</comment><comment><USER30> Ps, I've heard that apple will replace your iPhone for those purple specs in the pictures.

<comment><AUTHOR> Oh sick! Thanks!

Yeah, my camera has gone to shit. I'll take it in next time I'm near a store

</comment></comment><comment><USER31> You missed a spot in p1 with the case number.

<comment><AUTHOR> Oops, thanks

</comment></comment><comment><USER32> Surprisingly well-written response actually. Not too hard to figure out what they're talking about.

</comment><comment><USER33> _Were we to provide positive or negative responses to requests such as yours, our adversaries ' compilation of the information provided would reasonably be expected to cause exceptionally grave damage to the national security._

simple as that: _we can 't tell you what you want to know, because we think you are a terrorist_.</comment>


Internationalization made easier with static analysis - <AUTHOR> http://blog.glebm.com/2014/02/27/i18n-made-easier-with-static-analysis.html

<comment><USER2> I don't understand the importance of this gem: isn't this what gettext/Poedit helps you with? Not to be too negative here, I am just wondering how this actually works with Ruby. I am not familiar with the availability of gettext for Ruby, but the two issues can be negated with gettext/Poedit, as far as I know:

> If you use a key that does not exist, this will only blow up at runtime.

Using Poedit scans automatically your source and imports all missing translation keys. It's just a simple step you have to be aware of when dealing with translations.

> Keys left over from removed code accumulate in the resource files, > introducing unnecessary overhead on the translators.

Again, Poedit scans your source and also removes all unused keys.

We're using Poedit for ages and never had troubles with missing keys or orphaned keys. Just use it every time you deal with translations. The only issue you have with Poedit is you cannot translate variables, only strings, but this seems to be the same with i18n-tasks?

<comment><AUTHOR> Poedit looks great, but different from what i18n-tasks offers.

i18n-tasks is on the command line, easily extensible, with configuration that can be easily tailored to the app from data layer to usage search. It is also very easy to integrate it into the test suite.

The default data adapter supports YAML and JSON by default, more common in many web communities (rails, node) than .po.

</comment></comment><comment><USER3> I'd prefer static analysis that extracts strings from calls like t("Check out our Jobs page {{url}}!") and auto-populates the appropriate locale files/databases, etc. Referencing keys all over the place seems like a poor substitute to just writing the content in a natural way and having the tools do the heavy lifting for you. For instance, I know that Twitter and Facebook both handle I18N content in such a way, and you can see the text-strings that they use in the translation dashboards.

There's also a good technical overview of Facebook's I18N framework here: [https://www.quora.com/Facebook-Internationalization/What- was...](https://www.quora.com/Facebook-Internationalization/What-was-the- process-Facebook-went-about-getting-their-website-translated-into-different- languages) .

</comment><comment><USER4> My first observation is that in most of the apps I've worked on keys are composed by constructs such as `t :"something_#{from_the_context}"`, which I assume this tool will miss. I'd much rather see a tool that tracked i18n hits in a k/v store, and used that in addition to the static analysis.

Don't let this discourage you, your work looks great (props on the correctly tabulated output!) - but it would never work for me in what I think is a reasonable usecase :(

<comment><AUTHOR> Such keys _are_ supported to a certain extent (e.g they won't be reported as unused). A runtime tool that tracks runtime misses to the store is a part of ruby i18n gem and many other environments already. I have found such keys to constitute a minority in most projects I've worked on.

</comment></comment><comment><USER5> Great work, Gleb! This is in my top ten list of the best gems out there. We are using it on itbyen.no and it does the job really good.

Keep shipping!</comment>


Ask HN: What is the must have iOS book for the modern developer. - <AUTHOR>

I want a solid book to make sure over the past few years or so working in iOS development, I haven't missed anything, something that isn't a beginners intro, and covers a fairly broad and advanced spectrum.<p>Something that's pretty up to date with modern iOS community practices, too, ideally. <comment><USER2> I think the Big Nerd Ranch book covers (at some level) the broad spectrum of iOS. It may have some "beginner" feel but it wasn't one of those books where it goes over simple language constructs for half of the content. I read it about 6 months ago and I felt it met my needs.

[http://www.bignerdranch.com/book/ios_programming_the_big_ner...](http://www.bignerdranch.com/book/ios_programming_the_big_nerd_ranch_guide_rd_edition_)

</comment><comment><USER3> Anything with iOS 7 in the title. Definitely stay away from any books before iOS6 because there have been a lot of changes since the boom days of iOS books.

Not sure why you want to stick with community practice though. Who says the community is doing things the right way?

Check out "Functional Reactive Programming on iOS" for a more modern take on programming in general and how you can leverage it to make iOS apps.

</comment><comment><USER4> There are so many great guides on [https://developer.apple.com/library/ios/navigation/](https://developer.apple.com/library/ios/navigation/), that you shouldn't look for any book. I highly recommend WWDC materials as well. Up to date stuff and really well presented.</comment>


Build vs. buy: patterns and antipatterns - <AUTHOR> https://mux.com/blog/build-or-buy-patterns/ <comment><USER2> Nice write up! I would add another dimension to when you build on your own. If your business requires customization.Eg. build your own CDN with custom transport protocol(just came up with something)

</comment><comment><USER3> A prime example of this that I've personally run into is operations tooling. How many times has logging infrastructure been built from the ground up? I can think of a company (which are pretty great, to be fair), whose core business failed but ended up spinning out their logging infrastructure as a standalone product. The logging product is actually really good, but it begs the question if their focus on building logging infra distracted from their core business.</comment>


If I Were You: Perceptual Illusion of Body Swapping - <AUTHOR> http://www.plosone.org/article/info:doi/10.1371/journal.pone.0003832 <comment><USER2> That was fascinating. Why did I keep thinking of Trevor Blackwell and Monty? :)

Seriously; In a world filled with magazine articles stripped of all science and sensationalized beyond recognition, its nice sometimes to read the real deal instead of some nonsense about "the real body snatchers" etc.

</comment><comment><USER3> Some of the occurrences here could explain "out of body" experiences, the reported loss of connection during rage, and similar slightly paranormal events. It seems the brain is not quite as connected to our bodies as we'd expect..</comment>


An interview with Michael Lopp - <AUTHOR> http://michael.lopp.usesthis.com/ <comment><AUTHOR> I get the distinct impression he doesn't work at Apple anymore. Anyone know when that changed?

<comment><USER2> A few weeks before the most recent WWDC. I believe he left for a stealth mode startup (which I don't know the name of, or anything else for that matter).

<comment><USER3> i believe he's working at palantir tech now (in the old facebook offices in palo alto)

</comment></comment></comment><comment><USER4> Nitpick - The alt text for the "Being Geek" book reads "The site for Michael's book, 'Being a Geek'."

<comment><USER4> Ok one more - Johnson Murphy is actually Johnston Murphy.</comment></comment>


NFL Teams Should Use More Trick Plays - <AUTHOR> http://underamp.com/?p=78

<comment><USER2> You need more of the probability distribution for the plays to make that decision. Most trick plays involve a handoff deep in the backfield which can result in large losses, which can kill drives. One reason why football teams run the ball even though the yards per play is lower than passing is that the lower variability of yardage gain helps to sustain drives resulting in points.

On 4th down you need to figure in the opportunity cost of the punt (~35 net yards). There was a paper ~12 years ago that covered this in detail using a dynamic programming approach to calculate the value of a first down at each yard line for a team, to calculate the value of say punting. It concluded NFL teams punt too much. Nowadays you see a lot more 4th down attempts than 10 years ago. I duplicated this approach for Division 3 college games and came up with an even more aggressive result.

But good read, it gave me an idea for some analysis myself.

</comment><comment><USER3> This is a fun post. I love stuff like this. I don't think, however, that it's a particularly good example of "good analysis" - this analysis is clearly done either by (a) someone who isn't fully aware of all of the various strategies and nuances of NFL football, or (b) someone who is aware of such things but was in a rush to get this post written. There's just too much missing information to draw any conclusions such as those drawn by OP.

A trick's play's success rate is based on many factors. Saying that the down number is the primary factor is like rating a woman's attractiveness by how smart she is. Such a rating would, of course, give you false positives and negatives because it represents only part of the whole. A trick play's success rate depends on down number, position on the field, the clock, defensive tendencies, score, weather, field conditions, player injuries, and more. For example, a flea flicker isn't going to be attempted as often in really bad weather, or when you are up by four touchdowns, or when the main player who is the ultimate receiver of the ball (the "flea", perhaps?) is out of the game due to injury.

So I like this sort of analysis but it's completely useless due to its incompleteness. But I still am glad OP shared because I like seeing all the thoughts, functions, and so forth.

</comment><comment><USER4> The 1977 Broncos finished the regular season with one loss to the Dallas Cowboys. It seemed a bit fragile to me, though, given the three or four games won by trick plays. They me the Cowboys in the Super Bowl, and were soundly beaten...

</comment><comment><USER5> If you call more trick plays, you're less likely to trick people with them ...

<comment><AUTHOR> _Using, say, four more trick plays per season could mean the difference between making the playoffs and not making the playoffs, and probably would not change the way defenses behave much. There's a sweet spot here of using trick plays and being unpredictable that not many coaches play with. It's also difficult for a defense to change their play style in order to counter trick plays without sacrificing defensive efficiency on standard plays. There are obviously lots of points to be made here._</comment></comment>


Encoding.com Opens Vid.ly - A Single URL For Videos You Can Watch Anywhere - <AUTHOR> http://techcrunch.com/2011/03/25/encoding-com-opens-vid-ly-a-single-url-for-videos-you-can-watch-anywhere/

<comment><USER2> Well... looks good. I tested it on 3 different devices and it worked excellently on all of them.</comment>


OAuth - Everything You Want to Know (Hopefully) - <AUTHOR> http://www.infoq.com/presentations/OAuth

<comment><USER2> I wish all articles consisting of only video had a warning. I hate videos. I am way too impatient to wait for someone to say something. I also wish I could block all videos from my google results. /rant-off</comment>


Second layer of information in DNA confirmed - <AUTHOR> http://phys.org/news/2016-06-layer-dna.html <comment><USER2> No theoretical simulations (that's what this paper is) can confirm anything. The paper itself explicitly says that: Taken together, all these findings suggest the intriguing possibility that nucleosome positions are the product of a mechanical evolution of DNA molecules.</comment>


lessdate, the new online calendar in public beta - <AUTHOR>

Out of frustration and limited user experience using Google Calendar and dependency with other third party plugins, lessdate aims to provide a better calendar and up-to-date with the current trend and use. Hence, a modern, cool and dead simple calendar on all devices for everyone is created.
Some of its unique features are intelligent icons rendered based on input text, a set of wallpapers to choose from and other basic and user centric features. Not too complex and overloaded stuff.
Give it a try and feedbacks are much appreciated. Thank you!
http://www.lessdate.com <comment><USER2> Some screenshots etc. would be nice so I can get an idea if it's worth signing up.

<comment><AUTHOR> Thanks for the reply. You can look at [http://www.lessdate.com/img/screenshot.jpg](http://www.lessdate.com/img/screenshot.jpg) which shows the basic use.

As mentioned, you can set wallpaper for cooler interface. Another differentiator is the smart icon. Try input text like "lunch" and you'll see the magic :) ultimately, the app focuses only in basic needs and try not to confuse users

<comment><AUTHOR> Added explained screenshot to the main page which describes the features in a nutshell. Thanks for the suggestion.

Direct link - [http://www.lessdate.com/img/screenshot_explained.jpg](http://www.lessdate.com/img/screenshot_explained.jpg)</comment></comment></comment>


Concurrency is not Parallelism. Rob Pike at Waza 2012 [video] - <AUTHOR> https://blog.heroku.com/archives/2013/2/24/concurrency_is_not_parallelism/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+heroku+%28Heroku+News%29 <comment><USER3> You have four tasks A, B, C and D. B and C both depend on the result of A, D depends on the result of B and C. Now B and C are concurrent because there is no dependency between them - you can execute these tasks in order ABCD or ACBD. It is only important that A executes before and D after B and C. And there is a third option - you can execute B and C at the same time making the execution parallel. So concurrency is about dependencies between tasks or the lack of them while parallelism is about actually executing independent tasks at the same time.

<comment><USER4> > So concurrency is about dependencies between tasks or the lack of them while > parallelism is about actually executing independent tasks at the same time.

I understand what you're getting at, but I don't think that's a great summary of concurrency vs. parallelism. My version would be: currency is about non- determinism and multiple threads of control while parallelism is about doing multiple computations at once for performance reasons (possibly deterministically).

EDIT: sorry I see this has already been posted almost verbatim a few other places in the thread

<comment><USER3> I personally would not draw a (strong) line between concurrency and nondeterminism - while concurrent (real-world) systems usually show a fair amount of nondeterminism there is still no inherent requirement for that. The dependencies are static and one can always schedule task execution in a fully deterministic way.

<comment><USER4> Well, sure we're assuming ultimately some sort of deterministic result of our computation, but we're discussing pl semantics and properties of the computation itself, and non-deterministic semantics are one of the most important characteristics of concurrent programming, no?

<comment><USER3> We definitely want a deterministic result for every task execution even if the execution of some subtasks happens nondeterministically. But after rethinking what I wrote last time I would now even strengthen my statement. Concurrency is a structural property of a system, parallelism is property of an (specific) schedule of subtasks and therefore a property of the runtime behavior of a task. Nondeterminism is also a property of the runtime behavior and therefore nondeterminism MAY be associated with parallelism but CAN NOT be associated with concurrency.

</comment></comment></comment></comment></comment><comment><USER5> The irony was not lost on me... Heroku posts a video of Rob Pike discussing intelligent routing (load balancing) using concurrent go a week after the "random load balancing fiasco" [1]. I chuckled.

[1] <http://news.ycombinator.com/item?id=5215884>

<comment> grey-area Yes although the example given by Rob Pike highlights all the information that would have to be shared between the load balancer and the web processes in real time in order to make intelligent routing work well.

Very hard to enforce when you're running a heterogenous network trying to handle routing which may have any kind of app answering requests. If there was an easy solution to this, evidently Heroku would have put it in already, but I'd hope they're working on it.

Sounds like some of their customers have outgrown them though; given the amount they are paying per month they could easily host themselves and hire someone to look after their servers - at some point it becomes necessary to control your entire stack if you're looking at performance.

</comment></comment><comment><USER6> The difference, as I understand it, is actually pretty simple... This suggests to me that the confusion is due to the synonymy of the terms in common usage. Without making any claims about the quality of this presentation specifically, I wonder why anyone would insist on using them and inevitably have to lecture perfectly smart people about why they don't mean the same thing...

<comment><USER7> I listened to his presentation. IMHO the presenter laid too much stress on parallelism and concurrency being different, but never explained the difference clearly and succinctly. But from the presenter's side, I can see that he needs to sell his product(golang). Therefore he assumed that - <USER2> definitions are often confused, it is a big issue, and go is 42.

<comment><USER8> These terms have been confused since the early 90s at least. It is one of the first things we systems people learn: concurrency is doing multiple things at once because you must, parallelism is doing multiple things at once because you can.

Infrastructure and techniques that support concurrency (e.g. actors) are almost always totally unsuitable to parallelism (e.g. SIMD ala GPUs), and the other way around. Likewise, skills don't transfer very well between the two fields. So when someone talks about this technology being useful to your use case, and they've confused the terms, its very annoying (you should use actors to get more parallelism, WTF????).

<comment><USER9> You're taking a pretty narrow view of parallel computing. For example, there are plenty of systems that use essentially actor models for large-scale parallel computation, e.g. Charm++ and HPX.

<comment><USER8> Isn't Charm++ infrastructure comparable to MPI? In that case, its not clear what the goals are. I think it was during the MPI-phase that we began to realize that we had two very different problems on our hands. Fine-grained message passing has been obsolete in the parallel field at least for awhile now.

<comment><USER10> Do you say that MPI is obsolete? I thought most legacy codes in HPC based on MPI?

<comment><USER8> You know, its rude to say something is obsolete in this field, so we just say...there are other choices and hope the hint is taken. Nothing ever dies quickly, it just fades away off into the sunset.

There is a lot of legacy code running with MPI for sure, but the big data and almost big data trends are clear, and CUDA has been absolutely disruptive in the scientific computing field (though some people are beginning to use MapReduce here also).

<comment><USER10> yeah, I always map CUDA blocks to racks and CUDA threads to blades ;)

GPUs, Xeon Phi, FPGAs and other accelerators still need somebody managing them. Nobody said it should be MPI, but there are still many hybrid architectures with MPI handling distribution and actual compute done using OpenMP or accelerators.

In my system I use Erlang/OTP to handle distribution and concurrency and OpenCL for data-parallel compute.

<comment><USER8> > yeah, I always map CUDA blocks to racks and CUDA threads to blades ;)

Sounds like Jeff Dean.

> Nobody said it should be MPI, but there are still many hybrid architectures > with MPI handling distribution and actual compute done using OpenMP or > accelerators.

MPI or even RPC works fine as a control mechanism, just not as a critical performance-sensitive abstraction, where we care about the width and speed of the pipe, and MPI is nothing like a pipe!

> In my system I use Erlang/OTP to handle distribution and concurrency and > OpenCL for data-parallel compute.

This is quite reasonable. Once one understands the difference between concurrency and parallelism, they can pick appropriate tools to deal with each. As long as they confuse the issues, they'll make bad choices.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> I really love this talk, but man oh man the gophers are seriously creepy.

<comment><USER12> They're not so creepy compared to some of the artist's other work: <http://reneefrench.blogspot.com/>

<comment><USER11> Thanks for sharing, everything makes more sense now.

</comment></comment></comment><comment><USER13> I'm trying to wrap my head around this, not being familiar with Go yet... is this analogous to the difference between a Task and a Thread in the .net world?

<comment><USER14> A task is a future or a promise which can deliver a result later. A Goroutine in go is more general than a task because they don't have to terminate when they deliver a result. The subsume tasks in any way.

Goroutines are mapped onto (kernel-level) threads in order to make it possible to run more of them at once and thus provide parallel execution. Otherwise, you have a single scheduler of goroutines in a single process. You can still switch context between the goroutines, thus the system is concurrent. But it will not be parallel: One goroutine only at a time.

For a system in which most goroutines wait on IO or the network, it may not be a problem to run many goroutines on a single core only.

<comment><USER13> I still don't quite follow. What do you mean by "terminate" a task? From my understanding, when a Task returned, the underlying Thread would be returned to the common pool for use by other Tasks. Does the Go scheduler detect when a task is blocked for IO, and reuse the thread for other goroutines?

</comment></comment></comment><comment><USER15> tl;dr Parallelism implies concurrency but concurrency doesn't imply parallelism.

<comment><USER16> It's a bit more nuanced than that. Concurrency implies non determinism. For example if you have multiple threads then the result of the program is non deterministic: it may depend on the particular interleaving of the threads over time. Parallelism is about executing multiple things at the same time to improve performance. You can have parallelism without concurrency. For example a parallel map operation is parallel, but not non deterministic. It always gives the same result. Now, under the hood to implement parallel map, there is probably some concurrency involved, but that is not exposed in the interface of map. You can have concurrency without multiple threads, for example Node with asynchronous callbacks is concurrent, because the order in which those callbacks get called is non deterministic. But it does not necessarily need to run on multiple threads. Usually we don't want the end result of our program to be non deterministic, so we use synchronization primitives like locks and Go's channels to limit the non determinism in such a way that it does not affect the end result.

What most people don't realize is that for concurrency to be useful, there must be parallelism. But wait, didn't I just say that in Node you have concurrency without multiple threads? Yes, but the parallelism does not need to be in your CPU! If you do an asynchronous disk read, or an asynchronous network request, the disk and other computers on your network are working in parallel with your program. Concurrency allows us to exploit that parallelism, so that the CPU can do useful work while the disk is busy reading our data.

Now, you can write your program with concurrency, but if there is no parallelism anywhere in the system, that's not useful. So in practice it is the reverse: concurrency implies parallelism (but not necessarily on the CPU), but parallelism does not imply visible concurrency (though it might be hidden under the hood of a parallel construct like parallel map).

<comment><USER17> > What most people don't realize is that for concurrency to be useful, there > must be parallelism.

No, as far as I understand from this and other talks, Rob Pike argues that concurrency is useful even without parallelism: it's a better way to structure software. A nice example for this is shown in his talk about lexical scanning in Go: <http://www.youtube.com/watch?v=HxaD_trXwRE>

<comment><USER16> I'd say concurrency is a bit overkill for that problem (i.e. threads or processes scheduled by the run time system that appears non-deterministic to the programmer). Deterministic coroutines work fine. Even Python generators are sufficient.

Though perhaps "useful" is a bit too broad: maybe it should be replaced by:

> What most people don't realize is that for concurrency to improve > performance, there must be parallelism.</comment></comment></comment></comment>