HN user

jamescostian

1,129 karma
Posts12
Comments329
View on HN

I think there's more to your sibling's taxes than property taxes. The data tell the opposite story - WI property taxes are higher than TX ones, at least if we look at the medians:

https://www.propertytax101.org/propertytaxbystate

As someone living in Fort Worth and making good money as a Staff SWE, I got a tax refund this year. It was due to paying interest on my house, but still.

I'd recommend asking your sibling see if they qualify for the homestead exemption, it's significant. You or they can check if they're using it and see their exact property taxes here:

https://www.tax.tarrantcountytx.gov/search

with zero human checking of AI outputs

It can be hard enough for humans to just look at some (already consistently passing) tests and think, "is X actually the expected behavior or should it have been Y instead?"

I think you should have a look at the abstract, especially this quote:

75% of TestGen-LLM's test cases built correctly, 57% passed reliably, and 25% increased coverage. During Meta's Instagram and Facebook test-a-thons, it improved 11.5% of all classes to which it was applied, with 73% of its recommendations being accepted for production deployment by Meta software engineers

This tool sounds awesome in that it generated real tests that engineers liked! "zero human checking of AI outputs" is very different though, and "this test passes" is very different from "this is a good test"

Many iOS users use the Messages app to send and receive text messages which can be trivially backed up to iCloud but not other cloud storage solutions. Among people who text (common in the US) I'd imagine there aren't many iPhone users with less than 5GB of data stored in iMessages

That said, you can back iMessages up to a computer and back up files on your computer. You just can't restore iMessages to different Apple devices like this, but now we're talking about minor grievances to a really tiny segment of the population

you'd be an idiot if you don't mass apply using your resume. Everyone does it, so you have to as well.

I've been on the receiving end of mass applications. If you stopped justifying your spam behind "everyone does it" (no they don't) and started tailoring your applications, leaning on your network (or building one up) you may need a lot fewer.

I have never mass applied, so I may seem idiotic to you. But even during the times I quit a job before looking for another, I've never been on the market for more than 2 weeks.

Georgia the country has about half the land of Georgia the state in the US, and Georgia the country has about half the population of Atlanta alone (even less population when compared to the entire US state of Georgia). I think that huge difference in popularity contributes largely to why "Georgia" often refers to the the US state on this site

I think a lot of really smart people end up claiming something like "this whole system wasn't designed properly, we can do it way cleaner if we redesign it from the ground up" but it's always a trap. Incremental improvements take less time, can be more easily understood, are safer to deploy. But a lot of those really smart people have perfectionistic tendencies that cloud their judgement, and nobody can imagine all the different paper cuts that will get in the way of their beautiful vision. And thus, the new technical debt (to someone else) is written

Perhaps something that could you help is adding an H1 to the readmes like "This project is finished, not being developed", with some explanation like "Unless you found a security vulnerability, your issues and PRs may be ignored or receive delayed responses. Feel free to fork this repo if needed. Please do not ask if this is dead."

This clarifies your stance so well that people acting in good faith won't bother you, and anyone who does bother you very likely isn't acting in good faith - easy to ban.

Plus, when you see someone ask questions about your project and interpret them as "a bulleted list of the reasons I suck", it implies that on some level you think "I suck because I'm not giving these projects more of my time". Giving that kind of disclaimer might help you move away from that mindset, and instead feel more at ease with yourself. Your contributions should be celebrated (as the person with those bulleted points did!), and anyone acting in good faith can appreciate them and fork if needed

I've seen apps break in prod where third party libraries had array accesses on indices that didn't exist, or dereferenced nil pointers, in goroutines they spawned. And those aren't the only ways to cause a panic without ever calling the panic function.

Third party libraries have bugs sometimes, and other times our usage of them can create bugs. Nothing like a SIGKILL or anything malicious. That's just the way things are and will be. And breaking down like this in dev can be fantastic!

But when a once in a blue moon issue crops up in prod and all other connections are dropped, the fact that a simple defer+recover couldn't have been preemptively placed on all goroutines is a huge nightmare. I'd even take a "you can add defer+recover for any goroutines created further in this callstack" - it's rare that libraries spawn goroutines, I'll already know which ones to trigger that behavior on

This might mean you can't use TheTradeDesk and Google Adsense en-masse for example. Basically, as of today, a lot of price discovery is now automated by a majority of companies using a handful of vendors for this.

IANAL but this seems incorrect. Price discovery is one thing, being contractually obligated to keep prices at a certain level 80% of the time is another. A court can make a ruling about that 80% number in the contract without saying anything that impacts one's ability to discover the prices competitors charge

It could be your router giving it a new IP address, but the printer itself hopefully has a static MAC address. Check your router settings for static IP assignment, they may be under a section called DHCP. Over there you could give it a static IP address for its current MAC address

EDIT: this comment no longer makes sense after the parent comment was edited. It used to be explicitly asking for help and didn't mention any solutions like static IPs, nor did it spell out a general remark about how this complexity in consumer electronics is bad

1. You can just use `export type Foo = z.infer<typeof fooParser>` in one place and then import Foo everywhere else, without using z.infer everywhere else

2. Use let and modify your types as new ones become available - union them with a new object that contains the new property you need

3. How often are you making recursive types?

I agree that all of this could be made easier, but zod is the best we have and great for most normal usage. The reason TS doesn't want to make this available at runtime is that it means so many changes they make will become breaking changes. Perhaps one day when there's less development on TS we'll see this get added

Agreed that reallocating money and resources for the greater good is a good thing. That said, these are all topics that still receive lots of debate politically. That's what I mean when I say it's a human problem.

You can't solve healthcare by throwing tech, money, etc at it anymore than you could solve a broken heart with those things. Sure, money could help you get therapy or pay for lobbying for whatever your solution to healthcare is. OTOH, perhaps the person cutting the checks thinks the solution to heartbreak is a raise ("it shows we care"), and the solution to healthcare issues is to lobby for criminalizing generics ("they're probably cutting corners and making people worse off"). People don't even agree on what are the problems in healthcare (and other things in that list), let alone how to solve them

I don't think radical technical breakthroughs will be the solutions to any of those problems. Those are human problems. There's nothing wrong solving technical problems while human problems persist. Putting programmers, data scientists, etc on human problems doesn't solve them better or faster than putting someone outside of STEM on them

Vite 4.0 4 years ago

Angular has had 13 semver major bumps in the past 5.5 years

It sounds like you have experience with the string-heavy CSS in JS. Here's some examples showing how this can be achieved using `csstype.Properties` objects: https://emotion.sh/docs/typescript

I'm sure you can imagine how easy it is to compose functions that accept and return `csstype.Properties` objects, and then at the end, you call `styled` with it to make a styled component. You can even pass styled a function, which takes in runtime-adjustable props, and of course, that function can itself use other functions, passing around those same or some derived runtime-adjustable props.

That said, I have no idea what you mean when you talk about ergonomics being better, can you elaborate? I re-read your initial comment but there wasn't anything in it not achievable in TS using the kinds of things mentioned in the "CSS in JS" section, perhaps there's something else I'm just not aware of? I do not know elm, let alone have experience writing it in non-trivial production codebases, so a concrete example would be great

For anyone else trying to understand how this fits in, it's either the "Inline Styles" section or the "CSS in JS" section, as long as you use typescript and follow the same rules mentioned here

Here's the bulk of the code used to generate the code they're building: https://github.com/vercel/turbo/blob/main/crates/turbopack-c...

They're building basically the same thing over and over again. This surprised me, given their intro post: https://vercel.com/blog/turbopack

Relevant quote:

Turbopack is built on Turbo: an open-source, incremental memoization framework for Rust. Turbo can cache the result of any function in the program. When the program is run again, functions won't re-run unless their inputs have changed. This granular architecture enables your program to skip large amounts of work, at the level of the function.

I'd be curious to see if a real-world app (or even one generated with more variety in components) showed comparable performance numbers

You've repeatedly made leaps between what I've said and horrible arguments I never made, and you've never, not even once, admitted to a single good point being made by me - if I retort something, it's never "my b", always "no, let me twist your words, maybe pretend your argument was this strawman". And recently, straight up ad-hominem.

In the future, consider arguing differently.

I used to go to college. Nobody would spend $5 on a typical case of 24 average water bottles, that was way too much. $3 was more like it. A single reusable water bottle though? Even a cheap plastic one could run you $10, I'm sure you could find one for like $7 but the point stands. Convincing my friends to get a water filter was easy when looking at the money long-term, because they had the money short-term to cover it. If they didn't have the money short-term to get the filter and the bottle though, then they wouldn't have. It's as simple as that.

> So for example, if I were poor enough, I'd buy cases of water instead of a water bottle, EVEN IF I knew the single use water bottle was better for the environment and a better choice long-term!

I disagree. This seems to be based on pure speculation and projection.

No, it's based on not having enough money. I guess water bottles are a worse example here, you're right, I've done a bad job of making this point here. See my other paragraph for a better job. Here's a more specific example: a homeless person with $10 goes to a store charging $5 for a box of pads and $40 for a diva cup. They will not buy a diva cup. It's that simple. They'll get their pads. "They won't buy a pad at all" people have needs, maybe some won't but this is a matter many wouldn't compromise on. "They will save" what will they save, pennies? Trust me, this is not a winning argument, there are mathematical boundaries you can't cross, and there's also the fact that if you're optimizing so hard on the diva cup, you aren't optimizing as hard (if at all) on something else.

You seem to be imagining that poor people can't do any long-term economic planning in their own lives, which is false. As if they're somehow trapped in irrational, short-term, self-defeating thinking.

You're looking at a poor person who has the money to save. I'm looking at a poor person who doesn't. My point wasn't about smarts, this is about basic human needs and a lack of money.

It's true that with more money, you can spend it on more green things. I won't disagree with you there - it was actually the central point that started all of this! And we were agreeing that just because they can doesn't mean they will! That poor people are not somehow magically much more eco-friendly, if only they were given more money. They're not some monolith.

We're not talking about a homeless person with a few dollars to their name, who wouldn't be buying cases of water anyway, because there would be nowhere to put a case of water.

Very good point, my diva cup argument is a much better one than the water bottle one.

> A case of water bottles [...]. That's an example of the parenthetical, I'm sure you can think of many more

> [...] pads [...] diva cup

how much do you think water containers are contributing to global warming

As I hope you can see from my own words, not very much. I'm providing specific examples of a generality. I can do more at other economic levels if you want. How about "how much does a cheap ICE car cost vs a cheap EV"? Of course, keep in mind the idea I have that people aren't all investing the most resources possible into eco-friendliness, as well as how eco-friendliness exists in many dimensions, so if you're saving for the EV it's harder to be saving for other eco-friendly things, the difficulty in finding a cheap used EV nearby, dealing with debts, etc. - and yes, I do think we can construct a lot of scenarios where a person choosing ICE vs EV can afford the EV, but I think we can also see how it can be quite burdensome on average, and that with more money, the person in question could afford to get to and buy a used EV (but again, I'm not saying they necessarily will! Or even that poor people put into this scenario are more likely to choose the EV over a more expensive ICE car, or something else entirely)

I disagree that the part in parentheses follows logically from the part outside the parentheses

Me too, it does not! It's the reverse, the part in parentheses is what causes the larger part. Say I want water. A case of water bottles is a lot "cheaper short-term" than a single, reusable, water bottle. That's an example of the parenthetical, I'm sure you can think of many more. Now, look at how it connects to the part of the sentence outside of the parenthetical, and directly before it: "the more you must go for things that are cheap at the expense of other things"

So for example, if I were poor enough, I'd buy cases of water instead of a water bottle, EVEN IF I knew the single use water bottle was better for the environment and a better choice long-term! Note that I do NOT assert that most or even many poor people, given more money, would switch to reusable water bottles on their own (hence the "government intervention" bit). If you're confused by the first half of that sentence, think of it this way: if I have $10 and you have $1000, which of us can buy more plastic?

I disagree that the part in parentheses necessarily represents the economic strategy of poor people

This really isn't about poor people being the most environmentally conscious or the least environmentally conscious. It's about "this box of pads costs the cheapest so I'll buy it". Even if you imagine a tree-hugging poor person looking at a diva cup thinking "this is cheaper long-term and it's better for the environment", if they don't have the money for it, or if spending that money means not eating for quite a while, then they're not going to buy it.

I think you've misunderstood my position. You mention:

that poor people are buying over and over, more so than wealthier people

Not only is this a line of argument I disagree with, I even explicitly said I disagreed with it in this part of the comment you are replying to:

> I think the idea is that if more people were middle-class, we'd see consumers make better choices (personally, I don't see that happening without government intervention of some kind

Imagine if everyone made a little more money, except for rich people who made considerably more money. Prices would go up and pretty much everyone would struggle to consume as much (or, consume things of as high quality, or perhaps as eco-friendly), but rich people wouldn't really see much of a change in their spending power, since there's few of them and they're making considerably more. I'd argue that idea counters your argument.

Unfortunately, that idea is more than just an idea: https://www.epi.org/blog/inflation-minimum-wages-and-profits...

You're not replying to a comment saying "poor people are the biggest contributors of CO2 emissions", you're replying to a comment saying "driving people into poverty is the biggest contributor of CO2"

So the thing to look at isn't poor people's emissions, it's rich people's emissions, given that (relatively speaking, bc increasing money supply just decreases its worth) the richer rich people are, the more poor people there are (or the poorer the poor people are). This is well-known, you can google and find tons of articles, but here's one from BBC: https://www.bbc.com/future/article/20211025-climate-how-to-m...

The poorer you are, the less you can individually consume, and the more you must go for things that are cheap at the expense of other things (e.g. buying single-use goods over and over is cheaper short-term than buying something made to last). I think the idea is that if more people were middle-class, we'd see consumers make better choices (personally, I don't see that happening without government intervention of some kind, but that could hurt poor people even more if it happened before poor people got more money to afford more eco-friendly choices). And on the opposite side of the spectrum, if rich people weren't quite as rich, they wouldn't consume quite as much in excess, and would lead to less emissions.

Docker is extremely popular and so there are plenty of reference Dockerfiles. Books and tutorials on K8S, Packer, ECS, GKR, etc all use OCI images, so docker (or something similar) is useful to have on hand. Yes, packer supports vagrant too, but just go to their website and go to guides, and notice how many docker guides they have and how prominent they are compared to vagrant. I think it's not about the individual implementations but about the paradigms they work in

Let's say I have a bug in prod. I just adjust my code, or Dockerfile, or some declarative config (say cloudformation or k8s definitions) and push it, and the CD doesn't say "go to existing machines and update them", it says "spin up containers with this new build and configuration, divert traffic to them, and then remove the old containers when safe". For me, provisioning is not something I want to touch outside of setting rules for autoscaling and saying "start using this new build". So arguments about provisioning (for my usecases) don't help - they sound like adding more responsibility onto me that computers already handle for me.

I don't feel that this declarative and abstract model is necessarily ALWAYS better than the imperative model you get with ansible et al. And I can think of an example: if you just need to run 1 command everywhere, ansible (or chef or puppet) is much faster than pushing a commit and waiting for the build and deployment. Or maybe if you needed a custom kernel. But I've never had an instance where those things were valuable or valuable enough; in all my experiences, fine-grain provisioning and treating servers like pets instead of cattle has never been a better choice (especially given bursty traffic), so I'm trying to broaden my horizons and understand where it would be a better choice.

Personally, I've seen much more of the opposite - clever devs shrugging off good advice without understanding it, just thinking "it doesn't apply to me"

But I think you're right about the more mid-experience developers. It would be nice if things like the 12factor specification weren't driven by Heroku's desire to make people feel like their approach is right, but rather, had a more nuanced approach like "these are our guidelines, we're confident in most cases they should be followed. If you fully understand a guideline and have a reason (driven by the bottom line, not subjective tastes, and not mentioned by us) to avoid following that guideline, do not follow it"