This is good context to add to the article, because he's basically at retirement age anyways. Depends a little on whether 1980s means "1980" or "1989" but with that resume I think he can afford retirement even if it's 1989 :)
My relationship is quite long-term, it can almost get its learner's permit, and we use Instagram all the time to, like, share cute animal videos from the Explore/Reels screens to each other, share stories to our friends of whatever we're doing together, or not together, and see our friends' stories.
idk if your partner is jealous of you using one of the top five social networking apps in the world that seems a little weird and maybe your relationship is not very healthy? it's instagram, not tinder or okcupid...
As long as you stay on a happy path, it's only like 5% thirst traps. But many people don't like it when those things are popping up in their SO's feed, so Instagram isn't good for those relationships.
I avoid it now mainly because I don't need infinite scrolling of anything. But a side benefit is that it can't provoke any jealousy.
> As long as you stay on a happy path, it's only like 5% thirst traps.
I’m an infrequent facebook user, but every couple months I’ll visit the website for something on fb marketplace or an event I’ve been invited to and 100% of the reels that are shoved at me are softcore pornography. My only interaction with them has been to click the “hide this item” (or whatever it’s called) on every reel I’ve ever seen.
I like that JSON parsing libraries (Serde etc.) allow you to validate nullability constraints at parse-time. Protobuf's deliberate lack of support for required fields means that either you kick that down to every callsite, or you need to build another parsing layer on top of the generated protobuf code.
Now, there is a serde_protobuf (I haven't used it) that I assume allows you to enforce nullability constraints but one of the article's points is that you can use the generated code directly and:
> No manual validation. No JSON parsing. No risk of type errors.
But this is not true—nullability errors are type errors. Manual validation is still required (except you should parse, not validate) to make sure that all of the fields your app expects are there in the response. And "manual" validation (again, parse don't validate) is not necessary with any good JSON parsing library, the library handles it.
yes, but any sane JSON parsing library (Rust Serde, kotlinx-serialization, Swift, etc.) will raise an error when you have the wrong type or are missing a required field. and any JSON parsing callsite is very likely also an IO callsite so you need to handle errors there anyways, all IO can fail. then you log it or recover or whatever you do when IO fails in some other way in that situation.
this seems like a problem only if you use JSON.parse or json.loads etc. and then just cross your fingers and hope that the types are correct, basically doing the silent equivalent of casting an "any" type to some structure that you assume is correct, rather than strictly parsing (parse, don't validate) into a typed structure before handing that off to other code.
That's called validating? Zod is a validation library.
But yeah, people really need to start strictly parsing/validating their data. One time I had an interview and I was told yOu DoN'T tRuSt YoUr BaCkeNd?!?!?!?
looking at zod (assuming https://zod.dev) it is a parsing library by that definition — which isn't, like, an official definition or anything, one person on the internet came up with it, but I think it is good at getting the principle across
under these definitions a "parser" takes some input and returns either some valid output (generally a more specific type, like String -> URL) or an error, whereas a "validator" just takes that input and returns a boolean or throws an error or whatever makes sense in the language.
eta: probably part of the distinction here is that since zod is a JS library the actual implementation can be a "validator" and then the original parsed JSON input can just be returned with a different type. "parse don't validate" is (IMO) more popular in languages like Rust where you would already need to parse the JSON to a language-native structure from the original bytes, or to some "JSON" type like https://docs.rs/serde_json/latest/serde_json/enum.Value.html that are generally awkward for application code (nudging you onto the happy parsing path).
yeah I have repeatedly had things like "yOu DoN'T tRuSt YoUr BaCkeNd?!?!?!?" come up and am extremely tired of it when it's 2025 and we have libraries that solve this problem automatically and in a way that is usually more ergonomic anyways... I don't do JS/TS so I guess just casting the result of JSON.parse is sort of more convenient there, but come on...
> Seems we should be very concerned and work hard to avoid smoking, vs random death from a helicopter falling on us?
At a population level maybe... but if you (and your family/friends if you want to consider that too) already don't smoke, there is not much to do? I don't have to work hard to avoid smoking because I am not interested in doing it to begin with, and it is not like cigarettes jump out of bushes and ambush you.
Helicopter crashes aren't common, but traffic violence is mostly treated as normal in the US, and deaths are often brushed off as an unavoidable "accident" with little or no punishment for the perpetrator, or serious consideration of systematically redesigning streets or vehicles to make these deaths less likely. This is something that I cannot "simply" avoid like smoking is.
Alligators maybe not, but in the one time that I have paddleboarded in the keys I saw a crocodile. Probably a crocodile rather than a gator, I didn’t get that close… but from reading articles they’ll occasionally eat a small dog around there, so they are definitely out there.
Saltwater crocs do exist in southern Florida, no doubt. And there's some chance a gator could swim from one island to another (or the mainland).
The easiest way to discern each is based on their snout. If the reptile you saw has a blunt nose about the same width as its jaw, then it's a gator. If, instead, the jaw looked more like a trapezoid, then it's a croc.
Both are opportunistic hunters capable of taking down mammals up to adult bovines or horses. The latter two examples are rare as the size of the croc/gator has to be rather large.
I've received some "bonus" performance related equity grants with a four year vesting period. These are beyond normal the refresher grants. They are not described by the company as "bonus", because we also have the sort of cash bonus you're talking about, but were I to describe them to people outside the company, I'd probably say "bonus grants" or something.
In this case it seems obvious that it needs some kind of vesting terms to prevent people from taking the bonus and then just taking another offer anyways.
> Initially, everything looked great. The build succeeded, all components were found and added. But when I opened KiCad… nothing was wired up.
Maybe this is pedantic, but I thought that the core point of "Vibe Coding" is that you do not look at the code. You "give in to the 'vibes'".
I don't know how to translate it into a physical hardware product exactly, but I think it would be manufacturing it without looking at it, plugging it in for your use-case and seeing if it works, then going back to the model, saying it didn't work, rinse, repeat.
That's how Karpathy defined it - it's throwing and rethrowing it back to the LLM agent until you have a result that roughly matches the goal.
It's the behaviorism of programming. (Pay no attention to the man behind the curtain).
Personally I use the term "agentic coding" if you are high leveling describing the specs to the LLM agent but still taking some minimal amount of time to review the diffs.
I'm not saying you're wrong, or that I know better.
Yet I have to say that if you are correct, the term is no different than eating tide pods or dry swallowing cinnamon. Why tf would anyone impose such an absurd artificial constraint on themselves, on the tool, or on whatever they are trying to build? Good faith question, I promise.
Constructing detailed prompts to ultimately pair program impressive, complex outcomes is what I assumed vibe coding was. After 35 years of not being able to tell a computer to write the code for me, even getting an 80% coherent first pass of a sophisticated refactor was already radical enough.
If that's what vibe coding is, then nobody should be using that term because it might be the perfect example of "just because you can, doesn't mean you should".
> Yet I have to say that if you are correct, the term is no different than eating tide pods or dry swallowing cinnamon. Why tf would anyone impose such an absurd artificial constraint on themselves, on the tool, or on whatever they are trying to build? Good faith question, I promise.
IDK! I don't think Vibe Coding, with the definition that I understand, is a good idea.
I myself am unclear on what the "vibes" that one is giving into actually are. But terms should have meanings and my understanding from reading the original tweet is that "Vibe Coding" means something distinct from "coding using some AI to help".
