Ask HN: How do you pay remote employees in different countries? - <AUTHOR> I'm on of the founders of a small but fast growing startup. We're a team distributed across Europe, and so far we've had the fortune that everybody we employed had a sole proprietorship lying on the shelf somewhere.<p>But as we're growing, we can't keep asking every single employee to begin a company, right? Also, starting a mailbox firm in every country where >0 employees live sounds like administrative hell. How do other distributed teams (across borders) solve this? <comment><USER2> The best way to go about is ask you remote 'employees' to invoice your company. They are independent contractors and are responsible for their own taxes and social security payments.

Don't think that being a contractor is hard, in some countries you can just start invoicing without any company creation or registration as long as you declare the income and pay required taxes.

The downside is that anyone working as an independent contract can up and quit at moments notice. If you try to enforce exclusivity or a full time, fixed 'employment' roster some countries can sue you for fraud. The idea being that you are using contractors for full time employees and thus your company should pay employer taxes in that country.

<comment><USER3> >The best way to go about is ask you remote 'employees' to invoice your company. They are independent contractors and are responsible for their own taxes and social security payments.

This isn't legal in the Us except under specific circumstances. Whether I'm a contractor or an employee isn't my choice – the IRS has a pretty clear distinction between the two.

[https://www.irs.gov/newsroom/understanding-employee-vs- contr...](https://www.irs.gov/newsroom/understanding-employee-vs-contractor- designation)

<comment><USER4> Just send your employees all their work through an app that has a take it or leave it option on the price you'd pay them with no negotiation. Now they are all magically contractors while still acting like FTEs

<comment><USER3> I like the way you think! Ever considered using that idea to take on the taxi industry?

</comment></comment></comment></comment><comment><USER5> Transferwise Business offers an international payroll solution: [https://transferwise.com/gb/business/international- payroll-v...](https://transferwise.com/gb/business/international-payroll-via- batch-payments)

(I don't work for Transferwise, just a huge fan of their service)

<comment><AUTHOR> Thanks! But I don't see much about payroll there, only about transfers. Do they also do actual payrolling? I.e. dealing with taxes, employment laws, etc etc?

<comment><USER6> No, and no company will because of the liability and fraud.

They freelance, you pay them what you promise and that's it.

</comment></comment></comment><comment><USER7> You have 2 options:

1\. Hire them as "freelancer/self employed" and let them invoice your company. They can either invoice as individuals or through their own company if setup. But laws get tricky depending on countries. For example, if you are an employer-based out of the US and the freelancer is NOT a US person (US person has a specific definition) , you need them to fill out something called W8-BEN form but you need to talk to a CPA/tax lawyer to determine if that's the right setup.

2\. If you have more than 1 person from the same remote country, you may have to setup a subsidiary of some sort which again depends on where your business is setup and where the remote team is setup. That subsidiary can then still provide services to the parent company etc. But it then adds tons of overhead for the remote country laws, business setup and also something called "Transfer Pricing". Can get complex for smaller companies. But the advantage of this option is that you have an official local company that can pay employees on payroll, follow the local employment and tax laws etc.

<comment><USER8> That's seems pretty convoluted. Are the any companies that can take care of these things for you?

<comment><USER8> Apparently there is this: [https://news.ycombinator.com/item?id=18170086](https://news.ycombinator.com/item?id=18170086)

EDIT: I think the comment is wrong actually, trinet only offers this service for companies and employees in the US.

</comment></comment></comment><comment><USER9> As far as I know, the only way to avoid creating a tax nexus in each country where you have "employees" (or contractors) is to make sure the contractors invoice you. The way this usually works is indeed the contractors have a sole proprietorship or legal entity from which they invoice you.

If you just pay them without an invoice but as payroll then congratulations you're now on the hook for all taxes and social security payments in the country your now-employee works in, no matter what's in the contract. In fact you might have committed a crime against local labour law by putting in the contract that you're explicitly not liable for social security payments, benefits or business-side taxes. By not registering a mailbox firm in that country you're probably also committing some crime because this means you couldn't meet any of the local labour law obligations.

This may work while everything is peachy while you pay them a higher amount which they can use to pay their social security themselves, but if your now- employee ever gets a grudge against you, they can easily file a lawsuit against you, and it'll be hard for you to defend. Your now-ex-employee will keep the inflated salary, having not paid the security benefits, and you'll be on the hook for back-paying all tax and social security payments with interest plus a fine.

Especially as a startup you don't want to deal with all these administrative overheads. Just request that each person sets up a business from which they can invoice you, and that they get an accountant to help them with whatever obligations that comes with. You can suggest to pay for the accountant. It's not actually that big of a deal and will allow each person to meet the local obligations, which they (or the local accountant) will know better than you. Note that they themselves then become liable for taxes and social security payments, as someone always is.

<comment><USER10> This works if you have a person(s) for a period of time. But, the longer they work for you 100% of the time, and the more team members you have in a jurisdiction the more likely the team members are to be considered employees and that you have established a business in the jurisdiction. At least in the UK the separate company and 'invoice' rule is important, but there are a number of other questions used to determine if someone is an employee.

As you note, the other big problem is that it places you in a very uncertain situation with labour law / labour relations.

<comment> em-bee how can a remote country force me to open a local business entity? i am not there, so they can't get me. they can only get my contractors which would hurt them, not me. (the worst is i could loose them, and they'd be out of work)

the remote country would have to have an agreement with my country to be able to force me to change anything.

(the european union counts as one country here, so i am asking about the case where at least one party is outside)

greetings, eMBee.

<comment><USER10> Well it depends on whether doing things the legally correct way is important or not to you?

For a small team it's unlikely as the cost of enforcement outweighs the benefit. But as you grow the amounts become more significant and there are plenty of impacts of not doing things properly. Here are way this could impact a business:

* The business won't be able to legally carry out business (e.g. sales) in the jurisdiction because there'll be an outstanding court judgement or tax judgement against you.

* The business' auditors or professional company directors may either (a) ask you to keep money on your balance sheet to account for the outstanding judgement, (b) or refuse to sign-off your accounts.

If you refuse to tell them about the outstanding fines/judgement then you will be taken to have lied to them at which point you may be struck off as a company director. It's extremely difficult to find a professional finance professional to work for a business where ethical and reporting standards are not followed because they will risk being censured and losing their livelihood.

* You won't be able to travel to the jurisdiction (if you are a director/owner of the business) as you'll risk being put in jail/civil fine.

* The state in question can use international tax treatments and bring a court case or enforcement against the company within their main jurisdiction. Unlikely for a small company.

</comment></comment></comment></comment><comment><USER11> A sole proprietorship is not a business entity. There is zero difference between a sole proprietor business and a person.

I'm not sure how you got this confused, but it sounds like you need to speak to an accountant.

As far as how you pay people, you just transfer them money from your bank account. All of their accounts will have SWIFT or IBAN numbers or both, and you just transfer the funds.

Your accountant will take care of the rest, and they will be responsible for taxes on their end. No, they will not need to be companies, but you will need to pay them as companies, as these individuals will be responsible for their own expenses typically covered by a business (healthcare, union, taxes, etc.)

<comment><AUTHOR> > I'm not sure how you got this confused

Mostly because it holds for zero of the countries our current team lives in. :-) I appreciate your help though, but so far accountants have been less than helpful. The ones I talked to seem to know international employment stuff worse than I do.

</comment></comment><comment><USER12> The best option is the be Sole Proprietor/company/contractor. Then they send you an invoice once a month. You can use Transfer wise, online currency exchange or your bank (bank fees tend to be high)

There are other ways to hire someone, but it's a legal and paper work nightmare.

</comment><comment><USER13> I would have expected that anyone looking for remote international work would have things set up to make it as easy as possible for any potential employer to be able to pay them without running into local issues.

<comment><USER14> Problem is employers very often just need, want and look for full-time or part-time employees, not on-call contractors. In that case, they also have to manage the legal hassle.

</comment></comment><comment><USER15> One of my startup ideas is to start a service that makes it easy to hire full- time remote employees (not contractors) and we handle all the paperwork/hassle. Anyone interested?

<comment><USER16> Europe too?

</comment></comment><comment><USER17> From my experience: sole proprietorship, invoices and SEPA - that is the right way to go. Some people create Limited companies. Some "employers" create one HR proxy company to group all contractors as a shield and a way to offload administrative burden from the mother company.

Unfortunately EU currently has no framework for cross-border remote employees, local laws are too different to unify them all. This is not going to change soon.

</comment><comment> barrow-rider Nothing to add, just glad to hear that folks are asking this. I work remotely for a US firm and I'm baffled in their choices viz-a-viz payment sometimes.

</comment><comment><USER18> Been remote for a year and a half and I've taken payments in several forms including bitcoin. My preferred method when getting paid by European companies is transferwise since they let me get paid in euros and convert them to usd or whatever local currency of where I am residing. In a Pinch, I'll use paypal but its far from ideal.

</comment><comment><USER19> From my anecdotal observation, in case of EU usually a company is set up in a "permissive" country like Netherlands or Luxembourg, and the employees are implicitly required to handle the taxes and social insurances by themselves, the salary adjusted to the "cost of living" in where the employee is located.

</comment><comment><USER20> Thanks for posting this as I'm anticipating to be going down the same journey as well.

I'm surprised that there isn't already some sort of service that handles this although it does sound like quite an administrative entanglement.

Off topic: Do you get requests around embedding AI/NLP in your chat program?

<comment><AUTHOR> > Off topic: Do you get requests around embedding AI/NLP in your chat program?

Occasionally, but not too often. Thing is, relatively few of our customers use TalkJS for customer support - the usual suspects (Intercom, Zendesk, etc) are usually better than TalkJS for those use cases. Turns out most services that need the flexibility that TalkJS offers (eg for user-to-user chat instead of user-to-helpdesk chat) need it for direct communication between real humans.

But there's a number of edge cases, so we do have a few customers who've connected TalkJS to chatbot AIs via our REST API / webhooks.

There are other fields that AI could solve that we get requests about more frequently though. For instance disallowing people to share "real world" contact information such as street addresses (some of our customers are marketplaces who are afraid to lose their transaction markup if customers can easily bypass them). Given how insane street names can be this is an impossible problem, but decent AI could do better at that than any regex can.

Curious why you ask!

<comment><USER20> I run an AI enablement company. Basically, what we do is make it easy for startups to embed AI in their apps. We can also do the actual development of the AI solution as well. Chat programs are an area of interest for us and in general, I am just curious by what people make/think about AI and how they perceive it can solve their problems.

The detection of contact information is an interesting one although would not be able to solve this by just pinging the Google Maps API and then if it shows up, assume that it's an actual address at which you can discard it?

<comment><AUTHOR> The problem is when people share stuff like "sure, just drop by our office on one infinite loop in cupertino". I'd have no idea how and when and what to pass to Google Maps to get an idea of which part, if any, of that message to suppress.

<comment><USER20> Indeed that sounds like something NLP would be useful to pick at. Do you have any sample chatter that would be ok to analyze?

</comment></comment></comment></comment></comment><comment><USER21> Buffer have published their formula (and all salaries)

[https://open.buffer.com/salary-formula/](https://open.buffer.com/salary- formula/)

it's basically: base reference salary * cost of living * role * experience

edit: oh you where talking about payrole, sorry, I'm OT

</comment><comment><USER22> You don't have remote employees, you have remote contractors who send you a bill for their services which you pay. They deal with their countries tax and other issues.

Of course you have to treat them as real contractors and not employees. This means they chose where and when to work.

</comment><comment><USER23> I've participated in similar setups before. Everyone was self-employed, working as a contractor, invoicing the German company. As we were all in the EU, this was pretty smooth.

Why would you need to start a mailbox firm in every country with employees?

<comment><USER10> There are two problems, employment taxes/benefits and employment rights.

Lets say you have a German company and you have people working across Europe. For the sake of argument lets say that you have 15 people in France. Let say that all the people work for you 100% of the time, so they are effectively employees.

On the employment taxes/benefits front how are you paying the French state those 14 peoples payroll tax, and how are you paying in for their state pension? Pragmatically, you can't do this (AFAIK) without establishing a company in the jurisdiction and registering them as employees.

On the employment rights front, which jurisdictions are you following? As you have 15 people in France they are due to have a workers representative, does that fall under the French or the German system? If you have an issue with one of the team do you follow French or German employment law? Again, pragmatically each jurisdiction assumes that you fall under their employment laws and logically they'll assume you have a company in that geo.

<comment><USER23> The 15 people in France are self-employed. They pay their own taxes to the French state, they pay their own social and health insurance. It's very simple.

Wrt jurisdiction, usually the employer's jurisdiction. You don't follow "employment law", you follow "international business" law or some such, because that's what it is.

</comment></comment></comment><comment><USER24> What's the best solution if you're a CEO but work in a different country to where your company is founded?

Will the contractor model still work?

N:B I've created a company in the UK but I'm thinking of moving to Denmark.

<comment><AUTHOR> Fwiw, in the Netherlands most startup founders have a limited liability holding company to own the shares, and also use it send invoices from the holding to the startup. We don't, because being employed by our own conpany instead of sending invoices allows us to benefit from some R&D related tax cuts. But at least for Dutch law, founders sending invoices is allows and super common, maybe the same holds in the UK.

</comment></comment><comment><USER25> OrbitRemit works well for the countries they support, they also periodically throw in free transfers if you use them regularly enough.

</comment><comment><USER10> 1\. Individual service companies / Sole proprietorship

One thing to be aware of is that in many European companies a person who works for you full-time is considered to be an 'employee' even if they come in through an individual service company. In particular if they have no other active 'customers'.

The more you treat people as 'employees' the more at risk you are: if you give them holidays, if you monitor their work closely etc, if they don't invoice you, etc.

The risk is that you will have to pay employment taxes and benefits and you may be fined.

Pragmatically, you are unlikely to be at risk at a low number of team members within a jurisdiction: say up to 10-15. But, at some point you will be considered to have created a permanent establishment from a tax position.

2\. PE vs Limited Company

Many people talk about establishing a company in a jurisdiction and then employing people etc. There's actually a state before this where you have a 'permanent establishment' from a tax position even if you don't have a limited company in the jurisdiction. You can be considered to have employees at this point and you are responsible for payroll taxes, but don't yet incur the business taxes (e.g. corporation tax). Unfortunately, it varies by European jurisdiction how likely this is.

This state is essentially supposed to handle the idea of someone having an employment contract in one jurisdiction (say France), while living in another (say Germany). Practically, it doesn't work yet because the rest of the employment rights assume that you have a company in each jurisdiction. You can sort of hack it for an intermediate step.

3\. Pragmatically expanding in Europe

How you handle this is up to you in terms of how comfortable you are with the risk profile. The elements are too long (and boring) to go into here.

In my personal opinion it makes sense to:

1\. Hire team members in a limited number of jurisdictions. Basically where you believe you will eventually establish a full company: you might pick three jurisdictions you're comfortable with.

2\. Handle team members as employees: this is a basic decision about how you want to handle your remote team but it has big impacts. If you treat them as 'employees' then make it clear to them that they are responsible for their employment tax, pensions, etc.

3\. Risk the permanent establishment tax problem

4\. When a jurisdiction gets to 10 or so people form a company. In many European countries this is around the stage where employment rights also kick in.

5\. Reverse the people into the company and pay the employment taxes/benefits etc. This will cause problems because you will have to adjust pay since you will now be incurring payroll taxes and public pensions etc.

<comment><AUTHOR> Thanks a _lot_! This is an extremely insightful comment. I'm confused it isn't higher up the page.

<comment><USER10> No worries. I dealt with this (with a bunch of fantastic professional legal/hr/finance people) to handle about 40 jurisdictions. I appreciate how NOT fun it is :-)

Oh and I find it so odd that none of the famous "remote first" bloggers/talkers address these operational issues.

</comment></comment></comment><comment><USER26> I don't want to sound rude, but if you don't know how this works perhaps you'd like to hire legal and accounting professional services from the country where your company is registered. HN comments won't shield you from thousands of euros in fines, double taxation, possibly tax evasion charges and other issues you really should know about before trying to manage a business.

</comment><comment> em-bee the european union has free movement of labor, so you should be able to just employ them just as if you would employ someone living in a different city in your own country.

greetings, eMBee.

</comment><comment><USER27> it's called Bitcoin.

<comment><USER28> I would never accept payment for possible thousands of dollars in a currency that is not stable and I can't use for everyday transactions.

<comment> barrow-rider Maybe, if the BTC payment was at a higher rate that could help offset the risk and inconvenience.

</comment></comment></comment><comment><USER29> You are asking "we're currently requiring our employees to commit tax fraud, how can we streamline this".

In Germany (and a lot of other EU countries), there are laws governing bogus self-employment ("Scheinselbstständigkeit").

<comment><AUTHOR> No I'm not. I'm asking "how can I pay my people". Your snark doesn't help. If you say that asking people to be contractors is tax fraud, then I ask you what the alternative is. It's an honest question, we're an honest company. Don't assume the worst.</comment></comment>


The True story of Ooma - <AUTHOR> http://cerdafied.typepad.com/cerdafied_voip_mobile_web/2007/03/for_the_record.html

<comment><AUTHOR> well I am not sure if this story is really true but a sensationalist title makes a better read ;-)</comment>


C, Python, Go, and the Generalized Greenspun Law - <AUTHOR> http://esr.ibiblio.org/?p=7804 <comment><USER2> >> Even when you're merely at the edge of this trap, your defect rates will be dominated by issues like double-free errors and malloc leaks. This is commonly the case in C/C++ programs of even low greenspunity.

Citation needed. In my dayjob developing a major game engine in C++, we spend zero time on double-free errors or malloc leaks.

<comment><USER3> esr is a loon

</comment></comment><comment><USER4> Generalized ESR presumption based on no data and outdated methods.

Albeit I generally agree that smart but manual memory management works better and is more predictable. (range/scope based like in C++ RAII or Rust) If needed for performance, with memory pools.

There are different kings of automated too. Simple refcounting is sufficient for almost all cases but has to be still manually applied instead of guesswork to prevent performance bugs and leaks.

A specialized memory pool can be written in C++11 in less than 100 lines. (Likewise a thread pool.) Template even.

A smart pointer with or without refcounting is in standard. Compared to the immensity of GC these are easy to use and tune.</comment>


Regex Cheat Sheet - <AUTHOR> https://dev.to/emmawedekind/regex-cheat-sheet-2j2a <comment><USER2> Regex is one of those things that I've wished to be better at. I've tried learning it a few times. I feel like I get it, but some time later regex looks like black magic again. I think a cheat sheet like this helps with it. It gives some meaning to the magic spells.

</comment><comment><USER3> Bookmarking - this is laid out really well.</comment>


How to find cheap gas using game theory - <AUTHOR> http://mindyourdecisions.com/blog/2010/02/09/how-to-find-cheap-gas-using-game-theory/

<comment><USER3> Help my understanding: is this really an example of game theory?

I thought that game theory was about making decisions in which your success depends on the choices of others.

In the original secretary/dowry problem the values of your choices are random. In this case the gas prices aren't random but the strategy doesn't depend on considering the choices made by the gas station owners in setting those prices.

So while it's a nice solution (and one I've used myself when looking for an apartment) it doesn't seem to me to be an example of game theory.

<comment><USER4> Not to mention that gas stations in a small region (especially a small town) are playing their _own_ game which will probably tend to equalize prices between the stations.

I haven't seem gas stations with a 60c/gal(!) difference that are a reasonable distance apart.

Between Boston and Lexington? Sure it might be 60c cheaper, but that's almost 20 miles which would wipe out your savings and it has more to with city vs country which is predictable and doesn't require a game theory solution if you happen to be going that way.

</comment></comment><comment><USER5> This is of course the well known secretary problem. Of course to equate this with the secretary problem, one must assume a random distribution of gas prices.

But I think you can do better in real life. You can find a gas station that is more likely than average to have lower prices.

Just look for the station that would seem to be in the worst competitive position. I.e., the one that is inconveniently placed, that is away from the highway, that has a small sign, or that has a less famous logo. It will probably sell you cheaper gas.

<comment><USER6> Such station should probably have _higher_ prices to survive.

<comment><USER7> The out-of-the-way station should have cheaper real estate costs, and should have cheaper prices to lure repeat customers to travel further (more customers x cheaper price can be more than fewer x more expensive).

</comment></comment></comment><comment><USER8> Not sure if this is generally true, but in one freeway town I often pass through, you come off the freeway onto a main drag with lots of gas stations. Since we drive on the right side of the road, the gas stations on the left side of the road have marginally lower prices than the gas stations on the right side--presumably a premium to cover the inconvenience of making a left turn on a usually busy street!

</comment><comment><USER9> Neat trick! Unfortunately, in the U.S. it's less interesting -- by the time you've gotten off the highway you are usually committed to the 2 or 3 signs within line of sight of the offramp.

<comment><USER10> lol, so... It's not generally a good idea to cut it this close in the US. When I drove out to cali, my buddy and decided to drive it at night to avoid traffic - this is KY to CA. So, we're clear into indiana somewhere at around 11pm and we get to about 10-15% of a tank of gas, decide to stop... pull off at the next gas sign, oh hey - it's closed??? That's interested, let's go to the next exit... 2 exits later the needle is on E and we finally get to a city with an open station. From that point on, we always filled it up at 25-33% - <USER2> fact which was crucially important in the desert and mountains.

<comment><USER9> That's definitely a risk when you get out of the city areas. Unfortunately, when minimizing stops, the greedy algorithm is the ideal solution -- it's always better to risk it.

(In graph theory, nodes don't close after midnight.)

</comment></comment></comment><comment><USER11> In Western Australia, we have a state government run website, <http://www.fuelwatch.wa.gov.au/> , that lists almost all WA servo prices across all fuel types for both today and tomorrow. Prices are cents per litre.

</comment><comment><USER12> So, assuming all 5 retailers act rationally, and that they assume all their customers and competitors act rationally.

Station #1 knows most of its customers won't be comparing (don't care or running low). So they can jack prices up a little more.

Station #2 knows that the only comparison they can be sure ALL their customers make is with Station #1, which will be jacked up, so they can increase their margins a little (above avg, below #1).

#3, #4 and #5 could follow the same logic, except for this. Station #5 knows many of its customers won't compare either. They're the last option without turning around, and many comparison shoppers won't turn around for a few lousy cents / gallon. So they can increase their margin a little.

Which leaves Station #3 wanting to look reasonable compared to #1 & #2, and able to survive a comparison with at least #4. And Station #4 knows they will be a good comparison with #5 but need to compete with #3 and so will probably be at or about the same level as #3.

In other words, #1 will be most expensive. #2 & #5 will have good cause for being a little extra. And #3 & #4 will both be subject to the largest competitive forces and will likely have similar, lowest prices.

Shame the initial assumption I made was completely crap.

<comment><USER13> Given that people can drive down the road in two directions, station #1 is also #5 and #2 is also #4. This changes your analysis slightly, but the result remains that you should go to station #3.

<comment><USER12> And that the initial assumptions were crap.

</comment></comment></comment><comment><USER14> If I can plan it...I usually fill up a gas station a few miles away...why? Because there are 3 gas stations on that one intersection..and their prices are usually 20-30 cents cheaper than other gas stations in the area.

And if I can't plan it...I just fill up whenever, since the difference between the super duper cheap gas station and arm and a leg gas station...is pretty small.

If you have a 10 gallon gas tank, and the difference is 50 cents....you'll only be overpaying $5 for a tank of gas.

And since the difference is usually much smaller...you'll usually just pay 1-2 bucks more to fill up now...instead of trying to find a cheaper station.

</comment><comment><USER15> This is an amusing post. For me, buying gas is just as similar to stocks. The trick is to decide whether to fill 'er up full or not. Almost always, a full tank is a bad bet unless if you know from experience that it's the cheapest station in the area.

I say stocks because the gas in your tank is the value you bought it for that you could've gotten cheaply. I mean if you know the gas price is going to increase for sure (such as during a long weekend), then yes I will fill my tank please.

<comment><USER16> On long trips, especially coming _home_ from long trips, I'm usually in at least a little bit of a hurry to get there and be done driving. It's therefore worth $1.50 (assuming I pay $.10 per gallon more than is necessary for my 15 gallon tank) to me to only have to fill up once. In practice, I've found the price aren't usually even that much, so the time saved is that much better of a deal.

<comment><USER15> Well I agree with the time saved part, but in the long run the $1.50s add up to something of significance.

But, my point is that when gas is expensive and you're in dire need of it, fill it up as much as is necessary until the next favorable stop.

<comment><USER17> But the time saved adds up at the same pace, as well. If spending $1.50 to save 10 minutes is worth it in each invidual case, in aggregate it's worth it as well.

</comment></comment></comment></comment><comment><USER18> Problem rises when gas station operators, assuming they are rational, know that customers are using this strategy. In this case, they will set a price that will be function of how far and frequent other gas stations are located. The favorable outcome for customer is random chance here, somebody with less gas who would have used the same strategy would end up at more expensive station.

</comment><comment><USER19> Since you're (presumably) driving off the highway into an unknown town, my guess is that the first station or two will have more expensive gas, because these stations know there are people coming the same way from the highway who need gas asap (and don't mind paying a premium price). This is confirmed by the example in your post.

</comment><comment><USER20> <http://gasbuddy.com/></comment>


LivingSocial expected to lay off 400 in U.S. - <AUTHOR> http://www.bizjournals.com/washington/blog/techflash/2012/11/major-layoffs-set-for-livingsocial.html

<comment><USER2> Can't say I'm surprised by this.

I pass their fancy offices [1] all the time, but I'd have a hard time naming anyone who uses their deals regularly.

They've gone from expanding rapidly [2] to laying off heavily in 7 months.

It's a shame as they were often touted as a success story for tech [3] and business in general in the area.

1: [http://www.businessinsider.com/living-social-office- tour-201...](http://www.businessinsider.com/living-social-office- tour-2012-8?op=1)

2: [http://www.washingtonpost.com/blogs/capital- business/post/li...](http://www.washingtonpost.com/blogs/capital- business/post/livingsocial-gobbles-up-more-dc-office- spaceagain/2012/04/12/gIQAzBPqCT_blog.html)

3: Yes, I know tech is relatively small part of the daily deals business. I'm talking common perception.

<comment><USER3> Wow. Look at all that money spent on things that didn't make their business better.

<comment><USER4> Except for the giant screen, I don't see much that looks particularly extravagant. Too much space (why all those meeting rooms?) and too many employees, probably, but it's hardly Ion Storm.

<comment><USER5> DC office space has to be expensive, they can only build up 7 or so stories by law (nothing can be taller than the Treasury building).

<comment><USER6> The part about the Treasury building is a common misconception! It's actually related to the size of the street in front of the building: [http://www.welovedc.com/2009/05/19/dc-mythbusting-the- height...](http://www.welovedc.com/2009/05/19/dc-mythbusting-the-height- limit/)

</comment></comment></comment></comment></comment><comment><USER7> I still wonder about the daily-deal business model. The premise that loss- leading discounts will spark increased retail-price customers is losing its believability. In my circle I've never heard a business referred to as "that place I found on Groupon" -- I've really only seen it used as a marketplace for deep discounts on one-time (or nearly one-time) purchases. A groupon for skydiving or a guided tour? It doesn't make any sense.

For the businesses fueling daily deals, the cost of customer acquisition skyrockets. For customers getting the deal, returning to the business to pay full price is hard to swallow. It's going to take some real business intelligence to turn these daily deal companies around.

That said, my heart goes out to the 400+ employees looking at lose their jobs before Christmas. That sucks, a lot.

<comment><USER8> I don't think daily deals was the end-goal. Getting small business customers was.

<comment><USER7> If the small businesses take a bath on the daily deals though, you've alienated the small businesses instead of gaining them.

</comment></comment></comment><comment><USER9> During their hiring explosion, I had a hunch that I shouldn't have gone forward with an interview there. I think I made a good decision...

Something in my gut just said "who cares?" about the work. I couldn't get a straight answer on what I'd be building or why I should believe they would keep growing.

</comment><comment> daniel-cussen Does anybody else remember the articles about Tim O'Shaughnessy in entrepreneurship magazines?

[http://www.inc.com/magazine/201203/liz-welch/the-way-i- work-...](http://www.inc.com/magazine/201203/liz-welch/the-way-i-work-tim-o- shaugnessy-living-social.html)

Stepping back a bit, I'm starting to see a pattern. One day, the magazines are like, "Bobby Clampit built Something2.0 out of his own golden shit with his bare. ALONE." Ten month later we have an announcement that reads "And, ah, Something2.0 announced 2,000 layoffs, whoops, the core co-founder team is releasing statements that..."

<comment><USER5> Are we back to headcount as a success metric? The most surreal thing I remember about Startup.com was the company going "oh no, we're in trouble" every few months, doubling in size, and then going "oh no, we're in even more trouble."

</comment></comment><comment><USER8> My guess is a large % of these laid off workers will be sales people in the disparate cities. Call center workers too.

LS seems to be going after small businesses but w/a different end goal than groupon, groupon looks like it wants to be the merchant provider for these companies, LS, not sure.

</comment><comment><USER10> Honest question, why daily deals sites are imploding all of a sudden?

<comment><USER11> I think for the most part daily deals were a macro- experiment. Everyone jumped on board - startups, businesses of all shape and sizes, as well as end- customers with high hopes everyone would win.

I think what were finding out through the experiment is that it just isn't really sustainable for much of anyone. I dont know if that segment will be disappearing anytime soon but the model will have to adapt.

<comment><USER12> I agree and I think it is an important insight. Why did everyone jump onto this thing?

My intuition is that the turbulence in media, from mp3 players to PVRs to online newspapers to Netflix and other on-demand video experiences has seriously damaged the way in which small business would "talk" to their potential customers. This is a gaping hole that has yet to be well served.

So I wonder if the macro experiment was that something like Groupon would replace it those other forms of outreach.

<comment><USER13> I think small businesses have always been hungry for more customers, so I believe the dynamic is something slightly different.

I think the Groupon space was basically a big many-sided bubble. Consumers loved the discounts and the urgency of it. Businesses loved the pitch, and the big response was spectacular compared with regular coupons. Investors loved the large user bases and the crazy growth. Groupon loved the high margins and the ability to make the books look great. And media had some great stories to sell.

But I don't think there was much real value there. Many businesses didn't really see long-term benefit from running daily deals. The traffic was large, but fickle.

The only reason this got so big was that Groupon deals had relatively long feedback loops, so it took businesses a while to learn that there were better marketing options. And there were plenty of businesses for Groupon's massive sales team to burn through before their reputation started to wear thin.

</comment></comment></comment></comment><comment><USER14> A percentage figure gives us a much better idea of what the scope of this layoff will be.

 _> LivingSocial, which has raised more than $800 million in funding, entered 2012 with a staff of roughly 5,000. The company's most recent publicly disclosed headcount stands at "more than 4,500 employees," according to its website._

So that's around 8-9% of its workforce.

</comment><comment><USER15> Maybe Hungry Academy wasn't such a good idea after all...

<comment><USER16> Maybe the fact that this company created it wasn't optimal, but I still think it's a very solid idea.

<comment><USER15> Yes, I agree that it is an excellent idea.</comment></comment></comment>


REST vs. GraphQL APIs, the Good, the Bad, the Ugly - <AUTHOR> https://dev.to/xngwng/rest-vs-graphql-apis-the-good-the-bad-the-ugly-34i8 <comment><USER2> I haven't looked at working with GraphQL too closely yet, but this seems to partly answer some questions I wondered about. Because REST leverages HTTP, our infrastructure--our client software, our frameworks and programming languages--already have some knowledge of what to do with it, how to parse URLs and GET and POST requests, and so on. But the discussions I've seen of GraphQL suggest that in order to make it work, additional layers of code must be added, such as Relay and Apollo, or some equivalent. Is this really the case? Perhaps this will change in the future--as GraphQL becomes more widespread, it may be integrated more natively into the infrastructure.

<comment><USER3> No, you don't need Apollo or Relay to make the GraphQL work. The query of a GraphQL system is a string that represent the value of a GraphQL script. You can send this string using any protocol that you want, usually is by http with the verb POST. For execute the script in the server, in NodeJS for example, you just pass the string to a function that returns a promise. When the process is done you sent the response to the client. For example, I am using pure GraphQL with serverlesss. The client post the script to my function, my function execute the graphql promise and response the client.

<comment><USER2> Thanks for the explanation. That seems reasonable.</comment></comment></comment>


Improving memory with magnets - <AUTHOR> https://www.sciencedaily.com/releases/2017/03/170327114340.htm <comment><AUTHOR> Essentially they're recreating a stimulus in the brain that occurred when the initial memory was created. I don't know if this means generally stimulating better recall, but it has interesting implications for students. If you study with a particular tonal pattern in the background, then stimulating a matching theta wave as was generated by that tonal pattern might also stimulate better recall in that instance.

Perhaps memory was originally developed for same-environment tasks, e.g. remembering complex routes through a forest at a certain time of day in a certain season.</comment>


Software Carpentry: an introduction to basic software development - s-phi-nl http://software-carpentry.org/

<comment><AUTHOR> This is a wonderful resource. I especially like the lighthearted tone that goes easy on the jargon. With a great bibliography to boot:

 _Elliotte Rusty Harold: Effective XML. Addison-Wesley, 2004, 0321150406. This book explains which of XML's many features should be used when: Item 12 tells you to store metadata in attributes, and then spends six pages explaining why, while Item 24 analyzes the strengths and weaknesses of various schema languages, and Item 38 covers character set encodings. It's more than most developers will ever want to know, but when you need it, you really need it._

I couldn't have described Harold's tome on XML better myself.

</comment><comment><USER2> This is amazing. Actually, this kind of thing makes me wish I'd stayed in academia, if only because there are so few good courses out there, even less taught in an approachable manner.</comment>


CDC says coronavirus survived in Princess Cruise ship cabins for up to 17 days - <AUTHOR> https://www.cnbc.com/2020/03/23/cdc-coronavirus-survived-in-princess-cruise-cabins-up-to-17-days-after-passengers-left.html <comment><USER2> From the report:

"SARS-CoV-2 RNA was identified on a variety of surfaces in cabins of both symptomatic and asymptomatic infected passengers up to 17 days after cabins were vacated on the Diamond Princess..."

Presence of RNA does not necessarily mean it's a viable virus.

</comment><comment><USER3> Source: [https://www.cdc.gov/mmwr/volumes/69/wr/mm6912e3.htm?s_cid=mm...](https://www.cdc.gov/mmwr/volumes/69/wr/mm6912e3.htm?s_cid=mm6912e3_w)

 _SARS-CoV-2 RNA was identified on a variety of surfaces ..._

I guess we don't know from this data whether these are fragments or are intact and communicable?

</comment><comment><USER4> Would asymptomatic crew be a more likely vector between the voyages?

This is a respiratory disease: don't ignore touch as a vector but surely the vast majority of transmission is via the air?

</comment><comment><USER5> Damn. That will significantly lengthen any sort of quarantine I suspect.

<comment><AUTHOR> This is not conclusive yet but yes, this is going to take more than a few weeks and will be quite a disaster in some areas...</comment></comment>


Lush Programming Language - <AUTHOR> http://lush.sourceforge.net/ <comment><USER2> Abandoned, but large parts of this seem to be the work of Yann LeCun ([https://www.facebook.com/yann.lecun/posts/10151728212367143](https://www.facebook.com/yann.lecun/posts/10151728212367143)), Facebook's director of AI research, right?

...curious if scraped parts of this project are actually living a second life deep inside Facebook's labs :)

<comment><USER3> I sometimes wonder if there is too much emphasis on the idea of that some piece of software is abandoned. By which I mean that new and actively developed software isn't bug free and if a tool does the job it does the job. There's no guarantee that an active project in version 0.9 is going to fix any particular bug soon short of me [in theory] fixing it myself.

It's not as if much has changed in 2015 that would introduce show stopping bugs that weren't around in 2009. The process is the same, evaluate the tool against the problem domain and compile from source if it seems like a reasonable fit. Active development doesn't change the fact that there is no silver bullet.

<comment><USER4> You're right in general, but it seems that no _language_ that is being actively used by a non-trivially sized community _ever_ sits still. The more we use our languages (computer or human) the more they evolve. They are a form of communication. We are always evolving our communications methods and wanting more ways of expressing ourselves.

<comment><USER3> 1\. ANSI Common Lisp is nearly 25 years old.

2\. Picking up another language is the quantum leap in the possibilities of expression. Point releases aren't. To the point, if Lush expresses what a person wants to express, then it does so. It's not like people suddenly turn around and rewrite working legacy while loops as list comprehensions just for fun.

</comment></comment></comment></comment><comment><USER5> Project seems dead (last "news" from 2007). However if the feature list is accurate they invested a lot of time in building this. Makes you wonder why it was eventually abandoned..

<comment><USER6> the last code update seem to be in 2014 [http://sourceforge.net/p/lush/code/HEAD/tree/](http://sourceforge.net/p/lush/code/HEAD/tree/)

so maybe its not fully abandoned

</comment></comment><comment><USER6> there are so many lisps out there, i wonder when one will click

this site of course is linked to one arc, which i believe at least the original hn was created in, i am not sure if it still is

there is also racket, which is lauded by many, and i believe deservingly so

then there is clojure, which seem to have had the best chance to make a popular lisp, but i am skeptical it actually will (at least for some definition of popular, clojure is somewhat popular, but not at the scale of top languages, like java, c#, ruby, etc ...)

this language description look (surprisingly) very promising, focusing on pragmatic features like performance and integration with other systems, makes you wish it worked out better for them

anyway, good luck for all the lispers out there

<comment><USER7> > there are so many lisps out there, i wonder when one will click

I wonder if one ever will. Just as Tarver's Bipolar Lisp Programmer[1] finds it so fun and easy to reimplement things in Lisp rather than get work done with existing libraries, it's more fun, and easier, to reinvent Lispy languages than to get work done in an existing Lisp.

It was more fun to design & implement Clojure than it was to improve ABCL[2] and get work done; it was more fun to write racket than to get work done in Common Lisp; it was more fun to reimplement swathes of Common Lisp in Scheme than to just get work done in an existing CL implementation; it was more fun to build arc than it was to just get work done.

Rather than building small integration layers over necessary technology and then getting work done with it, we continually reinvent the entire stack because it's so easy and fun to do that in a Lispy language.

[1] [http://www.lambdassociates.org/blog/bipolar.htm](http://www.lambdassociates.org/blog/bipolar.htm)

[2] [https://common-lisp.net/project/armedbear/](https://common- lisp.net/project/armedbear/)

</comment></comment><comment><USER8> Looks like it is (was?) targeting roughly the same space as Julia.

</comment><comment><USER9> Lots of 404 errors when trying to access links (like the tutorial).</comment>


The Thought Emporium - <AUTHOR> https://www.thethoughtemporium.com/ <comment><USER2> Found this one: "Developing a Permanent Treatment for Lactose Intolerance Using Gene Therapy"

Seems very promising. Recently, I discovered that lactase derived from Kluyveromyces lactis is effective for me, whereas lactase derived from Aspergillus oryzae seems to have little to no effect. The latter is used in mose lactase supplements

<comment><USER3> This is interesting. Do you know which brands are derived from each source? I wasn't able to find much information online.

<comment><USER2> Source info is usually tucked away in fine print, or on the manufacturer's FAQ page, if at all.

"Lactose-free" dairy products (milks and yogurts) and OTC supplements in pill form, as far as I know, use lactase derived from A. oryzae. Commercial dairy supply companies sell K. lactis in bulk. I've found one brand on Amazon (SeekingHealth) that's made with K. lactis derive lactose. Maybe they re- package the commercial size product? I've thought about buying a gallon for $1200, but that would probably last me more than a lifetime. Lactase comes from different sources and has different properties [0]. K. lactis has a neutral optimal pH, so it's better for processing dairy prior to consumption; A. oryzae has a lower optimal pH and higher heat tolerance, so it's more suitable for OTC supplements.

[0] [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5429307/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5429307/)

</comment></comment></comment><comment><USER4> Have been a patron for some time, and discovered his channel with his lactose gene therapy video - to which he recently posted an update: [https://www.youtube.com/watch?v=aoczYXJeMY4](https://www.youtube.com/watch?v=aoczYXJeMY4) .

Great addition to scientific youtube.

</comment><comment><USER5> this guy has some really great youtube videos, particularly enjoyed the series on building a camera to "see wifi"

<comment><USER6> Agreed. I really like them...

Though ... his live streams are pretty revealing. I recommend watching a few of them, as it will probably change the way you view his other content, both in the positive sense and in the negative.

<comment><USER7> I've only watched his WiFi video, as well as his Lactose Intolerance gene therapy and felt he cane across quite positively. Are you alluding to specific negative behaviours he exhibits on stream that are edited from his videos?

<comment><USER6> I suggest watching a few and just drawing your own conclusions.

I'm not being coy, I just think that the conclusions I drew may be pretty unfairly negative and I don't necessarily want to bias you.</comment></comment></comment></comment>


How Amazon's Long Game Yielded a Retail Juggernaut - <AUTHOR> http://www.nytimes.com/2015/11/19/technology/how-amazons-long-game-yielded-a-retail-juggernaut.html <comment><USER2> Best quote from the article is the closing one:

 _I don't know, man. It's really hard._ \- Paul Vogel, an analyst at Barclays</comment>


Forgiving Student Debt Would Boost Economy, Economists Say - <AUTHOR> https://www.npr.org/2019/11/25/782070151/forgiving-student-debt-would-boost-economy <comment><USER2> Forgiving student debt is, in my view, admitting that our college system is no longer worth its cost for many who borrow aganist their future life, and sacrifice much to attend. The root issue is that degrees no longer reliably indicate higher competencies. Anyone hiring recently will notice the difference between degree holders and those without, is mainly their economic background, ocassionaly their drive, and seldom their critical thinking skills.

While forgiveness for students might be proper, scrutiny must be redoubled back at the institutions that drove this crisis.

</comment><comment><USER3> If I could get student debt forgiven, I'd go back to college full-time.

</comment><comment><USER4> or just stop subsidizing a retarded system and instead align the incentives between the business(colleges) and the customers(students) like Lambda school does.

</comment><comment><USER5> We don't exactly need a boost to the economy right now.</comment>


The Path to Parallel JavaScript - <AUTHOR> https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/ <comment><USER2> This is nice for some pretty limited use cases, but the most common use case for multithreading in app-like programs (which is what Worker-based apps presumably service: these are not documents) is removing latency from the UI thread. But as long as only the main thread can touch the UI, and the main thread also can't access shared memory, this limits uses of this to scenarios where copying the entire render state from a Worker is reasonably fast — in which case, Workers currently already solve the problem. This proposed implementation of shared memory doesn't actually solve one of the big remaining needs for shared memory, which is when it's prohibitively expensive to copy state between a Worker thread and the UI thread at 60fps.

For example, Workers aren't particularly useful for games in their current iteration: the overhead of copying the state of the world back to the rendering thread is high. This is exactly the problem that shared memory _would_ solve, were it not limited to Workers. This puts web export (or even primary web-based game authorship) at a significant disadvantage as compared to native apps: native code can share memory, and web-based implementations can't. In many cases architectures that are optimal for shared-memory threading are pathological when the rendering thread requires copies, meaning that threading gets thrown out the window for web. Even with asm.js-compiled "near-native" performance on the single core, you can only use 25% of the available CPU if you can't use multithreading. A 4x performance hit is the difference between 60fps and 15fps... Or 15fps and ~4fps.

The title of the blog post got me pretty excited, but the proposal is fairly disappointing in terms of unlocking better performance for web apps. The use cases here are pretty limited to things like CPU-bound number crunching, and I doubt too many people are running machine learning algorithms in a browser as compared to the number people who're using browsers to, y'know, render UIs. By all means scope the problem down to sharing primitive data in ArrayBuffers — we can build abstractions on top of that! — but limiting it to Worker threads makes it near-useless for most web applications. Workers already solve the use cases for UIs that can tolerate copies between the UI thread and the Worker threads, and this proposal doesn't allow us to solve needs for UIs that can't.

<comment><USER3> The blog post does mention the main thread, as something that is more complex and in need of further investigation.

Still, even without shared memory being accessible to the main thread, I think sharing between workers can be extremely useful. Yes, you need to proxy information to the main thread in order to render, but that doesn't need to be a big problem. See for example the test here, where a 3D game's rendering was proxied to the main thread, with little loss of performance,

[https://blog.mozilla.org/research/2014/07/22/webgl-in-web- wo...](https://blog.mozilla.org/research/2014/07/22/webgl-in-web-workers- today-and-faster-than-expected/)

That very small overhead could be worth letting the game run in multiple workers while using shared memory.

Also, things like Canvas 2D and WebGL are APIs that might exist in workers, there are efforts towards that happening right now. That would eliminate the need to copy anything to the main thread, and avoid a lot of latency.

<comment><USER2> I can't speak to the BananaBread codebase, since I haven't read it — although BananaBread performs poorly as compared to commercial engines, regardless — but if you look at even the published benchmarks in that blog post, the Worker-based implementation is slower in all cases except for Firefox with two bots. Chrome is always slower when using Workers, sometimes massively so, and Firefox with ten bots is slower multithreaded than single-threaded.

Regardless, shared memory isn't only useful for WebGL. It's useful for any kind of UI where you don't want to block the main thread, and if you don't have DOM access it's tough to make that work. If copying is fine then current Workers are good enough; if copying isn't fine, then this doesn't change that.

<comment><USER3> I agree with

> If copying is fine then current Workers are good enough; if copying isn't > fine, then this doesn't change that.

I am saying that copying _is_ fine (for most apps).

Copying is fine because BananaBread is indeed less performant than commercial engines, as you said, and that actually makes it a _better_ test candidate here. It does far more GL commands than a perfectly optimized engine would, which means much more overhead in terms of sending messages to the main thread.

Despite that extra overhead, it does very well. 2 bots, a realistic workload, is fast in Firefox, and the slowdown in Chrome (where message-passing overhead is higher) is almost negligible. 10 bots, as mentioned in the blogpost, is a stress test, not a realistic workload. As expected, things start to get slower there. (Game is still playable though!)

And large amounts of GL commands, as tested there, are much more than what a typical UI application would need. So for UI applications, that just want to not stall the main thread, I think a single worker proxying operations to the main thread could be enough. Copying is fine.

The proposal in the blogpost here is for other cases. Workers + copying already solve quite a lot, very well. What this new proposal focuses on are computation-intensive applications, that can multiply their performance by using multiple threads. For example, an online photo-editing application needs this. This might be just a small fraction of websites, but they are important too.

<comment><USER2> Here are some things that BananaBread doesn't test that I suspect would break larger games in commercial engines:

* High-poly models. This is one area where copying breaks down: that can be a ton of data. BananaBread has a single, low-poly model that it uses for NPCs, and it presumably rarely (if ever?) needs to be re-copied.

* Large, seamless worlds. If you can transfer the entire world into a single static GL buffer, sure, copying isn't a problem since it only happens once on boot. If you need to incrementally load and unload in chunks, you're going to be paying that cost again and again.

* Multi-pass rendering. In fact, the proxying approach makes multi-pass rendering impossible, as noted in the blog post.

By all means, if your application already works single-threaded, or within the confines of the existing spec, you're going to be fine. But memory copies aren't free, and UI offloading is one of the biggest reasons to use shared memory.

Shared memory in Workers is nice — it doesn't make anything worse, and it makes some things better! — but it's a little disappointing that the main thread can't access the shared memory buffers. That's all.

<comment><USER3> I understand your disappointment, clearly more opportunities are opened up on the main thread. As the article says, this is a proposed first step, and the main thread is trickier, so it can be considered carefully later on. Meanwhile, for a large set of use cases, the current proposal can provide massive speedups.

</comment></comment></comment></comment></comment></comment><comment><USER4> Great developments, since, imho, we really need multi-threading to make decent user-interfaces (ones without hick-ups due to blocking of the cpu-resource).

I think what we need is immutable data-structures to be shareable between threads. This approach should also allow structural sharing between threads, allowing for efficient and safe data structures.

Also, I could see a use for a mechanism where a thread creates a data- structure, then marks it as read-only, such that it can become shared.

<comment><USER5> Anecdotally, I've found that most performance hick-ups don't come from computation blocking the ui, but from rendering one part of the ui blocking every other part from rendering.

The solution to that being parallel or async paint/layout, which is something I never hear mentioned (probably because it's a really hard problem).

<comment><USER6> Servo is actually in the process of implementing a parallel layout engine[1][2]

1: [http://en.wikipedia.org/wiki/Servo_(layout_engine)](http://en.wikipedia.org/wiki/Servo_\(layout_engine\)) 2: [http://pcwalton.github.io/blog/2014/02/25/revamped- parallel-...](http://pcwalton.github.io/blog/2014/02/25/revamped-parallel- layout-in-servo/)

<comment><USER4> Interesting. I wonder how they handle incremental rendering though. Only the forward-path is described in your reference [2].

<comment><USER7> As far as I can tell there is nothing unusual or difficult here. Servo's incremental layout implementation is here: [https://github.com/servo/servo/blob/master/components/layout...](https://github.com/servo/servo/blob/master/components/layout/incremental.rs)

</comment></comment></comment></comment></comment><comment><USER8> What's wrong with message passing though - MPI does it, Erlang does it - surely this paradigm can deliver good performance for data and task parallelism.

I hope Mozilla will continue experimenting with parallel js. Exciting times!

<comment><USER9> I think they mostly mean the overhead of (de)serialization from/into JSON. It's also hard to pass binary data that way.

<comment><USER10> Would it work to have the data structures be copy-on-write? That way if the worker only reads then it's O(1), you just pass a reference to the worker.

I imagine it'd be a pain to write a garbage collector for something like that.

<comment><USER11> Copy on write is already implemented-ish with transferable objects [1] (just copy then write the copy).

However, copy on write still requires allocation and for some applications that is a deal breaker.

1: [https://developer.mozilla.org/en- US/docs/Web/API/Web_Workers...](https://developer.mozilla.org/en- US/docs/Web/API/Web_Workers_API/Advanced_concepts_and_examples#Passing_data_by_transferring_ownership_%28transferable_objects%29)

</comment></comment></comment></comment><comment><USER12> Will Spidermonkey be rewritten in Rust eventually?

Sidenote: WebGL 2.0 should come with ASTC support to be relatively future- proof.

<comment><USER13> Note that JITing compilers gain a lot less from Rust's safety guarantees than most code: you can easily JIT some code that breaks one of the safety properties that Rust ordinarily defends.

</comment></comment><comment><USER14> From what I've seen, SIMD.js does make doing some calculations quicker, although it's not the 4x increase one might assume. It's more like 30% to 50%. The latency and overhead associated with moving the SIMD.js calculations into a Web Worker actually reduces the performance increase to as little as 10% to 20%.

While message passing might make sense for some tasks, it's not going to be quick enough to do things in 16ms and achieve the magical 60fps. Eventually shared memory is going to be needed, and if we get that far I think there will have to be some sort of acknowledgement that these performance-related features can't possibly be foolproof.

Oh, and an asynchronous thread safe DOM, please and thanks :)

</comment><comment><USER15> I've been thinking that something combined with the use of async functions (es7) could be used for Shared* locking...

        sharedObject.lock(^() => {
          /* use object, which is locked until async promise resolves/rejects */
        });

where `^` is a short key for an async lambda function... `async` keyword could be used too... just throwing the `^` out there.

This could lock the object, allowing for an async function to execute... when the async function promise resolves, the lock is released... it would have to be limited to async functions though. but that would likely hit the JS engines around the same time as any shared objects anyway.

<comment><USER15> For me, the biggest problems with workers, is that you can't simply pass the functions that the worker needs (separated from state) from the main window... it means you're creating a separate script for workers, which isn't so bad, just not always easy to reason around.

It also makes isomorphic interfaces (async node & browser) slightly harder.

</comment></comment><comment><USER16> Does anyone know what is the origin of async/await? It's very convenient for simple cases, but it makes it very hard to mix synchronous and async code(C#).

<comment><USER5> How does it make it difficult?

<comment><USER7> You can only call async functions inside async functions.

See also What color is your function? [http://journal.stuffwithstuff.com/2015/02/01/what-color- is-y...](http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your- function/)

<comment><USER17> If that was the case then async functions would be useless, since the global scope is not an async function. You can call async functions from regular functions, they will just return a promise. You can then use normal promise handing behavior (passing a callback function, which is how you'd currently handle async anyway).

In real-world scenarios though, most of the time you'll be reacting to events, and not calling async code from sync code.

Edit: To clarify I'm talking about the ES7 async/await feature.

</comment></comment></comment></comment><comment><USER18> I would love to see a channel primitive similar to Golang's. They really seem to have hit the nail on the head with that one.

<comment><USER19> The CSP model is very nice, but I don't think that what this proposal is aiming for. CSP is more about concurrency, while the post makes it clear they are looking at parallelism. This is more addressing "things that appear to be single threaded but run faster" like image analysis, for instance.

<comment><USER20> They're obviously separate concepts, but tangentially related. Even in Go you'll learn that sometimes introducing multithreading to a concurrent application will actually _reduce_ your performance due to reconciliation of context-switching within the application.

Javascript already has its own inherent concurrency, obviously, but it's not outlandish to say that introducing a goroutine/coroutine concept would be a lot more elegant and manageable.

</comment></comment></comment><comment><USER21> i have always wanted Canvas as well as read-only array buffers (for things like map-reduce image analysis) to be accessible in web workers.

</comment><comment><USER22> Why not implement go routines model?

<comment><USER23> Aren't go routines pretty similar to WebWorkers, but with special syntax for creating them (and sending/receiving messages over channels) and perhaps lighter weight (though that may just be an implementation issue with current JS engines)?

Edit: nevermind, it looks like go routines can share memory, (but channels are the preferred method of synchronization): [https://golang.org/ref/mem](https://golang.org/ref/mem)

</comment></comment><comment><USER24> Good Article, Thanks.

</comment><comment><USER25> This is really important work!

</comment><comment><USER26> Oh no, will this become an ego thing? Parallelism must lie somewhere near abstraction as a premature optimization. Computers are hard, even single threaded.</comment>


Made a form-bakery for HN! Try it & let me know what other features you want. - <AUTHOR> http://formbakery.com/beta/

<comment><AUTHOR> Any criticism about the design is welcome too :)

</comment><comment><USER2> Who is the target audience?

<comment><AUTHOR> It's aimed towards those who are less code-savvy.</comment></comment>


GitHub and BitBucket's SSL Provider's Cert has expired - <AUTHOR> https://github.com/

<comment><USER2> I work with the Certificate Provider DigiCert and confirm that the expired intermediate is a deprecated certificate no longer used in installs. Some sites still have it installed on their server or users might have it installed on their local machine.

If you are on Chrome, follow @huntaub's suggestion and remove the expired certificate from keychain and restart.

We've been notifying customers of the expiration and have Technical Support in the office 24 hours to help the sites who need help updating the certificate.

We're also reaching out to the sites we see having issues online.

</comment><comment><USER2> For a full explanation on the legacy intermediate explanation and affected users see DigiCert's post:

[https://blog.digicert.com/expired-intermediate- certificate/](https://blog.digicert.com/expired-intermediate-certificate/)

<comment><USER3> Thanks, very helpful, though I think affected users are going to want to use this link instead:

[http://blog.digicert.com/expired-intermediate- certificate/](http://blog.digicert.com/expired-intermediate-certificate/)

</comment></comment><comment><USER4> I just got hit with this issue. There doesn't seem to be any information on DigiCert's site or Github's.

edit: For some reason, deleting the expired DigiCert certificate from Keychain (and restarting Chrome) allowed it to find a valid chain to the Github certificate. I would recommend doing this if you want to get to Github without turning off SSL.

edit2: (Or they just fixed it and I restarted Chrome.) Can anyone confirm that it works now (without deleting the Intermediate Cert)?

<comment><USER5> [https://twitter.com/flavmartins/status/493102588410494976](https://twitter.com/flavmartins/status/493102588410494976)

</comment></comment><comment><USER6> A side-project I'm working on will alert you when SSL certificates are about to expire, preventing these things from happening. It'll also show you a overview of all the expiration dates of your certificates and domains, updated automatically.

It's not live yet, but if you're interested you can sign up for the launch mail here:

[http://www.domainsquire.com](http://www.domainsquire.com)

<comment><USER7> Such a thing would have been very helpful to me. My domain's SSL cert expired and I got a new one but didn't notice that my provider had shipped a different, newer intermediate certificate.

For three weeks I was showing a great big THIS CONNECTION IS UNTRUSTED screen to Firefox users and didn't know it.

<comment><USER6> It surprises me how common it is, which made me build Domainsquire to fix it. As today's event shows it even happens to the big boys, and this is a predictable, pre-emptively solvable downtime event, so it really shouldn't happen.

</comment></comment></comment><comment><USER8> If this is anything like the issues we've seen at Stripe, the problem is probably an obsolete cross-signed root in your _login_ keychain. It's caused by a certificate with CN="DigiCert High Assurance EV Root CA" but signed by some other authority rather than being self-signed. It's not clear to us how these are getting into people's login keychains, as they're not present on a fresh install.

Typically servers will present their certificate and intermediates but not the root, under the assumption that browsers must already have the root in their CA store. So for DigiCert that would probably be all the certs up to but not including "DigiCert High Assurance EV Root CA".

You can see the presented cert chain using `openssl s_client -showcerts ...` or the Certification Paths section of the Qualys SSL Labs Test: [https://www.ssllabs.com/ssltest/analyze.html?d=github.com](https://www.ssllabs.com/ssltest/analyze.html?d=github.com)

Do you see an expired "DigiCert High Assurance EV Root CA" certificate in your login keychain? If so, delete it. If not, something weirder may be going on.

<comment><USER9> Just a heads-up for those who can't find the expired certificate: in keychain access, you have to click on "View > Show Expired Certificates".

<comment><USER10> Thank you!

</comment></comment></comment><comment><USER11> Looks like digicert itself screwed up - getting an invalid certificate error on digicert.com. Their twitter feed says they are in contact with GitHub, DigitalOcean, Namecheap, Stripe, Pingdom, and so on. This was a big error, and even they made the mistake on their own root domain.

</comment><comment><USER12> I'm having this issue as well. I deleted all digicert certificates from my keychain just in case. Still couldn't get to Github. I can get to the DigiCert Root Certificates download page, but it gives me an invalid certificate warning. It looks like the same issue as Github.

I really, really don't feel comfortable downloading a ROOT CERTIFICATE with an SSL warning on the page. Who knows what could be compromised in this case?

I'm going to try a couple other things first; I'd like to hear from a security expert, should we find this scary or just a small hiccup?

<comment><USER12> I had an outstanding OSX update, installed that and rebooted. One of the two fixed it for me. Note: I DID NOT have to install the the root certificates, and if anyone else gets an SSL warning from DigiCert's root cert download site, I strongly recommend against downloading anything from there.

</comment></comment><comment><USER13> Download your required certificate from here and it should work like charm

[https://www.digicert.com/digicert-root- certificates.htm](https://www.digicert.com/digicert-root-certificates.htm)

<comment><USER14> This is the right solution.

"DigiCert High Assurance EV Root CA" (Try test link before downloading). Add to KeyChain, restart browser.

</comment></comment><comment><USER15> Hah! I'm working on a side project to solve this problem: [http://www.renewalmonitor.com/](http://www.renewalmonitor.com/)

The idea is that the service will monitor things like domains and ssl expiry dates and then alert you in an increasingly obnoxious manner as the expiration date gets closer.

My MVP has just needs a few more finishing touches and then I'll send it live. In the meantime, you can signup on the waiting list.

Cheers.

</comment><comment><USER16> A fix to remove the expired cert right now:

[https://twitter.com/aarongraves/status/493116549599739905](https://twitter.com/aarongraves/status/493116549599739905)

Pretty sure this is on Digicert's side, but we (at GitHub) are investigating to make sure of that.

</comment><comment><USER17> I'm seeing the same issue on both GitHub and Heroku today as well. "Cannot connect to the real www.heroku.com

Something is currently interfering with your secure connection to www.heroku.com.

Try to reload this page in a few minutes or after switching to a new network. "

</comment><comment><USER13> I just upgraded the Cert from DigiCert Website. It's workable for 2038 now. Enough time. Who knows Github exist by that time or not.

</comment><comment><USER18> Is this only an issue for those using Google Chrome? I haven't had any SSL issues with Github all day using Firefox.

<comment><USER19> No, git fetch from MacOSX 10.10 command line as well:

        Maxims-MacBook-Air:walk maximveksler$ git up
        Fetching origin
        fatal: unable to access 'https://github.com/maximveksler/walk.git/': SSL certificate problem: Invalid certificate chain
        error: Could not fetch origin
        `git fetch` failed

</comment></comment><comment><USER20> not sure why, but i had to remove all the certificates and download its from here [https://www.digicert.com/digicert-root- certificates.htm](https://www.digicert.com/digicert-root-certificates.htm)

</comment><comment><USER21> I'm always surprised at how often this tends to happen to many startups/companies

</comment><comment><USER22> step tutorial [http://gianpaj.com/post/93100630815/cant-access-github-on- ch...](http://gianpaj.com/post/93100630815/cant-access-github-on-chrome-os-x)

</comment><comment><USER13> This certificate expiration also caused not using Github and HomeBrew from CLI.

</comment><comment><USER23> bitbucket as well

<comment><USER21> I thought you might have been joking. Weird.

<comment><USER23> I thought someone was after my private repositories

</comment></comment></comment><comment><USER24> What a fuck up. How did that go unnoticed.

<comment><USER2> It was noticed, but tested across a number of platforms did not show errors except for Android < v3.

The issue is with a weird Mac OS X chain issue that causes a chain to be downloaded to the login keystore in Keychain. Mac forces it to be used when validating the certificate chain. Most users have removed the cert and everything is working as it should.

Tracking down how and why that happens on Mac OS X is tough. Reaching Apple engineers has not been extremely successful. Not Apple's fault. Usually SSL Root Chain groups are distributed with organizations so it's not always clear who to go to.</comment></comment>


Judy Chu: How to talk about China's role in pandemic in racially sensitive way - <AUTHOR> https://www.nbcnews.com/news/asian-america/how-talk-abut-china-s-role-pandemic-racially-sensitive-way-n1235676 <comment><USER2> It shutdown Wu han in china but let WuHanians fought to the world. Index cases in quite a lot of cities like those in northern Italy are done because of this. And those better like Taiwan (and initially Hong Kong) is due to no chinese visit for some political reasons.

It is Wu han virus. Not because of any anti-china or cons. theory. Just fact.</comment>