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

101–110 of 174 posts

Re: Dave Herman’s contributions to Rust

#101

Post by willtim »

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?

Unfortunately Rust is currently lacking structural records/structs and enums. I think they removed them early on in the design. So you'd have to name the all the types. I hope they do add them back one day.

Re: Dave Herman’s contributions to Rust

#102

Post by Ar-Curunir »

galangalalgol wrote: post #99
xpe wrote: post #53

Earlier quoted context omitted.

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

I think maybe my question was taken differently than I meant it. I was legitimately asking if the gp had/could help with such a task.

It’s a very niche question. You’re better served asking in Rust support channels like the discord or the subreddit.

Re: Dave Herman’s contributions to Rust

#103

Post by Ar-Curunir »

MrBuddyCasino wrote: post #7
melling wrote: post #4

Haven’t learned Rust yet. I see they debated this: let and let mut let and var And went with the verbose option. Swift went with the succinct option, which I love about the language. In practice I suppose I do mostly type “let” in Swift so it doesn’t matter much Swift, however, chose ‘func’ instead of ‘fn’, after much debate. Those little things that are debated initially, then forever

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.

Re: Dave Herman’s contributions to Rust

#104

Post by bfrog »

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…

Clean compiles do take a moment. Comparable to heavily templated C++ in my experience.

On the other hand iterative development with rust analyzer going and all the dependencies already built is pretty painless. By the time you run your tests or program, it's likely to take only a few seconds to build.

That said you can write terribly long to compile rust. Usually there's some trades you can make to weigh compile time as more important than flexibility or static code paths.

I've written a sizeable ad server in rust with maybe 25kloc. Where I was the sole developer and sys ops person, it cost me a little upfront time but saved me many more hours in operations work.

Re: Dave Herman’s contributions to Rust

#105

Post by linkdd »

remexre wrote: post #98
linkdd wrote: post #90

Earlier quoted context omitted.

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?

In general, JSON Schemas are (wrongly, in my view...) validation-oriented rather than type-oriented (for notions of types that would be familiar to Haskell, Rust, or Common Lisp programmers). I think that schema in particular could be represented, though, as: enum Thing { foo { foobar: String }, bar { foobar: Option , barbaz: String }, }

What about user-supplied JSON schemas? You can't add types at runtime.

Also, JSON schemas allows you to encode semantics about the value not only their types:

  {"type": "string", "format": "url"}
That's something I like about Typescript's type system btw:

  type Role = 'admin' | 'moderator' | 'member' | 'anonymous'
It's still a string, in Rust you would need an enum and a deserializer from the string to the enum.

Re: Dave Herman’s contributions to Rust

#106

Post by seabrookmx »

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.

I don't know what your definition of corporate slave is, but you can certainly become wealthy off a salary.

Just limiting to software engineering (there's other lucrative fields out there) you can easily make a six-figure income remotely. This gives you the freedom to live somewhere with very low cost of living. It's not hard to build wealth this way.

You could debate that getting the necessary skills to get a job like this is harder than it should be.. that corporations themselves are broken.. whatever your worldview is that's fine but "cannot get wealthy off salary" is just plain false.

Re: Dave Herman’s contributions to Rust

#107

Post by ndesaulniers »

I swear I recall being a fly on the wall and just being in awe; early on in my career just listening to Dave Herman, Luke Wagner, and Alon Zakai discussing asm.js which would one day lead to webassembly. It was very early days even for asm.js, but from how they spoke of it and it's potential you could tell it would have huge impact on the industry.

Re: Dave Herman’s contributions to Rust

#108

Post by chubot »

willtim wrote: post #100
qznc wrote: post #93

Earlier quoted context omitted.

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.

It's better to evaluate at compile time, if possible, rather than runtime. The biggest issue with macros is code bloat, but every serious general purpose language should have them.

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: I'm using several Python code generators C++ in https://www.oilshell.org, and it's easy to reason about the performance of Python. Doing the same in C++ metaprogramming would almost certainly be a lot slower. It would also give me less indication of code bloat; right now I simply count the lines of output to test whether my code generator is "reasonable".

e.g. I generate ~90K lines of code now, which is reasonable, but if I had 1M or 10M lines of code, that wouldn't be. But there's not that much of a sanity check on macros (except binary size).

Re: Dave Herman’s contributions to Rust

#109

Post by capableweb »

bfrog wrote: post #104
capableweb wrote: post #88

Earlier quoted context omitted.

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…

Clean compiles do take a moment. Comparable to heavily templated C++ in my experience. On the other hand iterative development with rust analyzer going and all the dependencies already built is pretty painless. By the time you run your tests or program, it's likely to take only a few seconds to build. That said you can write terribly long to compile rust. Usually there's some trades you can make to weigh compile time…

I guess by in general a "dynamic programming languages" fan, "only a few seconds to build" already sounds like a lot. Different tradeoffs I guess, but hard to justify when you're used to ms compile time.

Re: Dave Herman’s contributions to Rust

#110

Post by steveklabnik »

linkdd wrote: post #105
remexre wrote: post #98

Earlier quoted context omitted.

In general, JSON Schemas are (wrongly, in my view...) validation-oriented rather than type-oriented (for notions of types that would be familiar to Haskell, Rust, or Common Lisp programmers). I think that schema in particular could be represented, though, as: enum Thing { foo { foobar: String }, bar { foobar: Option , barbaz: String }, }

What about user-supplied JSON schemas? You can't add types at runtime. Also, JSON schemas allows you to encode semantics about the value not only their types: {"type": "string", "format": "url"} That's something I like about Typescript's type system btw: type Role = 'admin' | 'moderator' | 'member' | 'anonymous' It's still a string, in Rust you would need an enum and a deserializer from the string to the enum.

As the input gets more dynamic, so does the type system representation. If you want to handle user-supplied JSON schemas, in my understanding of JSON Schema, you'd have to use the serde_json::Value way: https://docs.serde.rs/serde_json/#operating-on-untyped-json-...
Post reply on HN