unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Hartmut Goebel <h.goebel@crazy-compilers.com>
To: Pjotr Prins <pjotr.public12@thebird.nl>
Cc: guix-devel <guix-devel@gnu.org>,
	Nicolas Goaziou <mail@nicolasgoaziou.fr>
Subject: Re: Discussion: How to package rust crates now and in future?
Date: Sat, 2 Jan 2021 13:50:51 +0100	[thread overview]
Message-ID: <152549d0-cfb4-79e8-98c5-671a35f90c30@crazy-compilers.com> (raw)
In-Reply-To: <20201219064232.4ioar4776lxh6wm6@thebird.nl>

Hi Pjotr,

Am 19.12.20 um 07:42 schrieb Pjotr Prins:
> They are talking about librification of the language
> https://rust-lang.github.io/compiler-team/minutes/design-meeting/2020-03-12-shared-library-for-types/
> which may lead to a wider idea of libraries.

For your needs static libraries would suffice. Anyway: Unfortunately
this feature did not make i to the 2021 roadmap, AFAICS.

I'd be happy enable building crates when rust has some notion of
library. Until then I strongly propose to not build intermediate creates
per default.

> The language may still be changing - but I think it has gotten to the
> point that they can't change too much without hurting large software
> projects. It probably is a bad idea to mix different compilers to
> build crates in one software stack. Maybe I am misreading your idea,
> but we either have a 1.40 build or a 1.46 build.

Unfortunately this is not just an idea, but a sad reality :-( As of
today, the rust used by cargo-build-system is still 1.45, while some
crates (e.g. sequoia) require 1.46 language features. So in fact we
already/currently have a mixed stack. Maybe this is just since nobody
did update default rust to rust 1.46?!

Anyhow, my argument about rebuilding without any use still holds: When
upgrading rust, all crates will be be rebuild (which is part of guix's
concept) and the results are thrown away right away - which is a wast of
time and electrical power.


>>    6) This not only effect berlin, but also every user out there requiring
>>    a rebuild for some reason. This will lead to a very, very bad user
>>    experience - practically kicking out users with less powerful
>>    equipment.
> The Rust user experience is that Rust builds all crates or installs a
> single (static) binary. Even for Guix developers, the default is to
> use cargo because of the insane number of dependencies it typically
> pulls in. We package dependencies when we want to deploy, not to
> develop. 

I assume you are referring "Rust user" to someone using rust for
developing some rust software? I'm referring "user" to someone using
Guix for managing their system.

> The user here is a guix user, of course. So between compiler versions
> we rebuild the stack and then distribute binaries. No rebuilds get
> triggered normally. I think the use case you are referring to is users
> as developers (right?) who are actually used to waiting for cargo. I
> wait for cargo when I start a new Guix development environment.

FMPOV there is not much difference between a user and a developer here:
If substitutes are not available, a user - and this includes developers
- needs to build the packages. And even as a developer I don't want to
build the whole stack myself, but use substitutes - like I want to use
pre-built libraries for other languages.

My point is another one: While for programming languages supporting
(static) libraries the number of compiles is O(n), for rust – assuming
#:skip-build #f – it is O(n*(num_average_dependencies+1)) - since each
crate needs to compile all of its dependencies, even if 20 other creates
did this already.

To give you some numbers: sequoia 0.20.0, while directly depending on
only 55 crates, pulls in more then 430 crates (in words: four hundred
and thirty) and compiles about 280 (in words: two hundred and eighty),
including some duplicates compiles. Assuming each package depends on one
other crate (which is a low assumption), this will be 2*n=860 compiles.
Assuming each compile takes 30 seconds, and half of the packages need
rebuild, this is more the 3,5 hours - right away into the trashcan.


-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |



      reply	other threads:[~2021-01-02 12:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1608149415.git.h.goebel@crazy-compilers.com>
     [not found] ` <87tuskmq7l.fsf@nicolasgoaziou.fr>
     [not found]   ` <afa5f84c-4e44-35ba-19e3-4dad3e71fcb7@crazy-compilers.com>
     [not found]     ` <X9u62uXj6nEbuonK@E5400>
2020-12-18 18:08       ` Discussion: How to package rust crates now and in future? Hartmut Goebel
2020-12-18 18:26         ` John Soo
2021-01-02 12:53           ` Hartmut Goebel
2020-12-19  6:42         ` Pjotr Prins
2021-01-02 12:50           ` Hartmut Goebel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=152549d0-cfb4-79e8-98c5-671a35f90c30@crazy-compilers.com \
    --to=h.goebel@crazy-compilers.com \
    --cc=guix-devel@gnu.org \
    --cc=mail@nicolasgoaziou.fr \
    --cc=pjotr.public12@thebird.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).