> Considering that the recent Google code leak only substantiated that Chrome is the honey pot for surveillance and data harvesting that people long suspected
I'm vaguely aware of a code leak but haven't delved into the details; I'm curious if you have a link to details about this data harvesting?
The Internet existed before Internet ads (and particularly targeted ads) did. Personally, while I don't necessarily disagree with the point you're making, I'm curious to see what a pendulum swing in the opposite direction might look like.
I can't cite my sources, but I recently started learning Rust and I've been doing this. I would guess that I picked it up from the Rust book, since that's been my primary learning source.
I know I _could_ define my own error type, but that's tedious, especially if there are many types of errors to handle. For my (non-production) purposes it's been fine.
What's the idiomatic way to handle errors? Is there a way to collect more detailed error information without excessive boilerplate?
A common but of advice is “use anyhow for applications and thiserror for libraries” but what it really boils down to is, anyhow is good for handling errors, and thiserror is good for defining your own error types.
I just want to thank you for your contribution to this thread. I've long thought email should go in a direction similar to what you're describing, and I appreciate the specificity you've provided.
I wish I could say I'm surprised by the animosity (and relative lack of substance) in some of the comments you've received, but I guess that's a problem with social media and/or humanity that's unlikely to have a technical solution.
This seems like the type of thing that a sophisticated query planner in 2024 would be able to figure out on its own? Maybe as a non database expert I'm expecting too much?
There were attempts to do this automatically ~7 years ago (https://www.postgresql.org/message-id/flat/7f70bd5a-5d16-e05...). It didn't actually make it in due to worries about the approach and properly de-duplicating the final resultset, as well as that approach to the optimization not playing well with duplicate inner-join removal optimizations (which were also being discussed at the time).
RISC-V. But really ARM is a totally legit choice at the moment, not out of touch at all, and I say that working for a RISC-V company.
The entire ARM ecosystem is far more mature than RISC-V, plus the main RPis are ARM so they have experience with it and probably access to ARM people.
The main reasons to use RISC-V currently are cost and customisability. There are also some quite high quality open source RISC-V cores you can use off the shelf.
RISC-V is only really directly helpful for those building their own silicon (sure "anyone" can implement a RISV-V core in a FPGA but that won't give you the performance of an ASIC).
If you just want to buy a chip and put it on your own board you don't really care that much about the ISA as long as the toolchain, bootloader, kernel support is there and stable (which is pretty much the case with RISC-V now).
But if you're desiging your own silicon the ability to make or modify an existing open source RISC-V implementation can give you the flexibility that currenlty only the very largest players in the ARM ecosystem that have architecture licenses have (I think that's pretty much limited to Apple, Qualcomm, Samsung).
I expect the smaller but important players like NXP, ST, TI will be bringing out RISC-V chips taking advantage of this.
ARM have also been talking about making their fees dependant on the price of the final product so that could also push people to RISC-V, not just to pay less but also to not have to jump through the hoops that would be required to provide all the information to do that.
I was skeptical at first - tried the copilot beta, got annoyed by it, and quickly turned it off. Later I tried it again and haven't looked back.
For the most part it's not that I'm ceding the thinking to the machine; more often it suggests what I was going to type anyway, which if nothing else saves typing. It's especially helpful if I'm doing something repetitive.
Beyond that, it can save some cognitive load by auto completing a block of code that wouldn't have necessarily been very difficult, but that I would've had a stop to think about. E.g an API I'm not used to, or a nested loop or something.
The other big advantage that comes to mind is when I'm doing something I'm not familiar with, e.g. I recently started using Rust, and copilot has been a major help when I vaguely know what I _want_ to do but don't quite know how to get there on my own. I'm experienced enough to evaluate whether the suggested code does what I want. If there's anything in the output I don't understand, I can look it up.
> Are there tasks where you explicitly avoid them?
Not necessarily that I can think of, but after having copilot on for a little while it's gotten easier to tune it out when I'm not interested in its suggestions or when they're not helpful.
> How often do you find bugs in the generated code (and a corollary, how frequently has a bug slipped in that was only caught later)?
90% of the time I'm only accepting a single line of code at a time, so it's less a question of "is there a bug here" and more "does this do what I want or not?" Like, if I'm writing an email and gmail suggests an end to my sentence, I'm not worried about whether there's a bug in the sentence. If it's not what I want to say, I either don't take the suggestion, or I take the suggestion and modify it.
If I do accept larger chunks of suggested code, I review it thoroughly to the point where it's no longer "the AI's" code -- for all intents and purposes it's mine now. Like I said before, most of the time it's basically the code I was going to write anyway, I just got there faster.
I'm vaguely aware of a code leak but haven't delved into the details; I'm curious if you have a link to details about this data harvesting?