ezrast

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...

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

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)

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.

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.

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

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

Because it works, the infra folks you hired already know how to use it, the API is slightly less awful than working with AWS directly, and your manifests are kinda sorta portable in case you need to switch hosting providers for some reason.

Implementation-wise, yes, but the interface you're exposing is indistinguishable from that of a parser. For all your consumers know, you could be storing the username as a sequence of a 254-valued enum (one for each byte, except the angle brackets) and reconstructing the string on each "get" call. For more complex data you would certainly be storing it piecewise; the only reasons this example gets a pass are 1) because it is so low in surface area that a human can reasonably validate the implementation as bug-free without further aid from the type checker, and 2) because Go's type system is so inexpressive that you can't encode complex requirements with it anyway.

No, it's like saying you the employee are a separate entity from the company you work for. To say that Boeing is increasing profits suggests that they are raising prices, doing more business, and/or cutting costs. The article linked by the person you're replying to posits that airlines are actively weakening their own financial positions to increase leverage for shareholders, which is a different thing.

Not in all theory - Modern Monetary Theory[1] posits that if you control a mint, your money is effectively infinite and cannot be meaningfully increased. As such, some taxation truly does serve only as a money sink (but a necessary one that prevents runaway inflation in the face of government spending, as well as being a vehicle for incentivization).

[1] https://www.investopedia.com/modern-monetary-theory-mmt-4588...

What's better is largely unknowable if you're not collecting statistics to measure the impact of policy changes.

I think what they mean is: if you see a line like `import git.example.com/foo/bar/baz`, that could be package `baz` inside module `git.example.com/foo/bar`, or it could be package `bar/baz` inside module `git.example.com/foo`.

Also, even if you know it's the latter, package namespacing isn't strictly related to directory structure, so `bar/baz` has no specific meaning outside of the context of a go import. They could have used any other separator for package components - `git.example.com/foo:bar:baz` - but instead they chose the slash, making the scheme both technically ambiguous and easy to confuse for an HTTP URL.

Yeah, but it costs eight dollars to join.

The grammatical term for this is - perhaps surprisingly, for this crowd - "parallelism".

The "relevant From trait implementations" are the ones defined on the value wrapped by the Option or Result.

I've no horse in this race (not a homeowner), but Technology Connections has made a series of videos advocating heat pumps, most recently this one: https://www.youtube.com/watch?v=CVLLNjSLJTQ

The gist is that heat pump technology is continuously getting better at working in cold conditions, so if the horror stories are more than 5-10 years old they may not reflect the current state of things, and in extreme situations resistive heating can always be used as a backup.

Heat pumps are "just" air conditioners that point the other way, and AC is extremely common in the USA, so I'd doubt that the competency required is exceptional.