salmonellaeater

I've found the opposite. Go doesn't even have sum types, so it's hard to use constructive data modeling techniques to model the domain. The only tool available for ensuring exhaustive handling of all cases is interfaces (Visitor pattern) which is verbose.

The transit agency will choose more expensive features that do not meet a 1x ROI but do meet a 5x ROI.

It's the wrong architecture from a dependency management perspective. Directly importing a table into Iceberg allows analytics consumers to take dependencies on it. This means the Postgres database schema can't be changed without breaking those consumers. This is effectively a multi-tenant database with extra steps.

This is not to say that this architecture isn't salvageable - if the only consumer of the Iceberg table copy is a e.g. view that downstream consumers must use, then it's easier to change the Postgres schema, as only the view must be adjusted. My experience with copying tables directly to a data warehouse using CDC, though, suggests it's hard to prevent erosion of the architecture as high-urgency projects start taking direct dependencies to save time.

If the LLM was as smart as a human, this would become a social engineering attack. Where social engineering is a possibility, all three parts of the trifecta are often removed. CSRs usually follow scripts that allow only certain types of requests (sanitizing untrusted input), don't have access to private data, and are limited in what actions they can take.

There's a solution already in use by many companies, where the LLM translates the input into a standardized request that's allowed by the CSR script (without loss of generality; "CSR script" just means "a pre-written script of what is allowed through this interface"), and the rest is just following the rest of the script as a CSR would. This of course removes the utility of plugging an LLM directly into an MCP, but that's the tradeoff that must be made to have security.

What are some personal applications you created to fill these gaps?

I think OP was saying those three things were surprisingly dangerous. Kids have a natural fear of heights and falling, while the three on the list not so much.

Where this kind of API design is useful is when there is a user with an agent (e.g. a browser or similar) who can navigate the API and interact with the different responses based on their media types and what the links are called.

Most web APIs are not designed with this use-case in mind. They're designed to facilitate web apps that are much more specific in what they're trying to present to the user. This is both deliberate and valuable; app creators need to be able to control the presentation to achieve their apps' goals.

REST API design is for use-cases where the users should have control over how they interact with the resources provided by the API. Some examples that should be using REST API design:

  - Government portals for publicly accessible information, like legal codes, weather reports, or property records

  - Government portals for filing forms and other interactions

  - Open data initiatives like Wikipedia and OpenStreetmap

Considering these examples, it makes sense that policing of what "REST" means comes from the more academically-minded, while the detractors of the definition are typically app developers trying to create a very specific user experience. The solution is easy: just don't call it REST unless it actually is.

A useful error message would have made this a 1-minute investigation. The "fix" of trying to detect this specific program is much too narrow. The right fix is to change Yarn to print a message about what it was trying to do (check for a Sapling repo) and what happened instead. This is also likely a systemic problem, so a good engineer would go through the whole program and fix other places that need it.

> I found that there’s a slight aversion to creating new types in the codebases I work in.

I've encountered the same phenomenon, and I too cannot explain why it happens. Some of the highest-value types are the small special-purpose types like the article's "CreateSubscriptionRequest". They make it much easier to test and maintain these kinds of code paths, like API handlers and DAO/ORM methods.

One of the things that Typescript makes easy is that you can declare a type just to describe some values you're working with, independent of where they come from. So there's no need to e.g. implement a new interface when passing in arguments; if the input conforms to the type, then it's accepted by the compiler. I suspect part of the reason for not wanting to introduce a new type in other languages like Java is the extra friction of having to wrap values in a new class that implements the interface. But even in Typescript codebases I see reluctance to declare new types. They're completely free from the caller's perspective, and they help tremendously with preventing bugs and making refactoring easier. Why are so many engineers afraid to use them? Instead the codebase is littered with functions that take six positional arguments of type string and number. It's a recipe for bugs.

My initial interpretation of the title was that the TS team was adding support for another, faster, target such as the .NET runtime or native executables. The title could use some editing.

No.

You seem to be referring to runtime performance of compiled code. The announcement is about compile times; it's about the performance of the compiler itself.

This is a bad article. There are two issues that are being conflated: collusion, and algorithmic pricing. On top of this, the author is either ignorant of economic principles, or is deliberately avoiding using economic analysis.

Collusion is already illegal. If RealPage is facilitating collusion, then they and the participating landlords should be prosecuted. RealPage seems to be in a strange and novel business where they're recommending prices that might not be the best for their customers, the landlords. This seems a lot like collusion with extra steps. If they're actually recommending prices that maximize profits for each customer individually then that seems fine.

A quote from the article suggests that RealPage is being used in real estate companies by upper managers to guide and oversee the work of their reports:

> If a property manager disagrees with the price the algorithm suggests and wants to decrease rent rather than increase it, a pricing advisor will “escalate the dispute to the manager’s superior,” prosecutors allege in the suit.

This... is fine as long as the price being recommended is in the best interest of the real estate company rather than RealPage.

Algorithmic pricing is a perfectly normal extension of basic business management. A real estate management company could achieve the same thing that RealPage is doing (aside from collusion) by buying data from other companies and using some fancy math to choose the best rental prices.

The article makes a claim that isn't really substantiated:

> The complaint names specific areas where rents are artificially high.

> In the second quarter of 2020, the average rent in San Diego County was $1,926, reflecting a 26% increase over three years, according to the San Diego Union-Tribune. Rents have since risen even more in the city of San Diego, to $2,336 per month as of November 2024 – up 21% from 2020, according to RentCafe and the Tribune. That’s 50% higher than the national average rent.

This is a non sequitur. How San Diego rents compare to the national average doesn't tell you anything about whether rents are artificially high. San Diego is a desirable place to live; maybe the rents are artificially low and really should be 2x the national average! What would tell you that is whether landlords could make more money by lowering rents. This would only make sense if occupancy rates are low and landlords could fill more empty units by lowering rents. It wouldn't necessarily make sense even if occupancy rates are low, as high prices filter out bad tenants who cause damage and other costs and can't compensate the landlord because they don't have money. In some markets filtering out these bad tenants can be worth it even if units go empty. California has really poor protections for landlords against bad tenants, so I wouldn't be surprised if higher prices and lower occupancy rates was the correct business decision for landlords there.