Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust 1.24

blog.rust-lang.org

Post reply on HN
Print view View original

151–160 of 215 posts

Re: Rust 1.24

#151

Post by RX14 »

ComputerGuru wrote: post #142
fafhrd91 wrote: post #42

tokio-minihttp is 1 in plaintext benchmark in TechEmpower Web frameworks benchmark https://www.techempower.com/benchmarks/#section=data-r15&hw=...

Ugh. Every time I see tokio or futures-rs mentioned, a part of me dies. The syntax and ergonomics of rust futures ATM is insanely painful and slows down development 100x in some cases (not exaggerating) due to the current lack of async/await combined with hard typing requirements coupled with some very unreasonable design decisions (namely, each future generates as the result of a computation on a previous future has…

I've never quite understood the benefits of async/await over go-style csp. It seems to me that its far better to just write sequential code all the time then mark all the points where you add parallelism with spawn/go instead of layer abstractions to approximate the same result but with added (in my view unneccesary) keywords. Can anyone provide some insight?

Re: Rust 1.24

#152

Post by sgift »

themihai wrote: post #143
dsymonds wrote: post #70

Good to see rustfmt arrive. Sad that it is configurable, though. The biggest benefit of its predecessors such as gofmt is that they are not configurable, leading to a much more uniform formatting style and avoiding endless discussions about whitespace layout.

Yeah, I guess that's the Rust way. The more options/configurations the better! Simplicity is not on the top list for sure.

Using default == Simplicity. You don't have to use the options.

Re: Rust 1.24

#153

Post by sgift »

Thaxll wrote: post #79
fafhrd91 wrote: post #42

tokio-minihttp is 1 in plaintext benchmark in TechEmpower Web frameworks benchmark https://www.techempower.com/benchmarks/#section=data-r15&hw=...

I wouldn't post Rust benchmarks in here it's behind Java in every scenarios.

Which says more about Java than Rust. Despite all the "Java is slow" boohoo modern Java is a blazing fast language for many problems. Rust is young, still much potential.

Re: Rust 1.24

#154

Post by ZenoArrow »

pvg wrote: post #134
ZenoArrow wrote: post #133

Earlier quoted context omitted.

> "Because more or less everything is Turing-complete." If you understand what it means, then you'd know that it means that all programming languages are comparable, from assembly to Haskell, in the sense they can all be used to do the same job. Therefore, requesting a comparison of the strengths and weaknesses of two programming languages is not a foolish request. The point of such a request is to find out where it…

If you understand what it means, then you'd know that it means that all programming languages are comparable I think this is where we strongly diverge and I resent, a bit, your implication that because I don't buy into this I somehow 'don't understand what it means'. I understand what it means. I just think it's plainly ridiculous.

> "I just think it's plainly ridiculous."

You compared a Dremel to a plasma cutter as a way to explain the differences between Python and Rust, how is that any less ridiculous?

Re: Rust 1.24

#155

Post by 62747478182 »

RX14 wrote: post #151
ComputerGuru wrote: post #142

Earlier quoted context omitted.

Ugh. Every time I see tokio or futures-rs mentioned, a part of me dies. The syntax and ergonomics of rust futures ATM is insanely painful and slows down development 100x in some cases (not exaggerating) due to the current lack of async/await combined with hard typing requirements coupled with some very unreasonable design decisions (namely, each future generates as the result of a computation on a previous future has…

I've never quite understood the benefits of async/await over go-style csp. It seems to me that its far better to just write sequential code all the time then mark all the points where you add parallelism with spawn/go instead of layer abstractions to approximate the same result but with added (in my view unneccesary) keywords. Can anyone provide some insight?

go-style csp is just async/await hidden in the syntax.

Re: Rust 1.24

#156

Post by dbaupp »

RX14 wrote: post #151
ComputerGuru wrote: post #142

Earlier quoted context omitted.

Ugh. Every time I see tokio or futures-rs mentioned, a part of me dies. The syntax and ergonomics of rust futures ATM is insanely painful and slows down development 100x in some cases (not exaggerating) due to the current lack of async/await combined with hard typing requirements coupled with some very unreasonable design decisions (namely, each future generates as the result of a computation on a previous future has…

I've never quite understood the benefits of async/await over go-style csp. It seems to me that its far better to just write sequential code all the time then mark all the points where you add parallelism with spawn/go instead of layer abstractions to approximate the same result but with added (in my view unneccesary) keywords. Can anyone provide some insight?

Async/await can be cheaper given other constraints, e.g. Go ends up using a lot of GC infrastructure to keep stacks small/minimize memory use, which makes FFI to C-style languages expensive.

If syntax is all that matters, then sequential code is great, but there's more than that for many tasks.

(In any case, Go is adding layers of abstraction too: it is exposing a sequential interface over the OS's async APIs, whereas async/await is typically exposing them more directly.)

Re: Rust 1.24

#157

Post by dbaupp »

ComputerGuru wrote: post #142
fafhrd91 wrote: post #42

tokio-minihttp is 1 in plaintext benchmark in TechEmpower Web frameworks benchmark https://www.techempower.com/benchmarks/#section=data-r15&hw=...

Ugh. Every time I see tokio or futures-rs mentioned, a part of me dies. The syntax and ergonomics of rust futures ATM is insanely painful and slows down development 100x in some cases (not exaggerating) due to the current lack of async/await combined with hard typing requirements coupled with some very unreasonable design decisions (namely, each future generates as the result of a computation on a previous future has…

> some very unreasonable design decisions (namely, each future generates as the result of a computation on a previous future has a different type, even if they resolve to the same types upon evaluation of the future - basically abusing the type system to store the futures chain

If you don't need the performance, you can get back to the dynamic-language world by boxing everything (.boxed()). The generics approach lets everything be compiled down to a single state machine, exactly like Iterator.

Re: Rust 1.24

#158

Post by [deleted] »

coldtea wrote: post #136
civility wrote: post #99

Earlier quoted context omitted.

Not going to budge an inch, eh? It must be as good as it will ever get.

Is it they who didn't "budge an inch", or you, that despite a reasoned explanation, insist on the original accusation? Not to mention the underlying insinuation, that the Rust compiler developers are dumb for not being able to get at the 80s compiler's level of speed -- since you don't seem to accept that this is a byproduct of the advanced optimizations and security guarantees they do.

[deleted]

Re: Rust 1.24

#159

Post by lmm »

RX14 wrote: post #151
ComputerGuru wrote: post #142

Earlier quoted context omitted.

Ugh. Every time I see tokio or futures-rs mentioned, a part of me dies. The syntax and ergonomics of rust futures ATM is insanely painful and slows down development 100x in some cases (not exaggerating) due to the current lack of async/await combined with hard typing requirements coupled with some very unreasonable design decisions (namely, each future generates as the result of a computation on a previous future has…

I've never quite understood the benefits of async/await over go-style csp. It seems to me that its far better to just write sequential code all the time then mark all the points where you add parallelism with spawn/go instead of layer abstractions to approximate the same result but with added (in my view unneccesary) keywords. Can anyone provide some insight?

With async/await you can tell from the type signature whether a given function might suspend, and then reading through the body you can see whether each function call is a non-suspending one or a possibly-suspending one. It makes it really obvious what's doing what. If suspension is your only effect then it probably doesn't matter (one unmanaged effect is ok), but when you have other effects that might interact, having all the suspension points be explicit is really useful. https://glyph.twistedmatrix.com/2014/02/unyielding.html gives one example.

Re: Rust 1.24

#160

Post by RX14 »

steveklabnik wrote: post #28
XR0CSWV3h3kZWg wrote: post #25

Is rustfmt fast enough to reasonable be put on a save hook?

I went into one of my projects and did a `cargo fmt`, took 2.2 seconds. Dunno if that's within your tolerances or not. I personally have CI check it, rather than on save.

I know it's fairly pointless performance bashing but I just couldn't stop myself :)

    # In the crystal-lang/crystal repo
    $ find . -name '*.cr' -print0 | wc -l --files0-from=- | tail -n 1
    252745 total
    
    $ time bin/crystal tool format
    Using compiled compiler at `.build/crystal'
    bin/crystal tool format  0.62s user 0.04s system 106% cpu 0.625 total
and only 48ms to formal the longest file in crystal (the parser)!

Performance makes little practical difference as long as formatting a single file is fast enough to be on-save, but it does highlight the very interesting way that the crystal formatter is implemented. I'm not sure how rustfmt is implemented but crystal's formatter parses the file into the AST, and then does a single visitor pass of the file, in order, with a lexer in tow. It then basically reconstructs the entire file from scratch using the data both from the AST and the lexer (the AST visitor pass and lexer position have to be kept in sync). And surprisingly enough, this doesn't even make the formatter "too strict" in the way that it wipes out all existing style information as one would expect. It's a really cool - if a little messy - tool and one of I think my favorite parts of crystal (it doesn't have any config options either).

Post reply on HN