The “bypasses” your first link talks about are mostly ways of telling the compiler about types. If I make an HTTP request, how is TypeScript supposed to know of the return type of some arbitrary API? That’s where as Foo comes in. If that makes a language not type safe to you, then you must also throw out the types in Java’s variable declarations.

Quite a few more of these ‘bypasses’ fall into the category ‘garbage in, garbage out’. If you declare a string index on an object that does not, in fact, return a value for every string passed, what do you expect the compiler to do about it? This is easily fixed by declaring the proper type Partial<{[key: string]: T]>.

If you declare a variable as an Integer and then let the database driver write a Person reference into that variable, Java will fail in the same way.

Some of these bypasses are just lies, like “delete operator - Remove required properties”. You cannot delete a mandatory property from a type.

One thing I grant you that I was reminded of while reading that article is this: Some constructs are simply not expressible in TypeScript (that I know of). For instance, an object that serializes to valid JSON. That could be used to introduce type-unsafety (or whatever the correct term is).

From your second link:

TypeScript is indeed type-safe

Thanks for disproving yourself, I guess.

The medium article contains good examples, if a bit contrived. Thanks for digging that up.

10MB? Oh no! How is this going to fit on my 1TB drive?

What you’re describing is not really an ‘any’ type in the code but garbage data. No language is going to save you if you read a file expecting a character but it’s actually an int.

I wish people downvoting literal case studies would at least give a reason…

I don’t understand how this would happen. If the any type truly “propagates through the system”, that means you’re passing around a variable of which you say, “I don’t know what this is. You deal with it.” How can you do any meaningful operations on it when you don’t know the type?

Explain or be downvoted

Well, the kernel is unmaintainably complex. Linux saves his sanity by not looking deeply into modules and only inspecting the surfaces.

One of the backend devs started using Kotlin. From time to time I need to read backend code, and I have to say it’s very easy to write an incomprehensible mess in Kotlin.

I’ve seen VSCode advertise this for setting up tests, but I haven’t been trusting enough to actually try it.

Does it work consistently?

I agree with the post. Setting up typescript takes an hour or two if you have no clue what you’re doing. In return you get the absence of (the equivalent of) null pointer exceptions.

I chuckle every time I find an NPE in the Java backend. Doesn’t happen to me. Can’t happen to me.

Sidenote, while I’m already gloating: Once the backend code had an error where they were comparing two different kinds of IDs (think, user ID and SSN), which gave wrong results. This error can’t happen to me either, because I type my IDs such that they are not comparable. A strong type system really is a godsend.

At my company we use M-Files, which is a document storage system that prides itself in not using folders. “No more searching for the file in thousands of folders”, they proclaim. It’s all a huge dump of files. To find files you need to tag them when checking them in. Later you search via these tags.

Guess what happens: All documents are either untagged or they’re tagged with wildly unhelpful tags. So in reality you can’t find shit. You can’t even make a sensible guess as to where a file might be and check the 3–5 folders that come to mind, because there are no folders.

M-Files is a black hole for information. No, scratch that. Even black holes radiate out the information they receive. M-Files doesn’t.

They have access to and depend on kernel internals

That sounds like a stupid idea to me. But what do I know? I live in the ivory tower of application development where APIs are well-defined and stable.

Thanks for explaining.

When people switch to Linux they don’t do a lot of research beforehand. I, for one, didn’t know that Nvidia doesn’t work well with it until I had been using it for years.

The driver needs to interface with the OS kernel which does change, so the driver needs updates.

That’s a false implication. The OS just needs to keep the interface to the kernel stable, just like it has to with every other piece of hardware or software. You don’t just double the current you send over USB and expect cable manufacturers to adapt. As the consumer of the API (which the driver is from the kernel’s point of view) you deal with what you get and don’t make demands to the API provider.

I don’t get what needs support, exactly. Maybe I’m not yet fully awake, which tends to make me stupid. But the graphics card doesn’t change. The driver translates OS commands to GPU commands, so if the target is not moving, changes can only be forced by changes to the OS, which puts the responsibility on the Kernel devs. What am I missing?

What “‘real costs’ in running GitHub Actions” are these dipshits even talking about? All they need to do is send a message to my runner. All the rest happens on my machine. Is the “real cost” pulling the latest changes?

MiCrOsOfT hAs BeEn A gReAt StEwArD oF gItHuB

You can use spaces in Python.

From the godfather Himself:

I’d like to point out (yet again) that we don’t do feature-based releases, and that “5.0” doesn’t mean anything more than that the 4.x numbers started getting big enough that I ran out of fingers and toes.

https://lwn.net/Articles/781206/

From kernel.org:

Does the major version number (4.x vs 5.x) mean anything?

No. The major version number is incremented when the number after the dot starts looking “too big.” There is literally no other reason.

https://www.kernel.org/releases.html#does-the-major-version-number-4-x-vs-5-x-mean-anything

ISO is a theoretical model on how things work, suitable for teaching and for reference. In reality, there are only 4 layers and not the finely chiseled concern-separating layers at the bottom.