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

31–40 of 147 posts

Re: Thoughts on what a next Rust compiler would do

#31

Post by acedTrex »

stefncb wrote: post #17
WinstonSmith84 wrote: post #15

Earlier quoted context omitted.

Once you're done fighting with the compiler (Rust Analyzer), it's actually very enjoyable and one can be _relatively_ productive. The language allows so much flexibility that it's very easy to produce well organized code... But the compiler is really slow. Even an incremental build on a mid size project is never below 10s, whereas on a similar size project, Golang will take me less than 1 second to build incrementall…

My personal issue with Rust isn't the borrow checker. I actually find it quite intuitive. What I don't like is the extreme complexity of everything. There's just so much... stuff. What I want is a Rust, but with almost everything stripped away. Complexity similar to Go.

so you want Go then?

Re: Thoughts on what a next Rust compiler would do

#32

Post by mlindner »

nonethewiser wrote: post #16
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…

Not OP but for me it's the syntax. I'm not even saying it's bad or could even be improved... I just don't find it intuitive. I've only sat down and walked through some of the learn rust book and tried to hack out a few small things. I'm not sure what it is - there just always seem to be random symbols that dont seem to follow conventions of other languages. Guess I am use to C-style (including C++, C#, JS) syntax and…

New syntax is pretty easy to pick up. It's just window dressing.

What you're actually seeing is a trap a lot of programmers fall into where if something is unfamiliar then it's treated as if it's incorrect.

Re: Thoughts on what a next Rust compiler would do

#33

Post by sk0g »

bonzini wrote: post #27
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 Go compiler is barely an optimizing compiler. Rust needs massive amounts of inlining to avoid the performance cost of abstractions, and after inlining the code needs to be cleaned up. In this respect it isn't unlike C++.

Does anyone particularly care if development builds inline much? If you can get Go-like compile speeds for development iteration, and the current ones for release, it would be the best of both worlds for me.

Re: Thoughts on what a next Rust compiler would do

#34

Post by zozbot234 »

afr0ck wrote: post #18
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…

In real world software, you need lots of freedom in order to design high performance scalable systems. This includes using non-trivial data structures, and being able to access and organise memory in subtle ways. The Linux kernel is an example of this. Look at the reclaim subsystem in the kernel, for instance, and how it interacts in subtle and very complex ways with various other subsystems, the page cache, the gene…

The problem with "subtle and very complex" interactions is that they don't really scale to larger systems. They're inherently anti-modular, since they depend on the state of the program as a whole. This is exactly what's avoided in Safe Rust.

Re: Thoughts on what a next Rust compiler would do

#35

Post by alkonaut »

WinstonSmith84 wrote: post #22
baq wrote: post #5

How much faster can the compiler be? This is the top issue with rust IMHO - compile times are real bad.

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?

It could, if it stopped doing a lot of things it does which the Go compiler doesn’t.

Or of course if the Go compiler started doing them so it became a lot slower.

One example is “full”monomorphization of generics. But there are lots of such examples.

Usually though I find the Rust compilation speed a non issue, so long as “cargo check” and the IDE analysis is great, I just rarely compile to begin with.

Re: Thoughts on what a next Rust compiler would do

#36

Post by cxr »

bonzini wrote: post #27
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 Go compiler is barely an optimizing compiler. Rust needs massive amounts of inlining to avoid the performance cost of abstractions, and after inlining the code needs to be cleaned up. In this respect it isn't unlike C++.

The reference compiler needs a lot of time to make the resulting binary fast, okay fine. But where's the rust-lang.org group's fork of the golang.org group's `go build` tool modified to accept source files written in the Rust language as input and that (quickly) outputs a binary with a performance profile no faster or slower an equivalent program written in Golang? ~15 years of compiler research is too long and comparisons between the two languages (however fair or un-) are too numerous for there to be any excuse for this not to exist, and yet

Re: Thoughts on what a next Rust compiler would do

#37

Post by loeg »

TylerE wrote: post #4

I say this with great respect, but the thing keeping me from Rust isn't the compiler, it's the language.

That's fine. It doesn't have to be everything to everyone. We probably don't need this kind of comment on every single article about Rust, though. (Or similar generic "I don't like this language" comments on any article related to any programming language.)

Re: Thoughts on what a next Rust compiler would do

#38

Post by Animats »

There are already at least two Rust compilers, now that there's a GCC version. That's good; it means the language becomes stronger than the implementation.

Right now, the weak points are mostly library side. Too many 0.x version crates where the API is still in flux.

Re: Thoughts on what a next Rust compiler would do

#39

Post by [deleted] »

bonzini wrote: post #27
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 Go compiler is barely an optimizing compiler. Rust needs massive amounts of inlining to avoid the performance cost of abstractions, and after inlining the code needs to be cleaned up. In this respect it isn't unlike C++.

[deleted]

Re: Thoughts on what a next Rust compiler would do

#40

Post by oconnor663 »

stefncb wrote: post #17
WinstonSmith84 wrote: post #15

Earlier quoted context omitted.

Once you're done fighting with the compiler (Rust Analyzer), it's actually very enjoyable and one can be _relatively_ productive. The language allows so much flexibility that it's very easy to produce well organized code... But the compiler is really slow. Even an incremental build on a mid size project is never below 10s, whereas on a similar size project, Golang will take me less than 1 second to build incrementall…

My personal issue with Rust isn't the borrow checker. I actually find it quite intuitive. What I don't like is the extreme complexity of everything. There's just so much... stuff. What I want is a Rust, but with almost everything stripped away. Complexity similar to Go.

It's worth pointing out that if you say "Go except with Rust's guarantees for thread safety", a _lot_ of the complexity comes back. You need to pull in lifetimes and move semantics and the no-mutable-aliasing rule. You need the Send and Sync traits. You probably want Deref-based smart pointers too. (And you'd need to make extensive use of the new generics features that are already in Go.)
Post reply on HN