101–110 of 147 posts
Earlier quoted context omitted.
What do you primarily program in, Java? C#? Python?
Python
Earlier quoted context omitted.
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 tha…
I think it'd be a really good idea for the standard library to change many of its lifetimes to be descriptive, to encourage others to do the same. With my libs-api team hat on, I'd happily merge PRs that do that. (In small batches, please, not the whole library at once.)
There are already at least two Rust compilers, now that there's a GCC version. That's good; it means the language becomes stronger than the implementation. Right now, the weak points are mostly library side. Too many 0.x version crates where the API is still in flux.
It seems in terms of web dev related crates, admittedly a niche for Rust, there have been quite a bunch of abandoned, unfinished projects and other stability issues. There also seems to be a general trend towards sophistication and away from simplicity. That’s a tradeoff that makes me personally wary, rather than excited at this point in my life. Much of that is to be expected, given the age and the unique value prop…
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?
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.
Earlier quoted context omitted.
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…
Rust is the first language in its category. It won't be the best language we ever make in that category.
Earlier quoted context omitted.
Apart from rare pathological cases borrow checking is not a significant part of compilation time. Disabling it would be very detrimental for little gain.
Apologies, I was under the impression it was a significant cost. Do you have any good analysis of where Rust compiler time goes you could link to?
Here is an older article that compares compilation times between multiple different libraries, where one of them does spend a significant (and majority of the) time borrow checking: https://wiki.alopex.li/WhereRustcSpendsItsTime
Earlier quoted context omitted.
Apart from rare pathological cases borrow checking is not a significant part of compilation time. Disabling it would be very detrimental for little gain.
Apologies, I was under the impression it was a significant cost. Do you have any good analysis of where Rust compiler time goes you could link to?
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.
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 i…
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 include the two i mentioned above).
But I'm new to the language and understand that most people will just use `cargo init` and google a few other common cargo.toml settings to improve compile times.