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

Thoughts on what a next Rust compiler would do

matklad.github.io

Post reply on HN
Print view View original

81–90 of 147 posts

Re: Thoughts on what a next Rust compiler would do

#81

Post by echelon »

TylerE wrote: post #11
echelon wrote: post #7

Earlier quoted context omitted.

What about the language do you dislike? It's a strongly typed Ruby with generics. Edit: trait-based OO is a breath of fresh air compared to tree-style class inheritance. Super flexible without having to overthink. Immutable by default is reassuring, Option/Result are fantastic null/exception replacements. Enums and match blocks are powerful and gracefully help ensure handling of all cases, have nice syntax, and work…

The borrow checker. The syntax. It isn't a good fit for my needs. It'd be like using a forklift to move a few books. I'm not generally a fan of strong explicit typing/high ceremony in general.

You don't see the borrow checker. It manifests itself in encouraging RAII inspired writing and logical flow.

Lifetime annotations help how you use and exchange certain data, but you can get away without them unless you need them. For shared data structures (when synchronization primitives are too much) and highly performant code.

You can write high level Java, Ruby, and Python code in Rust if you want to. Writing Actix or Axum web handlers feels no different than Golang or Python/Flask.

Re: Thoughts on what a next Rust compiler would do

#82

Post by josephg »

loeg wrote: post #55
TylerE wrote: post #49

Earlier quoted context omitted.

Then we equally don’t need pro rust comments on literally every other thread Since a major thrust of the linked article is barriers to rust adoption it seemed relevant.

> Then we equally don’t need pro rust comments on literally every other thread Correct.

Eh. Every article about Go has the same thing - where regardless of the content of the article people discuss the pros and cons of the language itself.

I think it’s a symptom of there not being enough places where adherents of different programming ecosystems can argue back and forth about our choices. I think there’s an unmet need in our community to have those conversations, and there’s probably something healthy in that.

It definitely distracts from the specifics of the article though. The corresponding discussion on reddit is much more technical:

https://reddit.com/r/rust/comments/10ld2vn/blog_post_next_ru...

Re: Thoughts on what a next Rust compiler would do

#83

Post by Thiez »

loeg wrote: post #41
WinstonSmith84 wrote: post #22

Earlier quoted context omitted.

Any reasons why it could not be as fast as the Go compiler? Maybe GC and the borrow checker could slow down a bit, but apart from that?

The borrow checker is not an insignificant cost. Maybe you could imagine an incremental compilation mode that just didn't evaluate the borrow checker for faster development. As other commenters have noted, the Go backend is extremely simplistic ("barely an optimizing compiler"). Rustc is also a lot faster in -O0 mode than any optimizing mode. But -O0 is somewhat dumber than Go's compiler. You could imagine an -O1 (or…

Apart from rare pathological cases borrow checking is not a significant part of compilation time. Disabling it would be very detrimental for little gain.

Re: Thoughts on what a next Rust compiler would do

#84

Post by JoshTriplett »

tcmart14 wrote: post #72
JoshTriplett wrote: post #58

Earlier quoted context omitted.

(Aside: it's 'a , not `a.) One of the hopes is that it's usually not necessary to write those lifetimes explicitly in most programs, unless you're doing something unusual. If you could go back and change it, what would you have used for the lifetime syntax?

Good question. Thinking about it, I would choose '@'. So only when I read something like: fn print_one (x: &'a i32) using @ fn print_one (x: &@a i32) I can would see it as I sort of semantically read it. Function print_one AT lifetime of a.

Fair enough. I agree that that would have been more evocative of meaning. On the other hand, I also think that this:

&'a X

looks less like Perl / line noise than this:

&@a X

. In any case, not something we'd be likely to change at this point, but I agree that ' is effectively "arbitrary unique symbol with no evocative meaning".

(Arguably the same is true for things like & for "address of", but that has a long history in many languages which makes it more intuitive for current developers.)

Re: Thoughts on what a next Rust compiler would do

#85

Post by tialaramex »

choeger wrote: post #60
tomsmeding wrote: post #52

Earlier quoted context omitted.

> Even if this turns out to be futile, the actual specialization only needs to change very few things in the code, so monomorphization could effectively be handled by a dynamic linker. This is true in only the simplest case. Already if you have a polymorphic function that sums the elements of an array, you'll be doing function calls to string concatenation if those elements are strings but would really like the vecto…

> Specialisation is something that should happen before the optimiser. That's true, but your example shows a very important point: These cases are limited and (in current languages) known by the compiler developers. I don't know a language that would allow a user-defined datatype to come with such specific optimizations. So for today's languages one could probably enumerate the special optimizations before specializa…

I must not be understanding your idea at all, because it seems to me in both Rust and C++ you can just give user-defined data types completely different behaviour which doesn't occur in any of their built-in types which would be impossible with what you're suggesting.

Re: Thoughts on what a next Rust compiler would do

#86

Post by zarzavat »

Thiez wrote: post #76
tcmart14 wrote: post #51

Earlier quoted context omitted.

The slow compile times I look at as a trade off. Rust does a lot more during it's compile phase than most other compilers and there is a cost. Do I do all this static analysis and eat time here to hopefully reduce runtime bugs and subsequently the time to debug runtime bugs? It takes me a whole lot longer to debug something with a debugger than if the compiler can catch it. I do 100% agree on your commends on cross c…

For the vast majority of programs most time is spent in code generation/optimization. Rusts static analysis is not why compilation is slow.

Optimisation happens in release builds. I assume when people talk about compilation speed they mean debug builds because those are the ones you have to wait for.

For me the biggest hurdle to adopting Rust is that rust-analyser turns my laptop's fans up to 11. I don't know whose problem that is, but it doesn't happen with other languages, and my black box impression of rust's compilation infrastructure is that it's fucked up.

Re: Thoughts on what a next Rust compiler would do

#87

Post by josephg »

Thiez wrote: post #76
tcmart14 wrote: post #51

Earlier quoted context omitted.

The slow compile times I look at as a trade off. Rust does a lot more during it's compile phase than most other compilers and there is a cost. Do I do all this static analysis and eat time here to hopefully reduce runtime bugs and subsequently the time to debug runtime bugs? It takes me a whole lot longer to debug something with a debugger than if the compiler can catch it. I do 100% agree on your commends on cross c…

For the vast majority of programs most time is spent in code generation/optimization. Rusts static analysis is not why compilation is slow.

Yeah … I’ve done a lot of optimization work. (I love that sort of thing). I have an instinct that there’s at least an order of magnitude compilation performance gain possible with a different architecture for the compiler. Especially if you didn’t bother implementing a lot of llvm’s optimizations.

It’s just tricky because writing a new rust compiler is a monster amount of work because of how complex Rust is. And rearchitecting the existing compiler would also be a massive undertaking because there’s so much existing code, and it’s spread over rustc (written in rust) and llvm (in C++).

A faster compiler probably wouldn’t bother with all of llvm’s intermediate representations. Refactoring across a code boundary that spans two languages (and two projects) sounds utterly exhausting.

Re: Thoughts on what a next Rust compiler would do

#88

Post by bdickason »

I recently spun up a project in Rust (a small game using Bevy) and the main issues I ran into were around smart defaults for the compiler. I was surprised how many lines I had to add to my cargo.toml to just complete a simple game example.

Some examples:

It defaulted to the fully backwards compatible version (vs 2021) which threw errors as I went through some recent example code.

(I think) I had to add a few lines to my cargo.toml so the compiler would not rebuild bevy every time I recompiled (when I only changed 1 line in my program).

Re: Thoughts on what a next Rust compiler would do

#89

Post by Thiez »

JoshTriplett wrote: post #84
tcmart14 wrote: post #72

Earlier quoted context omitted.

Good question. Thinking about it, I would choose '@'. So only when I read something like: fn print_one (x: &'a i32) using @ fn print_one (x: &@a i32) I can would see it as I sort of semantically read it. Function print_one AT lifetime of a.

Fair enough. I agree that that would have been more evocative of meaning. On the other hand, I also think that this: &'a X looks less like Perl / line noise than this: &@a X . In any case, not something we'd be likely to change at this point, but I agree that ' is effectively "arbitrary unique symbol with no evocative meaning". (Arguably the same is true for things like & for "address of", but that has a long history…

I think way way back (about 10 years ago) the syntax was

    &x\a
The current tick is much easier on the eyes.

Re: Thoughts on what a next Rust compiler would do

#90

Post by MuffinFlavored »

TylerE wrote: post #14
MuffinFlavored wrote: post #13

Earlier quoted context omitted.

Curious, are you a fan of Typescript?

Never used it. I don't even have the need to touch vanilla javascript that often.

What do you primarily program in, Java? C#? Python?
Post reply on HN