I think it’s important to understand that there’s a design tradeoff here. Some languages (like Python or Lisps) allow the user complete freedom to do basically anything they want, at the cost of allowing them to do bad things. Meanwhile, languages like Java or Go will prevent you from doing bad things (like accessing fields) at the cost of burning you when you have a good reason to break the rules.
Those who are doing more exploratory programming are going to have completely different priorities to those building a banking system in a large team. As Julia is aimed at the former, it generally takes a “consenting adults” approach and opts for flexibility. For example: operator overloading is easy to abuse but essential for convenience when working with mathematical objects other than numbers. Macros introduce a higher learning curve but make custom optimisations easy. Access control helps encapsulation but will prevent you from writing a display system that does better than <Foo@0x5faf02>, or implementing automatic serialisation to JSON, etc. In each case Julia takes the opposite choice compared to Java-likes.
This doesn’t mean those issues aren’t valued at all. But it might mean taking a different approach, e.g. having field access be caught by a linter rather than enforced by the compiler. In the mean time you’re welcome to use PrivateRyan.