Ask HN: Which languages have better type safety than Java?

1 points by plugindev ↗ HN
After many years of Java development and at least a few years of hearing Ruby developers and others complain of the excess of Java's type safety, today I've come to the realization that actually by allowing an instance typed as a super-type to be cast as the implementing class type, Java doesn't go far enough in type safety. I know this isn't some new bright idea, but you don't hear it often, especially with so many that I talk to that are promoting duck typing. The problem with Java's type system is that it leaves the developer with a false sense of security that code that you've integrated with but "sneakily" cast to the instance that "always comes back, it just needs to be cast" can withstand updates to an external library that changes the implementation of the type that returns from a method. This didn't really bite me that hard when developing against most Java libraries available, because most of them are designed so that you don't have to cast as something else to get the job done. However, when you are dealing with a external libraries that comprise a huge, quickly evolving codebase and you are trying to maintain existing functionality, at some point they are going to change the class you use to an interface (which they did) and use the existing class as the implementation of the interface (which they did), and you will lazily just cast the instance returned from the method to that implementation, and you will get burned.

So that said, is there a language that really does type safety correctly and does not let you cast instances to a type other than (one of) the contractual type(s) defined by the method returning that instance, and likewise does not allow methods of accessing methods/data/implementing type on the implementing instance by default as part of the language?

0 comments

[ 3.8 ms ] story [ 8.3 ms ] thread

No comments yet.