Dave Herman’s contributions to Rust • Hacker News Board

Re: Dave Herman’s contributions to Rust

#71

Post by sireat » Mon, May 03, 2021, 2:35 PM UTC

stared wrote: post #67

willtim wrote: post #42

Rust 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.

Syntax wise Rust seems heavily inspired by the "good parts" of Scala.

- Pattern matching via "match"

- if being an expression (among most things)

Those are both found in Scala.

Re: Dave Herman’s contributions to Rust

#72

Post by ape4 » Mon, May 03, 2021, 2:39 PM UTC

willtim wrote: post #49

daoxid wrote: post #45

Earlier quoted context omitted.

> misappropriated Haskell/ML function syntax, enum/struct asymmetry I'm curious, could you elaborate?

In Rust, a function definition left-hand-side looks like an annotated pattern, e.g. foo(x : int) Therefore, one would expect to annotate the return type as, foo(x : int) : string Since the pattern is showing foo applied to x. The Rust syntax is actually confusing for both Haskell/ML programmers (where the arrow comes from) and mainstream programmers. It's too small an issue to change now though. Rust's support for pr…

I typed `foo(x : int) : string` when I was starting and there was an error message telling me to use `-> string` so many people expect this syntax.

Re: Dave Herman’s contributions to Rust

#73

Post by acdha » Mon, May 03, 2021, 2:47 PM UTC

willtim wrote: post #59

the__alchemist wrote: post #56

Earlier quoted context omitted.

FYSA, The Rust approach is the same way it's done in Python.

Well the Python community is hardly an authoritative figure on static typing :)

This is true but Python has a user community which is several orders of magnitude broader, which confuses the issue a bit. These days if I was designing a language I'd probably ask “How would I explain this to someone who learned JavaScript/Python?” since even if you have great reasons for doing things differently it's a pretty reasonable way to predict sources of confusion for newcomers.

Re: Dave Herman’s contributions to Rust

#74

Post by lgessler » Mon, May 03, 2021, 2:53 PM UTC

sireat wrote: post #71

stared wrote: post #67

Earlier quoted context omitted.

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.

Syntax wise Rust seems heavily inspired by the "good parts" of Scala. - Pattern matching via "match" - if being an expression (among most things) Those are both found in Scala.

Didn't Scala get both of those things from ML?

Re: Dave Herman’s contributions to Rust

#75

Post by Thiez » Mon, May 03, 2021, 3:00 PM UTC

steveklabnik wrote: post #70

Thiez wrote: post #61

Earlier quoted context omitted.

The pre-NLL version would need some additional scopes. In some ways the current borrow-checker is a lot friendlier (there are also some things possible today that weren't before) but it was also a simpler time, where one could easily imagine the various lifetimes. Getting started with the language was harder, but I think internalizing the borrow-checker was easier, because the rules were simpler and you were forced t…

> Getting started with the language was harder, but I think internalizing the borrow-checker was easier, So here's a funny thing: depending on what you mean, I don't think this is actually true. Let me explain. The shortest way of explaining lexical lifetimes vs NLL is "NLL is based on a control-flow graph, lexical lifetimes are based on lexical scope." CFGs feel more complex, and the implementation certainly is. So…

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 confirmation bias on my end, but I think truly understanding lifetimes was easier the way I learned it back then. That said, I have never bothered to write documentation for the Rust project, whereas few Rust contributors can claim to be in the same league as you in that area. We probably have very different perspectives.

Re: Dave Herman’s contributions to Rust

#76

Post by cletus » Mon, May 03, 2021, 3:04 PM UTC

willtim wrote: post #42

Rust 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…

First let me say: I like Rust. I'm a fan. But... it did make some early decisions that are going to be hard to shake off, most notably around build times. This [1] is well worth a read.

[1]: https://pingcap.com/blog/rust-compilation-model-calamity

Re: Dave Herman’s contributions to Rust

#77

Post by cies » Mon, May 03, 2021, 3:07 PM UTC

varispeed wrote: post #50

> A little appreciated fact: Rust was largely built by students, and many of them interned at Mozilla. So now companies make billions off of the software written in Rust and has even one student become a millionaire? Companies that appropriate such projects should start paying their fair share to people who made it possible for them to make such profits.

Are you familiar with (a) open source licenses, and (b) the profit maximization principle?

Re: Dave Herman’s contributions to Rust

#78

Post by gpm » Mon, May 03, 2021, 3:10 PM UTC

willtim wrote: post #57

devit wrote: post #51

Earlier quoted context omitted.

That would imply that "foo(x: int)" is a string rather than a function. Haskell doesn't use that notation either, it uses -> both for the parameter list and for the return type, and separates argument names (arguably, these are poor choices, since currying is not an efficient CPU-native operation and not intuitive so distinguishing between multiple arguments and returning closures is useful, and argument names are us…

> That would imply that "foo(x: int)" is a string rather than a function But foo(x : int) is a string! It literally reads "foo applied to x". In the function definition, it appears to be used as a left-hand-side pattern which is "matched". The definition is written as if to say, whenever the term foo(x) is encountered, use this definition here. At least, that was my expectation. > Haskell doesn't use that notation ei…

No, foo(x: int) is not a string, it's not even an expression, it's not even an AST node. It's a fragment of the larger ast node

    fn foo(x: int) -> ReturnType {
        body
    }

The ast here splits into

    Function {
        name: foo
        signature: (x: int) -> ReturnType
        body: body
    }

I.e. the arrow binary op binds more tightly than the adjacency between foo and x: int. And the type of foo is a function, not a string.

A "better" way to write this (in that it breaks down the syntax into the order it is best understood) might be

    static foo: (Int -> ReturnType) = {
        let x = arg0;
        body
    }

Or to put it another way. Reading foo(x: int) as "foo applied to x" in this case is a mistake, because that's now how things bind. You should read that "foo is a (function that takes Int to String)". It's a syntactic coincidence that foo and x are beside eachother, nothing more.

Re: Dave Herman’s contributions to Rust

#79

Post by varispeed » Mon, May 03, 2021, 3:14 PM UTC

rover0 wrote: post #64

varispeed wrote: post #50

> A little appreciated fact: Rust was largely built by students, and many of them interned at Mozilla. So now companies make billions off of the software written in Rust and has even one student become a millionaire? Companies that appropriate such projects should start paying their fair share to people who made it possible for them to make such profits.

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.

Re: Dave Herman’s contributions to Rust

#80

Post by jeltz » Mon, May 03, 2021, 3:20 PM UTC

willtim wrote: post #49

daoxid wrote: post #45

Earlier quoted context omitted.

> misappropriated Haskell/ML function syntax, enum/struct asymmetry I'm curious, could you elaborate?

In Rust, a function definition left-hand-side looks like an annotated pattern, e.g. foo(x : int) Therefore, one would expect to annotate the return type as, foo(x : int) : string Since the pattern is showing foo applied to x. The Rust syntax is actually confusing for both Haskell/ML programmers (where the arrow comes from) and mainstream programmers. It's too small an issue to change now though. Rust's support for pr…

Having used both Haskell and main stream programming languages I did not at all think that was confusing. The type of "fn foo(x: int) -> string" is quite obviously "fn(x: int) -> string" for people coming from languages like C. I do not see how a colon would make anything more clear. Imagine the function "fn bar(x: fn(x: int) -> string)", would that be more clear with a colon?

On the other hand the enum thing is certainly surprising.