Most of the conversations I have with folks about Scala issues these days center around implicits, tooling, and its decline/lack of popularity.

Macros were an experimental Scala 2 feature, but were used all over the Scala ecosystem. Because they were considered experimental a good migration story for them was never developed. That lack of support stopped migration efforts dead in their tracks at our company for a long while. It just wasn't worth contributing simultaneous support for Scala 3 and Scala 2 macros to every third party dependency who used Scala 2 macros. That said, we did it for some and lived on a fork for others.

IDE support for Scala 3 was really rough when it first released. We checked in on it with every IntelliJ release for roughly 3 years before we decided it was far enough along. Prior to that it was rough enough that we froze migration efforts in order to keep the tooling usable enough for engineers to be productive.

After skimming the rest of the table, it looks like the PurpleAir II sensors might have some of the best field R^2 for PM 2.5 and PM 1.0

Not sure how it compares with Awair or laseregg.

I have no affiliation with PurpleAir, but they are pretty popular in Utah.

If I recall correctly, people on Twitch streamed games from the Dota Majors/Minors and got more viewers than the Facebook stream. Then ESL started DMCA'ing streams https://www.reddit.com/r/DotA2/comments/7skt8e/did_mlpdota_j... Then Valve got involved and made a statement about the whole kerfuffle http://blog.dota2.com/2018/01/dotatv-streaming/

Money seems like a good reason. If a tiny fraction of your sales and a large fraction of your bugs are from a particular subset of those users, you don't want those users. They are too expensive.

I've run into nausea with other games that have a narrow FOV. Increasing the FOV (when possible) usually fixes the problem.

As far as I understand, the late Total Biscuit was similar. He frequently advocated for FOV sliders in games. I greatly appreciate his help making FOV sliders more popular.

These 'junior engineer' tasks are attractive for a manager who still wants to be in the code. They are non-critical and small. Perfect for someone with an unpredictable schedule. However, they also provide an opportunity for the manager to have a better, but still imperfect sense of the codebase and technology.

I am curious if AWS has any plans to build an IAM integration for K8s that provides IAM credentials/roles directly to pods. An integration through EKS or K8s directly would make interacting with AWS resources very easy.

Being able to authenticate to the K8s cluster using https://github.com/kubernetes-sigs/aws-iam-authenticator is nice, but it doesn't help give pods IAM roles.

We used it at Lucid when we converted our codebase from Closure annotated JavaScript to TypeScript. https://www.lucidchart.com/techblog/2017/11/16/converting-60...

Google has support for using TypeScript in Closure annotated JavaScript via Clutz: https://github.com/angular/tsickle

It also has support converting TypeScript to Closure annotated JavaScript via tsickle: https://github.com/angular/clutz

Before we converted all of our codebase to TypeScript we used both Clutz and tsickle. It was complicated to setup, but it worked. Now we just use tsickle. It's great to get the optimization of the Closure Compiler while using TypeScript.

It's not perfect, but we have found the types to be very nice when working on a large code base with lots of people. Dev development cycle remains quite fast.