Earlier quoted context omitted.
How is it not clear that var is variable?
Yes. I think the problem may be with the other one. "val" (and "let") don't seem obviously constant to me.
"val" is short for "value"
Dave Herman’s contributions to Rust
131–140 of 174 posts
Re: Dave Herman’s contributions to Rust
#132> Hiring Yehuda Katz to design Cargo I did not realize this; that explains why cargo is so similar to ruby bundler (which Katz also wrote).
The name Katz set off bells in my head while I was reading the article, but it was only until I saw your comment that I realized why. Cool bit of connection-making there!
Re: Dave Herman’s contributions to Rust
#133Earlier quoted context omitted.
Hey Steve :-) I've been following and using Rust since early 2013 (so starting around the same time you did, when I compare our contributions to the compiler) and back then I definitely did not find the lexical lifetimes hard to understand. I remember also noticing an increase in "dumb" lifetime-related questions after NLL landed, seemingly caused by a lack of understanding of how they work. Perhaps it's all just con…
Oh totally, I know you :) It's interesting how our perceptions are different though, I think a lot of the "dumb" questions went away since NLL. I wonder if there's a way to quantify this. So, I think this is the thing: I also think that it was easier to learn lexically, personally. I too was worried that it would make things harder. But, I just don't think that's been demonstrated to be true across most people. It is…
I started in mid-2013 too, and my position is similar to yours. I'd characterise it like this: lexical lifetimes are easier to grok, but NLL turns out to be more practical, doing what people actually want (where LL didn't) enough that it overcomes the greater conceptual complexity, because you have to actually think about the concepts less often.
Re: Dave Herman’s contributions to Rust
#134Earlier quoted context omitted.
Yep, this needs a `dup` mark somewhere. Edit for down-voters: the typical HN behaviour. Don't be lazy and take a time to explain why you downvote.
Downvoters on HN are not required to explain why they downvote. That would just lead to massive numbers of low-quality "explanations" and tons more flamewars. I'll respond to the point about duplicates below.
Downvoters on HN are not required to explain why they downvote
Maybe by this point this belongs in the document that talks about voting meta, given that it's one of the most persistent and common voting meta comments.
Re: Dave Herman’s contributions to Rust
#135[deleted]
Re: Dave Herman’s contributions to Rust
#136Dave Herman has been a high signal-to-noise contributor to Lambda the Ultimate over the years; if you want to get an idea as to where he is coming from, looking at his contributions there [1], his slightly active blog [2], and on his now pretty much inactive joint blog [3] are good places to start. [1]: http://lambda-the-ultimate.org/user/825/track?sort=desc&orde... [2]: http://calculist.org/ [3]: https://www.thefeed…
another random mention, Dave was also the main driver of EcmaScript Modules.
Re: Dave Herman’s contributions to Rust
#137> Hiring Yehuda Katz to design Cargo I did not realize this; that explains why cargo is so similar to ruby bundler (which Katz also wrote).
He also worked on Yarn. Yehuda Katz has probably the most experience of anyone on dependency management
Re: Dave Herman’s contributions to Rust
#138> A little appreciated fact: Rust was largely built by students, and many of them interned at Mozilla. The article doesn't mention it but this is of course a very good long term strategy. Things students learn during their formative years at university will bear fruit once they enter the work force. How many of those students are now at or about to enter important positions in the industry? Do you think Java could ha…
It is a double edge sword. No doubt if the students are motivated and dedicated, they could build the next metaphoric rocket ship. Also they also runs the risk of causing the project to off course and failed.
It sounds like the leadership of Dave was key to getting the team to focus and to delivery high quality results.
Re: Dave Herman’s contributions to Rust
#139> A little appreciated fact: Rust was largely built by students, and many of them interned at Mozilla. The article doesn't mention it but this is of course a very good long term strategy. Things students learn during their formative years at university will bear fruit once they enter the work force. How many of those students are now at or about to enter important positions in the industry? Do you think Java could ha…
Having so many students involved in Rust was huge. Definitely the most rewarding thing about working on Rust was seeing students get involved, grow, then turn that experience into a career, while seeding the industry with Rust talent.
Yes, but it goes both ways. As a student, I was always thrilled to see bits of future technology today.
I am still sad that some of the things I've seen or have taken part in didn't materialize and haven't taken a hold in the present.
The students you had were certainly as happy as being with you as you were having them. :-)
Re: Dave Herman’s contributions to Rust
#140Rust maybe a little adhoc in places (e.g. the misappropriated Haskell/ML function syntax, enum/struct asymmetry), but overall it is a fantastic effort. It is not an easy task to combine an advanced static type-system with mainstream ergonomics, but they seemed to have pulled it off. The fact that it is also not owned and controlled by a single big tech entity is icing on the cake. I really hope it achieves even great…
Personally, I find Rust syntax to be well-designed. At least, compared to any practical programming language I know. Quite a few times I was surprised that Rust breaks with some old patterns that were copied over and over in the last 50 years or so. For example: "match" instead of "switch", or the same if/else regardless if it is a statement or a value. These are small touches, but they show attention to detail.
I think that there's still time for Rust to reverse the .expect(...) naming mistake. It should be deprecated, either introducing something with an appropriate name like .unwrap_or_panic(...) or just leave it to be replaced by .unwrap_or_else(|| panic!(...)) which IMO one ought to use today instead of .expect(...).
Everything else is named so well and designed so well that this really sticks out.