[otde]

Speaking as someone who started in Java and moved to Julia, my experience has been that a lack of concrete subtyping has generally not made an impact on difficulty with respect to problem modeling (at least, not relative to Java or other languages with concrete subtyping). Moreover, some of the emergent properties of Julia’s type system (the “Tim Holy Trait Trick,” etc) enable problem modeling in different — and perhaps more “Julian” — ways, modeling by behavior rather than structure.

That said, if you absolutely need concrete subtyping in Julia, you can emulate it for structure with the tricks described in this (old but gold) Chris Rackauckas blog post: https://www.stochasticlifestyle.com/type-dispatch-design-pos...

[foerbert]

I spent far too many hours of my life writing a far too long response to another comment. Some... portion of it touches on some of this. I can't in good faith suggest reading it, but you could.

But the more specific and quicker version - I don't find Java is typed the way I want either. It seems to somehow find a way to be too much and not enough. I also don't do a lot of Java, so YMMV. Specifically I'm thinking of Ada when I start comparing type systems, if that helps.

I'd need more brainpower and probably Julia chops to give those a real shot. However I started to get a 'build your own type system' vibe from some of what I was seeing while nearing the end of that gargantuan post. This feels like some initial level of confirmation, so yay?

I'll give it a look later. I'm curious how far you can integrate it with external code, what sort of guarantees you get in practice, and how much it requires doing 'the right thing.'

Maybe in practice the way dispatch works ends up taking care of more problems than I'd expect, but also seeing the fairly widespread use of implicit conversions makes me a bit concerned. Again, maybe a thing sidestepped by other factors.