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

121–130 of 174 posts

Re: Dave Herman’s contributions to Rust

#121

Post by linkdd »

remexre wrote: post #115
linkdd wrote: post #105

Earlier quoted context omitted.

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.

> What about user-supplied JSON schemas? You can't add types at runtime. Right, well, since they're validators anyway, might as well represent them as a defunctionalized validation function or something. Agreed that this is more-or-less past the point where the type system helps model the values you're validating, though a strong type system helps a lot implementing the validators! > It's still a string, in Rust you…

Thanks for the insight! Didn't know strum.

But yeah, I tend to do more work at runtime than compile-time, which is not really the way to go in Rust.

Re: Dave Herman’s contributions to Rust

#122

Post by capableweb »

hctaw wrote: post #113
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…

> How is the REPL experience if there is one? About on par with C/C++ and Go. In that you don't have one and don't want for one. REPL driven development is difficult with languages like Rust, both to implement and use. I think there are some projects floating around out there, but I personally don't see a purpose for one. It's not python or matlab.

> I think there are some projects floating around out there, but I personally don't see a purpose for one. It's not python or matlab

I was thinking of a REPL in the sense of common Clojure usage (https://vvvvalvalval.github.io/posts/what-makes-a-good-repl....) not the basic "write lines into a separate program and then copy-paste it into your source code" that Python offers.

Re: Dave Herman’s contributions to Rust

#123

Post by east2west »

willtim wrote: post #96
jeltz wrote: post #80

Earlier quoted context omitted.

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…

> Imagine the function "fn bar(x: fn(x: int) -> string)", would that be more clear with a colon? In your example, why bother naming the inner "x" variable for the function param? It cannot be used on the right-hand-side (definition of "bar"). For that reason, the notation is not exactly "clear". In OCaml the annotation would be: bar( x : int -> string )

In Rust you can write ```f: fn(i32) -> i32```.

Ocaml's syntax is more consistent, I agree, but its colon operator has different precedence than in Rust, so I am not sure its rational applies to Rust.

Re: Dave Herman’s contributions to Rust

#124

Post by coder543 »

nessex wrote: post #91
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…

When I use rust, I find compile times faster and more manageable than other languages due to the speed of iterative compiles. Compiling from scratch is very slow, but iterative compiles are faster than most of my golang compiles and faster than running a JS builder in most projects. To make it extra fast, I follow the instructions from the bevy game engine[1]. With that setup, the feedback loop is quick. [1] https://…

> iterative compiles are faster than most of my golang compiles

Maybe you're comparing apples to oranges here. I've worked professionally with both Rust and Go for years now on a variety of real world projects, and I've never seen a similarly-sized Go codebase that compiles slower than a Rust one. If you're comparing incremental Rust compilation to first-time Go compilation, maybe they could be competitive, but... Rust is incredibly slow at compilation, even incremental compilation.

Yes, using lld can speed up Rust compilation because a lot of the time is often spent in the linker stage, but... that's not enough to make it as fast as Go.

YMMV, of course, but... my anecdotal experience would consider it disingenuous to say that Rust compile times are an advantage compared to Go, and I'm skeptical that Rust compile times are even an advantage compared to the notoriously slow webpack environments.

Rust is good at many things, but compilation speed is not one of them. Not even close, sadly. "cargo check" is tolerable most of the time, but since you can't run your tests that way, that's not actually compilation.

Re: Dave Herman’s contributions to Rust

#125

Post by qznc »

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.

The question is not runtime vs compile time.

The question is whether you do the meta programming/code generation within the language or as external tool. Code bloat is an issue in both cases.

Macros make it easy to write code which generates code which generates code which... This enables some wonderful use cases, often around generating type declarations. If done with an isomorphic language, you can also reuse the same code for compile time and runtime implementations with just thin wrappers.

External code generators however will build faster because the build system takes care of reusing the intermediate code.

Re: Dave Herman’s contributions to Rust

#126

Post by masklinn »

remexre wrote: post #115
linkdd wrote: post #105

Earlier quoted context omitted.

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.

> What about user-supplied JSON schemas? You can't add types at runtime. Right, well, since they're validators anyway, might as well represent them as a defunctionalized validation function or something. Agreed that this is more-or-less past the point where the type system helps model the values you're validating, though a strong type system helps a lot implementing the validators! > It's still a string, in Rust you…

> Yep, though if you really wanted it to be a string at runtime, you could use smart constructors to make it so. The downsides would be, unless you normalized the string (at which point, just use an enum TBH), you're doing O(n) comparison, and you're keeping memory alive, whether by owning it, leaking it, reference counting, [...].

Nit: it's more constraining but serde can deserialize to an &str, though that assumes the value has no escapes.

Ideally `Cow` would be the solution, but while it kind-of is, that doesn't actually work out of the box: https://github.com/serde-rs/serde/issues/1852

Re: Dave Herman’s contributions to Rust

#127

Post by staticassertion »

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…

I'm surprise to hear that it was so slow on a powerful machine. In my experience throwing more compute at a codebase can make compile times very, very fast, though of course only after the first run. It parallelizes pretty damn well.

Re: Dave Herman’s contributions to Rust

#128

Post by dang »

joseluisq wrote: post #19
aome510 wrote: post #15

The same story [0] was posted several hours ago by the author I suppose. [0]: https://news.ycombinator.com/item?id=27016848

Yep, this needs a `dup` mark somewhere. Edit for down-voters: the typical HN behaviour. Don't be lazy and take a time to explain why you downvote.

Downvoters on HN are not required to explain why they downvote. That would just lead to massive numbers of low-quality "explanations" and tons more flamewars.

I'll respond to the point about duplicates below.

Re: Dave Herman’s contributions to Rust

#129

Post by dang »

joseluisq wrote: post #31
Macha wrote: post #25

Earlier quoted context omitted.

https://news.ycombinator.com/newsfaq.html > Are reposts ok? > If a story has not had significant attention in the last year or so, a small number of reposts is ok. Otherwise we bury reposts as duplicates. > Please don't delete and repost the same story. Deletion is for things that shouldn't have been submitted in the first place. Dupes are not against the rules. You're likely getting downvoted by people aware of that…

If your affirmation is true, why many of HN users (me included) get [dupe] at first place? In general, Is not the HN intention to decrease number of duplicates? If not so then HN should provide a solution for prevent this, such prevention that is not happening today. Example search input. Sorry but I'm seeing big contradictions in the so called rules. Just one example: > If a story has not had significant attention i…

The issue with duplicates isn't reposts of articles as such, it's not wanting significant duplicate discussions. We allow reposts as a way of mitigating the randomness of /newest. But once a story has gotten significant attention, we bury reposts as duplicates. (But after a year or so, enough time has gone by that a repost is ok again.)

In the current case, the previous submission didn't get much attention, so we didn't count this one as a dupe. In the case of your post https://news.ycombinator.com/item?id=26812145, the previous submission of the story did get a big discussion, so we marked the repost as a dupe. There's no contradiction.

Does that make sense? If not, take a look at some of the previous explanations. If you still have questions after that, let us know.

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Re: Dave Herman’s contributions to Rust

#130

Post by Decabytes »

Having written Racket code myself I was surprised when I saw that Rust had Hygenic macros.

I've never learned how to use macros effectively, but once I've gotten more comfortable in Rust I'd like to give it a good shot. Given Dave's background with Racket and Macros, this feels like a worthwhile endeavor.

On a side note there are a lot of cool language oriented programming stuff that Racket does through it's macro system, and I wonder if it is at all possible to do something like that in Rust

Post reply on HN