Rust need a lot of extra stuff in function signatures to do its magic. Julia couldn't possibly do what Rust does because it doesn't have enough information
No. They didn't have to have a pub keyword, which takes space. They didn't have to have the ugly syntax to make functions generic: Julia's functions are generic without using those brackets. Rust didn't have to have explicitly needed return types, or having to have those fully specified.
So how do you make the difference between public and private code without a pub keyword? And for the "explicit return types", I think it makes the code more readable. You seem to think that what is your personal preference (something that looks like Julia) is best practice. It's not, it's just a preference.
Both Julia and Python has a concept of public and private code, neither have a pub keyword.
I don't believe Julia or Python is "best practice" over Rust. I even empathize with the opinion that explicitness may be preferential sometimes. But you _must_ be able to see how Rust's syntax overload obfuscates the core business logic, right?
The difference between pub in Rust and _/__ in Python isn't that big. It's like Go that uses a capital letter to say what code is public. There's also a difference in philosophy between public by default and private by default. All in all, it's a small detail and doesn't affect things.
Sure, business logic is more readable in something like OCaml than in Rust. On the other hand, Rust isn't really worse than something like Java, and I like having more information than what you have in Python. I'll also add that Rust is often chosen for speed and reliability, and that part of that syntax is here to guarantee that. It's not directly business logic in the traditional sense, but it's something you expect from your code.
All in all, Rust is still not at the level of the "platonic ideal for syntaxes", especially not for most of the code I write (business logic for web apps, which wouldn't need Rust's speed). Still, in the realms of programming languages that are used, it's one of the best.
> The difference between pub in Rust and _/__ in Python isn't that big.
FWIW `__` doesn't mean "this is part of the implementation", it means "I'm designing a class for inheritance and I don't want child classes to stop on my attributes".
> Both Julia and Python has a concept of public and private code, neither have a pub keyword.
No. Python certainly does not have a concept of private code[0]. The Python community has a suggestion of things being implementation details.
Surely you can see that absolutely would not be good enough for a language which strives for static correctness? And even more so as the soundness of `unsafe` blocks often relies on the invariants of the type it's used in?
[0] well that's not entirely true, I guess there's native code.
Fully specified function signatures are a conscious decision because it allows you to type check and borrow check a piece of code without needing to analyze the bodies of other functions. I also love it as a human because there is no guesswork involved.
Rust generics can be written in a more compact way,
fn f(x: impl Test) { ... }
Is basically the same as
fn f<T: Test>(x: T) { ... }
Having to annotate the return value of functions is partly to make sure don't break semver accidentally, but it also constrains type inference to a local search rather than global search, avoiding spooky action at distance (when modifying a function changes the signature of another function). It seems that semver hazards are more important in languages with static types.
That pub? It's punching waaay above its weight! Having things private by default protects against semver hazards too, but it's also the major tool that enable writing safe code that uses unsafe { .. } blocks underneath. That's because a single unsafe block typically taints the whole module it's contained (such that even safe code needs a safety review). Being able to write safe abstractions of unsafe code is the pull of Rust so people need to get it right.
For example, setting the field len of a Vec to a value larger than what's initialized in its buffer will cause UB when accessing that memory; if this field weren't private, making a safe Vec would be impossible (likewise, a function that could set the len to any value must be private, etc).
So pub can only be used for things that are safe to export, and people should be careful with that.
Here's my least favorite syntax from there: that damn Ok(..). Ok-wrapping sucks. There were proposals to remove it, but they were rejected. There's a library that removes it [0], and people should use it. It also makes the Result<..> return type implicit in the function signature too.
