Dave Herman’s contributions to Rust

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

willtim wrote: post #86

gpm wrote: post #78

Earlier quoted context omitted.

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.

Post by brundolf » Mon, May 03, 2021, 3:54 PM UTC

capableweb wrote: post #88

cletus wrote: post #76

Earlier quoted context omitted.

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…

Post by willtim » Mon, May 03, 2021, 3:57 PM UTC

jeltz wrote: post #80

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…

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

Post by remexre » Mon, May 03, 2021, 3:58 PM UTC

linkdd wrote: post #90

coolreader18 wrote: post #89

Earlier quoted context omitted.

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?

    enum Thing {
        foo { foobar: String },
        bar { foobar: Option, barbaz: String },
    }

Post by willtim » Mon, May 03, 2021, 4:03 PM UTC

qznc wrote: post #93

cletus wrote: post #76

Earlier quoted context omitted.

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

I'm so torn about macros. They are awesome but they make compile-time arbitrarily bad. The D compiler is roughly as fast as the Go one. However, D has macros though and that makes it very slow to compile sometimes. The alternative to macros are code generators. Works fine for bigger stuff like a parser generator but not for smaller stuff like a regex.