ezrast · HackerTrans

ezrast

no profile record

Submissions

Where did the other dollar go, Jeff?

blog.cloudandtree.com

407 pointsby ezrast5년 전229 comments

comments

4개월 전discuss

Setting aside the notion that a site presenting live-editability as its entire core premise is "pretending to be static", do the actual folks at Wikimedia, who have been running a top 10 website successfully for many years, and who have a caching system that worked well in the environment it was designed for, and who found that that system did not, in fact, trivialize the load of AI scraping, have any standing to complain? Or must they all just be bad at their jobs?

https://diff.wikimedia.org/2025/04/01/how-crawlers-impact-th...

5개월 전discuss

Gotta hand it to 'em though - posting this less than a month after the Matrix boondoggle certainly is, uh, audacious.

11개월 전discuss

High volume and inorganic traffic patterns. Wikimedia wrote about it here: https://diff.wikimedia.org/2025/04/01/how-crawlers-impact-th...

Another article that, by the third sentence, namedrops seven different AWS services they want to build their app on and then spends the rest of the argument pretending like that ecosystem has zero in-built complexity. My friend, each one of those services has its own security model, limitations, footguns, and interoperability issues that you have to learn about independently. And you don't even mention any of the operational services like CloudWatch, CloudTrail, VPCs (even serverless, you'll need them if you want your lambdas to hit certain other services efficiently), and so on. Those are not remotely free. Your "real developers" can't figure out how to write a YAML document, but you trust them to manage infrastructure-as-code for motherloving API Gateway? Absolutely wild.

Kubernetes and AWS are both complex, but one of them frontloads all the complexity because it's free software written by infrastructure dorks, and one of them backloads all of it because it's a business whose model involves minimizing barriers to entry so that they can spring all the real costs on you once you're locked in. That doesn't mean either one is a better or worse technical solution to whatever specific problem you have, but it does make it really easy to make the wrong choice if you don't know what you're getting into.

As for the last point, I don't discourage serverless solutions because they make less work for me, I do it because they make more. The moment the developers decide they want any kind of consistency across deployments, I'm stuck writing or rewriting a bunch of Terraform and CI/CD pipelines for people who didn't think very hard about what they were doing the first time. They got a PoC working in half an hour clicking around the AWS console, fell in love, and then handed it to someone else to figure out esoterica like "TLS termination" and "logs" and "not making all your S3 buckets public by accident."

EDIT: I originally had an escalatory reply here but have thought better of it. Trying again but without being an asshole: yeah, what you describe is one way miscommunications can happen. They can also happen in other ways that may be the engineer's fault, or nobody's at all. They may not happen every day, just like how you won't be deploying a new service every day, but anyone who works in an office is going to need to be able to deal with them regardless. Highly functional organizations are so because they can recover from mistakes, not because they don't make them.

Without wanting to be unkind, this author misunderstands the purpose of the exercise, which is to demonstrate to another human being that you can write code that meets the company's standards (as in, would pass PR review), not to ship a fully-functional product solo. The initial email makes it explicit that they don't care if the product even works ("Can use a fake backend") and that the specifications are deliberately open-ended. A little intuition and empathy can tell you that they probably are not going to spend many hours reviewing a complex submission, so the project should optimize for demonstrability of code quality, not completeness.

"I would like to know what kind of response I could expect..." - This is also established from the beginning: you can expect either a "Looks good, let's do some interviews" or a "Sorry, not interested," based on the code you submit. They can't narrow down the choices prior to your submission, because they're grading your submission, not your proposal document with an extensive list of details that they already told you they're mostly ambivalent to.

"So it is funny that my project is so weak, yet it made them update the guidelines to something stricter." - Main character syndrome. As someone who has been on the other side of these kinds of reviews, the far more likely explanation is that they kept getting submissions where the build instructions didn't work (which is not disqualifying by itself; the authors may not be on the same OS as the reviewers) and they got tired of spending time dealing with it.

Ultimately, the failure here was not a technical one but a social one. The author tried very hard to do the thing that it seemed like they were asking for, not the thing they actually wanted. The hiring manager's unwillingness to engage with the proposal doc was itself a form of communication that they were not interested in this level of detail, it was just an implicit one.

It's common for engineer types to want all that kind of communication to be explicit, and I have a lot of sympathy for those folks, but the reality is that teamwork is a skill, and the ability to suss out what a stakeholder actually wants, but isn't saying due to incomplete information and/or office politics, is a reasonable thing to select for. The ambiguity of the prompt is a feature, not a bug: it's kept the author away from a company whose communication style they're not compatible with.

(that said, this project does sound excessively complex for a take-home)

2년 전discuss

You can't programatically detect novel BS any more than you can programatically detect viruses or spam. You can only add the fingerprints of known badness into an ever-growing database. Viruses and spam are antagonistic to well-resourced institutions, and their databases get maintained reasonably well. LLM slop is being generated by those same well-resourced institutions. I don't think it fits into the same category as Nepenthes.

2년 전discuss

The whole point of systemic incentives is that there is no conspiracy. Nobody wants a DDOS and every large provider will have people genuinely working to avoid them. But every time there is an opportunity to allocate resources, the team that gets to frame their return on investment in terms of real dollars will always have an edge over one whose value is realized only in murky customer satisfaction projections. Over the lifetime of a company, the impact of these decisions will add up with no need for any of the individuals involved to even be aware of the dynamic, much less conspire to perpetuate it.

2년 전discuss

Whelp, looks like I'm today's Poe's Law poster child. ;)

2년 전discuss

This seems like a distinction without a difference, since we can never positively categorize any unobserved phenomenon as impossible (vs merely unobservable). To me, it seems ontologically cleaner to treat existence and observability as the same thing. shrug

2년 전discuss

What does "impossible" mean to you if not that a thing and it's consequences can never be observed?

2년 전discuss

It's not really a problem in practice (and I love Ruby), but it's still wild to me that they made the parser do this:

    $ irb
    irb(main):001:0> def foo(x=70) = x
    => :foo
    irb(main):002:0> i = 2
    => 2
    irb(main):003:0> foo / 5/i
    => 7
    irb(main):004:0> foo /5/i
    => /5/i

2년 전discuss

I'd call that reading poorly-supported enough to be incorrect. The report establishes that waypoint names are changed somewhat frequently for reasons that are largely left to mystery, but can include "a basketball player I like died." Additionally, "This is on fire right now" suggests some relevant context beyond "a single reporter sent us a nosy email." So while it may technically be true that the email preceded the name change in the chain of causality, its framing as the principal cause appears to be a narrative built of incomplete information. The linked NYT article also mentions pushback from pilots.

2년 전discuss

Think of all the algebra problems you got in school where the solution started with "get all the x's on the same side of the equation." You then applied a bunch of rules like "you can do anything to one side of the equals sign if you also do it to the other side" to reiterate the same abstract concept over and over, gradually altering the symbology until you wound up at something that looked like the quadratic formula or whatever. Then you were done, because you had transformed the representation (not the value) of x into something you knew how to work with.

2년 전discuss

There's no reason the tax needs to directly reflect the environmental impact. We figure out an amount that is enough to change corporate behavior without bankrupting them, maybe with some kind of sliding scale to put more responsibility on larger businesses who would otherwise benefit from regulatory capture, throw in some exceptions for the aforementioned medical devices, etc. "Pricing the externalities in" is a nice political justification but in reality this kind of thing happens because we've already decided that plastics are significantly worse than the alternative and we want to incentivize change.

Regarding consumers shouldering the cost - well, yeah, regulation drives prices up; even my liberal self agrees that that's broadly true. Those same consumers will be shouldering the cost of an environment permeated by toxic microplastics, which we are increasingly being driven to believe will be a greater impact than that of more expensive consumer goods.

2년 전discuss

It had done all that by 2010, no? The real hype was about what would come after.

I don't think the thesis of most Bitcoin critics is that the math and social engineering involved aren't interesting.

2년 전discuss

> Also, with this comment I hope to get some pushback

More of a push forward, really: if error-handling guarantees are what's driving you away from dynamically typed langauges, Go is pretty much the worst place you can land that isn't C. It doesn't make you check nils, it doesn't remind you to check error values from functions that you call only for side effects (though the linter will, admittedly), and it doesn't have sum types so there's semantic ambiguity even in the common case - that is, in `data, err := fn()`, it's common to assume that at most one, and perhaps exactly one, of `data` and `err` will end up non-nil, but that's not a constraint you can express with the type system.

2년 전discuss

Without meaning to detract from your point, "no one" is a bit hyperbolic. Elixir, Gleam, Caramel, and LFE all compile to BEAM, and Akka looks like a decent attempt at porting the VM semantics to JVM and .NET.

2년 전discuss

I think it makes more sense to look at it through the lens of labor distribution. Money is abstract and cyclical and can be inflated and deflated by policy, which makes it complicated to draw conclusions about. But money is ultimately used to influence the distribution of labor, which we as a species have a finite capacity for, and which has concrete impacts.

As a person becomes wealthier, each marginal dollar is less likely to be used to support critical infrastructure like food distribution and more likely to support the construction of mega-yachts. And because the labor pool is finite and subject to competition, increasing the leverage of the mega-yacht industry can have a negative effect on other sectors' abilities to meet people's basic needs. This is why I hold income inequality to _generally_ be a negative thing under capitalism: not because of any moral judgment on rich people, but because a certain level of competitiveness among individuals in the labor market is a requirement for survival.

edit: whoops, everyone else already made this point while I was typing. Sorry for the pile-on.

2년 전discuss

The alternatives aren't frictionless either; many items from that image are not specific to Kubernetes. I personally find AWS API's frustrating to use, so even if I were running a one-person shop (and was bound to AWS for some reason - maybe a warlock has cursed me?) I'd lean towards managing things from EKS to get an interface that fits my brain better. It's just preference, though - EC2 auto-scaling is perfectly viable if that's your jam.