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

141–147 of 147 posts

Re: Thoughts on what a next Rust compiler would do

#141

Post by alphanullmeric »

JoshTriplett wrote: post #57
alphanullmeric wrote: post #44

Earlier quoted context omitted.

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.

> There are so many places where more concise syntax wouldn’t even hurt safety and they forgo it anyways. Can you give some examples of this? If there are ways we could simplify the language without hurting existing use cases, we should consider doing so.

No default arguments, named parameters, variadic functions and generics, no C-style arrow operator, the whole default trait thing (why can’t you shorten it to just `..`?). And a bunch of awful reasoning to defend these decisions. Named function arguments are bad but `Iterator` is fine? Default arguments are bad but default trait implementations are fine? Something something implicit behaviour but type inference is ok? It’s to the point where idiomatic rust means writing a three different structs and enums to call a function.

Re: Thoughts on what a next Rust compiler would do

#142

Post by nequo »

stefncb wrote: post #140
majewsky wrote: post #139

Earlier quoted context omitted.

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.

What language features would you like to take away from Rust?

Re: Thoughts on what a next Rust compiler would do

#143

Post by nequo »

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

The quick-lint-js project ported a part of their code from C++ to Rust. Rust's compilation time scaled less well with the size of the code base. Here is a detailed report:

https://quick-lint-js.com/blog/cpp-vs-rust-build-times/

Re: Thoughts on what a next Rust compiler would do

#144

Post by satvikpendem »

mr_00ff00 wrote: post #125
satvikpendem wrote: post #120

Earlier quoted context omitted.

> you don’t need systems level speed on a backend API. I do, actually. > but memory vulnerabilities are found in cargo packages because of unsafe code. Forbid unsafe in your config and you're good.

Correct me if I am around, but Forbid unsafe does not include dependencies, which can and do have unsafe rust.

You can use cargo-geiger to check whether dependencies have unsafe code too, along with your own code.

Re: Thoughts on what a next Rust compiler would do

#146

Post by loeg »

gnuvince wrote: post #138
loeg wrote: post #43

Earlier quoted context omitted.

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.

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

Re: Thoughts on what a next Rust compiler would do

#147

Post by adamddev1 »

smt88 wrote: post #19
TylerE wrote: post #11

Earlier quoted context omitted.

The borrow checker. The syntax. It isn't a good fit for my needs. It'd be like using a forklift to move a few books. I'm not generally a fan of strong explicit typing/high ceremony in general.

> strong explicit typing/high ceremony If you think strong typing is "ceremony" then you probably spend most of your time writing (and documenting) code and not reading, refactoring, or collaborating on it. The time people spend writing unnecessary, buggy unit tests (that static analysis can do in better languages) is far greater than the time to just use the type system. Most languages don't even force you to be exp…

> The time people spend writing unnecessary, buggy unit tests (that static analysis can do in better languages) is far greater than the time to just use the type system.

Absolutely. Thank you for speaking truth.

Post reply on HN