tristanstcyr

I don't think that doing so across architectures is a major goal.

Language servers could still do this by reusing AST manipulation libraries behind the scenes.

From what I understand, the idea of "empty" no longer makes sense at that level. All you have are fields. There, everything is made out of fields and fields are everywhere. There is therefore no "empty" really anywhere, including inside yourself.

I agree that this isn't totally specific to JavaScript. It's just that the ecosystem is very extensive and so there are a lot of packages, because you don't need to write your own code for a lot of existing problems.

There is perhaps a something about the JavaScript audience tending to attract less advanced implementers. So you end up with a lot of otherwise considered trivial and low-quality utilities being published and pulled down from the registry.

Rust and Go tend to be for more advanced scenarios where things like performance, security and support matters tremendously.

React would normally be a peerDependency and so you shouldn't run into this problem if dependencies are specified properly.

If not, NPM module flattening should take care of it.

Then worst case, you can also tell webpack to bundle a specific installation.

There are some ways to solve these problems...

If you properly do validation at runtime this can be true, but it's a manual process that's not verified by Typescript.

It does not.

I think that this ship has sailed quite some time ago. For example, inner classes which were introduced in Java 4 (if my memory serves right).

That's an idealistic argument. Sometimes you just need to delete things and there's no negotiation possible.

Whether that makes sense to you or not as an engineer or scientist doesn't matter much. There are tons of things that humans want that "don't make sense" but that you need to conform to regardless. A great example of this is typically the law.

Is this because both languages are from different eras? When did you last see a consumer ad about scripting?

Try working with a large 5 year old JS codebase that's been hammered on by dozens of devs. The problems are no longer just pin point bugs but a systemic lack of modeling.

Static typing is not that much about preventing bugs but more about forcing the code to operate over a well defined model.

Can you write good code without static typing? Yes. Can you scale and maintain it in a large organization, probably not.

Rather facile advice.

As a software engineer, it's your responsibility to build the product according to the requirements. Sometimes that means it needs to be built it quick because it's likely to have a short life, or it needs to land quickly to market. Sometimes, you need to get things right, otherwise you end with an insurmountable amount of technical debt and a business that grinds to a halt.

Given this, you should make the analysis to understand the tools that you need. If that means learning, then so be it. Maybe you can keep going with superficial knowledge. Or, perhaps you need to find an expert, that's fine too.

As for growing in your technical knowledge, that should be agreed upon with your employer or whoever is paying for the work. If you find that you work somewhere that doesn't allow you to learn then perhaps it's not the right place to be.

Think like a professional.

The reality is that the atomic family model is antiquated. In our society, the individual is the unit We must therefore make the individual strong, meaning that we need to support both parents independent all the while having children.

We can observe that the old model was better in terms of a certain metric, but that's not going to help. We need to invest in making child rearing effective in today's world.

It's not that it's a failure, it's that being taken out of the workforce for many years is damaging to careers. It's more than a matter of perception. Public school starts when kids are 5. If you have several kids, it could then take someone out of the workforce for a decade. While it's not impossible to recover from that, it's extremely difficult, especially at a point where you're past your prime years such as your 20 or 30s.

Sure, but it comes at a cost. Companies rarely push the limits of these kinds of policies because customers are not willing to pay for them.