Type checking is not a panacea. You cannot use type checking to spot and fix all bugs.
Funny enough the problem you raised was trivially solvable by creating a BNF-like checker based on the spec for "THEIR" API response data.
YOU just didn't want to do it.
I'm pretty sure there are solutions at least in C++ and Java (eg. validate at the edge and convert it into a ValidatedString type and use this type throughout), but honestly, you seem like the type that complains about missing incoherent features that can be trivially resolved (and not recognizing that the "imperfect" parts being an inherent part of the problem as opposed to being a deficiency in tooling), so I'll just leave my comment at that.
> Type checking is not a panacea. You cannot use type checking to spot and fix all bugs.
I didn't say it was or it could.
> Funny enough the problem you raised was trivially solvable by creating a BNF-like checker based on the spec for "THEIR" API response data.
>
> YOU just didn't want to do it.
I didn't write the code, but if I did, I WOULD have used a NonEmptyString type for the deserialized result of the response body. That's... pretty much my whole freaking point here.
The "problem" is that my colleagues, as well as many, many, devs, including the ones at the company in question, are going to do the easiest thing they can. If your language provides String, and writing your own NonEmptyString type would require a bunch of boilerplate, most devs are just not gonna do it. "We'll never have an empty string here, anyway" they'll say. Until they do.
And, as I pointed out in another comment, I DO write these types in languages like Java. It's a ton of boilerplate and the language fights you at every turn. In Java, most texty APIs expect a String instance, which is a final class. So I have to wrap String with my class and convert to-and-from explicitly all over my code. Not to mention the performance overhead and optimization loss from wrapping a primitive type.
So, thanks for the condescending attitude, but I DO put my money where my mouth is and I still feel completely justified in criticizing the current state of software development tools.
If our tools and "best practices" are adequate, then how in the hell did Apple, a trillion dollar company, just release a version of macOS a year ago that literally had a calculator app that gave the wrong arithmetic answer if you used it too quickly?!
Every time I criticize software dev stuff and someone replies and tells me everything is totally fine, it only makes me stronger.
I'm rambling because our programming languages make it awkward, difficult, and performance-sub-optimal to do such things.
If you do what I often do, you have to wrap and unwrap your primitives explicitly so that you can use APIs that others have written.
You take a performance hit with all of the boxing and unboxing.
It's absolutely still a missing language feature if the language doesn't have ergonomic "newtypes". Just because it's possible to write a ton of poorly performing boilerplate to accomplish my goal of type safety, doesn't mean that I think we're done. You can do these things with essential zero runtime overhead and almost no boilerplate and friction in the code. It's entirely possible to do newtypes and refinement types in Rust, Haskell, D, Scala, even TypeScript. It's just that most of those languages are not very popular. TypeScript is the most mainstream of the lot.
I think "good programmers" are more of the problem than bad programmers. Good programmers are so used to these shit languages and all of their workarounds (excuse me: "design patterns") that they can't even see the forest for the trees and realize how tedious and stupid most of our work actually is. There's no Earthly reason it should take a million lines of code to write a CRUD app (I'm counting dependencies).
I sympathize if you put it this way. The boxing and unboxing of types can probably be done better in some languages. I suspect a well-optimized C++ compiler can probably make the perf cost mostly free if you give it the class the correct magic keywords.
It's just that you seem make a bigger fuss out of the problem than it actually is. Even with Java, there's boilerplate and some performance cost, but it's doable, and the real reason people don't do it (when they should) is because they underestimate the risk of making mistakes. (eg. Nobody uses JSON if the requirement is to squeeze out every single ounce of performance from the CPU, there are better binary protocols.)
Maybe it's indeed Stockholm syndrome, but I don't really see it as a problem of the "world at large". The tech is there, it's easily and freely available. Of course there's trade off between popularity and technical superiority, as always, but there's really nothing preventing you from writing Rust or TypeScript right now, if you feel strongly enough about it. So your job requires you to use a 3 decade old language? You can always change jobs or start your own thing using new tech. I mean, I'm using these 3-decades-old languages at work but at least I know it's a choice I make in exchange for decent pay and a stable job. Complaining about the lack of adoption of new tech (or coworkers not utilizing the type checking system properly) and then not taking proactive steps to fix the problem seems a tad bit hypocritical to me... The reason the world has not caught on with better tech is precisely due to the same reasons that you're not using it in the first place.
Funny enough the problem you raised was trivially solvable by creating a BNF-like checker based on the spec for "THEIR" API response data.
YOU just didn't want to do it.
I'm pretty sure there are solutions at least in C++ and Java (eg. validate at the edge and convert it into a ValidatedString type and use this type throughout), but honestly, you seem like the type that complains about missing incoherent features that can be trivially resolved (and not recognizing that the "imperfect" parts being an inherent part of the problem as opposed to being a deficiency in tooling), so I'll just leave my comment at that.