Hacker News Reader

Comment by stmw | Hacker News Reader

Good article, although there are also some unforced errors of what Rust community calls "ergonomics" - many of which have been addressed, and hopefully many others will be soon - that make things more difficult to learn than the absolutely have to be. But author is quite correct that some things are just hard, and if a language is being "honest", it must expose them to the user.

View on HN

What we could do better than we do today - and your comment about ergonomics alludes to our work to improve this - is ease the onboarding of that complexity we have to be "honest" about. Its a design constraint of Rust that it must maximize user control, but that does not imply that users have to be faced with all of those choices as soon as they first try to write Rust. In some respects I think this article is an attempt at a counterargument to that work (suggesting that it is "dishonest") but I fundamentally do not believe that there is a contradiction between giving advanced users control and making it easier for new users to write correct code before they have a full understanding of the entire system.

Indeed, I used the term "ergonomics" specifically as such an allusion. But I am not sure I read the article as claiming that such efforts are "dishonest", I instead see it as a reference to some other languages and runtimes that run up technical debt for the sake of easy living in the short term.

I would like a language that has knobs (e.g. file-level pragmas) for strictness, which you could turn all to one side (to get something as strict as Rust) or all the way to the other side (to get something like Ruby) or somewhere in between.

For example, a REPL would be pretty non-strict: When you define a function, you don't have to annotate types on the arguments, and everything gets passed around as generic objects. However, the standard library would be pretty strict [1], so in your unstrict REPL code, types are checked (and implicit clones are made to satisfy the borrow checker) as soon as you call into the strict code.

[1] In fact, the package repository for this hypothetical language (the analog to crates.io etc.) should only accept strict code, or alternatively put HUGE warning signs on libraries that contain unstrict code.

So Rust has a lot of that, both in turning off some checks and in ability to write whole blocks of unsafe code.

For the record, in PL jargon, "strictness" commonly refers to how soon the arguments in a function call are to be scheduled for evaluation. Using it to talk about the extent of static correctness checks can be slightly confusing!

I worked on some small learning projects in Rust about 6 months ago. When I got compiler errors related to the borrow checker and concurrency, I found that it was often easiest to look at whatever variable or function the compiler was pointing to, and then ask myself what could possible go wrong that would somehow fall under the purview of the borrow checker, because the actual error messages didn't always point to the root of the problem.

I don't have the specific examples anymore, but I think my errors were caused by things like passing around or trying to mutate references created from a data structure inside an Arc pointer or safety issues relating to unscoped threads. At the time, I felt like those things would have been very difficult to debug from the compiler errors alone if I hadn't had past experience with those same issues in other languages (which is what the article says about needing to learn quite a bit about writing programs correctly)

Reply on news.ycombinator.com