How much faster can the compiler be? This is the top issue with rust IMHO - compile times are real bad.
This is absolutely a pain point for us, working on a very large Rust project. In particular, incremental compile times are absolutely critical for developer comfort, and by far the most common complaint working on our codebase is that developer tooling, IDEs and running unit tests is slow. We've done everything that can reasonably be done - splitting the project into crates, using mold as a linker (the single biggest…
Thoughts on what a next Rust compiler would do
71–80 of 147 posts
Re: Thoughts on what a next Rust compiler would do
#72Earlier quoted context omitted.
For me, its the lifetime syntax I don't like the most. It doesn't feel "ergonomic" to type something like . Its mostly the ` I wish were different.
(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.
Re: Thoughts on what a next Rust compiler would do
#73This sounds great, but I don't think Rust has the complement of highly skilled core developers needed to tackle something this ambitious. I'm a close observer of the Rust project, and my impression is that Rust's core development team has been hollowed out over the past few years - there's been a string of quiet departures, which sadly included some of the most powerful contributors. The Rust project is quite secreti…
> I'm a close observer of the Rust project, and my impression is that Rust's core development team has been hollowed out over the past few years - there's been a string of quiet departures, which sadly included some of the most powerful contributors. Can you give more specifics on this?
The biggest name that left was Steve Klabnik. He made some statements that made it sound like he was upset with Amazon's involvement in the language, but as I recall it he didn't really go into any specifics so I don't really know.
Re: Thoughts on what a next Rust compiler would do
#74Earlier quoted context omitted.
> I'm a close observer of the Rust project, and my impression is that Rust's core development team has been hollowed out over the past few years - there's been a string of quiet departures, which sadly included some of the most powerful contributors. Can you give more specifics on this?
I don't want to list specific contributors here. We often have no information on why people left the project - there might be all sorts of personal factors. I will say that my broader sentiment - that Rust's momentum has slowed, that it's not delivering on its commitments in a timely way, that there are concerns about it's ability to deliver in future - has been expressed publicly by high profile past core contributo…
Most of the high-profile departures from the compiler happened in the wake of the 2018 edition (the first new edition since 1.0, and the edition that had to invent the very notion of "edition"), where a lot of people pushed themselves far too hard to deliver on what would be, in retrospect, far too aggressive of a release deadline. The edition just barely made it out in the 2018 calendar year, after getting delayed a handful of times, but it resulted in massive burnout among those contributing to its features, including the person who wrote the comment linked above. In practice Rust has actually been recovering quite nicely over the past few years after reaching a nadir of volunteer motivation in 2019; https://github.com/rust-lang/rust/pulse/monthly tells me that 178 discrete authors have contributed to just the rust-lang/rust repo over the past month.
Re: Thoughts on what a next Rust compiler would do
#75Earlier quoted context omitted.
> I'm a close observer of the Rust project, and my impression is that Rust's core development team has been hollowed out over the past few years - there's been a string of quiet departures, which sadly included some of the most powerful contributors. Can you give more specifics on this?
The biggest name that left was Steve Klabnik. He made some statements that made it sound like he was upset with Amazon's involvement in the language, but as I recall it he didn't really go into any specifics so I don't really know.
While there was some stink around his departure, he's not one of the contributors I'm concerned about here. I'm thinking more of people working on deep technical issues around the language and type system.
Re: Thoughts on what a next Rust compiler would do
#76Earlier 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…
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.
Re: Thoughts on what a next Rust compiler would do
#77Earlier quoted context omitted.
> I'm a close observer of the Rust project, and my impression is that Rust's core development team has been hollowed out over the past few years - there's been a string of quiet departures, which sadly included some of the most powerful contributors. Can you give more specifics on this?
I don't want to list specific contributors here. We often have no information on why people left the project - there might be all sorts of personal factors. I will say that my broader sentiment - that Rust's momentum has slowed, that it's not delivering on its commitments in a timely way, that there are concerns about it's ability to deliver in future - has been expressed publicly by high profile past core contributo…
Thanks for linking that thread, it's an interesting discussion. I didn't realis GATs were so polarising. I understand why, but it was my assumption that everyone was okay with the limitations, and that it would eventually be lifted (similar to how NLL and GAT lift limitations currently)
Re: Thoughts on what a next Rust compiler would do
#78Earlier quoted context omitted.
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 compa…
[deleted]
Re: Thoughts on what a next Rust compiler would do
#79Earlier quoted context omitted.
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.
If you want blazing fast and very scalable performance, you have to do that. Multiple independent contexts in the kernels can have a reference on certain objects and manipulate them concurrently with relaxed consistency. It would be very impractical to hard-protect certain parts of those objects and guarantee serial consistency. For scalability and performance reasons, certain data structures, objects or certain parts of certain objects could be accessed in a inherently racy manner, but guaranteeing correctness in the existence of races is extremely hard. Any attempt for modularisation, message passing or serial consistency would make your kernel look like a joke compared to Linux. It would make the interaction between subsystems easy but would not provide the opportunity for very fast low latency execution.
Re: Thoughts on what a next Rust compiler would do
#80There 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.
It seems in terms of web dev related crates, admittedly a niche for Rust, there have been quite a bunch of abandoned, unfinished projects and other stability issues.
There also seems to be a general trend towards sophistication and away from simplicity. That’s a tradeoff that makes me personally wary, rather than excited at this point in my life.
Much of that is to be expected, given the age and the unique value props of the language. But the stability to hype ratio seems unattractive overall, even though the language and tooling are great to a large extent.