mayank

> The big difference now is the convergence of code written for both server and client, and compilers which help strip down and optimize what happens in the client.

I understand the spirit of your comment, but this was/is also true of Google Web Toolkit (GWT).

> I can detect a cyclic reference before I even finish writing the code, what's the point of letting the compiler figure it out?

The compiler generally has better attention to detail and the ability to deal with larger object graphs than the typical human.

Yes, but modern DI (like Dagger for Java) can detect cyclic dependencies at compile time and break the build.

> Aurora on spot

How would that work for a database? And have you considered or tried Aurora Serverless?

I don't think this is cynical, it's a restatement of the "nobody gets fired for buying IBM" adage. Choosing PlanetScale at this stage in its market penetration is almost certainly going to be seen as the riskier business choice over RDS Aurora (even though it's not quite apples:apples) or GCP Spanner (which is). You can choose to spend your innovation token there, but you better be prepared for the downside when PlanetScale goes down and everything else is up.

An interesting aspect that I've seen missing from discussions on this is the dark growth pattern at play here.

All across the world, there are millions of languishing enterprise/educational fleets (generally Windows) administered by a single or a few "IT folks". In my experience, these people are often the only technologically aware people in the organization. This is Norton cutting them in on the grift. Install acclaimed "Norton Antivirus", which is likely already a line item on procurements, mine crypto on the sly for yourself on idle fleets at night, and give Norton a slice of the pie while you're at it.

Nobody's likely going to look twice at Norton running on a machine, we've already collectively conditioned ourselves to think of antivirus software as "slowing the machine down", and as a bonus: unless the next person in is as up to speed as your are, your grift can keep running long after you've moved on.

> There's overhead to connecting to a different cluster server each time you access a seperate shard.

While I agree with your point, this concern is easily addressed with connection pools.

> This judgment could have had devastating consequences and turned software development into a copyright nightmare.

It’d sure have made the practice of taking someone else’s API and re-implementing the innards a lot more interesting:

https://docs.oracle.com/en-us/iaas/Content/Object/Tasks/s3co...

> I'm curious on why you call these languages "romance" languages.

That's what they're called: https://en.wikipedia.org/wiki/Romance_languages

Git has large file storage now: https://git-lfs.github.com/

Any thoughts around the viability of open-core/self-hosted monitoring, when that also entails bringing the burden of scaling/monitoring your monitoring solutions in-house?

Do you feel that the market of people who need DataDog or Splunk or Lightstep for their scale but can't afford it is large enough to sustain this model? Or is this targeted at smaller shops where cost overrides other concerns?

I don't think the 3 products are serving as diverse a set of use cases as you think...

> The former is a better fit for your entire app stack (think Heroku) while the latter is for ad-hoc.

There's no product reason why App Engine couldn't start deploying custom containers.

> As for Cloud Functions and Cloud Run, the way you deploy is completely different. Cloud Run is strictly meant for containers.

AWS Lambda (arguably the "inspiration" for Cloud Functions) just announced support for custom containers. Cloud Functions could too. And then you essentially have Cloud Run.

> The endgame is that all energy companies will primarily be Bitcoin mining companies, feeding their excess renewable energy into the grid to power homes, etc.

Or you could just skip the Bitcoin part...

The Bose SoundTouch speakers have an HTTP API that you can hit. HomeAssistant picks them up and can route audio to them out of the box. Not exactly the polished solution you're looking for, but it's a start:

https://bosedevs.bose.com/categories/soundtouch-api

> Does OpenAPI generate code for you?

An OpenAPI spec is the equivalent of your .proto files. You need codegen to go from your .proto files to native classes, and you need codegen to go from your OpenAPI spec to native.

> Protobuf and Cap'n Proto feature dedicated schema languages that feel like a programming language. It looks like OpenAPI has you writing schemas themselves in JSON or YAML. Ick.

Counterpoint: I can take an OpenAPI spec and parse/process/render/codegen it in every single language without a custom parser library.

> that’s literally the table stakes of our profession

Table stakes for what exactly?

> aurora postgres lags behind mysql when it comes to features

And performance, on some workloads we tested. I would benchmark write performance very carefully before using Aurora Postgres (Aurora MySQL does not seem to suffer from the same issue on the same workload).

> Failovers are surprisingly slow, too.

The recommendation now is to use RDS Proxy for faster failovers.

Did all three (phd -> google -> startup). Couple of misnomers you might want to clear up:

* depending on your area, a PhD may not touch much "technology", if any at all. There will be a lot of writing, a lot of reading, a lot of math, and a lot of hard conference/journal rejections that you put 6+ months into apiece. And that's if you can land a fully funded position. You will have to teach, and skimp on niceties and luxuries, and "just barely get by" on a stipend. If you're not deeply motivated by the learning and willing to endure a monk-like existence, do not take this path.

* if you have a Google offer, especially as an intern conversion, TAKE IT. You will have access to the true cutting edge in technology (certainly way more than 99.9% of academic labs). You will learn rigor, elegance in code, how to critique and take criticism, and how to build truly scalable systems. It is very much like an "industry PhD"...it will change the way you think.

* you will still be "young" after a few years at Google, but you will be immensely more technically mature. If you do a startup now and burn out in 2-3 years, that Google interview will be immensely more daunting, and you might not be able to swing it. You'll also have a couple of years of RSUs saved up to tide you through the rough startup moments.

TL;DR--Google.

TIL it's "Dan G" and not the Chinese surname "Dang" that I'd always assumed.

> Metrics and tracing are actually just special cases of any normal log stream.

Theoretically perhaps, but for high-volume metrics (think counters in a tight loop), you really want some form or pre-aggregation in memory before flushing out to disk or network.

If you look at the Prometheus model for example, there's no flushing to disk or network at all, but rather a Prometheus server scraping from hosts on demand.

A very slightly less obnoxious popup also shows up on Uber Eats orders placed by end consumers before you can place a food delivery order.

> Remember Google was the promoter of the open-space office configuration

Are you thinking of Facebook perhaps? Google used to favor the 4-to-a-cube/office configuration.

Search is still up and snappy! I may be biased as an ex-search Xoogler, but Search's resilience is a testament to how battle-hardened a stack it is, considering GDocs and Gmail appear to be hard down.

> We’re taking a new approach by loading the site-under-test inside of a VM in the cloud rather than rely on a locally installed browser extension.

So while you do get the benefit of clean, repeatable tests, this requirement also puts you out of reach for most enterprise-y applications, where your pre-production environments (i.e., what you actually want to run your tests against) exist in a tightly locked down network environment that you can't reach from the outside. In stricter environments, even a reverse port forwarding setup to allow you to reach inside the LAN would be out of the question.

I think this is a problem you're going to run into pretty soon if you want to do enterprise sales, and one that is not trivial to solve without an open-source flavor of the test runner (e.g. like Selenium).

The new Composition API for components is a simpler, more imperative, low-level way of defining components compared to the older Options API that required exporting an object with fields like 'data', 'computed', or 'watch'.

I personally prefer the older API since its more declarative, but I can see how the new API can help to keep reactivity logic in a single function, rather than across computed properties, watchers, etc. (not to mention the annoyance of having to remember what type each property should export -- function returning object? raw object? object with function fields?).

The conclusion is just a restatement of the No Free Lunch theorem in optimization.

[1] https://en.m.wikipedia.org/wiki/No_free_lunch_theorem

This is a really good idea, and a fitting analogy. NPM already supports private registries, so it would be a simple configuration change to point to "main". On top of that, there is a lot of good work in the node community around static analysis, CVE detection in transitive dependencies, and more finely grained security perimeters, which could be used to detect possible backdoors or malicious code.

> If they have a number or publications as you say, they may be eligible to apply for O-1 visa.

This is only if you have a research-based job. If you graduate with a PhD and get a job on the software engineering ladder, you're SOL.

Yes, my bad. I meant arrow functions.

Unfortunately, the language has changed so much in recent years that I wouldn’t necessarily recommend that book anymore. A large number of fundamental features have been introduced since 2008, including async/await, lambda functions, class and extends syntax, proxies, and a ton of builtin methods like map() and forEach() on native list types.