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

91–100 of 147 posts

Re: Thoughts on what a next Rust compiler would do

#91

Post by TheDong »

bdickason wrote: post #88

I recently spun up a project in Rust (a small game using Bevy) and the main issues I ran into were around smart defaults for the compiler. I was surprised how many lines I had to add to my cargo.toml to just complete a simple game example. Some examples: It defaulted to the fully backwards compatible version (vs 2021) which threw errors as I went through some recent example code. (I think) I had to add a few lines to…

> 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 it's not really an issue with "defaults".

> smart defaults for the compiler. I was surprised how many lines I had to add to my cargo.toml

Normally this would be a pointlessly pedantic point, but cargo is not the compiler. This thread, the linked title blog post, they are about the rust compiler, not cargo. There's a close relationship, but cargo's defaults aren't necessarily related to what the "next rust compiler" might do.

Re: Thoughts on what a next Rust compiler would do

#92

Post by tialaramex »

spoiler wrote: post #61
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.

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

Re: Thoughts on what a next Rust compiler would do

#93

Post by eminence32 »

thagsimmons wrote: post #47
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…

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?

Re: Thoughts on what a next Rust compiler would do

#94

Post by josephg »

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…

For what it’s worth, I agree with the GP comment when it comes to network services and for quickly prototyping things out. I’ve been writing in rust almost exclusively for the last few years, but I still reach for typescript from time to time.

JS/TS just requires fewer decisions per line of code. As a pithy example, in javascript I don’t have to decide whether I want a String / &str / SmartString / Rc, etc. It’s just string. When I pass a callback I don’t have to decide between accepting a closure or FnOnce/Fn/FnMut. Or decide whether to accept a function pointer or take a generic parameter. In javascript I never have to think about the lifetime of the callee’s stack.

I tried to implement my own server-sent events style protocol in rust a couple years ago. I spent 2 weeks trying a bunch of different approaches but I eventually gave up - I just couldn’t get it working. (Mind you, async was pretty new then - I don’t think it was ready). I moved to javascript and had the whole thing working correctly in about a day and ~50 lines of simple code.

I think the resulting program is much better when I write it in rust than what I get when I build on top of nodejs. Rust programs can be orders of magnitude faster and I have a shockingly low defect rate in shipped rust code. But there’s a trade off. Rust programs take more effort to write.

Rust is a brilliant systems programming language. I’d pick it over C or C++ any day of the week. But not all problems are systems programming problems.

Re: Thoughts on what a next Rust compiler would do

#95

Post by dannymi »

tcmart14 wrote: post #53
nicoburns wrote: post #46

Earlier quoted context omitted.

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

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.

You mean having one ' ?

It's the same syntax in Lisp, Haskell, Ocaml, Ada and VHDL.

Re: Thoughts on what a next Rust compiler would do

#96

Post by thefaux »

josephg wrote: post #87
Thiez wrote: post #76

Earlier quoted context omitted.

For the vast majority of programs most time is spent in code generation/optimization. Rusts static analysis is not why compilation is slow.

Yeah … I’ve done a lot of optimization work. (I love that sort of thing). I have an instinct that there’s at least an order of magnitude compilation performance gain possible with a different architecture for the compiler. Especially if you didn’t bother implementing a lot of llvm’s optimizations. It’s just tricky because writing a new rust compiler is a monster amount of work because of how complex Rust is. And rear…

It seems obvious to me that eventually someone is going to write a compiler for a language that delivers on rust's main value propositions (fast native code/memory safety/data race protection) but that compiles at least 10x faster than rust for most problems. Initially the generated code might be somewhat slower than rust on average, but I think developers will find they would happily trade some runtime perf for such a dramatic compile time improvement. The runtime performance gap will also narrow over time and eventually probably even supplant rust for most common problems. Rust itself is already too complex and weighed down by many competing interests that will prevent it from being the best possible version of itself. But it also has many self owns such as objectively bad syntactic decisions (like angle brackets for generics) that were made to appease intransigent c programmers.

Re: Thoughts on what a next Rust compiler would do

#97

Post by tialaramex »

JoshTriplett wrote: post #84
tcmart14 wrote: post #72

Earlier quoted context omitted.

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.

Fair enough. I agree that that would have been more evocative of meaning. On the other hand, I also think that this: &'a X looks less like Perl / line noise than this: &@a X . In any case, not something we'd be likely to change at this point, but I agree that ' is effectively "arbitrary unique symbol with no evocative meaning". (Arguably the same is true for things like & for "address of", but that has a long history…

One thing I wonder about, although I don't have a clear recommendation, is the preponderance of single character lifetimes.

Other than 'static, a Rust beginner is unlikely to run into any lifetime with a meaningful name for quite a while. If when learning a new language you only ever saw variables named a, x, t, s, v and m it's not a big jump to guess that p, z and b would be allowed as well, but would you assume that in fact the language allows big_set and old_corp_logo as identifiers and it just forgot to mention that ? I'm not sure I would.

The Rust standard library does have lifetimes with reasonable names, for example std::thread::Scope needs two lifetimes and it names them 'scope and 'env which, although brief, are clearly not single letters. But most of the library and documentation doesn't bother with meaningful names, since it doesn't have anything worth saying about the lifetime, e.g. the signature of str::ends_with:

  pub fn ends_with(&'a self, pat: P) -> bool
  where P: Pattern,
  >::Searcher: ReverseSearcher

Re: Thoughts on what a next Rust compiler would do

#99

Post by posix86 »

TylerE wrote: post #11
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…

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.

Rust's type checker is very clever tough. You can omit types almost anywhere, and rust will infer it. Say you net a vector containing Foo object. You can just do

    let mut v = Vec::new();
    v.push(m_foo);
In fact it's so nice that you often rewrite code to keep clear what's actually happening, even though you could keep types largely implicit.

Here's another example:

    let f: Vec = vec![1, 2];
     let f2: HashSet = f.iter().map(|n|n.into()).collect();

Re: Thoughts on what a next Rust compiler would do

#100

Post by sowbug »

Thiez wrote: post #83
loeg wrote: post #41

Earlier quoted context omitted.

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…

Apart from rare pathological cases borrow checking is not a significant part of compilation time. Disabling it would be very detrimental for little gain.

As an end user of Rust, I think the borrow checker seems slow because it's one of the last phases to run during vscode's real-time feedback. More than once I've been in the midst of a long refactoring session, and finally fix what I think is the very last syntax problem. But then the borrow checker finally gets to run, and then I learn about a whole new set of problems.
Post reply on HN