FizzyOrange

Almost every good content creator is only on YouTube.

Nah Python is weird about static types - it only defines the syntax, not the semantics.

Ditch Mypy. Pyright is much much much better.

No I disagree. There are some things that it's really infeasible to use the scientific method for. You simply can't do an experiment for everything.

A good example is UBI. You can't do a proper experiment for it because that would involve finding two similar countries and making one use UBI for at least 100 years. Totally impossible.

But that doesn't mean you just give up and say "well then we can't know anything at all about it".

Or closer to programming: are comments a good idea, or should programming languages not support comments? Pretty obvious answer right? Where's the scientific study?

Was default case fallthrough a mistake? Obviously yes. Did anyone ever do a study on it? No.

You don't always need a scientific study to know things to a reasonable certainty and often you can't do that.

That said I did see one really good study that shows Typescript catches about 15% of JavaScript bugs. So we don't have nothing.

I disagree. Pyright has pretty reasonable inference - typically it's only containers where you need to add explicit annotations and it feels like you shouldn't have to - and it is extremely reliable. Basically as good as Typescript.

Mypy is trash though. Maybe you've only used that?

You'd be surprised. Every time I try to introduce static type hints to Python code at work there are some weirdos that think it's a bad idea.

I think a lot of the time it's people using Vim or Emacs or whatever so they don't see half the benefits.

I think we still must call this an “open question”.

Not sure I agree. I do think you're right - it's hard to prove these things because it's fundamentally hard to prove things involving people, and also because most of the advantages of static types are irrelevant for tiny programs which is what many studies use.

But I don't think that means you can't use your judgement about it and come to a conclusion. Especially with languages like Python and Typescript that allow an any cop-out, it's hard to see how anyone could really conclude that they aren't better.

Here's another example I came across recently: should bitwise & have lower precedence than == like it does in C? Experience has told us that the answer is definitely no, and virtually every modern language puts them the other way around. Is it an open question? No. Did anyone prove this? Also no.

To what? They don't really have any serious competition.

Just being open source doesn't guarantee a project's survival. If Google were to abandon it the most likely outcome would be a community fork that gets 100th of the development manpower it gets now, and most developers would abandon the platform leading to it's effective death.

But I also think it's unlikely Google will abandon it. It's actually quite good and quite popular now.

Definitely a high usefulness-to-complexity ratio. But IMO the core advantage of Make is that most people already know it and have it installed (except on Windows).

By the time you need something complex enough that Make can't handle it (e.g. if you get into recursive Make) then you're better off using something like Bazel or Buck2 which also solves a bunch of other builds system problems (missing dependencies, early cut-off, remote builds, etc.).

However this does sound very useful for wrangling lots of other broken build systems - I can totally see why Buildroot are looking at it.

I recently tried to create a basic Linux system from scratch (OpenSBI + Linux + Busybox + ...) which is basically what Buildroot does, and it's a right pain because there are dependencies between different build systems, some of them don't actually rebuild properly when dependencies change (cough OpenSBI)... This feels like it could cajole them into something that actually works.

Ah yeah I forgot about namespaces. I don't think they're a popular feature.

The other two only generate code for backwards compatibility. When targeting the latest JavaScript versions they don't generate anything.

Ok decorators are technically still only a proposal so they're slightly jumping the gun there, but the point remains.

No they don't. Enums are actually unique in being the only Typescript feature that requires code gen, and they consider that to have been a mistake.

In any case that's not the cause of the difference here.

Private or obscure ones I guess.

Real-world (macro) benchmarks are at least harder to game, e.g. how long does it take to launch chrome and open Gmail? That's actually a useful task so if you speed it up, great!

Also these benchmarks are particularly easy to game because it's the actual benchmark itself that gets gamed (i.e. the code for each language); not the thing you are trying to measure with the benchmark (the compilers). Usually the benchmark is fixed and it's the targets that contort themselves to it, which is at least a little harder.

For example some of the benchmarks for language X literally just call into C libraries to do the work.