434 karma · joined May 11, 2017
I truly don't get it.
use std::error::Error;
use csv::Reader;
use reqwest::Client;
use serde_json::Value;
#[tokio::main]
async fn main() -> Result<(), Box<dyn Error>> {
// Define the CSV file path
let file_path = "data.csv";
// Open the CSV reader
let mut reader = Reader::from_path(file_path)?;
// Create a new HTTP client
let client = Client::new();
// Iterate over each record in the CSV
for record in reader.records() {
let record = record?;
// Get the value from the first column
let url = record[0].to_string();
// Perform GET request
let response = client.get(&url).send().await?;
// Check for successful response
if response.status().is_success() {
// Read response body
let body = response.text().await?;
// Parse JSON
let json: Value = serde_json::from_str(&body)?;
// Process the parsed JSON (e.g., print it)
println!("JSON for URL {}: {}", url, json);
} else {
eprintln!("Error fetching URL: {}", url);
}
}
Ok(())
}
[0]: https://dflate.io/shady-phoney
[1]: https://dflate.io/vscode-soy
So the difference wrt discovery is that you only have to gesture at what you wanna do and, if a matching action exists, there is a chance it will be understood.
I'd wager we'll see a renaissance of voice assistants with LLMs, especially once the good-enough ones can run on device.
https://dflate.io/state-of-tofu
I then further cut scope and extracted a few useful actions into a less revolutionary but more well rounded vscode extension
It also inspired me to take the learnings and build a mobile code editor for shaders
Wrt "even ones in which the tenants built the house": For me the baseline of implementing LVT is that ppl don't have to pay it for their primary housing (or a much lowered version of it). Is that controversial?
The post echoed many of my frustrations and inspired me to consider adopting the fisheye-zoom to my editor.
I'm looking for people interested in doing shader programming on the go to try this early version, hit me up if you are interested shade@dflate.io
Going between Rust and TS it is painfully obvious how much sth like tagged enums are missing, which can also be seen in this post.
I know of this [1] proposal for ADT enums which looks like it has stalled. Anyone know of other efforts?
[1] https://github.com/Jack-Works/proposal-enum/discussions/19
I vaguely remember my colleague having a reason for why his abstraction did not fit in the computed box. Probably something related to async, so it might very well have been because of that
I don't think I agree with that generalization. I probably could not even make a generalization about what normal closur-ing does or should look like.
> In a mutable framework that really pays attention to all these details (like MobX) there is a consistent model to how things work. So not only is state management way easier, its also on average less prone to these kind of issues.
My experience with MobX and the greater observable-industrial-signal-complex is that accidental loopiness very much can and does still happen. I have seen codebases with complex MobX computed-changes-graphs that senior engineers were clever enough to write but not to debug. And I was not aware of tooling which helped keep these graphs in line.
That said, I agree React's hooks have friction to them. I just tend to be in the camp of "I prefer my computational change graphs to be gated by a bit more boilerplate".
1. Starts talking about empiricism, does not actually deliver on it
2. Talks a lot about how React-things are old-actually, and then talks about signals and two-way data-binding as if there wasn't a time before React where these things were also pushed. React's non-adoption is not an accident I think, and these kind of posts would be more interesting if they would leave the surface-attacks and actually engage with the philosophy behind React's approach[1].
3. Quoting Alex Russel suggests you are more interested in heat than light (which is what he is known for where I'm from)
4. Distorted guitars are good actually.
[1]: https://gist.github.com/sebmarkbage/a5ef436427437a9840867210...
I have worked across these frameworks and React is the only one where I find the lib ecosystem satisfiyingly large (and still growing most steadily).
[1] https://npmtrends.com/@angular/core-vs-react-vs-solid-js-vs-...
That said it's only slow to load, it does not freeze or stutter. I guess that's still an upside to what it would've looked like under Windows or Linux.