Alex: A ML-enhanced range index - <AUTHOR> https://github.com/microsoft/ALEX <comment><USER2> The paper [1] does not refer to COLA or Fractal Indices.

[https://dl.acm.org/doi/pdf/10.1145/3318464.3389711](https://dl.acm.org/doi/pdf/10.1145/3318464.3389711)

ALEX uses gaped arrays (arrays with holes) to amortize key insertion. This wastes bandwidth - an exchange of read bandwidth wasted for speed of insertion gained.

Cache-Oblivious Lookahead Arrays (hence, COLA [2]) waste bandwidth in a different way - they use several layers of inserted data which are merged in amortized way during insertion.

[2] [https://en.wikipedia.org/wiki/Fractal_tree_index](https://en.wikipedia.org/wiki/Fractal_tree_index) \- Fractal Tree Index is based on COLA paper.

That COLA thing allows for variable size keys, etc. And, generally speaking, is quite fruitful and efficient structure, especially for a disk storage.

Because of this, I think this paper lacks very important part - a comparison with modern write-and-read-efficient structure. Without this comparison, it is not worth considering.

<comment><USER3> ALEX copies the next entry to the right into the gaps, meaning there's no read bandwidth wasted. It's also key to how they estimate the cost model to decide when to split a model. I'd suggest rereading the ALEX paper with a bit more care rather than using it just as a diving board to talk about unrelated papers you're fond of. There's some really interesting and novel ideas here.

<comment><USER2> Please forgive me, but no to both.

Having gaps in an array is a waste of bandwidth (TLB, for example, memory controller bandwidth is wasted too).

The COLA approach also can be adjusted - it is not necessary to have arrays with sizes that are power of two, we can use any other multiplier, correcting the necessity of merging. Many contemporary storage technologies can be adjusted to the workload and data statistics. Fighting against half a century (B+-trees were used by IBM in 1973) old technology with machine learning is, at the very least, not honorary.

Please, excuse me for not reading ALEX paper more thoroughly. I think onus is not on me in this case. So, my second no - I will not read ALEX paper again until they compare their achievements with more or less current technology.

</comment></comment></comment><comment><USER4> I had expected something really fancy for the predictive model, but it's a really simple linear predictor that even I can understand )

That's somewhat comforting, but I guess that limits the properties of the key space where it is useful?

[https://github.com/microsoft/ALEX/blob/d2fc3dc79766aa5c36adc...](https://github.com/microsoft/ALEX/blob/d2fc3dc79766aa5c36adc2772abd29b7fcf0e8fa/src/core/alex_base.h#L79) [https://github.com/microsoft/ALEX/blob/d2fc3dc79766aa5c36adc...](https://github.com/microsoft/ALEX/blob/d2fc3dc79766aa5c36adc2772abd29b7fcf0e8fa/src/core/alex_base.h#L120)

</comment><comment><USER5> This is an amazing accomplishment, I could see the ideas here being applied to more data structures

</comment><comment><USER6> This will be quite useful if ported to database

<comment><USER7> It is / will in various shapes. Check out Andy Pavlo's (CMU) work on self- driving databases [https://www.cs.cmu.edu/~pavlo/](https://www.cs.cmu.edu/~pavlo/)</comment></comment>


Ask HN: How long does it take you to familiarize yourself with a new codebase? - <AUTHOR> Sometimes, I try to contribute to open source projects, but codebase of some projects are huge (chromium, spidermonkey, anything written using LLVM (Swift, Nim), ...)
How long does it take to you, surf codebase, find something for yourself and try to create patch for it?
I am mostly interested in deeper knowledge of C/C++ in order to improve my skills in high-performance, distributed computation area.
But whenever I see huge codebase and until I surf the code, find something for myself, another guy would create a patch for it, or issues look so hard to begin with, or not possible for me at this time (consider beginner issues which require special environment with some special device)
So how do you contribute? What would you do in my situation? <comment><USER2> Too long.

I faced this problem while interning in the Google Chrome team and working on Chromium. Most of my time was used by reading the source code and figuring out the bigger picture of how classes and methods play together. I actually came to the conclusion that the big problem is that current tooling does not really support a developer on the task of reading existing source code. So I started building a new tool, Coati, an interactive source explorer for C/C++ based on clang. After using Coati myself for about half a year now, I can say that it really helps me navigate through the codebase quicker.

The tool is still at an early stage. We recently launched our website with a first release version: [https://www.coati.io/](https://www.coati.io/)

Do you think Coati is a tool that can help you?</comment>


What I look for in a pitch - <AUTHOR> https://news.greylock.com/what-do-i-look-for-in-a-pitch-866355bddb3 <comment><USER2> There is a difference between what VC's claim they look for, and what they actually look for. What they actually look for is momentum and all these conditions are 'bent' when that weird FOMO feeling takes over.

Anyone who thinks that all this data is pertinent to make the investment decision will most likely never say yes to any startup.

<comment><USER3> _What they actually look for is momentum and all these conditions are 'bent' when that weird FOMO feeling takes over._

Yup, this exactly. MAYBE your team matters depending on who you are talking with, but if some VC gets a whiff that you have 2MM users, are growing 5x MOM for the past 6 months with 1% churn and high engagement they will literally hunt you down to throw their money at you.

<comment><USER4> Can confirm. And they'll call you on your personal cell. VCs are tracking us just as much, if not more, as we are tracking them.

<comment><USER5> _Gurley spoke again and again on not getting Google, being put off by its valuation as many were back then. "[We are] looking for positive black swans if you think you see one any price is kinda any price," he said of the mounting valuation mania around unicorns. "The Google round-- because I was there went down-- $80 million-$90 million [pre-money valuation] with no revenue and it seemed crazy. You can only lose one time your money the real losses are the missed outcomes. You have to teach yourself to be more optimistic than maybe you were programmed to yourself because there's way more cost to a false negative."_

</comment></comment></comment></comment><comment><USER6> I don't understand.

> What's the difference between a great idea, and a early-stage VC-fundable > business?

Well, an early-stage business in my mind is a business that has some kind of product or service already built or at least a prototype.

But hopefully they already have customers.

> If the customer base grows, then you suddenly need to build a company that > can support that growth — an executive team of leaders and an organization > that can operate and adapt effectively without the founder driving every > decision.

In my mind I want to build a company with as little employees as possible with as much profits as possible. Is the way to do that really by employing an "executive team of leaders"? Isn't it just better to hire people that are productive and don't really need supervision in order to get things done?

Later on the author writes about an IPO, which is something that feels so far from the initial founding stage that it is useless to think about?

I wouldn't want to build a company if the only goal is to complete an IPO as soon as possible but maybe that's just me.

<comment><USER7> As others already mentioned, it sounds like your preference is building a bootstrapped company from day one without need for any VC funding. You're not the intended audience for the author's blog post.

But to respond to your other questions...

 _> Is the way to do that really by employing an "executive team of leaders"?_

Yes. Many founders can't delegate and end up obsessively micromanaging others which puts a ceiling on growth.[1]

 _> he author writes about an IPO, which is something that feels so far from the initial founding stage that it is useless to think about?_

The IPO thinking at the very early stage isn't necessarily premature because the founders may make early decision to offer equity (stock options) to employee #2 instead of a higher market salary. (Because they have no money to pay high salaries.) If so, they've basically chosen the fork in the road towards an IPO. If the employee can't eventually sell the stock (liquidity provided by IPO), there isn't much point to offering equity.

[1] [https://en.wikipedia.org/wiki/Founder%27s_syndrome](https://en.wikipedia.org/wiki/Founder%27s_syndrome)

<comment><USER8> Offering equity is nothing more than giving a stake in the company. An IPO is only one way that can pay off, and these days probably not even the most likely.

Of course VCs want you to believe that an IPO is the only successful exit, because they want moonshots. But as a founder you need to keep your own council as to the wisdom of pursuing growth at all costs.

<comment><USER7> _> Of course VCs want you to believe that an IPO is the only successful exit,_

Yes IPO is not the only way. VCs will also consider an acquisition by Google/Facebook/Microsoft/Amazon at a good price to be a "successful exit" and will explicitly go over those possible scenarios with the founder.

But there are other motives behind exploring the acquisition scenarios:

1) VC is actually asking in a more roundabout way if the founder has an answer for the above giants cloning the feature and rendering his startup obsolete

2) VC wants to gauge founders' openness to sell to earliest buyer or has plans to stick it out and stay independent until the end

I don't think Sequoia VC is complaining too much that WhatsApp never went to IPO. They still got a good return when Facebook bought it.

Also, I don't think VCs are actually that single-minded about IPO-or-else... especially for SaaS/enterprise type of startups. They will tell the founder that the more likely exit scenario is a bigger company acquiring them. This is not a big secret.

<comment><USER8> You can also grant equity in a bootstrapped or angel-funded company where the goal is not an exit, but to build a profitable business. The main thrust of my point is that granting equity to employees is not only for VC-funded companies in the typical moonshot case study.

</comment></comment></comment></comment></comment><comment><USER9> The feeling I get reading this, is that there's lots of groupthink and a whole lot of luck among VC's...

</comment><comment><USER10> > What's the difference between a great idea, and a early-stage VC-fundable > business?

I think we forget that a restaurant can be a great idea. It only makes sense for a restaurant to be an "early-stage VC-fundable business" if it's going to turn into a huuuuuuge chain.

But more importantly, the story of McDonald's rings true: McDonald's founder didn't do the work of expanding the chain.

In the VC world, a successful investment has a 10x return on the investment. A great idea may turn into a great small business with organic growth. It can provide for a career without needing VC investment! This can be a small group of consultants, or someone who builds an SAAS business.

(Edit) But, the thing about restaurant vs tech is that there's plenty of room for 1000's of small burger joints to co-exist with McDonald's. It's a lot harder for 1000s of "Joe's Git hosting" to co-exist with Github. Thus, it's often harder to see how a "great idea" in tech can turn into a small no-VC business.

</comment><comment><USER11> The cynicism in this thread makes me feel a little more confident that even if there was a bubble, its going to deflate, rather than pop.

A theory of mine is that really what we're seeing is a change in attitude about corporate governance and business building as the VC money from _outside_ the SV bubble becomes increasingly relevant.

Discussion of founder-friendliness recently seem to back that up in my mind. If FF attitude is going away, it is because of declining influence of the SV venture crowd controlling the narrative about their own special sauce and the right way™ to form a company.

Increasing diversity of LPs and VCs from outside SV are bound to have an effect on the attitudes toward companies being founded. Posts like this seem like justifications for existing behaviors, rather than a playbook based on any evidentiary burden.

<comment><USER12> The average person in SV is a cynic but the average dollar is metered by VCs.

</comment></comment><comment><USER13> The link to the Blitzscaling[1] article interviewing Reid Hoffman is a nice read. Good comparisons how Microsoft / Amazon / Google scaled up in terms of company org and even more insight with PayPal's customer service growth outside of Silicon Valley.

[1] [https://hbr.org/2016/04/blitzscaling](https://hbr.org/2016/04/blitzscaling)

</comment><comment><USER14> I read that page as "Here are a bunch of reasons why our answer might be no. Don't do this stuff. Don't talk to us if you haven't figured out these basic issues." It's not about how to get to yes. It's about how to get past no.

You get to yes by already being pretty successful, or for complicated subjective reasons that add up to apparent promise.

</comment><comment><USER15> The 'no market need is key'. I am remembering when I started my first business after graduating college. It was a retail business. The day before we even opened people were knocking on the door wanting to come in. Everything else that happened afterwords just flowed from that. It was really just simplistically executing and making it happen.</comment>


There's Still So Much We Need to Learn About Weed–and Fast - <AUTHOR> https://www.wired.com/story/theres-still-so-much-we-need-to-learn-about-weed/ <comment><USER2> The article doesn't really go into the scientific questions remaining, chief among them (IMHO) being the effect of weed on driving ability. There are some studies that suggest it's comparable to being drunk, but the evidence is still weak, and most people I know who do these sorts of things are oblivious or dismissive to it.

<comment><USER3> No doubt, if you live somewhere with it legalized, your insurance will go up. And there is no breathalyzer equivalent, so it is hard to prove someone is impaired.

</comment></comment><comment><USER4> The idea that kids eating edibles 'may not pose a risk to them' is absurd. It's not something I'd want kids exposed to.

</comment><comment><USER5> With the WHO recommending rescheduling, maybe research can finally happen at a normal pace.</comment>


Macho cultures are fairer for women - <AUTHOR> http://blogs.hbr.org/cs/2012/04/macho_cultures_are_fairer_for.html#.T5z073zqF5I.facebook

<comment><USER2> This is a very short post, with minimal statistical force, carrying the weight of precisely one writer's opinion, radically generalized to a universal law. Skip it.

</comment><comment><USER3> Or "macho cultures" have a lower percentage of male college graduates, creating more opportunities for women at the top. Or they correspond to fast- growing underdeveloped countries which, because they are developing in an equal(er) rights environment, aren't replicating the male-dominated model elsewhere. But who knows? There's not any data to back p explanations in the article anyway.

</comment><comment><USER4> Correlation does not equal causation. Brazil has a lot of features which differentiate it from countries like the US and UK. Picking two and simply assuming one must be caused by the other is a gross nonsequitur. Brazil also has a much stronger culture of birth control, and has experienced a lot more social and political churn in its recent history. I'd look to either of those as plausible contributing factors before fixating on negative stereotypes.

</comment><comment><USER5> When someone talks about a country with the size of Brazil like if it was a little city is just dumb, and all concepts are just pre-conceived. Brazil has lots of different cultures, it's the biggest country on south america.

</comment><comment><USER6> How are the US and the UK not macho cultures? Without clearly delineating what a macho culture is, this article is meaningless.

</comment><comment><USER7> Here comes another loud Hacker News gender 'debate'.

<comment><USER8> I swear this community falls for linkbait more than any other.</comment></comment>


Vancouver Airport blocking ads with information on travellers' privacy rights - <AUTHOR> https://globalnews.ca/news/5203960/yvr-rejects-ads/ <comment><USER2> As an airport traveler, I'm glad they blocked the ads for the phrasing submitted, but I'm upset that they refused to explain their reasoning and negotiate better phrasing. For example:

"Know your digital rights at the border" is great. It's in the classic tone of raise-awareness campaigns, does not use fearmongering, and can be safely ignored by anyone who already understands them.

"Your phone isn't safe at the border" is not great. It makes you feel afraid, mis-describes the issue (what about laptops?), and doesn't specify the vested interest (it's about rights).

Both parties deserve censure for their choices.

<comment><USER3> "Your phone isn't safe at the border" is a statement of fact, really, not fear mongering. It is not safe from warrantless searches.

<comment><USER4> But you just answered the GP's concern, safe from what?

Also, just my phone? What about my laptop? Safe from searches? Pickpockets? Malware?

There's a big difference between raising awareness of issues(ex know your rights - check out xyz.com for more info) vs big brother is, watching; trust no one, followed by a border security queue

<comment><USER5> >Also, just my phone? What about my laptop? Safe from searches? Pickpockets? Malware?

If slogans had to be that comprehensive to be allowed, we would be blessedly free of advertising.

"Your phone isn't safe at the border" is on pretty much the same level as "for everything else there's mastercard" on the accuracy<->drama scale. I think your standards are beyond unreasonable here.

</comment></comment></comment></comment><comment><USER6> > "In reviewing Open Media's request to place advertising at the airport, we > determined that it did not serve all of our stakeholders as we felt it > pitted two groups against each other and it also has potential to add undue > stress to the travel experience," wrote spokesperson Brock Penner.

What should cause every single person passing through that airport stress is the idea that their fundamental assumptions about personal security are incorrect.

</comment><comment><USER7> Good idea, bad approach. "Your phone isn't safe at the border" might be a hard fact but it's nonetheless an intentionally divisive expression of that sentiment. It's ambiguous, fearmongering.... facts can be clickbait, and this is one such case.

If the ads said "You can be legally compelled to X, even if Y. Learn more about your airport rights at www.url.com" then it would be much less objectionable IMO.

I don't get why campaigns keep making this mistake. Take the freaking high road. Imagine the mind of your opposition, and accomodate the low-hanging complaints they're going to have. Craft a message that's maximally agreeable to the people who disagree, while maintaining accuracy.

Weasels on both sides here, IMO.

<comment><USER8> >If the ads said "You can be legally compelled to X, even if Y. Learn more about your airport rights at www.url.com" then it would be much less objectionable IMO.

It's 'less objectionable' because it's bordering on bootlicking, and could even read as a tacit endorsement of the status quo.

<comment><USER7> Is that really bootlicking? I struggle to understand how that's the case, and I'd prefer to hear a dispassionate reading of reality that lets me decide how to feel based on my own values, rather than one that's intentionally extreme to try and scare me into subscribing to a position.

<comment><USER9> The phone is not safe from prying - their description sounds very accurate to me. Or would you describe a broken lock as 'safe'?

<comment><USER10> I wouldn't describe it as "unsafe". It's neither. Locks aren't dangerous. There is a whole level of subtext going on there and if you are in on it (which you seem to be), then it makes complete sense. If you are not, it leaves you scratching your head (as I was). I will argue that it is completely ineffective wording as the only people who will understand what it means are the people who don't need to read it.

</comment></comment></comment></comment></comment><comment><USER11> > _They said we didn't fit into the criteria but weren't able to tell us at > that point what were the criteria_

This kind of thing is problematic when someone has a monopoly, which governments and major airports do by default. It might be reasonable under some conditions to have criteria for rejecting ads that are too political, controversial, unfair to the airlines, etc... but those criteria should be published.

</comment><comment><USER12> > "In reviewing Open Media's request to place advertising at the airport, we > determined that it did not serve all of our stakeholders as we felt it > pitted two groups against each other and it also has potential to add undue > stress to the travel experience," wrote spokesperson Brock Penner.

I now have undue stress because of you Brock Penner and your stakeholders.

Who are these two groups? Your customers and an oppressive regime?

</comment><comment><USER13> > YVR aims to be non-political

…telling people about their rights is non-political.

<comment><USER14> That's a dishonest quote, you didn't include the context that was provided on why YVR considers it political.

> Additionally, YVR aims to be non-political and Open Media's borderprivacy.ca > website promotes an online petition with a political call-to-action directed > towards government officials.

Not that I agree with YVRs decision not to allow the ad, but I find it hard to argue that a website including a petition and urging visitors to message the government about the issue to be "non-political."

<comment><USER15> Your point is technically correct (the best kind of correct), but consider that in the US, the IRS's rules for 501(c)3 organizations, for example, allow those organizations to advocate for political policies without jeopardizing their tax-exempt status, but not for or against candidates.

There is a legitimate argument to be made that policy advocacy is a different kind of "political" than what people generally take that term to mean.

EDIT: That said, I agree with the many other comments here that the tone of the ad in question was confrontational, counter-productive, and fear- mongering. They could perfectly well have made their — again, technically correct — point with a more constructive or informative tone.

<comment><USER16> I get that you used it as an example, but IRS's rules wouldn't apply or likely even be relevant to a Canadian airport's internal policy.

</comment></comment></comment></comment><comment><USER17> Advertises and marketers mislead and exaggerate with near impunity and use legalistic language drafted by lawyers to cover their asses. It is standard practice for companies to knowingly deploy psychological trickery in order to manipulate consumers, including very young children. This is accepted because capitalism is the one cow that can not be slaughtered. Profit is always good. Caveat emptor.

But a civil liberties group informing citizens of their rights in an attention catching way is deplored as intrusive and inappropriate and not "objective" enough.

This attitude speaks volumes about a society that has lost its way and is slowly collapsing under the irreconcilable contradictions it refuses to honestly address.

</comment><comment><USER18> I encourage people to read this article as it more or less gives each side their "best shot" by fully quoting the airport's position, in their own words. I'm sure the side blocking the ads would prefer that the headline redd "rejects" or "chooses not to run" (rather than blocks), but in the body of the article they have a chance to state their piece in full. I'll quote this part (in the article this is followed by a direct quoted rebuttal literally starting with the words "This is wrong"):

>"In reviewing Open Media's request to place advertising at the airport, we determined that it did not serve all of our stakeholders as we felt it pitted two groups against each other and it also has potential to add undue stress to the travel experience," wrote spokesperson Brock Penner.

>"Additionally, YVR aims to be non-political and Open Media's borderprivacy.ca website promotes an online petition with a political call-to-action directed towards government officials."

(It should go without saying that I am not endorsing this statement.)

</comment><comment><USER19> A recent student software engineering competition competition in Canada gave first prize to a team that used cell phone signals and embedded devices around an area to locate a person and track their movements. It was a sponsored project, the idea being to use it in airports. The sponsor was very happy.

</comment><comment><USER20> Can't we target mobile users that just arrived within a geo fence from a long- distance-away geofence?

</comment><comment><USER9> Yet another example of the failure of the narrow view that free speech only concerns government. A view that is disturbingly popular (see [https://xkcd.com/1357/](https://xkcd.com/1357/)) despite an ever larger portion of public speech being conducted through corporate platforms.

<comment><USER15> Requiring private parties to convey speech they disagree with is, itself, a violation of their freedom of speech.

EDIT: Otherwise, please explain to me how _compelled_ speech is "less bad" than its restraint.

<comment><USER9> You skipped a step, jumping straight to a possible solution. But that may not be the only solution, and even if it were, it shouldn't prevent us from acknowledging the problem.

And it gets blurry when the private parties are ISPs or phone companies.

Edit: Alright, taking the hypothetical that the solution is compelled speech, I'll try to explain how it's less bad. First is that there's a distinction between original speech and _conveying_ the speech of others. E.g. it would be pretty awful if ISPs or phone companies started interfering with what they'll transfer through their networks. I frankly disagree with calling what a telecommunications provider does 'speech' \- they're paid to move bits, like a moving service is paid to move furniture. And second, if you don't look at it through such an abstract "free speech vs. compelled speech" lens, but through a pragmatic "who can speak and what can they say" one, you'll see that almost no-one has effective free speech. Online, almost all of the audience is on (a small handful of) private platforms, carried by private ISPs, hosted on private servers. Offline, people spend much of their time in privately-owned spaces, such as airports. If you cut all those away, how much speech does the great 1st Amendment buy you? You can yell on a street corner (not Wall street though - those streets are private!), or in the woods, and send a few paper letters through the government-ran post office. You'll reach maybe a handful of people. Meanwhile speech blessed by the platform owners will reach millions. Difference from complete censorship is negligible. That's why you shouldn't legislate in a vacuum divorced from reality, where only platonic ideals of free or compelled speech exist. You'll choose an ideal free speech law, and the effect will be that a handful of corporations will get to decide what can be said.

<comment><USER15> Re: your edit:

The First Amendment doesn't guarantee you an audience. It only guarantees you that _the State_ can't constrain your speech without a damned good reason. It is utterly orthogonal to conduct between private parties, and it's specious as hell to bring it up in that context.

For example, even in the case where it effectively limits your ability to sue people for speech you don't like, the _actual_ constraint is on the ability of the State, in the form of the court system, to be leveraged against an individual's speech, not on your ability to sue.

<comment><USER9> I know very well the 1st Amendment applies only to the State - my whole series of posts is about the problems that arise due to that. Free speech as a concept is not limited to the 1st Amendment.

<comment><USER15> Your right to make noise with your pie hole in no way obligates anyone else to listen to, or even hear you, let alone broadcast that noise to a larger audience than you would have had without their help. Full stop.

There is absolutely a legitimate, and very, very important conversation to be had around whether, e.g., online censorship or moderation or "deplatforming", or whatever, might constitute something functionally akin to prior restraint, where the edge cases are in those questions, and what to do about all that.

That said, having those discussions about private behavior using terms that are — and historically have more or less _always_ been — used in the specific context of the State only confuses things.

My point being: if we're going to have that discussion, which we for reals should be doing, let's try to do it in a way that doesn't make it _harder_ to have, let alone have productively.

The attempt to expand the specifically and narrowly constrained notion of "Free Speech" (note the capitalization) to domains other than a constraint upon the State is a specious conflation, and ultimately yields more heat than light.

EDIT: I mean, really, how productively can that conversation be had if it's using terminology that enables randos who don't meaningfully understand this distinction to pile on, all, "But the Twitters violated my 1st Amendmentses!"?

</comment></comment></comment></comment></comment></comment><comment><USER21> globalnews.ca blocks videos if you use ad blocker.

<comment><USER14> good. Autoplay videos on most news sites are useless.

<comment><USER22> At best, useless. At worst, detrimental to the experience. It's a good way to drive me away from your site. I can't think of anything I hate more (in design terms) than the current trend of auto-playing videos following you down the page.

</comment></comment></comment><comment><USER23> "In reviewing Open Media's request to place advertising at the airport, we determined that it did not serve all of our stakeholders as we felt it pitted two groups against each other and it also has potential to add undue stress to the travel experience," wrote spokesperson Brock Penner.

Just so much wrong in this quote, three questions for Brock:

Which stakeholders aren't being served?

What two groups are being pitted against each other?

Is stress that results from knowing the extent of your rights 'undue'?

<comment><USER24> I am guessing the two groups are border security and airline passengers.

</comment></comment><comment><USER25> I'll assume the two stakeholder groups referred to are travellers and CBSA.

I believe they should let the advocacy and informative message run.

The message is sensational, but no more so than any other ad with an agenda (i.e. all of them) and many travellers through YVR (Canadian or otherwise) would benefit from considering what they may be compelled to share, without warrant or regular safeguards, with CBSA.

And if CBSA wants to run a sensational, informative, and fear-based campaign of their own, let them. (As if they already aren't.)

</comment><comment><USER26> When at airports, I want to see kinda harmless ads: beautiful homes, greenery, that sort of thing. I'm fine with this. Traveling is stressful enough as it is.

If this were a frequent event it'd be fine, but it's a rare event, so I'd rather be chill. Like having a big ad saying "Your plane could crash" before the gate. No thanks. Not worth it.</comment>


The fish shell is awesome - <AUTHOR> https://jvns.ca/blog/2017/04/23/the-fish-shell-is-awesome/ <comment><USER2> I switched to fish a bit more than a year ago. I used to have a script with shorthands of frequently used long commands because I just couldn't get to them easily enough with bash's ctrl+r.

Now with fish, I don't need that anymore. Pressing up a few times always gets what I need and I don't need to come up with names for shorthands. (If I really want to name it, I can always add a # "tag" at the end. A trick I picked up from one of the post here (I can't remember which one).)

Although sometimes I do wish there was a keyword search feature treating space as a separator for what I've already typed. One frequent case is when I'm looking for `rsync --bunch --of --options user@server:path other_path`. I remember `rsync` and I remember `user@server` (or one of the two paths) but not the rest (and I also ssh, sftp, scp, etc to the same place a lot).

</comment><comment><USER3> Zsh can do all of these things without too much configuration, but Fish is still missing my favorite Zsh feature: `push-line-or-edit`: [https://nathangrigg.com/2014/04/zsh-push-line-or- edit](https://nathangrigg.com/2014/04/zsh-push-line-or-edit)

</comment><comment><USER4> Personally, if POSIX compliance wasn't mandatory I'd go one step further and go with Xonsh, which offers more tangible benefits.

As it is, I can add a couple of plugins to zsh with zgen and get most of what makes fish interesting. They're great ideas, but there's no need to sacrifice so much for them.

</comment><comment><USER5> Fish' auto completion is what's been keeping me on it all these years. I tried to switch to zsh and hack some autocomplete on, but it didn't work nearly as well.

</comment><comment><USER6> It's nice, but it has its rough edges.

Just look at the longstanding HISTFILE issue. (I would link it, but GitHub doesn't have search on mobile)

</comment><comment><USER7> Incompatible with bash which is ubiquitous. I much prefer zsh which can do everything fish can

</comment><comment><USER8> Yes it is</comment>


New $11 HDMI video capture card outperforms the $280 market leader in 1080p - <AUTHOR> https://www.youtube.com/watch?v=qlrtAUCDFAQ <comment><USER2> with respect this yt review of the item talks too long and as best i can see does NOT even test / demo this item? Just (eventually...) talks about a 3rd party review?

[https://mobile.twitter.com/Ascii211/status/12686310690514534...](https://mobile.twitter.com/Ascii211/status/1268631069051453448)

sorry for any bad attitude. just found the yt vid irritatingly slow, repetitive and in the end not even from a user of this device.

<comment><AUTHOR> Hmm well you learned about the very useful NASA guy that ripped it apart and found the latency is only 20ms so that's good I suppose.

</comment></comment><comment><AUTHOR> Would really love to hear from the designer / manufacturer of this device.</comment>


Ask HN: Best backups/sync for virtual teams (DropBox or CrashPlan or??) - <AUTHOR>

HNers,
I work for a consultancy where my team is 100% virtual (First time working 100% from home + travel -- best decision I ahve ever made) - and I need to find a good way to share, sync and backup my data and the teams data.
I have been encouraging others to use DropBox, but it is so focused on individual use and completely not designed around multiple users accessing the same data, that I am not sure how well it will last in the long term. (Is dropbox even considered by any of you as a real and viable data backup model? Or just a convenient data access utility?)
Is CrashPlan the enterprise version of DropBox? Or simply cloud backup?
I want to know the best tool for cloud backup, team data sharing/sync?
Anyone have any advice? <comment><USER2> Take a look at <http://box.net>. I have a friend who uses it in his small organization and is pretty happy with it.</comment>


Drone Delivery Becomes a Reality in Remote Pacific Islands - <AUTHOR> https://spectrum.ieee.org/the-human-os/biomedical/devices/drone-delivery-becomes-a-reality-in-remote-pacific-islands <comment><USER2> Why are they showing only quadcopter drones on images? AFAIK for long distance flights you _need_ winged drones, which are much more efficient... You should of course adapt them so they can take off & land vertically, like Google's Project Wing.

<comment><USER3> Because fixed wings require either landing/takeoff strips, or complex systems to transition between two modes of flight. Quadcopters, with their only four moving parts, are a simpler option. If the capacity/range is there, why not go with the easiest to maintain? It's not like they are paying for fuel.

<comment><USER4> > _Because fixed wings require either landing /takeoff strips, or complex > systems to transition between two modes of flight_

For small planes you don't need a full strip. You can use launch accelerator ramps and capture harnesses for a very small footprint, ala Zipline. [https://www.cnet.com/pictures/take-a-look-at-ziplines-new- dr...](https://www.cnet.com/pictures/take-a-look-at-ziplines-new-drone- delivery-system/)

<comment><USER3> Such systems require someone trained at the receiving end. A quad can land and take off without much, if any, human interaction needed. That can matter if you perhaps want to drop something at a location where there might not even be any people waiting to receive it. (In SAR scenarios helos often drop supplies in fields even though those who need them are hours away.) Needing any physical landing/takeoff equipment at the destination also means that you can only deliver to prepared routes. So you couldn't do rapid response to remote locations. Physical equipment can also be damaged in disasters(hurricanes) after which air transport is most needed.

<comment><USER5> Zipline's landing system is totally automated, so I don't think it needs anyone specially trained, but it does need equipment to land. They don't land at the receiving end, though, they drop the package via parachute, with a claimed accuracy of within two parking spaces. So, the origin point (where the packages come from) is fixed, by they can do arbitrary destinations so the routes aren't fixed.

</comment></comment></comment></comment></comment><comment><USER6> [http://www.flyzipline.com/](http://www.flyzipline.com/) is already doing this in Africa (specifically Rwanda and Tanzania), seems like a good contender.

<comment><USER7> Vayu too, though they're less publicized about: [https://www.vayu.us](https://www.vayu.us)

<comment><USER8> The Vayu craft strongly resembles the prototype passenger-carrying tilt-rotor- wing craft Airbus is test flying at the Pendleton, OR test range:

[http://nwnewsnetwork.org/post/robo-air-taxi-makes-first- flig...](http://nwnewsnetwork.org/post/robo-air-taxi-makes-first-flight- pendleton-airport)

<comment><USER9> Other than having two wings I don't really see the similarities between Vayu and Vahana. BTW, a better source of info on Vahana is from the project itself: [http://vahana.aero](http://vahana.aero). Disclaimer: I work on the project.

</comment></comment></comment></comment><comment><USER10> I was expecting drone boats, which I imagine might take larger loads farther.

</comment><comment><USER11> > Today, shipments are flown from the three major islands (which have cities > and airports and such) to small rural islands in 9-seater planes. When a > plane rolls to a stop on the grass airstrip, it's met by someone from the > local health clinic—but that's assuming that one of the few trucks on the > island is available and in working order.

Why do small parcels need to be moved by big trucks? Why not motorcycles? Cheaper and easier to operate and maintain, and off-road models can be used where trucks can't. Motorcycles are ubiquitous on the islands and is an appropriate technology. Drones are the exact opposite.

They already have the planes, motorcycles can be sourced in a matter of weeks. Whereas this will take a fortune and years to develop, and it's not even certain it will work before they run out of money.

I've been there and I know how Vanuatu works. This is clearly some elected retard in Vila playing games with the national budget as every other one has done since 1980.

<comment><USER12> As I understand the article, drones replace people hiking over mountains. It seems plausible that these hiking trails can't be safely navigated on bikes.

<comment><USER13> But can be navigated by trucks?

<comment><USER12> No the trucks bring the packages to the central hospital, not to the secluded villages.

<comment><USER13> So then what does using trucks instead of motorcycles have to do with the passes being non-navigable by bikes?

</comment></comment></comment></comment></comment><comment><USER14> >>When the delivery drones fly behind a mountain, the operators will have to send signals either via a relay aircraft or a satellite.

Wouldn't it be easier to deploy a high-altitude balloon tethered to the ground, with an antenna? Should be much much lower operating cost than relay aircraft and better latency than satellite relay?

</comment><comment><USER15> > _The conditions in Vanuatu make vaccine distribution a tough challenge. > Today, shipments are flown from the three major islands (which have cities > and airports and such) to small rural islands in 9-seater planes. When a > plane rolls to a stop on the grass airstrip, it's met by someone from the > local health clinic—but that's assuming that one of the few trucks on the > island is available and in working order.

The health worker picks up the vaccines, which are packed in ice, and hurries back to the clinic to stash the precious vials in a refrigerator—but that's assuming the fridge and the clinic's solar power system are working. Any breakdown is a serious problem, because spare parts can take weeks to arrive. And the whole operation is very expensive._

It sounds like they're going for JIT delivery, deliver the vials to the remote hospitals as they're using them - instead of transporting a supply that the remote hospital would store. This would obviate remote refrigeration, removing numerous situations where the supplies could go bad. They could get an email from the remote hospital and send a drone with a few insulated vials right away.

If the drone payload is big enough, they could replace the airplane and trucks too, saving a lot on fuel and maintenance costs.

<comment><USER16> The drones would have to be pretty tough to do JIT delivery during cyclone season. Maybe it can be done when the weather is good, provided that it is beneficial to do so.

<comment><USER2> I wonder if there's another way to "protect" them during bad weather... Maybe by turning drones into zeppelins? So they couldn't "crash" but would merely get "blown away", and hence wouldn't need motors for levitation, but only for horizontal movement.

</comment></comment></comment><comment><USER17> PR stunt for delivery-by-drone companies: deliver symbolic vaccines to Nome, Alaska, and get video of the competing Iditarod teams along the way. Be sure to keep both batteries & vaccines warm.

</comment><comment><USER18> I wonder how regularly these vaccines are needed, or what is the frequency of demand for them? Maybe the drones will deliver other medical supplies as well?

</comment><comment><USER19> There's a joke to be made here about the cargo cults, but I'm having trouble coming up with anything sufficiently witty.</comment>


Kegan's Theory of the Evolution of Consciousness - <AUTHOR> https://tomprof.stanford.edu/posting/1110 <comment><USER2> _I was talking with the guy who ultimately edited this book, and his son had just watched Star Wars, his 4-year-old-son, and was very affected by it. And I kind of had this theory that when you 're a very young person, the character in Star Wars you care about the most or like the most is Luke Skywalker, who's this, you know, wholly good, heroic, almost naively pure kind of character._

 _And then you become, you know, 12 years old, a teenager, and you gravitate toward Han Solo, who seems like a bad person, but ultimately he is good. And when you 're kind of going through adolescence, you sort of like the idea of being perceived as a dangerous individual, even though you still sort of identify as being good._

 _" But when you really become adult, you're no longer looking at characters — fictional or unfictional — as aspirational. You kind of are the person you are. And now when you look at characters, you kind of want to see things in them that help you understand yourself. So I feel, as an adult, the character you care about the most is Darth Vader. The maturation process seems to move a person toward relating to and understanding villainous personalities._

-Chuck Klosterman

[https://www.npr.org/2013/07/09/200141185/chuck-klosterman- on...](https://www.npr.org/2013/07/09/200141185/chuck-klosterman-on-batman- bad-guys-and-wearing-the-black-hat)

<comment><AUTHOR> As I think about this more, when I first watched the office series I related more with Jim however as I got older and kept watching it again and again I started relating more with dwight.

</comment></comment><comment><USER3> > While most students approach learning from an order 3 perspective, teaching > is generally approached through the lens of order 4, creating a > developmental mismatch. For instance, instructors expect students to be > self-reflective, engaged, independent, self-directed, critical thinkers- > skills that become evident only in order 4.

Can confirm, based on my undergrad experience. Virtually none of the students (myself included) were yet at the level of maturity expected of them.

<comment><USER4> Absolutely. My wife went back to school to finish her undergrad in her 40s. It was amazing to observe the immaturity of the people around her. She ended up graduating top of class in everything and getting multiple awards for best social science, anthropology, best student in arts department, best part time student, etc. for the year.

Yes, she's a smart cookie -- but more than that, the other smart people around her? They just weren't mature and serious enough to excel.

</comment></comment><comment><USER5> Kegan's work has been quite influential for me, both in helping me understand myself and others.

His later work, collaborating with Lisa Lehey is more actionable, in a work context, but builds on the foundations outlines here.

<comment><AUTHOR> Nice, I am just beginning to explore his work. Any recommendations on the books or articles would be great.

<comment><USER6> David Chapman quotes Kegan a lot in his "Meaningness" blog. I included one link, but you should find more of his writing linked from there. Check out the rest of the site as well.

[https://meaningness.com/metablog/stem-fluidity- bridge](https://meaningness.com/metablog/stem-fluidity-bridge)

ETA: From the (Stanford) article this thread is attached to...

> Kegan (Robert) introduced his theory of self-evolution in 1982 in his book, > The Evolving Self. In his later book, In over Our Heads: The Mental Demands > of Modern Life (1994), he presented a revised version of his theory and > further discussion of the implications of his work for society.

Of those two books, The Evolving Self is the easier read. I would start with that one.

<comment><AUTHOR> Ha that is where I found kegan. Meaningness blog is a reip down the rabbit hole.

</comment></comment></comment></comment><comment><USER7> Great recent interview [https://www.youtube.com/watch?v=bhRNMj6UNYY](https://www.youtube.com/watch?v=bhRNMj6UNYY)

<comment><USER8> One more vote for this podcast. They produce extremely high-quality interviews.

</comment></comment><comment><USER9> Order 6: Illusory Mind. In this order, consciousness reaches a level of self reflection that leads to the realization that self-hood is an object in subjective experience and merely an observer of thoughts, not an author. Free will slowly begins to erode and the mind is finally set free.

</comment><comment><USER10> > Order 5: Self-Transforming Mind. In this order of consciousness, which is > infrequently reached and never reached before the age of forty (Kegan, > 1994), individuals see beyond themselves, others, and systems of which they > are a part to form an understanding of how all people and systems > interconnect (Kegan, 2000). They recognize their "commonalities and > interdependence with others" (Kegan, 1982, p. 239).

This idea is awesome, and is common sense in eastern philosophy. First generation Americans, or anyone who finds themselves the venn between multiple diagrams of culture, can also arrive to this pretty quick. Everyone's ideas are limited to the experiences that produced them, but it's embarrassing for western science on the whole for it to shirk the east when it comes to the realm of inner experience.

</comment><comment><USER11> At stage 0 it is immediately taken for granted that there is a sense of self, an identity. This is a very bold leap and his entiry theory builds on this.

<comment><AUTHOR> I didn't get that from him. In state 0 the baby has sense but not about the self. Imo self is something taught by the society and nurturing so baby would not have that concept.

<comment><USER12> Parts of the world belonging to a system and other world parts are so different in a system's ability to control them, that I suspect that any system capable of planning, learning and building world-models will naturally divide the world into self and not-self.

In state 0 such discovery just hasn't happened yet.

</comment></comment></comment><comment><USER13> I've found Kegan's work to be an extremely useful lens on the world, and I've found his research with Lisa Lahey to be extremely useful both for my personal development and for my company. We currently have a pilot program implementing insights from their books An Everyone Culture: Becoming a Deliberately Developmental Organization (one of the best books I've read in years, and I read a lot) and Immunity to Change, and I think it's made a significant difference for those who are taking part in the pilot and for the company in general.

</comment><comment><USER14> I recently found out that my schizophrenic mom committed suicide. This was the end of a childhood that was filled with abandonment, neglect, and abuse.

I recently started meditating and read "The Power of Now". I think without those two things I would be completely lost. It's still hard but I can feel myself getting stronger in the face of all this.

</comment><comment><USER15> Before you waste your time, this regards the personal development of consciousness over one's lifetime, not the biological evolution of sapience.

<comment><USER16> Came for the homo sapiens evolution discussion, but individual psychology is not below me, as presumed in your comment.

</comment></comment><comment><USER17> To those interested, the Urantia book describes our individualized purpose as to becoming increasingly conscious by evolving and becoming progressively more spiritual until we can understand God the Father. It describes evolution not just as a species, but within each of us; and that actually God created us purposely to evolve and become like Him, for reasons still unclear to them.

Kegan's theories and philosophies seem similar, but the Human soul would not just be limited to 5 potential stages, as Kegan described. Probably, Kegan himself has been limited to acquiring just a 5th stage, but these stages are possibly unlimited.

According to the Urantia book, by eventually becoming so spiritual, the body can no longer contain the Spirit, so it will automatically proceed to a next stage bypassing death, like what happened to Jesus Christ, Elijah the Prophet, and Enoch in the Holy Bible.

<comment><USER18> The point of life is to increase our level of consciousness to the point that we become infinitely, universally loving and utterly, absolutely selfless. This state of consciousness is God.</comment></comment>


The Foreign Visa Crackdown Is Putting Americans Out of Work - <AUTHOR> https://www.bloomberg.com/news/articles/2017-06-21/the-foreign-visa-crackdown-is-putting-americans-out-of-work <comment><USER2> I'm strongly in favor of open borders and immigration, as long as immigrants have all the same workplace protections as American citizens.

But the argument that Americans won't take these jobs is and always had been bullshit. They'll take the jobs if you pay well enough. A whole lot of the American economy runs on effectively indentured servitude, either from illegal immigrants working under the table, or legal immigrants trapped in jobs because of the terms of their visa or literal prisoners or literal slave labor from sweatshops in developing countries and it depresses salaries for everyone.

We have an expectation for the price of goods and services that's based on the idea that the less privileged should do shitty backbreaking work for next to nothing.

One of the things that had lead to the rise of vile, xenophobic populists like trump has been the complete unwillingness of both parties to address this, and the unwillingness of Americans to recognize that the cheap shit they buy from Walmart and amazon has real human costs.

<comment><USER3> >They'll take the jobs if you pay well enough.

Taking a job and doing it with sufficient attention/quality/skills/etc. are two different things. No money would make most of Americans working 110F strawberry field for any prolonged period of time. Even $1M/day - most would just quit after a week with cool $7M (at least i'd :)

Of course, the immigration system making illegals pretty much slaves is just a shame for a civilized society and has to be replaced with more humane system. We should value and respect people doing such hard and undesirable jobs. Practically it means at least minimum wage and all the labor laws irrespective of status (one of the effects otherwise is just breeding predatory employers and that drugs the society back and lower). And of course the minimum wage in US should already be 2x-3x what it is now (the current minimum wage in US is another shame for a civilized society)

<comment><USER4> Actually I think $40/hr (obviously not a real number) would get quite a large labor migration to the strawberry fields. North Dakota saw a huge influx of out-of-work men when oil was booming.

<comment><USER5> Sure, and then the price of strawberries goes up, and grocery shoppers complain and don't buy them.

The US is addicted to cheap goods. In many sectors cheap goods can't be had without cheap labor.

<comment><USER6> You are exactly right. But who said that strawberries should be inexpensive and found in every fridge in America? What you have just acknowledged is that strawberries are not cheap. They should not be cheap.

The real danger here is not that Americans will be deprived of strawberries. The danger is that some American who does not actually harvest strawberries will not be able to profit so much from strawberries. Their business will be in jeopardy. It is obviously bad for America when we drive businesses out of business. American business people need to be able to have somebody else do all the work very cheaply so that the American business person can profit.

If nobody values your product enough to pay its true costs, the answer is to reduce costs by having somebody else work cheaper. If the free market doesn't support cheaper labor costs, you need to use some other method to reduce labor costs. Wielding control of immigration status is one tool to incent cheaper labor.

<comment><USER5> > If the free market doesn't support cheaper labor costs, you need to use some > other method to reduce labor costs.

What if you can't? Do we just do without strawberries, then?

</comment></comment></comment></comment></comment></comment><comment><USER7> Recently heard someone argue "If you can't afford to pay livable wages, then you can't afford to be in business". Have to say I agree with that. It's hard for me to feel sorry for businesses who rely on importing cheap labor to survive.

<comment><USER5> I'm sure you'd also be totally ok with the _much_ higher prices this would cause?

<comment><USER8> The greater part of operating cost isn't wages, it's rent for the premises, cost of energy and of raw materials, and yet this pernicious meme gets trotted out every damn time the subject of minimum wage comes up. What I cannot understand is why that is.

<comment><USER9> I understand why: _It serves the interest of CEOs_

What I don't understand is why non-CEOs believe it so dogmatically.

</comment></comment></comment></comment><comment><USER10> We need to start distinguishing between the H1B abuse of several large foreign consulting companies and the seasonal low skill jobs in our discourse. You yell "let's reform the visa process" in a crowded room in this country and everyone cheers for different reasons.

<comment><USER11> That's right, it isn't black and white. There isn't one knob to turn. If you read the visa regulations, it looks perfectly fine. But "body shops" game the system. Because, short of litigating every job description, there is no visibility by regulators into job requirements and whether applicants meet those requirements, H1-B has hijacked for the purpose of wage suppression.

There's also no bright line between the generally bad actors and the good guys. Even R&D-oriented high tech companies that often use H1-B for the intended purpose of importing otherwise unobtainable talent also use H1-B (and other methods like anti-poaching agreements) for wage suppression.

Reform needs to be flexible and enforced by financial incentives, like auctioning visas at a high reserve. It does not need to be cheap for employers.

<comment><USER12> I think wage suppression was a side effect despite good intentions. In addition, H1Bs are/were a mechanism for outsourcing companies to win US IT contracts. Auctioning visas may not solve this problem.

Other causes of recent wage suppression include the no-poaching and other gentlemen agreements among the big players in the Valley. In addition the basic, I'm not going to pay more than the other guy (or the minimum I can get away with).

Wage suppression comes in other forms too. Asking for previous salaries, asking for W2s etc... Some companies are so large that they just refuse to pay more as well. But that's just "the market" at that point. In every company there's some maximum value for you.

The only way to escape this is to start your own company.

</comment></comment></comment><comment><USER13> Two diametrically opposed quotes from the article:

"Employers find the H-2B program expensive and bureaucratic, and tend to reserve it for hard-to-fill jobs that are critical to expanding operations." (American Enterprise Institute for Public Policy, 2011)*

vs.

"In the Pentagoet's case, that's meant six women from Jamaica (about a fifth of the total staff) who work in housekeeping and in the kitchen."

Are housekeeping and kitchen jobs hard to fill, critical to expanding operations, and worth significant investment? I'm just confused about H1-B in general and what it's supposed to do. Bring high-skilled workers? Provide cheap, seasonal labor? Both?

*Paraphrased for readability. Original quote hedges the conclusion.

<comment><USER14> > Are housekeeping and kitchen jobs hard to fill, critical to expanding > operations, and worth significant investment?

No. In the Pentagoet's case, this is about being able to find pre-trained workers without paying the market rate. This place has gone out of their way to establish travel and housing, yet completely failed to look in any major urban area for staff. Ask yourself why that is.

</comment></comment><comment><USER15> "Many Businesses Are More Viable When They Can Pay Employees Peanuts"

Looking forward to more insightful articles from Bloomberg.

</comment><comment><USER16> Counterpoint to their argument. Japan has negative population growth and an aging population. Yet, outside of Tokyo and even in Tokyo it's rather rare to see foreigners do the "immigrant" work that we see in the US.

Go to a restaurant in Tokyo, for the most part the cooks server and other staff are Japanese --you will see a smattering of foreign staff, but it's not nearly the same as in the US. And that is in an economy with an aging population and decreasing population.

And things are not super expensive. Food is healthy and reasonably priced. Some foodstuffs cost more than the equivalent in the US but Japanese are quite willing to pay the price difference to keep their farmers afloat --many times have they imposed barriers to cheaper imported foodstuffs but they like things their way.

Point is, it's not pre-ordained to ruin an economy.

</comment><comment><USER17> Came here for the comments.

Just wanted to make sure that FOSS hadn't made everyone open borders evangelicals.

Many demographics have huge unemployment problems, mostly NEETs, because the jobs they used to do are replaced by absolute lowest wage immigrants. This problem has been long brewing in the US, and I just don't understand how making it worse (more immigration) is going to solve it. At the same time I know I'm a massive beneficiary with overseas production of my products and cheap food at home.

Also, why is HN posting pure political articles so much now? I understand technology intersects with politics, but at this point anyone strongly advocating for saving the H#B programs are probably H1B beneficiary companies which are only the Big tech companies, so a story like this feels like it's rolled out to the tech community to soften you up to the plight of the H2B community.

If that's the case, this is nothing more than a propaganda feed.

<comment><USER12> What's a NEET?

<comment><USER17> "Not Seeking Employment Education or Training"

Economics term, growing subset of mostly disconnected young men across NA / EU.

<comment><USER12> And what's a FOSS?

<comment><USER17> Free Open Source Software.

Am I getting trolled?

</comment></comment></comment></comment></comment><comment><USER18> If they need low-wage unskilled laborers, surely there are high school students or college students who would do the work while on summer break. I worked in a kitchen as my first job (age 16) and it was a great experience, even though it was hard work with low pay. Some of the people working there were immigrants (not seasonal though) and it was a great cultural learning experience in that respect too.

Sure there will be increased turnover and more expenses spent on hiring, but that should be accepted as a standard cost of doing business. Also, hiring young people is better for the community. When a young person has their own job they learn responsibility, money management, and are contributing to the economy instead of getting into trouble.

The numbers of young people working part-time or over the summer has dropped significantly in the past 30 years. I wonder if the ease of getting visas for seasonal labor has contributed to that.

</comment><comment><USER19> Maybe they should pay local people fairer wages for the work to make it more appealing hmm?

<comment><USER20> I dunno. That might go against the narrative that literally everything is subject to market forces except for labor. The only thing for which we can arbitrarily set a magical, minimum value for some reason.

<comment><USER21> So your point is that indeed everything is subject to market forces and hence we cannot control the minimum wage. Or that market forces are not all encompassing and we should legislate the areas where they lead to unacceptable equilibria? I am confused...

</comment></comment></comment><comment><USER22> I'm confused why they're complaining to bloomberg & not bothering to put ads in some nearby towns/cities.

I imagine there's no shortage of low-skill workers available in the united states, shipping people in from afar seems outrageous.

<comment><USER23> I get the sentiment, but from TFA:

> including the costs of the newspaper ads they have to take out as part of > the process, plus (...), they've already spent thousands of dollars they > won't get back.

<comment><USER13> From the article, H1-B costs an estimated $2,500/person, plus flight and lodging. Let's pretend all 6 people Pentagoet wants to hire are staying in the mentioned apartment ($1,200/mo).

Assuming a 40 hour work week, they could increase the hourly wage by $4+/hr. and spend the same amount of money. That's a ~50% increase from minimum wage.

Now I feel for the business in this particular case. They had a process, they followed it, spend their money, and got staff. Now the process has changed, but they've already spent the money. It's a sunk cost. That _sucks_.

</comment></comment></comment><comment><USER24> Perhaps this reduction in visas and foreign workers will make voters realize how much of the economy they currently enjoy is buoyed by cheap, foreign labor. We aren't paying the real costs.

<comment><USER25> We are paying the real cost, just not in the price of goods. We spend it on public assistance, food stamps, medical care for these cheap laborers. A direct parallel would be the outrage over walmart employees being asked to go on supplementary services in order to survive. I'd rather know what this magical extra cost is so it can be compared to the other real hidden costs.

</comment></comment><comment><USER26> Looking at the broader scope of things, it seems to be that the idea of Americans filling low paying jobs directly competes with the relatively small pay these foreign workers are getting.

The question is, are these businesses being artificially propped up by foreign low paid workers, or is it a symptom of jobs paying too low for any American to actual work?

<comment><USER27> There's no such thing as a shortage; only a clearing price. If these businesses paid more they could get local workers.

</comment></comment><comment><USER28> Ever heard of summer student labor? These are lame tears.

<comment><USER29> Sounds like a project. Match students seeking jobs (and who have some experience) with employers similar to those in the OA.

UK: it tends to be waiting/bar staff in my local Universities as lower skill requirements and more flexible working times

</comment></comment><comment><USER30> > Maine, meanwhile, is set to be hit so hard by the shortage that Republican > Governor Paul LePage has conditionally commuted the sentences of a number of > prisoners so that they can fill some of the needed positions.

That's interesting - I wonder what the conditions are?

</comment><comment><USER31> > "I don't think that people who talk about defending American jobs with this > policy have ever looked into the economics of it," says Giovanni Peri, chair > of the economics department at the University of California at Davis.

Amen...and I find it doubly cool because my degree is from the economics department at UC Davis.</comment>


React v16.3.0: New lifecycles and context API - <AUTHOR> https://reactjs.org/blog/2018/03/29/react-v-16-3.html <comment><USER2> Summary:

* Context overhaul that makes it way easier to pass state/props down multiple levels of components. Uses function as a child for the API

* Adds React.createRef function to create refs. Creating refs through callbacks is still a thing for advanced cases, but this provides a more ergonomic API to replace the old clunky ref={(c) => this._yourthing = c} type callback.

* Adds React.forwardRef, which solves the issue of HOC not passing refs to the component they're wrapping.

* Lifecycle methods (componentWillMount, componentWillReceiveProps, and componentWillUpdate) are now considered legacy, and will be deprecated in future releases. To replace them, they added two new ones (getDerivedStateFromProps and getSnapshotBeforeUpdate). This is due to these lifecycle methods interfering with the goals of async rendering and other ambitious ideas.

* Adds a StrictMode component, which basically just causes React to log more errors during development about deprecated/legacy APIs and unexpected side effects.

<comment><USER3> Note: createRef doesn't _replace_ callback refs. It just offers a more ergonomic API for common use cases.

There are still rarer cases where callback refs are useful. For example when you need to run a side effect on a node as it attaches and detaches.

Also note: legacy lifecycles are not deprecated _yet_. You won't see the warnings unless you opt in with <StrictMode>. They will be officially deprecated in a future minor release when more libraries have had time to update.

<comment><USER4> Off topic but Dan - referring to your question to me yesterday I'm curious to your answer:

You asked "Curious, what do you use it for?" in regard to componentWillReceiveProps

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

I use componentWillReceiveProps for just about everything - I had thought it was a fundamental part of the Redux flow. i.e. Redux updates, new props flow through the hierarchy, I pick that up in componentWillReceiveProps and make changes based on new props.

Is this not correct?

<comment><AUTHOR> The purpose of componentWillReceiveProps was to update state in response to props changes. (This is also the purpose of getDerivedStateFromProps.)

What you're describing sounds more like you're updating something external (e.g. your Redux store). This isn't what the lifecycle is meant for, and you'd be better off using componentDidUpdate instead.

</comment></comment></comment></comment><comment><USER5> I like that they are taking the deprecation of the lifecycle methods slowly. And the automated script to migrate to the 'UNSAFE' version of those methods in 17 is a nice touch. I don't know if I love the new context API, but it's great they're giving an official option.

Of the big JS frameworks that are popular at the moment, I think the React team is doing the best job of balancing new features with minimizing developer pain and breaking changes.

If I had one thing negative to say about this release, it's that I think the forwardRef is maybe moving in the wrong direction a bit. In my experience, higher order components should be the exception, not the rule. They are a neat way to provide some functionality that is otherwise difficult, but their cognitive and maintenance overhead are high. If it stops at forwardRef, no big deal, but I am not sure HOCs are something that deserve explicit API support (and the additional surface area that entails)

<comment><USER6> "higher order components should be the exception, not the rule."

This just isn't true. Abstracting form logic. Request logic. Anything else you use across your app. Connect in redux. There are hundreds of good reasons to have a higher order component.

It makes testing easy. Test your request logic in one place, anything that uses it is now a stateless component, and testing it is trivial.

<comment><USER7> Render props can solve many of those problems without Higher order components.

</comment></comment></comment><comment><USER8> These lifecycle changes make me nervous. We're losing some important escape hatches to make way for async rendering which solves a problem that very few web apps have. To use an analogy, it's like "unsafe" features being deprecated in C to make way for the next major release which will be more like Java. My first impression of this is that it's the beginning of the end for React. People can still use old versions, but the reality is that they'll have to stick with old versions of related libraries and they'll have to shrinkwrap their node_modules because these drastic changes are being rolled out in minor version updates.

<comment><USER3> _> async rendering which solves a problem that very few web apps have._

From my experience of talking to React developers, data fetching is _the_ most common problem people bump into with React apps. Async rendering is key to making data fetching easy and natural in React, and to providing a great user experience whether the user is on a fast or a slow network. Please watch the second part of my talk for a demo if you're not convinced: [https://reactjs.org/blog/2018/03/01/sneak-peek-beyond- react-...](https://reactjs.org/blog/2018/03/01/sneak-peek-beyond- react-16.html)

 _> We're losing some important escape hatches_

We believe that the combination of new lifecycle hooks and the non-legacy old ones covers all use cases we are aware of (including escape hatches!). If we missed some use case you relied on, we are asking you to let us know: [https://reactjs.org/blog/2018/03/27/update-on-async- renderin...](https://reactjs.org/blog/2018/03/27/update-on-async- rendering.html#other-scenarios)

Escape hatches are core to React's philosophy. To reiterate a point from the blog post, we have more than 50,000 React components at Facebook, and they aren't going to rewrite themselves :-).

So we are committed to both supporting those lifecycles under `UNSAFE_` aliases (as mentioned in the blog post, they will continue working in React 17), and will provide async-safe hooks for use cases we might have missed (please report them!)

Thanks.

<comment><USER8> I watched the video and I'll keep an open mind.

I really hope you will hold off deprecation warnings until 17.0.0 instead of 16.x, even if that means you need one more major version than you had planned. Being on a team whose policy is to not shrinkwrap, so that we automatically get patches (not my policy, personally), at some point we're going to start seeing all these deprecation warnings without having explicitly version-bumped React.

My overall concern is that we're paying for the async renderer by moving to a higher level of abstraction for all class components. With Fiber, React is becoming a vastly different library. From the outside, having seen Fiber slated for release in 16.0.0 and, being pushed back to an unknown 16.x release, and then being pushed back to 17.0.0, it seems like you had not anticipated the extent to which the core React API had to be changed to enable the async renderer. It seemed simple enough in the beginning, but now we're looking forward to losing what React once was so we can use a DOM renderer that will be optional anyway.

<comment><AUTHOR> > From the outside, having seen Fiber slated for release in 16.0.0 and, being > pushed back to an unknown 16.x release, and then being pushed back to > 17.0.0, it seems like you had not anticipated the extent to which the core > React API had to be changed to enable the async renderer.

"fiber" was the code name for the rewrite that was released as version 16. Async rendering is a feature that we've been working on adding- (which the "fiber" rewrite was done to support). We've known that would take some time, mostly due to the fact that we want to gradually migrate old apps (as much as possible). :)

We're also working on other cool, related efforts- like a compiler ([https://twitter.com/trueadm/status/944908776896978946](https://twitter.com/trueadm/status/944908776896978946)) and proper built-in support for async-data, dubbed "suspense" ([https://reactjs.org/blog/2018/03/01/sneak-peek-beyond- react-...](https://reactjs.org/blog/2018/03/01/sneak-peek-beyond- react-16.html)).

<comment><USER9> > We're also working on other cool, related efforts- like a compiler > ([https://twitter.com/trueadm/status/944908776896978946](https://twitter.com/trueadm/status/944908776896978946))

That sounds like it could bring a lot of benefits. Would, and if so how, that affect people using TypeScript?

<comment><AUTHOR> I don't think we know enough about where compilation will end up to comment much. I wouldn't expect TypeScript to be negatively affected though (since it compiles to JavaScript). So far, the problems we're noticing are from certain coding patterns or practices within components. However we deal with these (whether we add new lifecycles or encourage alternate patterns, etc) it should hopefully apply equally to JS/Flow/TypeScript.

<comment><USER9> Obviously, but thanks for the tentative impact estimates :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Does anyone finds the new getDerivedStateFromProps adds too much boilerplate code for the developer to write and be aware? So for every previous prop that I need to compare with I need to remember to update it in the state? If before it was as simple as this.props.X!==nextProps.X now I need to set the state with the current prop!

<comment><USER3> This lifecycle exists for a fairly rare use case. Why do you use it often? Instead of keeping state "in sync" with the props, can you just read it from the props?

For the rare cases where you _do_ want to retain previous props, yes, we're asking you to be explicit about it. This will allow better memory usage in future versions of React, and also avoids the need for an extra `prevProps !== null` check that would need to happen in every `getDerivedStateFromProps` method.

<comment><USER11> Responding to "exists for a fairly rare use case" statement, I just searched the the web app I am currently writing and it uses componentWillReceiveProps() ~20 times. Most cases are for detecting changes requiring freeing/fetching network based resources where the data involved can get excessive if care is not taken. This would seem to be a common scenario for many domains. On a sidenote, I have thoroughly enjoyed working with react and RN over the last 4 years and have learned much from dan's work. Thanks guys.

<comment><USER3> _> I just searched the the web app I am currently writing and it uses componentWillReceiveProps() ~20 times._

How many components do you have? Absolute number doesn't tell me a lot. :-)

 _> Most cases are for detecting changes requiring freeing/fetching network based resources where the data involved can get excessive if care is not taken._

Not sure I fully understand. Could you provide a small example?

<comment><USER11> Component count is around 140. Fwiw, some are stateless, functional components while others are more complex.

A form of master/detail is driving the need to detect prop changes to fetch additional data while freeing previous data. Consider the master/detail of multiple levels deep driven by route parameters through the ui hierarchy. In RN, this is less of an issue since screens tend to be more focused and ui stack driven. But users working full-time in a complex ui specialized for power users can require much more data/dynamism.

<comment><USER3> Fair enough. As mentioned in Update on Async Rendering blog post, there's a less verbose data fetching API coming down the line ("suspense"). Not quite ready for the release yet. But it will require components to be async- compatible which is why we're getting these lifecycle changes out now.

<comment><USER11> Intriguing. Been too busy cranking on a new product to stay up on the latest changes so thanks for the pointer. I have lots of reading to do.

And thanks for listening about my use case. One concern about using a static function for getDerivedStateFromProps() is that it will not allow for taking instance variables into account. Have not thought through how that might come into play but components certainly allow for this, though many may feel it a strange idea. Perhaps a reference to the component could be passed as well as an additional argument.

I look forward to coming up for air and catching up with the improved approach. Things continue to move quickly and I continue to be impressed at how the changes bring improvement to the ecosystem.

<comment><USER3> Lack of instance is intentional—otherwise we would've made it an instance method. Happy to hear about specific patterns you're aiming for but since getDerivedStateFromProps executes during the "render phase" (interruptible in async mode) we want people to treat it as pure and discourage them from any side effects and mutations. If you really need some instance variable there then perhaps you could move it into state.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I was hoping they were going to simplify the lifecyles but it looks like they are adding more.

Since I switched to hyperdom[0] I haven't missed lifecycles at all. In fact my app has practically none of the "plumbing" code that my old react apps seemed to have.

Hyperdom is so much simpler but seems to be just as powerful.

[0] [http://github.com/featurist/hyperdom/](http://github.com/featurist/hyperdom/)

<comment><AUTHOR> Lifecycles aren't mandatory in React. Pure functional components don't use them. Stateful class components don't necessarily need them either (although they _can_ be useful, particularly when interfacing with imperative APIs like the DOM).

I've never used Hyperdom, so this isn't meant as a criticism or commentary on it.

</comment></comment><comment><USER13> In the unlikely scenario of Facebook's demise, how do you think the maintenance of React would transpire? Do you think some other tech company would snatch up the design leads, and pick up the torch? Would it go into its own independent organization?

<comment><USER4> There is no demise coming for Facebook.

They'll clean up, grandma, aunty and the school mothers will continue posting and they never even knew there was an issue.

People will soon forget.

<comment><USER14> > Will MySpace ever lose its monopoly? [2007]

[https://www.theguardian.com/technology/2007/feb/08/business....](https://www.theguardian.com/technology/2007/feb/08/business.comment)

<comment><USER15> People that keep comparing FB to Myspace simply don't understand scale.

Having 2 billion users is not a 1000x better than having 2 million ones. It's more like a million times. The network effect compounds non-linearly.

Facebook (the company) is here to stay. Even if the product is gone, they own 2 other multibillion dollar social networks: Instagram and WhatsApp.

</comment></comment></comment></comment><comment><USER16> I use and love React, but I'm also a little scared of it. I opened this little app I did 1 year ago in React 15, and it's completely incompatible with what I use now.

Every time I read of a new release I get this chill down my spine for a second.

<comment><AUTHOR> Our upgrade process is very gradual. As long as you've fixed all of the dev warnings for the last minor release of a given version, you should be able to upgrade to the next major without any problem.

<comment><USER16> The problem is when--like in my case--people develop a project for a client and then go on with their lives, until the client notices a bug, or wants to implement a new feature months after.

I tried to explain the client that I needed to upgrade the code before even being able to understand what the problem was, and I lost the client.

As much as they suck, PHP apps from 10 years ago are still working great, and so are jQuery-based apps from 5 years ago.

Would never go back to either one, though.

<comment><USER17> Why do you need to upgrade the code to fix a bug or implement a new feature? I don't understand that. Keep React version and do what client wants.

<comment><USER16> Things wouldn't even compile.

Don't forget that a React project might be made of many libraries--not just React itself--that might be worse at supporting legacy versions and guaranteeing mooth upgrades.

</comment></comment></comment></comment></comment><comment><USER18> I've been thinking about different situations in which Redux could be replaced with the new Context. Id sure appreciate having to write less boilerplate. The biggest concern I always get stuck on is where I'll put all my app's business logic, which I'm so used to putting in async redux-observable or redux-thunk actions. Does anyone have anything ideas on how to make an elegant business- logic-full Provider component?

<comment><USER19> I put up a post today called "Redux - Not Dead Yet!" [0], where I responded to recent comments claiming that the new context API will replace Redux. (Answer: maybe, if all you need is just passing down data to deeply nested components.)

As for the "boilerplate" topic: you are encouraged to use as little or as much abstraction on top of Redux as you want, whether it be small utility functions or entire other frameworks that wrap Redux. We've got a "Reducing Boilerplate" page in the docs [1], and I've got a section of my React/Redux links list for articles on that topic [2].

I'd be happy to suggest possible solutions for whatever problems you're concerned about.

[0] [http://blog.isquaredsoftware.com/2018/03/redux-not-dead- yet/](http://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/)

[1] [https://redux.js.org/recipes/reducing- boilerplate](https://redux.js.org/recipes/reducing-boilerplate)

[2] [https://github.com/markerikson/react-redux- links/blob/master...](https://github.com/markerikson/react-redux- links/blob/master/redux-techniques.md#reducing-boilerplate)

</comment></comment><comment><USER20> I have very mixed feelings about the new context api. On one hand, you're taking a foot-gun away, which I approve of having worked on code bases that abused it. On the other hand, it's very clunky, and I think people who abused the old context will just start making components larger, and wrapping them in a single context, rather than doing the right thing with many small components individually wrapped. Personally I think props inheritance, with IsolatedComponent as an escape hatch/boundary would have been much cleaner.

<comment><AUTHOR> Would you elaborate on what you find clunky about the new context API? :)

<comment><USER20> Well, I tend to make a lot of very small stateless components. If a component is 1-6 JSX tags, the new context API represents a boilerplate overhead of between 100 and ~17%. Additionally, the semantics of having a consumer's props.children be an immediately invoked function are a little bit unintuitive to me. I think having multiple ways to pass "props" increases the api surface area, having everything "just be props" would be simpler.

<comment><AUTHOR> > Well, I tend to make a lot of very small stateless components. If a > component is 1-6 JSX tags, the new context API represents a boilerplate > overhead of between 100 and ~17%.

Not if you use a HOC (e.g. `withContext(Component)`) like a couple of the docs examples showed.

> Additionally, the semantics of having a consumer's props.children be an > immediately invoked function are a little bit unintuitive to me.

That's fair! I would encourage you to give it a chance though. I think it's a pattern that really grows on you after a short time. :)

</comment></comment></comment></comment><comment><USER21> Can someone point me to reasonably simple but not contrived examples that put createContext and forwardRef to good use? As I look at this from a Mithril perspective the value isn't obvious.

<comment><USER22> Context is a way to pass state down the component tree without it having to go through intermediate nodes.

Say context doesn't exist, and you have a branch of components A -> B -> C, if C depends on some state in A, B would have to have a dependency on that state too. And you'd need some boilerplate code in B that reads the props from A, and passes them to C.

If you want to use C in a different context, say A -> D -> C, then that boilerplate code needs to exist in D as well.

With larger apps, containing large component trees, the amount of this boilerplate prop-passing you need to do starts to get excessive. It's not uncommon to see components read 14 props from their parent, use one of them, and pass 13 to their child(ren).

Until now, this problem has been solved by using data stores that inject state anywhere in the tree that they please. Context is an alternative to that.

It's always existed, just now it has a new API. I have no idea what was wrong with the old one. Nobody seems to have properly explained it anywhere, the docs just make condescending suggestions not to use it without reasoning. I think I saw an arcane tweet once explaining that certain things may not have re-rendered properly when using the old API or something...

<comment><USER21> Thanks, that seems like a good explanation.

I still think I'll need examples to be convinced of the usefulness, though. I don't see why a large component tree would have 14 disparate props passed down individually. If the tree is supposed to be a reusable component, why not define a single object to pass down?

Edit: Having read the docs I now see that my current perspective on it is the one they want me to have. "Don't use context just to avoid passing props a few levels down. Stick to cases where the same data needs to accessed in many components at multiple levels." So it's better for me to avoid it until I see it's definitely needed.

<comment><AUTHOR> I'm curious why the theme example I mentioned in my earlier comment- (and showed in the docs)- doesn't qualify as "useful" to you. Another example would be using context to share the selected language/locale between all of the localized components in an application.

<comment><USER21> In self-contained apps couldn't a single prop be passed down that's an object with all things like that in it? Maybe there's a scenario with 3rd-party components where context could make it look more elegant, but I don't have a clear picture.

I know there are several ways to construct a component, but I like that your examples make them functions of props, because that's how I picture a component. Having its behavior depend on a semi-hidden context appears less purely functional. To stretch the term a little, the component is no longer idempotent. Maybe there's a situation where that's what you want, but the examples you've given so far sound like ones where props would serve just fine.

<comment><AUTHOR> Yes, but then that prop would need to be passed down explicitly through every component. This would require a _lot_ of boilerplate.

<comment><USER21> OK, it just boils down to me thinking one explicit prop for every component isn't too much boilerplate. I can see some teams liking the idea of shaving off that explicit prop as long as everybody knows about the implicit context(s) that also affect component behavior.

<comment><AUTHOR> > s everybody knows about the implicit context(s) that also affect component > behavior.

Just in case there's any misunderstanding- (I don't think there is, but just being safe)- context isn't implicit. You have to opt into it either by using the `<Consumer>` component or a HOC that injects a context prop.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> Lot of niceties in this one. Painful to keep up at times but at least the React team makes it worthwhile for those who do so. Kudos.

</comment><comment><USER4> Any example anywhere of using context for current authenticated user?

<comment><AUTHOR> No, but you could do it in a similar way as the "Dynamic Context" example [1] - store the authenticated user/status in component `state` and pass it down via a AuthenticationContext.Provider. Then anything that needs to know about it could use the AuthenticationContext.Consumer.

1: [https://reactjs.org/docs/context.html#dynamic- context](https://reactjs.org/docs/context.html#dynamic-context)

</comment></comment><comment><USER24> disclaimer: I don't like react. Outside of dom node diffing and a focus on components I don't think it brings much to the table considering the considerable complexity it brings.

It seems like react gets re-written and APIs undergoes drastic changes every few months. I'm not complaining about churn (I don't write react), but rather that maybe React isn't the right tool to be hyping up, or pointing newcomers to JS at to look into/use.

I don't remember any other supposedly simple library having had this many major rewrites/api changes. I don't think I've ever seen something like this in KnockoutJS or even Angular1 for a long time (even though the way you had to handle $scope and apply/digest cycles was terrible). Relative newcomers like Mithril and Vue seem to get this stuff right without requiring as much breaking changes. Maybe they owe their simplified structures to some of the new thought to what React inspired, but it seems like they're actually simple (Vue's documentation is amazing, concise, and you can actually render Vue in the browser to get started quickly).

Maybe it's time to rethink whether React is a good tool. There's no way I would recommend React to anyone (beginner or intermediate) over something like Vue these days.

For example, I don't know what HOC (and am thoroughly uninterested, it sounds like the same kind of thing you only need to know when you're chest-deep in React land) is but it sounds like a hack necessary because of a bad design decision.

[EDIT] - Took a few seconds to look up HOCs (Higher Order Components) and they're a bad example of what I think is incidental complexity inside React but I think my point still stands. To clarify, here's my thesis:

React is complex (both internally, evidenced by multiple rewrites, and with the tooling it forces you to use, evidenced by needing to download a zip file to start, or touch webpack), but masquerades as a simple library.

<comment><USER3> We maintain more than 50,000 components at Facebook, and I don't believe your assessment that "APIs undergoes drastic changes every few months" is accurate. The component API has barely changed since the initial release five years ago.

When we need to make changes, it's the team of 8 people that need to port all those dozens of thousands of components to new APIs. It would be infeasible for us to break APIs every few months, or to do so in a manual way. This is why we embrace automatic codemod scripts.

There have been some breaking changes between major releases (which have a roughly yearly—not monthly—cadence) but we always provided automatic scripts that convert your code as much of your code as possible automatically: [https://github.com/reactjs/react-codemod](https://github.com/reactjs/react- codemod).

We also call attention to the automated migration scripts in all major release blog posts (for example: [https://reactjs.org/blog/2017/09/26/react-v16.0.html#upgradi...](https://reactjs.org/blog/2017/09/26/react-v16.0.html#upgrading)).

That's the only way we could maintain dozens of thousands of components while still moving the library forward.

I hope this information is helpful. You can read more about our commitment to stability without stagnation here: [https://reactjs.org/docs/design- principles.html#stability](https://reactjs.org/docs/design- principles.html#stability)

<comment><USER24> I apologize -- I should have written "API internals". I did not mean to state that the component API changed a lot, just seemingly that the internals did, with fiber and the like.

I understand the team is hard at work making React better, and there is absolutely no doubt that you are succeeding and react is getting better. However, the amount of large internal changes indicates that as you improve and (most likely) shed unneeded complexity, that there must have been complexity to shed. Obviously no one is perfect, and hindsight is 20/20, but for such a "small" (yes, interacting with the dom is actually super duper hard, and edgecases abound) scope, I've seen more large-ish overhauls than I am comfortable with.

Many internal changes makes me feel like react is more Mongo than RethinkDB (the latter being a document store that actually got most things right and was well engineered but no one ever heard of while mongo started with a badly engineered product, good marketing, and pivoted to relative reliability and good engineering).

I want to also note that I'm not in the target audience for a post like this. There are tons of people who lovingly and productively use React -- I'm not one of them. I am just dumbfounded when people bill react as simple but have never heard of something like Mithril that actually _is_ simple (almost "stupidly" so), and another post at the top of HN means there's that many more people I have to convince to pick something at least slightly simpler when they start doing web development for the first time.

<comment><AUTHOR> > However, the amount of large internal changes indicates that as you improve > and (most likely) shed unneeded complexity, that there must have been > complexity to shed.

The v16 rewrite (dubbed "fiber") wasn't just about cleaning up internals- it was about supporting a fundamentally different type of behavior- asynchronous rendering [1]

> Obviously no one is perfect, and hindsight is 20/20, but for such a "small" > (yes, interacting with the dom is actually super duper hard, and edgecases > abound) scope, I've seen more large-ish overhauls than I am comfortable > with.

To be fair, React supports many more targets than just the DOM. In addition to the DOM- there's react-native, react-art, react-music, react-hardware, etc.

Don't mean to sound argumentative, just wanted to add some info in case there were potential misconceptions. :)

1: [https://reactjs.org/blog/2018/03/01/sneak-peek-beyond- react-...](https://reactjs.org/blog/2018/03/01/sneak-peek-beyond- react-16.html)

<comment><USER24> This is a huge point that I do often miss when I think about react when used for react development...

You're absolutely not being argumentative -- while I still don't think react is the simplest thing to start with, the explanations that have been given so far seem very very reasonable, feel like an asshole for essentially ranting

</comment></comment></comment></comment></comment><comment><USER25> React API reminds of Microsoft COM for JavaScript. It was called Component Object Model. It was hell to deal with when lasted.

<comment><USER24> The downvotes are unfortunate, since this is a reasonable sentiment, here's an article I read a while ago that presented this point in a more nuanced fashion:

[https://bitquabit.com/post/the-more-things- change/](https://bitquabit.com/post/the-more-things-change/)

<comment><USER19> COM and a Win32 WndProc function aren't very similar :)

(And yes, that's a very good post.)

<comment><USER24> Ahh I thought they were the same -- admittedly I've never worked deeply with windows program (and do not plan to at any point in time), so I couldn't tell the difference</comment></comment></comment></comment>


Jobric: A smart job search engine that uses artificial intelligence - <AUTHOR> http://jobric.com/?ref=ijm_hn

<comment><AUTHOR> This is a little something I've been working on which will be launched to the public in the coming months. Request an invite to get earlier access.</comment>


Neu.de, Hier fängt es an - <AUTHOR> http://www.neu.de/scheduler.php?url=/members/index.php?aref=66788378&origin=5 <comment><USER2> Top-level for the site is a German singles site. Didn't follow the URL; looks like it contains tracking information.</comment>