zenbowman

"Preserving privacy and anonymity online" is not an inherent good. It depends on how it is being used and what the consequences on society are.

Thus far, privacy and anonymity have been used to get children addicted to garbage, distribute CSAM, create elaborate schemes of financial fraud (cryptocurrency), and develop drug distribution networks.

It's completely reasonable to limit privacy in order to combat these social evils.

Exactly right. Also, better to be overly restrictive here given the well documented harms of social media on young minds. If the law stipulates that you must be 15 to obtain social media access, and most people don't get their IDs until 18, then most people will stay off social media for another three years: no big deal.

100% correct. At this point the harms to children from social media use are very well documented.

Like everything else in society, there are tradeoffs here, I'm much more concerned with the damage done to children's developing brains than I am to violations of data privacy, so I'm okay with age verification, however draconian it may be.

100%. I do this all the time, this will be very useful internally.

This was the norm about a decade ago. When I was at Hulu, we built our own analytics platform on top of Hadoop, we almost certainly wouldn't have done that today with the amount of off-the-shelf stuff available.

Even things like protobuf or Avro weren't as broadly adopted (>80%) at the time, many many companies at the time persisted stuff using JSON or other text formats (which in retrospect was very dumb, but it was very normal for a while).

Beyond that, someone as emotionally brittle and allergic to criticism as he is will inevitably create a yes-men culture, which will destroy engineering discipline & lead to declining quality. No way around it.

The one thing you absolutely need to preserve engineering quality is the ability to take criticism.

I would argue that it made sense for performance-sensitive code until the maturation of Rust, so it made sense even in 2015. But not today.

I understand wanting to defend your baby, and I think C++ was VASTLY better than most other languages for performance sensitive code until maybe 5 years ago - but the combination of memory safety and thread safety that Rust offers means that there are very few situations where C++ is the appropriate choice for a new project now.

I have written professionally in C++ for 20 years now, and I would pick Rust for a _new_ project/fresh codebase in a heartbeat. tokio alone is so vastly superior to anything you can do in async C++ that it makes zero sense to select C++ for a _new_ project (obviously if you have an existing codebase the price of interop may not be worth it).

Bjarne is being deliberately obtuse here.

This is a great writeup, I work on batch/streaming stuff at Google and I'm very excited by some of the stuff I see in the Rust ecosystem, Arroyo included.

I wouldn't say "infinite", its still susceptible to read hotspotting; and while fine-grained locking enables generally higher write throughputs, you can still get in a situation where interconnected updates end up being pretty slow.

That said, its way better than anything else I've used in my career.

Exactly. I used Unity starting from almost the first release, and attended Unite in 2007.

Unity was seen as a hobby engine then, we used it for the web, but for desktop used Unreal. Godot today is way ahead of where Unity was in 2007ish.

Same. Slowing down traffic is an inherent good, whether or not you have any intention of crossing.

Because I tend to write all my code such that a complete stranger should be able to drop in and understand it

This isn't an achievable goal for most complex systems. Even very well written and documented code bases (for e.g. tcmalloc, bigtable) require a good deal of background reading to develop a baseline understanding of what is going on.

Things like large functions or code duplication are not necessarily bad in the first place. A far bigger problem that I encounter regularly is the invention of extreme layers of abstraction to avoid a small amount of copy-pasting + edit in the name of DRY.

But an even bigger problem is lack of understanding of the problem domain and a lack of documentation on how you plan to fix the problem.

Shipping around individual video frames between components is really an astonishingly bad idea.

Microservices seem to be a decent idea with a terrible name. The idea of running services that are small enough that they can be managed by a single team makes sense - it enables each team to deploy their own stuff.

But if you break things down further, where you need multiple "services" to perform a single task, and you have a single team managing multiple services - all you do is increase operational & computational overhead.

Very well said.

A clean data model, one aligned with business needs, and sensitive to the nature of machines, makes the best architecture.

Far too many decisions are based on what is trendy and fashionable rather than what is right for the domain.

For someone coming from India, you aren't necessarily forgoing thousands of dollars of income. My PhD years were quite relaxed, you can live frugally, you get a stipend, you work on interesting projects, and at the end of the day you have an option to live in a country with far more opportunity than the one you came from.

That is precisely why a lot of us pursue STEM degrees - it is easier to immigrate with a STEM degree, and the job market is favorable.

How is that an anti-immigrant statement?

If anything, it indicates that many immigrants are deeply pragmatic, which is a compliment.

If all your RPCs take a single parameter, this isn't a problem provided you use universal defaults.

One correction: Futures are not necessarily run on a separate thread pool. If that were always true, they would offer no performance advantage over the thread-per-function or thread-per-request model, and would burden us with more complex code.

The advantage of futures comes when they are used in conjunction with AIO, they provide a decent abstraction for dealing with it. The performance benefits come from using AIO, Futures just provide a convenient way to deal with the results.

If Play was built on Tomcat instead of Netty, and you made various blocking calls inside the functions called by the Futures, you wouldn't get any performance benefits.

It isn't just fitness that helps, but movement.

Movement and sunlight are fundamental nutrients for the human body.

Well written and understandable. The use of illustrations was particularly good.

For the most part, this is correct.

It would take an exceptional company with a grand vision for me to swap 2 & 3. I could see myself doing that if I worked for Seymour Cray's companies in the 60s and 70s, or Bell Labs in its heyday, or a company with a grand vision like SpaceX today. But for the most part, you are right.

Academia is far more cutthroat and stressful than programming. It is not even close.

Coming to industry after being in academia was like being on permanent vacation.

One thing I would recommend: Try a programming job outside the Valley, preferably somewhere where tangible goods are produced. It doesn't have to be outside the technology industry, technology companies are not limited to Internet startups. Big oil, the automotive industry, defense and aerospace, these are all industries whose primary business is the development of technology.

And even "non-technical" companies like Walmart have demonstrated a lot more technical prowess than the average trendy startup, and my guess is that the hours are very reasonable.

Having gone to college is not evidence that your opinion is any more important than anyone else's.

What matters is: what does the data say about GMO safety? Are your views informed by the consensus of scientific studies?

If not, then the position is still scientifically illiterate, even if the individual has a Masters degree.

Resisting vaccinations is also quite common among educated, affluent people.

http://www.chicagomag.com/city-life/March-2014/Why-Is-Vaccin...

The issue is precisely that we have an "educated" public (based on credentials) that is also scientifically illiterate.

I know what they do, not what you do.

If you know something I don't, then I have no way of using it to form an opinion until you tell me about it.

If that were true, I'd be proud to work there. Food innovation is of critical importance for mankind, in the same realm as space exploration or improved information accessibility.

Certainly a lot more important selling ads, or providing an internet-based service to pick up your laundry.

But it isn't true. Maybe someday.

It's a hot topic, yes, but an important one. We are in an age where policy is decided by a scientifically illiterate public, with potentially devastating consequences for people outside the developed world. That needs to be confronted head on, not shied away from.

http://www.usatoday.com/story/opinion/2015/05/18/pew-vaccine...

Not being willing to talk about these issues is what allows fearmongers to win the day.

Of course there are other aspects to agricultural science and technology. However, there is nothing in this company that indicates they are advancing technology in any sense.

This is not to say they are not providing a worthwhile service. Even my local farmer's market provides a worthwhile service to me, but I don't call it a "tech market" just because some of the vendors have an online presence.

Organic food is fine. But it is, fundamentally, an anti-technology approach to growing food. You should be free to eat it if you want.

The point is simply that firms that reject technology should not be described as "tech" companies simply because they use the Internet in some way.

I'm not suggesting in any way that companies should not exist if they don't solve planet-scale problems.