Did MoonBit add support for some kind of shared memory concurrency like threads? I remember discovering the language, being very excited about it, and then learning it is single-threaded, which makes it a poor replacement for Rust IMHO.
Agreed. There was a period of time roughly 10-15 years ago where symbolic operators in Scala were very en vogue. That fell out of style in a big way and I haven't encountered symbol soup in a very long time.
Most of the conversations I have with folks about Scala issues these days center around implicits, tooling, and its decline/lack of popularity.
Not confident it's quite that straightforward. Here's a presentation from Meta showing a 6-12% increase in diff throughput for above-median users of agentic coding: https://www.youtube.com/watch?v=1OzxYK2-qsI
From my perspective the two biggest challenges of the Scala 3 migration were macros and poor tooling support.
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.
Compiler error messages improved significantly with Scala 3. IIRC there was a dedicated effort with Scala 3 to improve error messages and make them more actionable. Scala 2 error messages improved somewhat over time, but can still be obtuse.
Based on my reading of the table, the PurpleAir II sensors seemed to be the best of the sub $300 for PM1.0 (field R^2 of 0.96 to 0.98) and PM2.5 (field R^2 of 0.93 to 0.97). The PM10 readings were not as good (field R^2 of 0.66 to 0.70).
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
>I don't understand why they wouldn't do it, though. I see no plausible explanation.
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.
Several years ago, I ran into the exact same nausea with the Source engine as the GP, but when I increased the FOV the problem went away.
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.
I imagine there are climates that are better for grass or certain species of grass that are very drought tolerant. However, in my experience, not watering a lawn will kill it. I have a few patches in my lawn that were killed this summer by lack of water due to a poorly designed sprinkler system.
If you only have 20% of your time available to write code, then I would much rather you do not review code in which the person who wrote it had 90% or more of their time to write code. The review will be less thorough, correct, and timely than if someone else who regularly spends more time in the code.
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 understand that both kube2iam and kiam exist and they're both fine. I am interested in Amazon/EKS directly supporting something. Hopefully we will see something soon via CRD or otherwise.
>we need to set up a way to manage AWS IAM credentials to Kubernetes pods... In a production system, this should be done using a tool such as kube2iam or kiam...
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.
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.
Lucidchart and Lucidpress are large projects that are almost entirely TypeScript on the frontend. The team really likes it. We use TypeScript and Angular that is compiled using Tsickle and the Google Closure Compiler.
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.