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

141–150 of 215 posts

Re: Rust 1.24

#141

Post by ComputerGuru »

nine_k wrote: post #105
civility wrote: post #96

Earlier quoted context omitted.

Oberon certainly compiles quickly, and I believe Delphi (Pascal-ish) was fast too, but I was thinking of Microsoft's Java compiler before they got spanked.

Java without generics used to compile pretty fast. When you add generics, lifetimes, and type inference, the amount of work the compiler does grows significantly. It allows to check much more interesting invariants, leading to the "if it compiles, it runs correctly" effect.

Basic generics in rust don’t have that much overhead; it sounds like your conflating generics with templating. Generics aren’t Turing complete, unlike C++’s templates.

Other languages with powerful generics and type inference like modern C# clearly manage just fine, too.

Re: Rust 1.24

#142

Post by ComputerGuru »

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 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. Combined with the very strongly typed nature of rust, even with experimental language features like “impl future” the code becomes impossibly hard to reason about.

For example, the result of future.or returning a future bool is not the same type as the result of future.and similarly returning a future bool; and a two-level future evaluating to a future bool is not the same type as a one-level future also evaluating to a future bool.

async/await cannot come soon enough.

Re: Rust 1.24

#143

Post by themihai »

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.

Re: Rust 1.24

#144

Post by pcwalton »

civility wrote: post #108
pcwalton wrote: post #104

Earlier quoted context omitted.

I don't know what this means.

It means things don't usually get better until you admit they're not as good as they can be.

rustc could definitely be faster.

I'm simply pushing back on the idea that there's some obvious low-hanging fruit that clang did that rustc didn't. Compiler performance has more or less much been the #1 goal for well over a year now. The Rust compiler team (which hasn't included me for years, by the way) is fantastic. We'd all like for there to be some magic bullet that makes the compiler faster, but at this point I don't believe it exists. It's hard work from here on out.

Re: Rust 1.24

#146

Post by eptcyka »

ComputerGuru wrote: post #141
nine_k wrote: post #105

Earlier quoted context omitted.

Java without generics used to compile pretty fast. When you add generics, lifetimes, and type inference, the amount of work the compiler does grows significantly. It allows to check much more interesting invariants, leading to the "if it compiles, it runs correctly" effect.

Basic generics in rust don’t have that much overhead; it sounds like your conflating generics with templating. Generics aren’t Turing complete, unlike C++’s templates. Other languages with powerful generics and type inference like modern C# clearly manage just fine, too.

Yes, but things like `fn do_something(t: T) -> impl Future Where t: Serializable` definitely take a while. And C# has the added benefit of being JIT'ed, it doesn't have to flatten all the generic code during compilation, it can optimise later.

Re: Rust 1.24

#147

Post by tome »

lmm wrote: post #137
FullyFunctional wrote: post #48

Earlier quoted context omitted.

Well, O'Caml and Haskell predates Rust by decades. I was delighted to see Sum-Product types in Rust when I played with it. They go a long way to cleanly model the problem domain. Obviously you can simulate them, but it's much easier to get wrong or "cheat" (say having a bunch of fields, only some of which are valid depending on a tag).

> I was delighted to see Sum-Product types in Rust when I played with it. They go a long way to cleanly model the problem domain. Umm yeah, they've been a part of every ML-family language since the '70s, OCaml, Haskell and Rust included.

(FullyFunctional seems to understand this, as far as I can tell)

Re: Rust 1.24

#148

Post by pjmlp »

pcwalton wrote: post #75
civility wrote: post #72

Earlier quoted context omitted.

> Incremental compilation! Is there some algorithm in Rust which has a necessary big-O? There were compilers in the 90s which ran a million lines per second (on much slower computers). Incremental compilation feels like working around the problem rather than solving it, and I have to imagine the complexity and maintenance is much worse. I'm sure some of the LLVM optimization passes are expensive, but those are used i…

> There were compilers in the 90s which ran a million lines per second (on much slower computers). Those compilers performed nowhere near the level of optimization that modern compilers do. > I'm sure some of the LLVM optimization passes are expensive, but those are used in clang++ too, and it's not terribly slow. clang++ is sure slow if it has to rebuild an entire codebase from scratch. The main reason that C++ comp…

Have you guys spend any time with the incremental compilation and linking of Visual C++ or C++ Builder?

It really does make a difference versus traditional UNIX compilers.

Re: Rust 1.24

#149

Post by pjmlp »

eptcyka wrote: post #146
ComputerGuru wrote: post #141

Earlier quoted context omitted.

Basic generics in rust don’t have that much overhead; it sounds like your conflating generics with templating. Generics aren’t Turing complete, unlike C++’s templates. Other languages with powerful generics and type inference like modern C# clearly manage just fine, too.

Yes, but things like `fn do_something (t: T) -> impl Future Where t: Serializable` definitely take a while. And C# has the added benefit of being JIT'ed, it doesn't have to flatten all the generic code during compilation, it can optimise later.

C# could always be AOT compiled to dynamically linked native code via NGEN.

It is also the only deployment option on iDevices and Windows Store since Windows 8.

Also if you prefer other native examples, Ada, Eiffel, Sather, D come to mind.

Re: Rust 1.24

#150

Post by coffeeacc »

pcwalton wrote: post #78
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.

If rustfmt were not configurable, it would get a lot less use. Rust has been around for quite some time now, and there's a lot of code out there. We can't force anybody to run rustfmt, and if they don't like the results, they won't use it. It's not a choice between different code styles and a single code style; it's a choice between different code styles with a tool to keep things tidy and different code styles with…

Agreed - I am an example. I had vim format my rust code on save, but there was one single bit of formatting which drove me nuts, so I turned the plugin off.
Post reply on HN