Depends on if you identify it early enough really and even then halving your app tier costs could be sizable for any company. If you can get some productivity benefits at the same time from say static typing then there's even more reason to switch.

I've observed the weird phenomenon that any valid criticism of Python is treated as either some kind of personal attack or because you're a mad static typing ideologue.

To be honest I feel like most criticisms against any languages are bound to sooner or later be met with the response "well, this is how this language works, and if you don't like it pick another". If you criticize a weakly typed language for an issue that is solved by strong typing, you could even argue that they are correct in saying so, unless you come up with a way to solve it without types.

I suspect that the reason that it's so common to be initially suspected of being an ideologue is that there are so many out there, and they are very vocal compared to the majority that often couldn't care less. So if you don't come up with alternate solutions, maybe the tendency is to assume you're getting at the old trope they've already heard before.

Adding to the list “oh if it’s not fast enough, just write it in C”

As if wishing for any performance that’s an improvement on bottom-of-the-barrel is some kind of wild, unreasonable ask for which the solution is “write it in a language full of pitfalls, sharp edges and an even worse packaging and developer experience than the current one? Seriously?

If you think that's hard don't look at the types for any moderately complicated JavaScript project.

What? I've worked in a whole bunch of languages and I tend to find that Haskell is the easiest on this front. Hackage has all the definitions for packages cross linking to each other.

Types for checking things are correct is really important which is what this talks about.

For me though they really come into their own when those types then help to eliminate boilerplate. Haskell's foldMap function is my classic example of handling the accumulation of a result where it does the hard work based on the types. Idris goes even further by supporting the ability to infer obvious code for your code editor like handling each case in a sum type.

Surely helping prop up iMessage is a terrible idea? Especially if it still has that "feature" where if you switch from an iPhone to an Android phone the messages aren't sent to your phone for a while?

I think characterizing this as having any effect of “propping up” iMessage is laughable. To call it a “terrible idea” is unfair to the project creators. They’re solving a problem people have, they’re not the cause of it.

But the problem stems from their use of iMessage and Apple not doing an Android app.

> if you switch from an iPhone to an Android phone the messages aren't sent to your phone for a while?

Apple set up a page years ago that lets you manually disable iMessage to avoid this issue.

And yeah, I personally dislike iMessage as a concept. But I use it a lot every day and it’s simply better than SMS. So I don’t blame the creators for doing what they’re doing.

> Apple set up a page years ago that lets you manually disable iMessage to avoid this issue.

Exactly, why is a page needed in the first place? I'd bet more than 99% of users don't even have a clue that exists or even know about the underlying problem.

The page is needed because Apple has no way of knowing whether you have turned your iPhone off for a couple of days or whether you’ve switched away permanently. It isn’t necessary if you do a factory reset of the phone, which also covers a lot of bases.

Because of the way iMessage is designed though, it just happens to benefit them by making any other platform look broken if you don't do these steps. They worked with the mobile companies to get visual voicemail support, why not for this?

How many regular users do neither of these things and just shove their old phone in a drawer or let their kid watch YouTube on it?

Any company with a load of binaries built without any effort towards supporting cross platform builds that uses Docker is gonna have a bad day with this. They buy a bunch of new MacBooks and then find they can't use them until they spend a few weeks porting everything.

I suppose that depends what they’re written in. Some languages (e.g. Go) far simpler than others.

I've found it to be easy to work personally, if you want long names of functions in your code if it helps you should. Common libraries might not have long names for functions, but you'll find the same thing for the most part if you look at the API of collections in various languages for example.

Oddly now I find it really legible compared to other languages, you can still make things obtuse if you really want to, but the flow seems so much clearer.

I would say compared to Java (as you mentioned it) there's much less separation because things invariably gravitate towards big balls of mud containing lots of state. But in Haskell the function you're looking at is only tied to the functions and data types it uses, no more, no less.

Already handled in NixOS by Nix.

Not sure about daily signal failures, even when I commuted daily it wasn't near that bad. The idea of powering such a safety oriented system with JavaScript quite literally terrifies me, I'd expect it to be about 30 minutes before two trains collided.