Obviously there is a lot of work here, but I am a bit confused. If you already have lab code in Julia, Matlab, R, Python, Excel, etc., what is the motivation to use this tool? Is this hot in a specific community?
Readit Newsjtrueb commented on LabPlot: Free, open source and cross-platform Data Visualization and Analysis labplot.org/... · Posted by u/turrini
jtrueb commented on Real-time CO2 monitoring without batteries or external power news.kaist.ac.kr/newsen/h... · Posted by u/gnabgib
That's in the normal range of accuracy of modern CO2 sensors, for example SCD40 from Sensirion is described with an accuracy of ±50.0 ppm ±5.0 %m.v.
That’s if the voltage supply was stable and within electrical specs for a sufficient period of time. We can see this is a snippet 2 hours into the discontinous collection.
3.6V is the maximum value that the nrf52832 SoC can handle. I would suspect the VDD is variable.
A true champion
> when I started contributing to Rust back in 2021, my primary interest was compiler performance. So I started doing some optimization work. Then I noticed that the compiler benchmark suite could use some maintenance, so I started working on that. Then I noticed that we don’t compile the compiler itself with as many optimizations as we could, so I started working on adding support for LTO/PGO/BOLT, which further led to improving our CI infrastructure. Then I noticed that we wait quite a long time for our CI workflows, and started optimizing them. Then I started running the Rust Annual Survey, then our GSoC program, then improving our bots, then…
jtrueb commented on Rust Any part 3: we have upcasts lucumr.pocoo.org/2025/3/2... · Posted by u/jmillikin
"sometimes" is doing a lot of work there.
Sometimes it is, but also sometimes it isn't, and Rust at least gives you a choice (you can use Arc all over the place, or if performance is critical you can be more careful about specifying lifetimes)
Arc doesn’t give you the choice until this upcasting feature lands in stable.
jtrueb commented on Rust Any part 3: we have upcasts lucumr.pocoo.org/2025/3/2... · Posted by u/jmillikin
Just having features associated with OOP isn't a bad thing. Object upcasting has its uses.
It's some of the other stuff that gets OOP its bad rap.
Garbage collection, common in many OOP languages, enables having arbitrary object graphs. The programmer doesn't need to think hard about who has a reference to who, and how long these references live. This leads to performance-defeating pointer chasing, and fuzzy, not-well-thought-of object lifetimes, which in turn lead to accidental memory leaks.
Additionally, references in major languages are unconditionally mutable. Having long-lived mutable references from arbitrary places makes it hard to track object states. It makes easier to end up in unexpected states, and accidentally violate invariants from subroutine code, which means bugs.
Also, class-like functionality conflates data-layout, privacy/encapsulation, API, namespacing and method dispatch into a single thing. Untangling that knot and having control over these features separately might make a better design.
I agree this is useful. I also think it isn’t the end of the world to support some semblance of OOP in Rust.
If it helps you ship the business logic, sometimes it’s okay to concede some performance or other cost.
jtrueb commented on Rust Any part 3: we have upcasts lucumr.pocoo.org/2025/3/2... · Posted by u/jmillikin
Getting closer and closer to OOP
Any language that is copy-paste compatible with C is a lost cause in regards to security.
From language features and community culture point of view.
I think that is a bit of an overstatement given the amount of legacy code and bindings generation capabilities. I do think it had to swing towards memory safe and C++ still didn’t have a plan for smart pointers much less move semantics when Swift dev started.
Who knows what present day Objective-C++ could have been if it had been the workhorse language of choice. Maybe this profiles thing Bjarne is pushing could have been in the roadmap. We will never know.
Most Objective-C codebases are brown field development.
Apple themselves, the only framework that they started from scratch in recent years was Metal, and even there only die hards use Objective-C instead of the Swift bindings.
Could be better, it isn't as bad as you make it to be, for a language whose design goals are to replace C, C++ and Objective-C for Apple.
Having worked on the old, the migrating, and the new, I appreciate Swift more than Objective-C mostly due to IDE support.
If they had put the effort into Objective-C++ that they put into Swift, I struggle to imagine it in a worse place than Swift is in these days.