3 ms·

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 c

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

sk0g 4y ago
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.
- loeg 4y ago
  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#:~:text=The%20default%20opt%2Dlevel%20for%20dev%20is%20therefore%200 https://doc.rust-lang.org/book/ch14-01-release-profiles.html...
  - gnuvince 4y ago
    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.
    - loeg 4y ago
      > 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. It could definitely be better, sure.
cxr 4y ago
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
- deleted 4y ago
  [deleted]
deleted 4y ago
[deleted]
WinstonSmith84 4y ago
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

sk0g 4y ago

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.

loeg 4y ago
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#:~:text=The%20default%20opt%2Dlevel%20for%20dev%20is%20therefore%200 https://doc.rust-lang.org/book/ch14-01-release-profiles.html...
- gnuvince 4y ago
  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.
  - loeg 4y ago
    > 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. It could definitely be better, sure.

cxr 4y ago

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

deleted 4y ago
[deleted]

deleted 4y ago

[deleted]

WinstonSmith84 4y ago

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