1. 47
  1.  

  2. 9

    I am ecstatic to hear that the TryFrom API was finally stabilized.

    1. 4

      The largest feature in this release is the introduction of alternative cargo registries.

      This seems pretty cool. Well, the fact that there’s now some choice as to where to host your code, but the implementation seems difficult.

      I would like a system that lets me throw some code online with minimal effort and allows anybody to use without tying myself to someone else’s infrastructure. The go build system has some oddities, but I really like the way they’ve built go get. 1. I get to use mercurial. 2. The effort required to support go get was basically that of putting a mercurial server online, which I’d already done, plus adding a meta tag to an html file. Literally minutes. It does not appear I will make the same progress in the same time running cargo.

      1. 8

        cargo already supports git dependencies. no one is stopping you from using those nor advising your users to use your code as a git depedency.

        crates.io does not allow crates with git dependencies though, but for a good reason: crates.io wants builds to be repeatable and the only way to guarantee that is if it can guarantee the availability of all dependencies.

        1. 0

          Oh? doc read fail. I wasn’t sure how to do that, but may have just missed it.

          I can understand the point, although this is still lockin. Don’t use our system? You don’t exist.

          1. 9

            Many (edit: well, one or two) of Cargo’s design decisions are a fairly direct reaction to the 2016 left-pad debacle. The decision was made that packages should be immutable by default and, while they can be marked as “don’t use this” (and the build system will warn you if you try), they can’t be un-published or removed by their authors.

            Whether or not this is a good decision is up for debate, that’s just why published packages can’t depend on random git repos. You don’t want to tie yourself to someone else’s infrastructure? crates.io doesn’t want to tie itself to someone else’s infrastructure either.

            1. 7

              Whether or not this is a good decision is up for debate

              I’d say there’s no debate. For professional development, immutable releases in public repositories (heck, any kind of repositories, for that matter) should be mandatory.

              You should only remove releases for legal reasons.

        2. -2

          Why are you always like this.

          1. 4

            Because I’m tired of reading blog posts about leaving centralized services ten years later.

        3. [Comment removed by author]

          1. 19

            “Indexing” isn’t a particularly meaningful concept in the general case for a Unicode string. What entities would you be indexing, codepoints? That’s seldom a useful thing to do. Graphemes? Those don’t map 1:1 to UTF-32 codepoints. In real-world code, indexing a string is pretty rare. It’s much more common to iterate. So then why not save memory and increase speed in the common case, with UTF-8?

            1. 6
              1. 6

                For algorithms that don’t care about Unicode semantics you can view the string as a byte slice and poke it at random.

                For string-like operations you have all kinds of iterators and helper functions that give you correct offsets or ready-made substrings.

                But keep in mind that there is no meaningful constant-time indexing in Unicode, period. Not even in UTF-32. Unicode, on a higher level than codepoints, is always inherently a variable-width representation.

                1. 3

                  Yes, it’s space efficiency, and that a lot of external world is UTF-8.

                2. 1

                  Still open Tracking issue for const generics (RFC 2000): https://github.com/rust-lang/rust/issues/44580

                  1. -1

                    And …?

                    1. -1

                      And …?