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

131–140 of 147 posts

Re: Thoughts on what a next Rust compiler would do

#131

Post by spoiler »

tialaramex wrote: post #92
spoiler wrote: post #61

Earlier quoted context omitted.

You don't technically need the macro to print hello world. However, the macro is useful due to format strings, which are also type-checked (eg to checks if the args implement `Display` or `Debug`, etc). The good thing about the default hello world example is that it introduces you to both language features without being overwhelming (IMO). You can read more about format strings here: https://doc.rust-lang.org/std/fmt…

Right, the canonical C "Hello, World!" uses C's formatted print, even though obviously it's not formatting anything, so it seems appropriate for Rust to do the same. It would be more impressive if Rust had an actual type checked variadic print format function like C++ 23's std::println - nobody should be under any false impression about how impressive that feature is, but the type safe macro is effective, that'll do…

I think Rust is probably working towards features like this. They've added partial const generics only a year ago, and I'm not sure what the stance on variadic functions is, but unless they're considered bad, they might get added too.

AFAIK C++ does format string parsing at runtime (as you need to provide a parser function), but maybe it can be made constexpr? I've not written C++ for over a year now so my fluency is fleeting a bit

Re: Thoughts on what a next Rust compiler would do

#132

Post by WinstonSmith84 »

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

Go production build is quite small as much as I can say, but I don't understand much at compilers so I will not discuss this. I've a lot of hands on experience with both Go and Rust, and on mid size project, an incremental production build in Go will take less than 1 second, whereas a development (non release) incremental build in Rust will take 10/15s (something as simple as a `println!` update). It's subjective, but it's not much exaggerated to tell that a Go prod build is >10x faster than a Rust dev build

So, I get your point for production build, that it needs some special optimization that maybe doesn't happen for Go, but I don't need any optimization when doing Dev testing and this could well remain totally unoptimized. Then I would at least expect for an "un-optimized" dev Rust build to be roughly as fast as a production Go build. At least not >10x slower

Re: Thoughts on what a next Rust compiler would do

#133

Post by stefncb »

jug wrote: post #50
stefncb wrote: post #17

Earlier quoted context omitted.

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 t…

Go is fast, cgo is slow. Cgo is also annoying to set up on windows. It kills the simplicity of a simple go build.

Re: Thoughts on what a next Rust compiler would do

#134

Post by tetromino_ »

mr_00ff00 wrote: post #124
Dylan16807 wrote: post #122

Earlier quoted context omitted.

> Rust isn’t as safe as GCed language Safe rust should be. And C# is a notable example of a GCed language that also has 'unsafe'. Along with most of the GCed languages with FFIs.

Safe rust can still use crates with unsafe rust, so no. Unless it’s safe rust and uses no outside code or none of its dependency tree has unsafe rust. It’s pretty crazy how many people will argue this point and downvote comments about it. It’s like a C++ dev claiming they never write memory bugs. I love rust, but the community pretending like memory safety bugs are impossible is as annoying as people claiming memory…

> Safe rust can still use crates with unsafe rust

Every language ecosystem that I have used has a good subset of its popular libraries implemented in memory-unsafe languages (usually C or C++), and the use of these libraries is typically unavoidable if you need high performance or to interact with the OS. Which is to say, most large projects in GC languages end up pulling in memory-unsafe dependencies.

Rust's advantage is that at least your dependencies are not 100% unsafe code, but have unsafe parts limited to small, easily auditable blocks.

Re: Thoughts on what a next Rust compiler would do

#135

Post by TheDong »

bdickason wrote: post #110
TheDong wrote: post #91

Earlier quoted context omitted.

> It defaulted to the fully backwards compatible version (vs 2021) "cargo init" and "cargo new" default to the 2021 edition, and have ever since it was stabilized: https://github.com/rust-lang/cargo/pull/9800 Either you accidentally installed a version of cargo from before the 2021 edition was stabilized, or you ran "cargo new --edition ", or you started by cloning an out of date project of some sort, in which case i…

Thanks this is helpful! I started my project without cargo at first and tried to start writing code without a cargo.toml. I was surprised that cairo didn't default to 2021 until I specified it in the .toml file. Good point that cargo init/new would have solved this! I guess my point about the compiler was that it seems to rely on cargo.toml for many 'optimizations' that I would expect to be defaults. (Examples includ…

Ah, yeah, hand-writing a Cargo.toml like that does run into that issue.

However, I don't think the solution is a better default, but rather the solution is time-travel.

Defaulting to the latest edition would mean that any rust library that predates editions would likely break when you imported it (since it would default to an edition that didn't exist when it was written, and editions are allowed to make breaking changes of that sort).

The thing that would fix your issue would be time-traveling back in time to when cargo was created, and making edition a required field of all cargo.toml files that results in an error until you add one. That would have saved you from any trouble.

Rust could also do a python2 -> python3 like transition, where crates from the old "edition not required" world can't be imported anymore at all, but that seems like a very small thing to cause so much ecosystem pain over.

Re: Thoughts on what a next Rust compiler would do

#136

Post by Alifatisk »

eminence32 wrote: post #93
thagsimmons wrote: post #47

Earlier quoted context omitted.

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…

I'm curious what are your actual compile times? What does "painfully long" mean for you and your workflow? 15 seconds? 2 minutes? 15 minutes?

Painfully long to me is everything over 5 seconds.

Re: Thoughts on what a next Rust compiler would do

#137

Post by baq »

Too wrote: post #121
baq wrote: post #5

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

For someone who hasn’t written any larger rust programs. Is the compile time worse than c++?

Same order of magnitude, i.e. depends, but really bad if you actually use the language.

Re: Thoughts on what a next Rust compiler would do

#138

Post by gnuvince »

loeg wrote: post #43
sk0g wrote: post #33

Earlier quoted context omitted.

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

The Rust dev builds are very often (1) slower to build than the equivalent Go program, (2) slower to run than the equivalent Go program. Rust programs really need the `--release` flag to shine—and in some cases, the dev builds of a program cannot be meaningfully used, even for local testing, since they're so slow.

Re: Thoughts on what a next Rust compiler would do

#139

Post by majewsky »

stefncb wrote: post #128
oconnor663 wrote: post #40

Earlier quoted context omitted.

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.)

That's not what I'm saying. I want rust, but with the simplicity of go. I want a compiler that's super portable and it itself compiles in a few minutes. I want a straightforward build system that doesn't leave me confused. I want less language features. I also want a more lightweight syntax but beggars can't be choosers.

You can only add so many constraints to a problem until it becomes unsolvable.

It's like saying "I would like to have a non-volatile storage device that is as long-lasting as microfilm, as fast as an SSD and as cheap as a HDD." At some point, you have to renege on at least one of your constraints.

Re: Thoughts on what a next Rust compiler would do

#140

Post by stefncb »

majewsky wrote: post #139
stefncb wrote: post #128

Earlier quoted context omitted.

That's not what I'm saying. I want rust, but with the simplicity of go. I want a compiler that's super portable and it itself compiles in a few minutes. I want a straightforward build system that doesn't leave me confused. I want less language features. I also want a more lightweight syntax but beggars can't be choosers.

You can only add so many constraints to a problem until it becomes unsolvable. It's like saying "I would like to have a non-volatile storage device that is as long-lasting as microfilm, as fast as an SSD and as cheap as a HDD." At some point, you have to renege on at least one of your constraints.

Fair point, but I don't think my constraints are _that_ extreme. I think it's doable, but we'll never know unless someone seriously attempts it.
Post reply on HN