I felt the same, but then thought of experts in their field. For example, my PhD advisor would already know all these papers. For him the prompt would actually be similar to what was shown in the video.
You are absolutely right, and a follow-up CL fixed the non-Zba code path. At the time of writing of the blog post, the generated code was however still using the 4 instructions instead of just two.
V8 is a huge project and ports almost have to start from backends of existing architectures. Over time we (I recently worked on the RISC-V port) improve the situation.
Note that it's also crucial to stay somehow similar to the x86 and ARM backends as the V8 team frequently makes changes to these and keeping up with them would be a nightmare if the RISC-V backend was too different.
"Does no one at Google know RISC-V"
This work wasn't done by Google. Also, you don't hire RISC-V experts, but V8 experts (or other similar VMs) for such a port. I, for example, had never worked with RISC-V before. As such, it can happen that some code of the RISC-V backend is written by engineers that aren't yet experts in RISC-V.
When I published Grisu (Google double-conversion), it was multiple times faster than the existing algorithms. I knew that there was still room for improvement, but I was at most expecting a factor 2 or so. Six times faster is really impressive.
First, where does it say it costs $1000 for PR approval?
Second, what's the problem? The person who opened the PR is adding code support for the feature; the repo maintainer says they need a dedicated CI environment for that new feature; the person who opened the PR is unwilling to meet that condition.
If they can get the data without a user's consent, then it's independent of this new feature and thus unrelated. If you believe that the government has unlimited access, then it was most likely already possible before this feature.
Now, there is at least a "proper" way to give law enforcement access.
Currently it's only targeting the ESP32 family, but the code is pretty portable. By default, it probably also needs more resources due to OS-like abstractions, allowing for multiple containers to run on parallel, etc. Obviously that also brings some nice advantages. For example, installing or updating, a new container is just a few lines of code.
We have been working on it for more than 5 years now, and it's definitely at a stage where lots of projects would benefit from it.
We found that Python isn't really designed for constrained environments. The object model, in particular, makes it hard to have fast method calls. The memory layout is also affected by the language, leading to bigger objects and a worse GC.
If you are just running a small hello world, or a number crunching loop, then both languages behave similarly. However, if you actually want to run something more consequential in production you will have an easier time with Toit.
Speed: maybe, sometimes. Of course, MicroPython makes it very easy to create modules written in C, accessible from MicroPython. So if you need extra perf you can always write a smattering of C.
Reliability: I don't see why Toit would be any better? FWIW we make medical devices using MicroPython and have tests that have run for many months with no failures. MicroPython, the language, is extremely reliable and thoroughly tested [1], though admittedly the port-specific code can be less so.
We've evaluated Toit and it has some nice features (the containerization is novel and powerful!)...but it's a quirky language with sparse peripheral support. Ultimately it's trivial for Python-familiar developers to switch across to MicroPython - a big benefit. Being constrained to the ESP32 is a limitation that many of our customers would not allow.
You will improve your language skills this way, but if your skill level isn't high enough it's going to be exhausting to the native speaker as well.
I have been living in Denmark for 15 years now, and it's still easier to do conversations in English. When I speak Danish it requires more mental capacity from the other side.
I am speaking Danish from time to time, but it's only to get better at it. The English proficiency in Denmark (and probably the Netherlands) is so high that you need to be really good at the native tongue before it is easier than English in conversations.
This is my point. especially in a country where everybody speaks English anyway. you will never be better at Dutch than English so by that logic. it will always (or at least for many years) be more difficult to talk to you in Dutch. so, ask the hard question:
Are you learning it to actually talk to other people?
If yes, just do it. to many people it is endearing if you are struggling with a language. And if they don't like it they probably just don't like talking to you in general so learned or not doesn't matter.
I think many people are scared of talking and use language learning as an excuse for fear. You can start talking to real people or you can keep learning and never talk to real people and then what's the point.
Technically probably yes, provided you had millions of neighbors, the sun never sets and all big users like kettles and heat pumps kindly switch off as well. If either of those conditions stops being true, then either the frequency or the voltage will drop too much and the panels turn themselves off. In practice these balcony panels are not sufficient in the slightest to power a house, let alone an entire apartment building, and they will turn off almost instantly.
reply