Dave Herman’s contributions to Rust

This is quite contradictory and proves my point.

I'd love to see an interview with him on his experiences with dependency management. What did he learn? What things in earlier attempts did he change in later attempts (from bundler to cargo to yarn)? What does he think he got rightest? What mistakes does he think he made? What mistakes does he think other people are still making? What features of a language or platform faciliate or challenge good dependency management? etc etc etc.

In general, I think there isn't much "learning from prior art" in our field that crosses language/platform boundaries. Katz being personally driving the implementing popular dependency management solutions on three different langauges/platforms was one way to actually learn from cross-language experience! I think in dependency management in particular, there are still a lot of lessons people are learning on their own not realizing another language/platform already learned some painful lessons on it... or maybe differences in langauges/platform mean some things aren't transferable...

“Let” feels like some in-joke, coming from a math via lisp heritage of “let k be any number...” to distinguish it in English from the surrounding writing. I have to guess that in early lisp (= k 5) would be an error as k isn’t defined and (k 5) errors because k isn’t a function and (let (k 5)) comes out of need for a binding function and why not “let”.

In c-like languages “k=5” is an established binding that both programmers and compilers can deal with. What does “let k=5;” add to Rust over “k=5;” ?

In my experience, you write some code, the rust analyzer (which is easily embedded in an IDE like VSCode or IntelliJ - which has its own "analyzer" I think) gives you immediate feedback, so you know immediately if things compile or not (there are a few edge cases the analyzer might miss, so when you actually run "rustc" something doesn't compile, but it's pretty rare)... you then write a little test , and Rust has many ways of letting you do that (unit tests right into the same file as the code being tested, integration tests which let you use the code as if from another crate, and even doctests, which are like unit tests but embedded in the documentation of your code)... running the tests is a matter of pressing a button and waiting a few seconds (compilation + test runtime) normally, unless you change dependencies between runs as that requires downloading/compiling your code AND the dependencies, which can be very slow (dozens of seconds)... which is the same problem as with a fresh build, which will almost certainly run in the minutes because of the necessary local compilation of all dependencies... but the experience is not very different from something like Java or Kotlin IMO (but definitely a slower cycle than Go, for example).

Not only his name is on the Rust commit repo, he's also in the list of top 10 commiters the article features as an early Rust development example (although for just 6 commits or so).