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

51–60 of 174 posts

Re: Dave Herman’s contributions to Rust

#51

Post by devit »

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…

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 useful for documentation).

Re: Dave Herman’s contributions to Rust

#52

Post by fithisux »

The impression left by this article is that Bjarne Stroustrup is doing a big mistake by continuing his work on C++. Nim / Zig / D are UFOlogists and who needs Racket / CL / Haskell anyway. Java could be found in ancient Egypt being served to mummies.

Re: Dave Herman’s contributions to Rust

#53

Post by xpe »

galangalalgol wrote: post #46
jxf wrote: post #44

I confess I'm pretty ignorant about the history and origins of Rust, and it's not something I tend to investigate deeply for a lot of my tools. But I derive a great deal of my current livelihood from Rust and helping firms use it well, so thank you, Dave. If nothing else, maybe I'll be looking more closely at my next tools, and hoping they have their own Daves quietly advocating for their success.

Have you ever helped a firm use rust on airgapped or nexus ptoxies developer networks? The nexus module appears abandoned, and the documentation on running an offline crates.io mirror is very lacking.

This seems like a non-sequitor and off topic. There are plenty of better places to give this feedback.

Re: Dave Herman’s contributions to Rust

#54

Post by xfer »

chrismorgan wrote: post #40
NanoCoaster wrote: post #38

Earlier quoted context omitted.

I see, interesting point. Thank you :)

I feel like making one more note. I said that “mutable references” was a misnomer and that it’s actually about unique references, but even that’s a bit of a misnomer, because it’s not quite about uniqueness, but uniqueness of access . You can have multiple &mut borrows to the same thing, but only one of them is accessible at any given time: let mut x = 1; let y = &mut x; let z = &mut *y; *z += 1; *y += 1; assert_eq!(…

Would this have worked pre-NLL?

Re: Dave Herman’s contributions to Rust

#55

Post by valenterry »

devit wrote: post #51
willtim wrote: post #49

Earlier quoted context omitted.

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…

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…

I don't think that would be the implication, because we are in the context of a function. Otherwise, we should also not write foo(x: int) but foo: int -> ?

Re: Dave Herman’s contributions to Rust

#56

Post by the__alchemist »

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…

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

Re: Dave Herman’s contributions to Rust

#57

Post by willtim »

devit wrote: post #51
willtim wrote: post #49

Earlier quoted context omitted.

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…

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 either

OCaml does and Haskell once had a proposal to add it. Haskell type signatures are normally written separately, but it does support annotating patterns with the right extensions.

Re: Dave Herman’s contributions to Rust

#58

Post by ModernMech »

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 wouldn't say this is a wart or confusing (to me at least). As someone who uses Haskell, C++, and Rust regularly, I just accept that each language has its own syntax. It's true that Rust borrows ideas from many languages, but I view Rust's syntax as its own thing, and the meaning of the symbols are what they are. It doesn't have to do things the C++ way or the Haskell way. It does things the Rust way, and that's not a wart.

Re: Dave Herman’s contributions to Rust

#59

Post by willtim »

the__alchemist wrote: post #56
willtim wrote: post #49

Earlier quoted context omitted.

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…

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 :)

Re: Dave Herman’s contributions to Rust

#60

Post by willtim »

ModernMech wrote: post #58
willtim wrote: post #49

Earlier quoted context omitted.

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 wouldn't say this is a wart or confusing (to me at least). As someone who uses Haskell, C++, and Rust regularly, I just accept that each language has its own syntax. It's true that Rust borrows ideas from many languages, but I view Rust's syntax as its own thing, and the meaning of the symbols are what they are. It doesn't have to do things the C++ way or the Haskell way. It does things the Rust way, and that's not…

It did confuse me when I first saw it, but yes, it is not really a significant issue.
Post reply on HN