I work in Fintech, and we use Python with type checking. It works like a charm. Safer than Java.

That was a fun one, being safer than Java.

Since we are at it, faster as well.

Not as fun as still having no null safety in Java.

As if Python was any better in that regard, as dynamic language.

Python with type checking is statically type checked. So yes, Python with type checking is better in that regard. And it's safer than Java because there are more classes of errors that Python with type checking will pick up during static type checking than what the Java compiler will pick up.

If Python with added sugar counts, same goes to Java with added sugar.

Can you name any tool that adds static null safety to Java?

JSpecify does. And the work for adding null restricted types to Java has already started:

https://openjdk.org/jeps/8303099

Thank you for sharing this, I was unaware of this and it does seem very promising. I hope that the JEP gets done soon.

As this is, in fact, tacked on, I guess you don't really get much benefit unless you rewrite all your code with these still non-standard annotations.

It does not seem like pointing JSpecify at a standard spring boot codebase will do anything for you. Whereas pointing Mypy to a standard Python codebase will type hints will do something for you, as null safety is not tacked on but baked in for python type hints.

Also, the syntax seems awkward and clunky as heck, but I guess for something as essential as null safety it's worth it.

---

From JSpecify, I found the Checker Framework, which also seems really interesting and seems like it supports checking for more types of annotations than just JSpecify annotations. https://checkerframework.org/

> Whereas pointing Mypy to a standard Python codebase will type hints that conform to the language spec will do something for you, as null safety is not tacked on but baked in for python type hints.

That is if you wrote your code base with type hints, just like if you wrote your codebase with jspecify annotations.

You cannot "point" JSpecify to anything. It is a standard like PEP 484, but much smaller, because everything else is already part of the language standard.

How did you do typing? Was it 'hints', or some other outside option.? It always seemed to me that since it isn't baked in, that it comes down to organizational discipline.

We run mypy with `--strict` mode in CI, which means it only passes if we have type hints and if they are correct, or if we have added `# type: ignore[code]` for places where the errors are reported.

And the type hints and behaviour are specified as part of Python, so it's kind of baked in. It's just that the actual type checker is not part of CPython, though Mypy is considered the reference implementation.

We have quite a large code base and very few `# type: ignore[code]` directives.

Some third party code still has poor type hints, but for the most part it's fine, and we get null safety which you don't get for Java.

SonarQube/Checkstyle/Kotlin/Scala sugar > Mypy sugar

Type hints and their behaviour are part of the Python language. Kotlin and Scala is not Java. I did not know that checkstyle + SonarQube adds static null safety to Java, but I appreciate that you will share a citation that it adds static null safety. I think everyone coding Java should really learn to use this so they don't create null pointer exceptions.

It's been years since typing was added to Python, and many people still underestimate it. You're right; Python with strict type hints is more type-safe than Java and Go. It even has features like pattern matching and proper enums, both of which Go lacks.

The only issue is that some libraries (not many!) are still untyped, so you may need to write wrappers or stubs occasionally. But that applies to a small and decreasing minority of libraries.

I only wish Python were faster and had ahead-of-time binary compilation.

Python sure is slow. It's not that big a problem most of the time, but once it becomes relevant, it becomes super relevant. The lack of AOT binary compilation also is very annoying.

You should give Julia a go, can be written completely static if desired (not as static as rust of course, but compared to python it’s miles ahead). Can be made fast, very fast. AOT compilation with trimmed executables is coming in 1.12

Doesn't Julia suffer from very long startup times? One of the things I use Python for is CLI programs. The startup time isn't great either, but Julia was even worse last I tested.

Julia v1.12, the unreleased version which is currently in release candidate stage (and has had a longer RC stage than expected but should be done at least by the end of the year) has the ability to fully ahead of time compile and generate binaries, like you would expect from a language like C. It also trims these binaries so that they are a reasonable size given the elements of the runtime that are used. Thus for good type-stable code you get callable binaries without JIT overhead, and this leads to a much better CLI experience. It will take a bit of time so that there's more package tooling and support built around this feature, but this is the path a lot of the ecosystem CLI tooling is now going and that will be a pretty dramatic shift in the usability for these kinds of use cases which Julia had traditionally ignored.

aot will help a lot. In cases of simple programs you can also start Julia with no optimizations, which trade off the startup latency for runtime speed.