Rust 1.27.0 has been released! As regular readers will know, I’m not a programmer and know very little about the two main new features in this release. The biggest new feature is SIMD.
Okay, now for the big news: the basics of SIMD are now available! SIMD stands for “single instruction, multiple data”.
The detailed release notes have more information.
unfortunately not that easy to boot-strap. Also somehow everyone nowadays needs to invent their own build system – that will be fun the next time I update Firefox: https://www.youtube.com/watch?v=zNipdcUh7ZE
Honestly the guy in this video has his mind set on finding things he dislikes, and will find them no matter how easy the process actually is.
Some of the gotchas are real (although he’d have hit none if he had used the standard install method, and yes you can install without `curl … | sh`) but most of them are just complaints for the sake of it.
Regarding bootstrap, when is the last time you bootstraped gcc with something else than gcc ? When did you even bootstarp it instead of using your distro’s package ? Rust is in the same situation.
As for cargo, it may look NIH-syndrome to you, but I don’t know of any other build system that’s as nice (and I use quite a few languages). Rust wouldn’t be as good a language if it used some 3rd-party build system.
To be fair, circular dependancies are considered evil by just about any developer that ever has to deal with them.
It would have been much nicer if Cargo could be bootstraped with just rustc alone, and who knows with the rust of Rust embedded libraries that becomes a little easier. And if Rustc itself didn’t need Cargo to build itself…. then it’d be great.
Edited 2018-06-22 13:30 UTC
It’d be nicer indeed for people bootstrapping Rust from scratch.
But in practice almost nobody does this (sorry Rene). They compile the new version using the old one, and start with a rustc+cargo blob if necessary. I’m not saying that bootstrapping from scratch is a vain or useless endeavor, it should certainly remain possible. But this is a niche usecase, not one that you want to devote too many resources to.
In contrast, making sure that the main rust development tool (cargo) is of high quality is a primary concern. And that requires that the tool is easy to maintain/improve, which means that you’ll want to use cargo to build it (cargo). That may be an annoying circular dep, but it’s really worth it.
Not only for security and reproducibility is fresh bootstrapping a requirement, it also is vital to bring it to new CPU architectures, such as ARM64, RISCV, not to mention PowerPC, SPARC, et al. (which appear to have binary blogs available, though one complaint to me PowerPC would not work, I have not yet personally tried the non-x86-64 binary downloads).
Reproducability is one thing (I suppose reproducing from a known signed binary is not good enough ?), but bootstrapping isn’t “vital” to bring rust to a new platform: Rust’s crosscompile story is good enough to bring rustc to a new platform using that (then again, you might be happyer crosscompiling your project than bringing rustc over to the other platform). What *is* vital is LLVM support the the platform in question.
moltonel,
Sure they should make cargo good, just understand that not everyone wants to use it. There are a lot of projects that I’d like to use rust in but it’s neither practical nor worthwhile to ditch the existing build systems for cargo. We should respect that.
I think rust has a good future in writing more reliable software, but I do hope the project maintainers will try to address some of these build problems that rener brought up.
Edited 2018-06-22 17:53 UTC
Upstream realizes that, and there are groups working on improving those usecases, both getting cargo to behave better when controlled from another buildsystem, and getting cargo to better control other build systems.
And again, cargo is nice but not mandatory, you’re free to use Make or whatever to build your project, in Rust or something else.
it is not only offline builds, I do even want a build system (cargo) to fetch any (or as many as over 50!?) dependencies behind my back that I did not have verified for integrity.
And if I do not need cargo I have no problem? Well, I want Firefox, and it needs cargo, so I got a 50+ deps problem if I wanted or not.
I’m by the way not against Rust per se, the more innovation and experiments the better. But not to the cost of no proper bootstrapping and building. And no, needing the latest greatest compiler to compile the latest and greatest compiler is not proper, reliable and future proof bootstrapping.
Somehow I can build gcc, llvm/clang, perl, python, ruby, Lua, and many many more languages and build systems (cmake, scons, …) without such problems.
Edited 2018-06-22 22:50 UTC
My impression is that this kind of bootstrapping is not a big priority. If you care about it, please engage with the rust community.
you are strangely bias against c/cc, I don’t understand your hate against it. ten thousands of developer had no problems with c and c++ for decades, Heck, Linux distributions are full with thousands of nicely sized C and C++ libraries, from zlib, over libjpeg, openssl, Gtk+, Qt, libalsa, etc. pp. Nicely sized slices, don’t know where you make up problems there. Integration is -I … -L -l, e.g via pkg-config no drama there either. Instead cargo already has 50+ deps from atty, over curl and many many micro bindings for plenty of seemingly trivial things. Also since when is static linking considered a good thing – I missed that parallel universe Star Trek episode.
I can assure you there’s no hatred against C/++, or denial that we’ve built amazing high quality things using it, or even a suggestion that we should migrate all the C/C++ code to Rust. I’ve spent much more time with C/C++ than with Rust, I’m still more proficient with the former, and it’s generally been a happy experience.
But there’s no denying that working with dependencies in C/C++ is a pain, and Rust isn’t the first to try to fix that. Trending towards many smaller libs is the natural result of having good dependency handling. People cut libs in smaller pieces because it’s a good thing (better QA, better architecture, more reusability, less bloat…). Note that many rust crates are part of a single project, for example tokio is slpit into about a dozen crates but it’s a single project.
In C/C++ you use larger libs not because it is inherently a good thing, but because dependency handling is costly. For example Zlib is a great library, but it probably would have a lower implementation and maintenance cost if it had access to a trove of small utility libs instead of reinventing a few wheels for the sake of being dependence-free.
Static linking is a blessing and a curse. It makes security updates harder and takes more space. It makes deployments easier and less buggy.For better or worse, static linking (and vendoring and containers…) is gaining ground. As an administrator and package writer I shudder. As a software developer I rejoice.
Just throwing this out there I imagine you are aware of it…
mrustc is a rustc written in C++14 that outputs C11 designed to facilitate bootstraping rust… it also includes a minicargo that supports enough stuff to bootstrap rust.
It’s kind of what gcj was to the openjdk on Linux.
You realise that is the OP, right? You can address him directly.
Hadn’t realized that, it’s very easy to miss. I’d have used a less convoluted “you” if I had, but the reply still stands.
I compiled LInux system since gcc-2.95 when there even was egcs, and ARM, SPARC, PowerPC, and when x86-64 was too new to just build, and never was something as annoying as this. I also show plenty of nice things and cool vintage systems on my channel, no problem w/ disliking a thing or two. They had neither to code the Rust compiler in Rust, nor invent yet another not very Unix friendly build system just for their plethora of micro “libraries”. Not everything new is progress. PS: maybe we all should also concentrate more on compatible, interoperable and stable solutions, than inventing more and more proprietary, non-standard solutions that break in an ever changing maze every other day. Also remote code execution is evil, and also I’m not interested in an one time, uncontrolled installation but package it for the long term, for others in our distribution. How should we build Firefox without a properly packaged Rust and Cargo which all distributions agree is a total pain, ..?
Edited 2018-06-22 16:24 UTC
Which far-reaching language isn’t a total pain to package ? Decades of solving packaging problems for gcc, python, or perl and it’s not a smooth process yet.
Give this young Rust language a chance, my guess is that distributing rust-based software will soon be less trouble than for other languages (thanks cargo and static linking). And as far as I know, pretty much all distros have a good rust package at this stage ?
You could use other C compiler to bootstrap GCC, including to target C++, ObjC, Java, Ada, Go, … You can only compile Rust with the (nearly) one and only Rust compiler, and even then usually only the nearly latest version.
Also cargo install into a hidden .cargo/ sub-tree instead of /usr/local or wherever? And cargo basing on 50+ micro packages that you all need to build Firefox?
I apply the same principle to gcc and clang, and happily build them including some other 3000 or so packages form source in our #t2sde Linux. The only thing that currently resists normal packaging is Rust/Cargo.
Edited 2018-06-22 17:34 UTC
Your argument would be valid if a C compiler was not a standard tool, as described by the POSIX specification. See cc(1), for more info. Even today, GCC does not use non-standard C exactly so that it can be compiled by other C compilers. Additionally, C compilers used to be coded in assembly, and even in other languages, when a C compiler was not a standard tool. This particular argument is completely invalid.
Concerning the build system, there are numerous systems that the devs could have chosen. I point you to: https://en.wikipedia.org/wiki/List_of_build_automation_software
You/They should have a really good reason why yet another, incompatible with current offering, should be created. Additionally, as a system language, the Rust build system should not be dependent on anything other than the standard system tools. What makes their build system so special that a ./configure && make && make install not possible
Really, the fact that CC is described by POSIX or commonly available is irrelevant. As long as you can get your software on the system, it doesn’t matter which door it came thru.
Asking that every language should be bootstrappable from C is very narrow-minded. Some People have high ambitions for Rust, that it’ll displace C/C++ in the many areas that they still dominate. Rust being written in C would kill its credibility in that respect. Rust tools are written in Rust because the language is believed to be superior.
I’ve already why writing cargo was worth it, and why compiling cargo with cargo made sense (I hadn’t mentioned Windows support though: you don’t want to have to `./configure && make` on that platform).
You link to a big list of build systems, don’t you wonder why there are so many, instead of everybody simply using make ? The Rust team wasn’t allowed to add to that list ?
Cargo is not incompatible with current offerings, it can be incorporated into an existing build system, just to build the bits that want to be built with cargo.
Cargo is not just a build system : it handles dependency tracking, fetching, updating, it tests, benchmarks, generates docs, releases, analyzes. It is ergonomically integrated with Rust. It’ll take over the functionalities of rustup. It is a great tool that I’d love to have in other languages.
I tried to learn Rust some months ago, and, though the premise is nice and the language is demonstrating all its power and capabilities… I feel some discomfort when using it:
* Probably because the weird syntax for things that could have had a C/C++/Java/C# syntax (examples: match, “all is an expression” approach, type declarations, no ++ operators, etc.).
* Probably because the borrowing rules that are kind of strange for me, a C++ dev.
Anyway, it is nice to have one more language on systems-language-land