Yes, my presentation was centered around how Julia solves the Expression Problem, reusing material from Stephan’s “Unreasonable effectiveness of multiple-dispatch” talk. I’m pretty sure those concepts reached home with my audience. Nonetheless, some were uncomfortable with the possibility of type piracy.
I think this fear of type piracy is not really rational, but it does seem pervasive with software engineers, right up there with people having strong feelings about static type checking and types being attached to variables not values. That’s probably why Java has so many and such refined mechanisms for denoting and enforcing privacy. And why if you google for people ranting about Python, these kinds of things bubble up to the top.
There are many many different ways to shoot yourself in the foot while writing code, and the less obvious ways can be the worst. Encroaching on type privacy is something that people are clearly viscerally aware of, and so they tend to do the right thing without the language disallowing it; in other words you really need to go out of your way to engage in type piracy. On the other hand, failing to solve the Expression Problem produces an insidious, long-term tech debt situation where people’s code cannot be reused as much as it could, so package ecosystems tend towards large monolithic code-bases, whereas in Julia what grows organically are smaller packages that capture well-known mathematical and programming abstractions, that users and downstream package authors can mix and match.
I bet the tradeoff is clear for most julians, and I agree that it’s not really an issue in practice, but I wonder if forbidding type piracy would help with adoption by appeasing those who It scares.