Compilers are pretty hard. Languages like C and Go are able to short circuit the problem by having a simplistic type system, but the Rust team's main option here is hard work, and so far they seem to be more than willing to engage in it.
> At best it can beat C++ compilers - C++ being a language whose build times people love to bemoan - but usually it does far worse.
Citation needed on that one. How can you even make that kind of comparison fairly?
For all I know, that might be true, but it's one of those "citation needed" type things.
It takes me about half an hour to update rustfmt, racer and rustsym, every time a new Rust release comes out. On a dual core with 8 GB and HDD.
On the same computer, any of my VC++ 2015/2017 builds, configured to take advantage of incremental compilation and linking, using forward classes and PIMPL idioms, with all third party dependencies already available as binary dependencies, takes around 5 minutes.
Lack of incremental compilation and cargo not being able to deal with binaries dependencies has putted me off, after all if I want slow builds I can have them already in C++ when I go template meta-programming craziness, which are not that slow when using the experimental work Microsoft is doing with C++ modules.
Also since our use of C++ is constrained to libraries used from Java/.NET/Android/iOS, the build times are usually relatively fast.
Hard to sell Rust to anyone on the team, if that means their workflow would become slower, in spite of the safety improvements over C++.
I'm used to ~100kloc of C++ taking half an hour per config+platform on a 4-6 core, 16GB+, SSD machine. Less hygenic than your codebase sounds like, but with some beefy PCHs. Toolchain updates are usually a full day affair in this context, although that's not entirely from just the compiler bump.
Of course, incremental vs full rebuilds are no contest. Rust is at least working on incremental builds now that they have MIR AFAIK. And binary cargo support would be really nice as well. As would be compiling in general.
But I do take advantage of all VC++ improvements for fast C++ compilation, even playing around with the ongoing research work for C++ modules.
If you're seeing very large compile time then it's a good sign that you probably want to break things into smaller crates anyway. I've been working on some pretty large stuff and compile speeds haven't been an issue(aside from the Emscripten linker, but that's not Rust's fault).
I wouldn't expect Rust would ever be as fast to compile, even if it weren't a younger language, because Rust is doing compile time optimization that Java defers until runtime. And that's ok: there may be times what Java does is better, but there are also times it's worse.
On top of that `cargo watch 'test'`, runs fine on a 100kloc project, way better than my personal experience with Java. Now, when Rust compiles all dependencies from the ground up it is really slow, but that's only generally one time during development or after updating dependencies.
For me, the compile times are fine, and the end product generally doesn't need as much debugging as an interpreted language that requires no compilation at all, or has minimal validation, prior to running.
Cargo does it's own dependency management, so I assume you mean to say that because of this, it makes it difficult to integrate into standard methods package managers use. After reading some of the email threads with OpenBSD, I do get the sense that it's complex in that situation, but isn't that because of Ports? And Ports' expectations? Most things in Ports are C, right? I haven't worked with Ports in a long time, so I don't know it very well.
If you're pre-building something and pushing a package for say dpkg or rpm, I don't see a problem. If you're packaging source, then you'll need have the rust tools installed on the host to do that, which seems obvious.
After that, I can see some debate about blessing versions of crates in the Rust ecosystem for use in the OS' package manager, but this starts to blur the lines between what the OS is guaranteeing and what is the responsibility of the build tool. Should an OS want to bless crates, cargo does have an override for crates.io: http://doc.crates.io/config.html see the 'registry' section. I believe the other options in that configuration would also be things that the package manager on the OS would want to specify as well.
I haven't done any of this myself, but would be interested in trying to help figure it out if you have specific concerns.
Compiling the whole world, including dependencies is big waste of time.
I already tried to play around with workspaces to see if at least crates only get compiled once.
With other AOT compiled languages I use, zero third party dependencies are compiled from scratch.
This old issue discusses a bunch of this: https://github.com/rust-lang/cargo/issues/610 I couldn't find another in a brief search.
Edit: I should add that it does harken back a bit to my Gentoo days, where recompiling the world for that 10-15% architecture boost was a lot of fun, but also a waste of time in general ;)
Exactly, that's why it's a "fuck the package manager" approach, it ignores the package manager.
> If you're pre-building something and pushing a package for say dpkg or rpm
The problem is multi copies of the same dependencies everywhere adding all sorts of bloat and security issues. Not to mention introducing it's own incompatibilities.
> Should an OS want to bless crates, cargo does have an override for crates.io
That's a recipe for dll hell if I've ever heard one.
most binaries would be statically linked and compiled, so there wouldn't be copies, but you do have a valid point of an issue with needing to upgrade an tool that was build with a static dependency that has an issue.
If I understand you, you're saying Rust, a general purpose language, with it's own build tool should do what exactly? I see that you believe it's doing it wrong, but every package manager for every OS out there does things differently, Rust can not fix this.
> That's a recipe for dll hell if I've ever heard one.
The package managers can be configured to work with Rust, and likewise Cargo can be configured to work with the various package managers, but it takes work.
I think what you want is every crate on crates.io to be packaged as an installable rlib and dylib for every package manager out there, with the cargo manifest used to generate the various package managers dependency graphs as necessary. This would probably look a lot like, or actually be an integration with, FPM.
Exactly, it can't fix it but it tries to cover over this fact by bundling dependencies with every app.
> I think what you want is every crate on crates.io to be packaged as an installable rlib and dylib for every package manager out there
Basically, but more to the point, when a bug or security issue is fixed I don't want to rely on individual programs updating their dependencies. Let's say 10 years from now the rust version of gstreamer is widely used and a security issue is discovered, I want to be able to "apt-get upgrade" and know that it's patched. This is how things work now with the c version, but this can't be done with cargo, every app using the library has to update it's dependencies and many (particularly any corporate ones) will never update. Rust might be a boon for security but cargo could undermine the effort.
Aside from that, static linking creates a tonne of bloat, memory and disk. There is a reason windows apps are often so bloated compared to their linux counterparts.
> The package managers can be configured to work with Rust, and likewise Cargo can be configured to work with the various package managers, but it takes work.
I don't think that's good enough, if rust wants to be a systems language then it has to work with the system, not be a layer on top of it like java/.net/node. It can do this technically, but culturally it's looking more like node and less like c.
If I'm installed zlib for general system use, I want a package manager. If I'm installing a Rust compression library to be compiled into the program I'm working on, I want that to be managed by my build chain (especially since the version I'm using in my build may not necessarily match what I have installed on my system to run).
As another example, if someone makes a cook general purpose library using Rust, eventually it should be packaged up and shipped in the normal distro package format by the distro if it's useful. I wouldn't expect cargo to be the normal way to distribute software. It's the Rust equivalent of the old tar -zxvf package-1.2.3.tar.gz && cd package-1.2.3 && ./configure && make && make install. You can do it, but if you have a distro package, use that first.
To be clear, neither does the Rust team. You're exactly on point here.
From the getting started chapter of the rust book (which I believe you wrote?). That implies that rust can't be used without cargo right there. And I'm not seeing any libraries published as ubuntu packages.
After this conversation I thought I should expriment more with rust and it's linking options and quickly ran into an error of some sort (quite possibly a system one) trying to buils hello world with dynamic linking:
http://stackoverflow.com/questions/44012802/rustc-and-prefer...
> That implies that rust can't be used without cargo right there.
rustc can absolutely be used without cargo, and is in larger companies that use tools like Bazel. And we're working on making this even better, see https://github.com/rust-lang/rust-roadmap/issues/12 for one of the major items of work this year.
Second, again, Cargo is a tool you use to build your software, not necessarily one you use to distribute your software. It's like the difference between Make and pbuild or a similar tool; see the parent comment about "./configure && make" vs a system package.
> And I'm not seeing any libraries published as ubuntu packages.
Debian has an entire tool, https://crates.io/crates/debcargo, which automatically re-packages a Cargo package into a .deb. Currently, they only package the Rust compiler itself and Cargo, but this work was done specifically so that programs in Rust could be included in the distro, but packaged the way distros like. They've mostly been working on that stuff; I assume by the time Buster's cut-off date happens, there'll be some stuff; I'd like to see ripgrep, personally.
I haven't used -C prefer-dynamic in a while; usually SO questions get answered relatively quickly though.
The trouble is it's both. It's a build tool like make and I have no issue with that, I'll stick to make personally but to each there own. But I can't do that because It's also the primary distribution mechanism for rust libraries and even some apps. SPeaking of ripgrep, take a look at the installation section of ripgrep (http://blog.burntsushi.net/ripgrep/#installation) "cargo install ripgrep" is an installation option.
And because static compilation is also a distribution mechanism (just not for the end user) the binaries are 10 times larger than grep, not to mention a giant GPL trap for commercial users.
Please don't misrepresent my writing. `cargo install` is NOT the primary distribution mechanism for ripgrep. The installation section starts with instructions that use standard system package managers, and only then suggests installing it using cargo if you're a Rust programmer. Why did you leave that out?
You might also consider looking at the actual README of the project[1], which lists several more installation options, including using brew, chocolatey, pacman, emerge, dnf, yum and nix. There is clearly an effort to suggest that users install ripgrep using their standard system package manager.
Some of the points you've made in this thread are valid concerns, but please don't misrepresent other peoples' hard work while you're doing it. It's extremely rude.
I think the user experience is more important than the developer experience. Using shared libraries that are likely already in memory provides a better user experience because it's faster, more stable, more secure and uses less memory.
The cargo approach will end up with windows/node level bloat where every app bundles half an OS.
Cargo is to Rust as cpan (the client) is to Perl, as pip is to Python, and as gem is to Ruby. All those other languages also have packages provided in many distros, but the developtment tool listed that downloads and installs relevant packages is also used when appropriate. For the regular, non-developer user that needs a module to support some program, that may be never. For the developer working in those languages that needs the newest version of the package, regardless of the back-patching policy of their distro, that may be often.
As I said, rust is meant to be a systems language, it shouldn't have an equivalent of cpan and, pip or gem because it needs to work with the system, not be yet another platform.
It's meant to useful as a systems language, so was designed with certain constraints in mind. It is whatever people want to make of it. There have been plenty of instances I've seen on HN alone of people mentioning use that isn't specifically tailored for a systems language.
> it shouldn't have an equivalent of cpan and, pip or gem because it needs to work with the system, not be yet another platform.
Those are entirely orthogonal issues. Cargo works with the system just as well as tar and make. They're just binaries. You could just as easily say that traditional source tarballs shouldn't be provided because people might download the source and use their compiler to build instead of using the distro package. This is a non-issue. The only people that will even have the choice are those that chose to install the compiler (whether it be a C compiler or Rust), and even then the vast majority that actually do so will probably end up having a good reason for doing so.
Cargo is part of the build tool chain. Just because it can be used to distribute a package, and even while it probably will be used to distribute a package, that doesn't mean it's purpose is to do so, or that it's inappropriate that it exists. Any feature can be abused. You should not judge it by the abuse, but by its intended and common use.
To be fair my javac comparison with with Gradle + Android Studio layered on top so it may be a bit slanted in favor of Cargo/Rust. That said I've never seen a Java build environment that I'd call 'snappy'.
Some Rust projects are very quick to build; but some are astonishingly slow to build. e.g. lalrpop is unusably slow (~15mins to build on 2014 Macbook Air).
I think the place here performance breaks down is liberal use of generic types in functions. e.g. AsPath<T> and AsRef<T>, etc.) where the compiler creates the function for all the different types and then tries to collapse them again later on. So one rules of thumb is to only use those in the public APIs and convert the type so it can be passed around without generics internally within a module. Or maybe that's just me trying to do some `cargo cult` heuristics (haha! puns!)
I always thought `cargo new` should have been called `cargo cult`.
Gradle sucks big time, why do you think Google still does talks letting angry Android developers that Gradle + Android Studio will some day be as fast as Ant + Eclipse?
http://androidbackstage.blogspot.de/2017/04/episode-64-gradl...
https://www.youtube.com/watch?v=BKRK4SvMtRk
The Android Gradle plugin being slow as molasses is a typical discussion theme at Google IO since it was introduced. Being partially written in Groovy also doesn't help.
Now, viewing this as someone coming from Python, Ruby, Node, etc., I can see compilation as being annoying. Is it really the only reason that they are disliking the language or is that just a strawman?
I wonder if too much attention is being paid to this. Now there are legitimate things we can focus on, such as making cached precompiled libraries very easy to use. This can especially be important in CI environments... This would also generally make most compilations fast.
This is already true today; that is, this cost is only paid the first time you compile. It's still not fast enough for people.
On my machine, a fresh build of rustc takes an hour, and small changes take 20 minutes, and even that makes it a giant pain. It's an ergonomic thing, IMO.
A bit influenced by the fact that rustc has to compile itself three times. :P
https://edn.embarcadero.com/article/20803
And even today Delphi 10 is quite fast.
Same applies to many other compiled languages with modules.
And no where near as fun. Hilarity ensued when I didn't realize there was no garbage collector.
Turbo Pascal was more a kind of simplified Ada than a pure Pascal, which made me look down on C when checking down the laundry list of language features of Turbo Pascal 6.0 versus ANSI C89 in 1993.
Also by 1999 no one was doing anything serious in Turbo Pascal with the last version being targeted at Windows 3.1.
Delphi 1.0 was released for Windows 95, and it did at least have some kind of GC for COM based classes.
Also Delphi 10 might not have every Rust feature, but it surely has it own set of complex language features.
Or if you prefer Ada, C#, D are also possible sources of information regarding performance of compilation toolchains, with relatively complex languages.
Build tools like Maven and Gradle, as well as IDEs' internal build tools, will be smart and compile only the changed files.
Also a bit disappointed when compared with other languages that support modules, specially the ones whose toolchains support binary dependencies.
Not everyone has a high end development workstation.
I am however confident the experience will eventually improve.
Cite a source? This isn't my experience at all, Rust is still way faster at compilation than C++ on average. The advantage that C++ currently has is ccache which helps avoid needless rebuilds (which pairs well with C++'s smaller compilation units relative to Rust); building this behavior into the compiler is part of what the incremental compilation initiative is addressing.
> It consists of ~7700 lines of Rust
...
> Compile times with Rust are Not Great. This is easily my single biggest gripe about Rust right now. The build for A Snake’s Tale takes 15+ seconds, which makes iterating rather tedious. The current incremental compiler work also doesn’t seem to make the build for A Snake’s Tale’s codebase any faster.
Actually, the compiler isn't the bottleneck - most of the time is LLVM codegen. So 'cargo check' is fast - the miri MIR interpreter likewise.
Right now, I don't do much serious work in Rust, almost solely because of compilation speed.