Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dave Herman’s contributions to Rust

brson.github.io

Post reply on HN
Print view View original

151–160 of 174 posts

Re: Dave Herman’s contributions to Rust

#151

Post by staticassertion »

varispeed wrote: post #79
rover0 wrote: post #64

Earlier quoted context omitted.

Being in the team that created rust would look great on any CV. I think millionaire is reachable for many of them.

Under the current framework, you cannot get wealthy off of salary. If you working a wage, then you are a corporate slave most of the time.

> Under the current framework, you cannot get wealthy off of salary.

You can make hundreds of thousands of dollars a year as an engineer, without even talking about stock. I'd call that wealthy. If you're an engineer of some stature, 7 figures TC yearly is not out of reach.

Re: Dave Herman’s contributions to Rust

#152

Post by worik »

Very nice story

I love the designed by committee aspect of Rust. I have great respect for good committees. I have served on a few (and some bad ones, shiver). One of the things that makes a committee work is a good facilitator

As the saying goes: A camel is a horse designed by a committee: Goes twice as far on half as much carrying twice the load....

Re: Dave Herman’s contributions to Rust

#153

Post by est31 »

chrismorgan wrote: post #36
est31 wrote: post #35

Earlier quoted context omitted.

> falling apart as soon as you touch things like atomics, RefCell or Mutex. Does it really fall apart? None of these constructs change the fact that if a &mut T is available, you can call functions on that type that take &mut self . The only thing that breaks is the assumption that non-presence of mut implies that there is no way to call those &mut self functions. If you change it to "non-prsence of mut implies that…

The mental model of & being immutable and &mut being mutable, that’s what falls apart. Here are types that are taking &, and yet are mutating themselves. This becomes a huge deal when people think that they have an immutable data structure just because they have an & reference to it. Someone will inevitably stash a mutex or similar in there because they just need to be able to mutate it this once… I mean these three…

> The mental model of & being immutable and &mut being mutable, that’s what falls apart. Here are types that are taking &, and yet are mutating themselves.

&mut still implies mutability, and even the constructs like Mutex or RefCell still expose their mutability support via &mut references. Only atomics don't (they don't provide any &mut access). Note that you don't add const like in C/C++, you add &mut.

As for the VDOM caching thing, you have a point. But even if Rust had &uniq and &shared pointers, the challenge would be the same. Users might still use constructs like RefCell.

Re: Dave Herman’s contributions to Rust

#154

Post by leshow »

rover0 wrote: post #66
akvadrako wrote: post #13

Earlier quoted context omitted.

How is it not clear that var is variable?

I'm a javascript developer. if mutable is expensive, and should be difficult then "let mut" makes more sense. var looks like a default to me, not a special case that needs care.

Nitpick: "expensive" may be the wrong word there, to me that implies some kind of runtime cost. The stated reason for the keyword is that it forces users to think a little bit more about mutability. You may want do this because safe mutability requires exclusive ownership.

Re: Dave Herman’s contributions to Rust

#155

Post by BrendanEich »

zozbot234 wrote: post #2

The OP mentions in passing that Brendan Eich "was solidly on team Rust" prior to leaving Mozilla, but adds no further details to that intriguing statement. Wouldn't that make Eich the Most Unrecognized Contributor? I don't think his name would be on any commit repo, after all.

Thanks for digging this up. Honestly I was doing more for SpiderMonkey than for Rust at code level, but at exec sponsor level, it was me and only me. HTH

Re: Dave Herman’s contributions to Rust

#156

Post by BrendanEich »

kevingadd wrote: post #41
zozbot234 wrote: post #2

The OP mentions in passing that Brendan Eich "was solidly on team Rust" prior to leaving Mozilla, but adds no further details to that intriguing statement. Wouldn't that make Eich the Most Unrecognized Contributor? I don't think his name would be on any commit repo, after all.

Having sat next to / worked with a lot of the rust core people (and Eich) I think while his support was important, that doesn't make him more important/pivotal than people like Dave Herman

It’s cool to erase me, no problem. Inconvenient facts: I hired Dave, as well as (not as hiring manager but by influence) Graydon. Also I’m cofounder of Mozilla Research and C-level advocate for grad student internships. I’m not taking more credit than them, I want less! But don’t erase sr. management or give anyone else at that level undue credit. It was a team effort, but while there is no “I” in team, there is no budget without C level sponsor.

Re: Dave Herman’s contributions to Rust

#157

Post by chrismorgan »

est31 wrote: post #153
chrismorgan wrote: post #36

Earlier quoted context omitted.

The mental model of & being immutable and &mut being mutable, that’s what falls apart. Here are types that are taking &, and yet are mutating themselves. This becomes a huge deal when people think that they have an immutable data structure just because they have an & reference to it. Someone will inevitably stash a mutex or similar in there because they just need to be able to mutate it this once… I mean these three…

> The mental model of & being immutable and &mut being mutable, that’s what falls apart. Here are types that are taking &, and yet are mutating themselves. &mut still implies mutability, and even the constructs like Mutex or RefCell still expose their mutability support via &mut references. Only atomics don't (they don't provide any &mut access). Note that you don't add const like in C/C++, you add &mut. As for the V…

Mutex::lock() takes &self. RefCell::borrow_mut() takes &self. Those (and try_ variants) are the main ways people will use those types to gain access to their interior mutability.

Sure, both do have get_mut() which takes &mut self (though these came after 1.0), but that’s seldom how you’ll actually access it.

> But even if Rust had &uniq and &shared pointers, the challenge would be the same.

Remember again that the mutpocalypse wasn’t ever about changing the semantics, just about fixing incorrect labelling. I’m not saying the challenges would be different, just that &mut is false advertising, giving people the impression that & means an immutable reference, when it just doesn’t. &/&mut misleads people into thinking they can have immutable data structures, but you’d actually need an OIBIT (like Send) to achieve that.

Re: Dave Herman’s contributions to Rust

#158

Post by chubot »

pcwalton wrote: post #148
chubot wrote: post #108

Earlier quoted context omitted.

I think a problem is that programmers have little intuition about about the evaluation time of macros. It's possible that Zig's approach helps here -- since the metalanguage is just the language, you can take some of your intuition about performance along to compile time. And the macro language is not weirdly restricted, so you can write something you're more used to, with similar idioms. In the limit this is clear:…

Macros and compile-time function evaluation are different and fill different roles. Macros define new syntax, while compile-time function evaluation evaluates expressions written using the existing syntax. The corresponding Rust feature for the latter is not macros, but rather "const fn".

I think they both have potential performance issues in the compiler though, and both can be compared with textual code generation.

I think of one as metaprogramming with the parser and the other as metaprogramming with an interpreter. (And the C preprocessor is metaprogramming with only a lexer. Code generation is the kind of metaprogramming that every language supports :) )

Although maybe you're saying Zig doesn't have the functionality of Rust macros, and that could be true; I haven't played with it enough.

However I do think there is overlap as Zig implements printf with compile-time evaluation and Rust does it with macros:

https://ziglang.org/documentation/master/#Case-Study-printf-...

https://andrewkelley.me/post/zig-programming-language-blurs-...

Re: Dave Herman’s contributions to Rust

#159

Post by MrBuddyCasino »

Ar-Curunir wrote: post #103
MrBuddyCasino wrote: post #7

Earlier quoted context omitted.

Kotlin's version is even better: val & var Super clear. The "let" version smells a lot of "I have a CompSci PhD".

The hamming distance between val and var is tiny; easy to miss in a code review.

When assigning to val more than once: in a statically checked language the compiler will complain, and devs default to 'val' anyway. In a dynamic language you'd quickly get a runtime error.

Using 'var' instead of 'val' where possible: the compiler/linter will tell you this.

Or do you mean something else?

Re: Dave Herman’s contributions to Rust

#160

Post by MrBuddyCasino »

mkl wrote: post #18
akvadrako wrote: post #13

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.

var => variable

val => value => is immutable

Of course people are different, but this seems clear as day, assmuning very basic familiarity with functional programming?

Post reply on HN