regular_trash

Well clearly. But the above comment was about jobs that didn't exist before AI that AI will lead to the creation of.

Tiktok arguably led to more datacenters being created, AI is not unique in this regard and it's silly to imply that datacenter jobs meaningfully contribute to employment on the same scale as the loss of jobs AI could potentially lead to.

I think the problem is primarily if you publish a REST api for commercial consumption on some level. If people depend on your REST api, the "RESTfulness" of it affords you some level of inaccuracy when documenting how things work.

But that said, I'm okay with it not following the spec as long as things are clearly documented to end users. We just went through an issue where a prominent CDN provider exposing a REST API we depend on broke REST in a very important way (i.e. NOT stateless). It's extremely annoying to try and construct clients around nonstandard APIs, and the more REST-y, the less annoying.

Well that's a pretty contrived example. There are fair amount of requirements that can be predicted as "possibly coming" in a given problem space, and a good design typically takes them into consideration and plans contingencies such that a design doesn't crumble.

Clearly lol. I think a good-faith interpretation of the question is: "What kinds of things is go's concurrency model suited for where the normal pythonic alternative is cumbersome/less desirable"

It actually is a paradox, a veridical paradox. But I'm splitting hairs lol

This line of thinking necessarily throws out any formal systems of reasoning humans have adopted. E.g. belief in a divine creator gives little reason to believe that Newton's First Law is eternally consistent if an omnipotent being could change the "rules of the physics" at any point.

It's not even a proper argument if you think about it, because you are essentially positing logic/reasoning aren't sufficient to comprehend the reality we live in.

I'm not convinced jobs will be axed in the long-term - All the big tech companies frequently staff teams on projects that basically go nowhere to spread bets on multiple projects in case one has legs. Once LLMs reach the point of commoditization and drop in price, it seems like the natural next step is more teams with smaller structures to spread bets even more. A 5 person team that is LLM-assisted is going to move faster and be more cohesive than an 10 person team that ends up stepping all over each other.

One of the many things that has been strange to me is how often people will label written thoughts as AI slop when the "signs" are just normal phrases. Sure, that's a tired expression, and I 100% agree we should be critical of writing that seems to embolden pointless trite expressions. But people have written in that way for years before LLMs.

I find it very interesting that we only now have more widespread discourse around the quality of prose and rhetoric now that LLMs have become ubiquitous.

Well this is not the context I had in mind. I'm thinking of the many times I've had to break apart 3kloc react components to reuse some part just because someone decided modularity didn't matter

Hot take - I hate YAGNI. My personal pet peeve is when someone says YAGNI to a structure in the code they perceive as "more complex than they would have done it".

Sure, don't add hooks for things you don't immediately need. But if you are reasonably sure a feature is going to be required at some point, it doesn't hurt to organize and structure your code in a way that makes those hooks easy to add later on.

Worst case scenario, you are wrong and have to refactor significantly to accommodate some other feature you didn't envision. But odds are you have to do that anyway if you abide by YAGNI as dogma.

The amount of times I've heard YAGNI as reasoning to not modularize code is insane. There needs to be a law that well-intentioned developers will constantly misuse and misunderstand the ideas behind these heuristics in surprising ways.

Stuff like this is very common. For example, at the start of Trump's second term, the whitehouse history page was changed to make democrat presidents look bad -

https://www.whitehouse.gov/about-the-white-house/the-white-h...

Can you elaborate? This seems like a simple mistake if they are incorrect, I'm not sure where 33% or 50% come from here.

The distinction between rent/own is kind of a false dichotomy. You never truly own your platform - you just "rent" it in a more distributed way that shields you from a single stress point. The tradeoff is that you have to manage more resources to take care of it, but you have much greater flexibility.

I have a feeling AI is going to be similar in the future. Sure, you can "rent" access to LLM's and have agents doing all your code. And in the future, it'll likely be as good as most engineers today. But the tradeoff is that you are effectively renting your labor from a single source instead of having a distributed workforce. I don't know what the long-term ramifications are here, if any, but I thought it was an interesting parallel.

Before I got into software development, I worked at a company doing technology-adjacent things. Nothing too fancy, but I got to improve a lot of things just by knowing a little powershell.

One day, a senior developer there - a guy very fond of music - was showing me his process for converting a text file into SML. His process consisted of opening two notepads: one with an SML template block, and one with the text file to be converted. He then proceeded to convert each line into SML by copying the prefix tags and postfix tags and pasting them around each line.

I wrote a powershell script in front of him to automatically do that and save an entire days worth of work, and he just stared at me. I had removed the one really mindless part of his job that he could use as an excuse to listen to a TON of music. Needless to say, he never used the script.

Reflecting on this, I feel fortunate to have had this experience early on - it really helps put things into perspective - perceived improvements to anything depend entirely on the workflow of the people impacted.

Rust is an unergonomic language that slows development in the general case (because it has lots of arcane syntax and rules, and people generally don't know it). Suggesting it as the "obvious" choice ignores the tradeoffs that come with adopting it for a project.

I disagree that this is an issue in every language - the problem is that in other languages the validation against some schema is more or less required for unmarshalling, and it's optional in TS.

Seeing a deserialization error immediately clues you in that your borders are not safe. Contrast that with TypeScript, where this kind of issue can lead to an insidious downstream runtime issue that might seem completely unrelated. This second scenario is very rare in other languages.

It's a lot more effort, but branded types for conceptual differences can bridge that last gap

Not parent comment, but TS is generally safe if you have types correct at system borders, but very scary when you don't. Some of the most impactful bugs I've seen are because a type for an HTTP call did not match the structure of real data.

Also, many built in functions do not have sufficient typesafey like Object.entries() for instance

I think the point was that they are contradictory, yet "data" was shown to indicate they were each sound decisions, implying an inherent dishonesty and willingness to bend data to support an already drawn conclusion.

Not sure if it's just me, as I'm relatively new to the field, but I notice a surprising amount of people assume that the details in programming have already been made intuitive to them, and they use this "experience" to push ideas that are at odds with other domain specific details. To me, maybe this is what the author means by "stuck"?

At any rate, great read.

Wouldn't this complicate variable binding? I'm unsure how to think about this kinda of syntax if either D or E are expected to return some kind of data instead of "fire and forget" processes.

This is a foolish consistency, and a contrived counterexample. Consistency is not an ideal unto itself.

Excalidraw

There are usually flights from hub to spoke, and spoke to hub, and each one will have the same number. This is within a 24 hour period. 3934 is one such flight between PHX and SEA.

The misconception here is that Flight numbers are not treated as IDs. A unique key to any flight is the composite of number/origin/departure date.

And it's mostly a holdover from legacy systems airlines are entrenched in, so there isn't much else anyone can do here short of completely reinventing the mainframe reservation systems and heavily refactoring all the pieces that depend on it.

If the problem is pervasive as made out to be, it stands to reason that a person would have at least one anecdotal experience in favor of the claim.

This is specific to the act of learning a language, where writing out the characters with intentionality will obviously have more carryover to memorizing the forms of such characters.

When the learning tools are detached from the subject at hand - as is the case in most college classes where basic literacy is a given - it's hard to see how one particular tool could possibly be better than others.

Turrles all the way down

I don't think you have to have malice in mind to see it in that way. It's more like: This is a company, and they have to make money. And it isn't a far leap to assume the margins come from exploiting the mismatch between value of labor across countries borders.

Hard disagree. Abstractions are nice when they match the mental model of a problem domain, but the odds you have the right set of abstract primitives in mind from the outset is practically 0.