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

81–90 of 174 posts

Re: Dave Herman’s contributions to Rust

#81

Post by galgalesh »

fithisux wrote: post #52

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.

Even if rust becomes a full replacement, it might take half a century before the last C++ project stops being maintained. In the meantime.

Investing your time in improving C++ is a safe bet for a long-lasting meaningful impact on software [development]. C++ will outlive Bjarne.

Re: Dave Herman’s contributions to Rust

#82

Post by linkdd »

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.

Rust syntax is weird. Weirdly good and sometimes bad.

I'm currently designing my own toy language and writing the compiler (to LLVM IR) in Rust.

Representing the AST with Rust's sum types is so simple. Visiting that AST through pattern matching is great. But the "enum" keyword still bugs me.

The way you define product types (tuples, records, empty types) and then their implementation, just awesome. But the "struct" keyword still bugs me too.

It feels "high level" with some quirks.

Then you have references, Box, Rc, Arc, Cell, lifetimes etc... It feels (rightfully) "low level".

Then you have traits, the relative difficulty (mostly for Rust newbies like me) of composing Result types with distinct error types, etc...

It feels "somewhat high level but still low level".

Sometimes you can think only about your algorithm, some other times you have to know how the compiler works. It seems logical for such a language, but still bugs me.

The one thing I hate though, is the defensive programming pattern. I just validated that JSON structure with a JSON schema, so I KNOW that the data is valid. Why do I need to `.unwrap().as_string().unwrap()` everywhere I use this immutable data?

Re: Dave Herman’s contributions to Rust

#83

Post by brson »

bhaak wrote: post #47

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

Re: Dave Herman’s contributions to Rust

#84

Post by Jtsummers »

lgessler wrote: post #74
sireat wrote: post #71

Earlier quoted context omitted.

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?

Yes, and Rust has more direct lineage to OCaml than Scala (initial version was written in OCaml, and the language had a more ML-ish syntax early on).

Re: Dave Herman’s contributions to Rust

#85

Post by willtim »

ZoomZoomZoom wrote: post #69
willtim wrote: post #57

Earlier quoted context omitted.

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

> But foo(x : int) is a string! Can you say so decisively for a language with first-class functions?

You are quoting me out of context. In many languages, the term and/or pattern foo(x : int) is a string, if foo : int -> string.

Re: Dave Herman’s contributions to Rust

#86

Post by willtim »

gpm wrote: post #78
willtim wrote: post #57

Earlier quoted context omitted.

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

That's a nice explanation of what's going on. My point remains that I found the syntax confusing though.

Re: Dave Herman’s contributions to Rust

#87

Post by steveklabnik »

Thiez wrote: post #75
steveklabnik wrote: post #70

Earlier quoted context omitted.

> 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 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, however, only my gut-check feeling for what I've seen. I could be wrong.

(And, the borrowcheck documentation is very minimal, and didn't really change with NLL, other than needing to add some println!s to make things not compile again. So it's certainly not because I wrote some amazing docs and explained it in a good way, hehe.)

Re: Dave Herman’s contributions to Rust

#88

Post by capableweb »

cletus wrote: post #76
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

Yeah, the build times. How does a normal Rust developers development environment look like? Do you have to rebuild after each change if you want to try out the change itself, after you've written tests and so on? How is the REPL experience if there is one?

My only experience with Rust so far has been trying to learn it by writing applications in it and also use 3rd party CLIs, but quickly loosing interest because the "change try out change" cycle has been too slow and cumbersome, and installing/compiling dependencies take fucking forever, even on a i9-9900K.

Re: Dave Herman’s contributions to Rust

#89

Post by coolreader18 »

linkdd wrote: post #82
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.

Rust syntax is weird. Weirdly good and sometimes bad. I'm currently designing my own toy language and writing the compiler (to LLVM IR) in Rust. Representing the AST with Rust's sum types is so simple. Visiting that AST through pattern matching is great. But the "enum" keyword still bugs me. The way you define product types (tuples, records, empty types) and then their implementation, just awesome. But the "struct" k…

Because ideally your JSON schema validator would turn it into a type that mirrors the structure of the data. "Parse, don't validate"[0]

[0]: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

Re: Dave Herman’s contributions to Rust

#90

Post by linkdd »

coolreader18 wrote: post #89
linkdd wrote: post #82

Earlier quoted context omitted.

Rust syntax is weird. Weirdly good and sometimes bad. I'm currently designing my own toy language and writing the compiler (to LLVM IR) in Rust. Representing the AST with Rust's sum types is so simple. Visiting that AST through pattern matching is great. But the "enum" keyword still bugs me. The way you define product types (tuples, records, empty types) and then their implementation, just awesome. But the "struct" k…

Because ideally your JSON schema validator would turn it into a type that mirrors the structure of the data. "Parse, don't validate"[0] [0]: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

But the Rust type system cannot fully express a JSON Schema:

  {
    "type": "object",
    "oneOf": [{
      "required": ["kind", "foobar"],
      "properties": {
        "kind": {"enum": ["foo"]},
        "foobar": {"type": "string"}
      }
    }, {
      "required": ["kind", "barbaz"],
      "properties": {
        "kind": {"enum": ["bar"]},
        "foobar": {"type": "number"},
        "barbaz": {"type": "string"}
      }
    }]
  }
Or am I wrong?
Post reply on HN