Overflows are a major source of security vulnerabilities. NULL values are a major source of logic bugs. Data races are the most common bugs in parallel and concurrent applications.

There is no real argument why programming languages as tools should stop at the level of "well you can't put a string into an int".

Is there really a way around this? overflow should be an error in most languages - but isn't for a variety of reasons such as simplifying the construct

c = a + b

In a language without native memory management, it's rare that this type of bug could lead to disclosure of sensitive information. In the cases it would, it's easy enough to guard the overflow with a test such as if (MAX_VAL - b) < a then error.

Chasing safety features which result in difficult to reason about semantics will inevitably lead to low language adoption. I'd be very interested in approaches which guard difficult cases while maintaining ease of use. I'd love a statically typed language which automatically increases the size of numeric type on over/underflow.

> overflow should be an error in most languages

> Chasing safety features which result in difficult to reason about semantics will inevitably lead to low language adoption.

Python solves this problem by not having overflow for integers at all, instead all integers are unlimited. It's still one of the most widely used languages in the world.

true, however python doesn't have static typing. It would be interesting to see more static languages adopt a "Number" primitive.

Haskell has it as well, in a very clever way in my opinion. Number literals don’t have a type themselves, they are inferred to be the correct type based on context/available type notations, etc.

There is both a 64bit integer type and an “infinite” one, and you can change the implementation by a single type notation, in a completely safe way.

And they are mostly niche ideas that in practice gives overly verbose code filled with boilerplate making it just as insecure as languages that take a more pragmatic approach.

Named arguments are in a lot of modern languages: Python, Kotlin, Swift, Javascript*, probably others.

* APIs often do something similar by passing in an object with optional fields*

> Javascript, > APIs often do something similar by passing in an object with optional fields*

That's really not the same as the others though, as it's a convention. That's arguing that passing a Python dict or Namespace to a function is the same as named arguments in the function's definition itself. You can do the same in Java with Dictionary<string,object> if you want.

I wouldn't call that the same. In Typescript the arguments object is fully typed, while in Java you lose all typing.

They are but ultimately the author wish that their usage is enforced. And that is IMHO in no major language including the above.

(Nitpick, but is python a modern language? It is almost a decade older than Java)

Definition question. It fits if you use "languages that appeared after or incorporated features from younger languages in newer versions".

Also 4 years older, not a decade.