Well it is not quite a mutable vs immutable strings war, nor Ruby being late to the party or something like that.
The move is so we can avoid allocating a string each we declare and use it since it will be frozen by default. It is a big optimization for GC mainly. Before we had to do such optimization by hand if we intend not to modify it:
# before
def my_method
do_stuff_with("My String") # 1 allocation at each call
end
# before, optim
MY_STRING = "My String".freeze # this does 2 allocations with 1 at init being GC quite early
def my_method
do_stuff_with(MY_STRING)
end
# after
def my_method
do_stuff_with("My String") # 1 allocation first time
end
But this move also complicates strings manipulation in the sense of it will lean users toward immutable ops that tend to allocate a lot of strings.
foo.upcase.reverse
# VS
bar = foo.dup
bar.upcase!
bar.reverse!
So now we have to be deliberate about it:
my_string = +"My String" # it is not frozen
We have frozen string literals for quite a while now, enabled file by file with the "frozen_string_literal: true" comment and I've seen it as the recommended way by the community and the de-facto standard in most codebase I've seen. It is generally enforced by code quality tools like Rubocop.
So the mutable vs immutable is well known, and as it is part of the language, well, people should know the ins and outs.
I'm just a bit surprised that they devised this long path toward real frozen string literals, because it is already ongoing for years with the "frozen_string_literal: true" comment. Maybe to add proper warnings etc. in a way that does not "touch" code ? I prefer the explicit file by file comment. And for deps, well, the version bump of Ruby adding frozen string literals by default is quite a filter already.
It is sorta late to the party. Common Lisp has similar with regards to how lists are done. Specifically, it is not uncommon to make a static list like `'(1 2 3)`. Doing this, however, has implications on what operations you can do on the data elsewhere.
I say sorta late to the party, as I think it is more than fair to say there was not much of a party that folks were interested in in the lisp world. :D
I do. It's a whole thing that get you down to writing your business logic in an expressive way very easily. Framework (Rails) helps, yes, but even pure Ruby can be nice. I've written a second time accuracy simulator for cars and chargers in a EV charging stations in pure Ruby, that was fast to iterate around and pleasant to write.
The ecosystem, toolchain and all do a lot. It is really missed when I do other languages, and I wish to find the same way of developing elsewhere. I currently do C for embedded in an horrible IDE, and I want to bang my head against the table each time I had to click on something on the interface.
- We are also designing and developing a more advanced family of microcontrollers, RP235x, which we expect to launch in the second half of 2024, as well as chipsets for use in our SBCs and compute modules for release thereafter.
- We continue to invest in the design and development of new SBC products, including successors to Raspberry Pi 5 and Raspberry Pi Pico, that will incorporate future semiconductor products, including RP235x. We intend to develop new products that address customer requirements such as industrial temperature tolerance and onboard non-volatile storage. We also intend to continue working to extend the long-term availability of our older SBCs
This means on-board flash !
- We are designing and developing a family of microcontrollers, RP235x, which will serve as successors to RP2040, and which we expect to launch in second half of 2024. RP235x products are designed to operate at higher speeds, use less power and provide greater security than RP2040.
Yeah I sure hope they will fix that ADC. I hope they will fix it on the RP2040 too. That would be great to use the RP2040 as peripherals for a more powerful chip (and load the code/pio through the swd ports so you don't need flash for each of them).
This will likely not happen, this chip is made to be integrated and there are many advantages to QFN; including the ability to make much smaller boards. See: https://includemicro.com/tiny-rp2040/
The foundation has made a lot of work to reduce board sizes as they are major contributors to water waste in a project (they also are the majority of the weight).
That would be nice to also optimize SELECT DISTINCT foo FROM bar. It is usually very poor on big tables and we have to do recursive CTE. This comes a lot with admin builders for filters (<select >).
SELECT DISTINCT has seen quite a bit of work over the past few years. As of PG15, SELECT DISTINCT can use parallel query. I imagine that might help for big tables.
I assume the recursive CTEs comment is skip scanning using an index and looking for the first value higher than the previously seen value?
Certainly skip scans would be nice. There has been some work in this area, but not recently. As far as I recall some other infrastructure needed to go in first to make it easier for the query planner to understand when skip scanning would be useful.
But with neuropathy, which causes loss of feeling, pain… in the feet for example, you can ignore damage that combined with a loss of blood circulation capabilities can make things deteriorate very badly (necrosis, amputation).
For me, the main thing keeping at being good at the closed loop system is delay. In the pancreas, « measure » and delivery happen at the blood level. It is instant. With CGM and pen or pomp insulin delivery, it is in the superficial higher layers of the skin for which you have 15min delay to and from blood.
Well, Netlify went south by forcing businesses (including ours) to migrate from Pro to Entreprise plan (which is very pricy) by having a hard limit on the members of the Pro plan. We were forced to migrate, then we migrated away to pure AWS a few month later.
We don't know what happened there. Did they have money issues?
One thing AWS has done well is charge enough out the gate that they don’t need those “good news” posts where companies jack rates up. Google maps, but many business focused apps I’ve used too end up squeezing ridiculous price increases through. I’ve not experienced that with AWS.
Type 1 is not preventable, but detecting it is important as it could arise in infants (half of cases). Consequences are kind of hard if ignored / not detected. Then proper glucose monitoring can be set.
And more generally, detecting glucose level from urine is a bit late for any kind of diabetes. So pretty useless for Type 2 monitoring I think.
Meant to inquire about this with my other response. Do you have a source for this?
My daughter was diagnosed at 2 (almost 3) and doctors gave the impression this is younger than average. We're also in many Facebook T1D parent support groups. There are certainly some diagnosed under 2, but it seems to be quite rare (1% maybe).
That's all anecdotal though. I'm genuinely curious about formal stats.
I'm not suggesting this wouldn't be useful for Type 1 diabetics. It certainly would! I've a Type 1 diabetic daughter who was indeed still (occasionally) wearing nappies/diapers when diagnosed.
Just that the paper/research in question has been conducted with adults in mind. Perhaps infants don't produce enough urine, I'm not sure.
The move is so we can avoid allocating a string each we declare and use it since it will be frozen by default. It is a big optimization for GC mainly. Before we had to do such optimization by hand if we intend not to modify it:
But this move also complicates strings manipulation in the sense of it will lean users toward immutable ops that tend to allocate a lot of strings. So now we have to be deliberate about it: We have frozen string literals for quite a while now, enabled file by file with the "frozen_string_literal: true" comment and I've seen it as the recommended way by the community and the de-facto standard in most codebase I've seen. It is generally enforced by code quality tools like Rubocop.So the mutable vs immutable is well known, and as it is part of the language, well, people should know the ins and outs.
I'm just a bit surprised that they devised this long path toward real frozen string literals, because it is already ongoing for years with the "frozen_string_literal: true" comment. Maybe to add proper warnings etc. in a way that does not "touch" code ? I prefer the explicit file by file comment. And for deps, well, the version bump of Ruby adding frozen string literals by default is quite a filter already.
Well, Ruby is well alive and it is what matters)