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.
I believe it's not as much moonbit's limitation as wasm-gc limitation – shared gc structs will have to be supported at low level in wasm-gc first and I don't think there are any concrete proposals for it yet?
They support native target (as well as js target) but wasm one was always the primary one.
Having said that they have (cooperative) async for native target only currently.
Personally I'm looking forward for them to self host it – not sure why they're still holding to ocaml compiler, the language seems sufficient to have moonbit written in moonbit. Together with it I'm waiting for proper open source – currently what the team is doing is a bit like what Meta sometimes does – internal development, no community development, they just dump updates as snapshots from time to time instead of normal, fully open development.
I'm also clinging on my last intel purchase (macbook pro) and unfortunatelly they don't provide intel builds for macOS just arm ones (even though they do for linux), which is a bit of a pain – but I think I'll just buy arm macbook before they'll support intel on macOS (and maybe they'll never do, which is fair). It's a small thing from moonbit perspective, but annoying and limiting a bit for me personally to work remotely only with it.
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.
> 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.
Same story for us - about 3 years before Intellij was usable, even then not up to what it had been on Scala 2. We still only have 2 Scala 3 repos, out of about 30, for my team, and we're actually MORE adventurous than most other teams at the company!
Well, IJ experience for Scala 3 is still noticeably worse than for Scala 2. We're still cross-compiling our work projects, waiting until Scala 3 support in Intellij is good enough to switch.
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
That sensor is also available from Adafruit: https://www.adafruit.com/product/3686
I got it hooked up to a RaspberryPi that exposes sensor readings in Prometheus format.
Do you have a PurpleAir II to compare against? I suspect that there will be some extra calibration or signal processing some to make it more accurate that will be missing in the raw sensor.
EDIT: The link we're discussing says this explicitly: "[...] These particle counts are processed by the sensor using a complex algorithm to calculate the PM1.0, PM2.5 & PM10 mass in ug/m3. [...] PurpleAir PA-II uses two identical PMS5003 sensor units attached to each other and placed in the same shelter. [...]"
I don't think you can recommend the PMS5003 as a substitute for the PurpleAir II.
That sensor available at Adafruit uses the same algorithm for calculating PM levels, it's literally the same chip. Maybe using 2 of them yields more accurate results though.
The Adafruit sensor is just the sensor, the PurpleAir II is two sensors plus extra logic that processes the readings to give extra accuracy.
You can't expect one sensor to give the same performance as two sensors plus correction logic. If it was that easy, PurpleAir could just put a case on a PMS sensor and be done with it.
reply