Comment by Annatar | Hacker News Reader

Comment by Annatar | Hacker News Reader

In today’s Rust, this would be an error, you need to write (e.f)(); At least the error tells you exactly what to do!

If the programmer knows what the error is, and how to correct it, then their program should automatically do so, rather than molesting the user, as the purpose of computers is to speed up and automate. Why should the user have to foot the designers' bills?

Another cardinal sin and a sign of lack of thinking things through is breaking backward compatibility, like the example above: imagine you were an early Rust adopter, and wrote a non-trivial application in Rust; now imagine that the newest Rust compiler has several major performance and efficiency gains. It is understandable why one would want to re-compile one's application with the newest compiler, only to be thwarted by the authors' lack of understanding of just how important not breaking users' applications is. That is one of the core differences between engineering and hacking. What other land mines await potential Rust adopters from programmers who do not have any respect for their users' time?

> If the programmer knows what the error is, and how to correct it, then their program should automatically do so, rather than molesting the user

But then the meaning of that syntactic construct differs contextually. Even if it could be parsed efficiently, it still goes against Rust's principal of favoring explicitness over convenience.

> Another cardinal sin and a sign of lack of thinking things through is breaking backward compatibility,

The examples Steve cited span throughout Rust's history, way before any commitment was made to backwards-compatibility. These sort of changes won't happen anymore (it'd require a "Rust 2.0").

It's not the job of the compiler to speed up and automate _editing_code_. That's the job of an IDE. And we have a unfolding story for that: Rust Language Server, or RLS for short, which is a package providing pluggable Rust IDE-functionality for all kinds of text editors.

Besides, the change we are talking about happened 4 years ago, when Rust emphatically did NOT have any compatibility guarantees and was in a process of rapid experimentation. This has changed a whole lot – it's a stable language now, and has been for a year and a half.

It's not the job of the compiler to speed up and automate _editing_code_.

Calling changing the syntax on unsuspecting users _editing_code_ is really a stretch of gargantuan proportions. And I don't really care whether it's the compiler, the linker, or mega_mojo-2.546-alfa5-preview18, what ever it is, it runs on a computer so that whatever is being done would be fast, automated, and therefore efficient. If the programmer knew what to do with the input, the computer should churn through it, instead of chastizing the user and making them pay for the authors' oversight.

Otherwise, a computer makes no more sense than a toy does.

If I want to use a computer as a toy, I'll go play a video game. The rest of the time, it's a tool, a tool to do something an order of magnitude faster than a human could. If it slows me down because it requires me to babysit it, I have a problem.

That's all well and good if the context is unambiguous, but if it isn't, people will get used to having this done for them (or not even know that it happens at all), and then be totally perplexed. Worse, maybe then people want even ambiguous situations to be made friction-free, so the compiler must guess. Then you've got the possibility of very confusing behaviour, doubly so if the ambiguity involves any kind of polymorphism (different, possibly contradictory behaviour per type!)

Reply on news.ycombinator.com