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

41–50 of 147 posts

Re: Thoughts on what a next Rust compiler would do

#41

Post by loeg »

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?

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 -O0.5) with compilation time vs performance tradeoff similar to Go, but it isn't there today. There's also an attempt to adopt a more simplistic backend (cranelift) into Rustc to improve codegen performance, but so far it hasn't provided much speedup.

Re: Thoughts on what a next Rust compiler would do

#42

Post by thagsimmons »

This 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 secretive and opaque about its internal politics, so I don't know if there's any unified reason for the attrition, and I don't think it's useful to try to read the tea leaves. At this point, I'm just keen to be reassured that Rust has the momentum to complete things like async and shore up holes in the type system on a reasonable timescale.

Re: Thoughts on what a next Rust compiler would do

#43

Post by loeg »

sk0g wrote: post #33
bonzini wrote: post #27

Earlier 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++.

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.

In fact, that's exactly why cargo's default for dev builds is -O0: https://doc.rust-lang.org/book/ch14-01-release-profiles.html...

Re: Thoughts on what a next Rust compiler would do

#44

Post by alphanullmeric »

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.

It would actually be such an amazing language if it wasn’t so verbose. There are so many places where more concise syntax wouldn’t even hurt safety and they forgo it anyways. But here we are, where macros are required for a hello world.

Re: Thoughts on what a next Rust compiler would do

#45

Post by the_mitsuhiko »

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.

I would be quite impressed if there was a way to have Rust with "less stuff". It's not like there is a lot stuff that can be removed without making the language quite useless.

Re: Thoughts on what a next Rust compiler would do

#46

Post by nicoburns »

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…

Interestingly very little of Rust's syntax is novel (the exception being lifetimes which of course don't exist in other languages). The closest language syntacticly is probably TypeScript (you'd be surprised how many programs are actually valid in both Rust and Typescript!). And where syntax doesn't match TypeScript it usually matches something else common. For example the `self` parameter in methods comes from Pythong, and the closure syntax comes from Ruby

Re: Thoughts on what a next Rust compiler would do

#47

Post by thagsimmons »

baq wrote: post #5

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 improvement), etc. Without a really big improvement to incremental compile, we will have a continuing drag on our development momentum.

Re: Thoughts on what a next Rust compiler would do

#48

Post by josephg »

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…

> Rust is as unsafe as C and it's just making your life harder for no reason, except hype.

I hear what you’re saying, but that hasn’t been my experience with rust. I love C, but I’ve been writing rust for the last couple of years. And rust has stolen my heart.

You’re right that unsafe rust is a bit less ergonomic than just writing C. Sometimes I miss void pointers. I definitely miss how fast C compiles. But most rust isn’t unsafe rust. Even deep in my custom in-memory btree implementation I think more than half of my methods are safe. And safe rust is a fabulous language when you can use it. There’s all these bugs you just can’t write.

Early on with rust I had this magical experience. My program segfaulted in one of my tests because of memory corruption. It was “spooky action at a distance” where the segfault happened well after the buggy code was executed. Bugs like this are awful to track down in C because the bug could be literally anywhere. But when I looked at the trace, there was only one unsafe function which could be causing the problem. (Since I could rule out all my safe code). Sure enough, 10 minutes later I had a fix.

I have a skip list for large strings that I ported from C to rust. I still have no idea why, but the rust code ran about 20% faster out of the box than the original optimized C code. And yet, the code is significantly smaller and easier to work with. I’ve added a few more optimizations since then - it’s about 10x faster than the C code now. The new optimizations are all from tricks I never got around to adding in C because I was afraid I might break something.

And then there’s the things rust does well that aren’t in C at all. Cargo is incredible. Monomorphization is the right tool for a lot of problems, like custom collections. (Higher performance and types? Yes please!) Parametric enums & match statements are so much better to work with than C enums and unions. Then there's rust's std, which is fantastic. I use Option, Result, Vec, BtreeMap, PriorityQueue, the OS-agnostic filesystem API, and so on daily.

So yeah, I hear you about C being lovely. But I think rust is even better. Rust is a bit of an ordeal to learn but I'm really glad I learned it. Its a joy to use.

Re: Thoughts on what a next Rust compiler would do

#49

Post by TylerE »

loeg wrote: post #37
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.)

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.

Re: Thoughts on what a next Rust compiler would do

#50

Post by jug »

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.

I just use Go (or Nim) for native. It’s not comparable in goals and what Rust tries to do at all. But Go compiles super fast, is very fast, solves the glaring C safety issues, very keen on helping you with threads, and has a very fast garbage collector. If I run into performance problems, it’s not because of Go. But yeah Rust has its place in certain scenarios. I still hesitate to call it general purpose though — I think it’s best suited for stuff that underpins applications/usermode. And I don’t think it can be made much less obnoxious.
Post reply on HN