1. 16
  1. 5

    When Go updated their branding I stated that it would be used as an excuse to add bloat to their website…. So it begins.

    1. 8

      But they got around your definition of bloat by adding a second website!

      In fairness, it’s nice to have a “boss look at this page” for go, I wish they had it before I used it at work.

      1. 1

        golang.org is not suitable for bosses’ eyes?

        1. 4

          Depending on what type of boss, yes. But the front page of go.dev has: companies using go, and addresses the “Why choose Go” questions.

          1. 2

            I agree, it makes sense to have a more marketing focused site. And I’m happy they went away from this unfortunate “golang” name.

            Bit weird they put an alternative godoc.org under it as https://pkg.go.dev/, but maybe even that’s good for the Corner Office: look at all the stuff we support.

            1. 1

              i’d expect go.dev to be the developer site but i guess shit happens

      2. 3

        For a bit of fun, put https://rust-lang.org and https://go.dev side by side ;).

        1. 3

          Reminds me that the Rust website still provides no links to its package management (search for package, crate, cargo, etc. nothing) on the frontpage – while Go has it in its header.

          rust-lang.org should – at the minimum – have a big, fat link “Libraries” before or after “Tools” in the header that either links to crates.io or (better) calls the crates.io REST API to provide the information in a design that looks consistent with the rest of the rust-lang.org site.

          1. 2

            I agree. I got that on my list somewhere.

            1. 1

              Would love to work on it if it didn’t meant having to deal with everything is fine as it is-type people.

              The easiest way would be to use the same instance of the site, and just ship a different CSS file if the requests come from rust-lang.org/libraries.

              I guess the core questions are:

              • can the backend support multiple frontends?
              • how to integrate that Ember.js frontend into the main site: add it to the main website repo or use a distinct repo?

              But I fear people will be busy XY-probleming the whole thing.

              1. 2

                Would love to work on it if it didn’t meant having to deal with everything is fine as it is-type people.

                Let’s talk, please. A lot about the website is not fine :).

                As the engineering lead of the website, but not of crates.io, I’d like to make clear that I have absolutely no problem with change requests of that kind, as long as they have:

                • A consistent vision for future and maintenance
                • Don’t add extensive stack
                • Preferably add no JS build system that needs to be run in the website build process

                (I’m willing to relax on any of these for practical reasons, I just get tons of requests of the kind “please rewrite the website using my favourite $stack” where $stack is the persons favourite)

                I definitely don’t want to stand in your way. The way you layout sounds okay.

                On the crates.io-side, I sadly can’t say much, but I’m willing to research all that for you and clear your way a little. All I know is that the frontend doesn’t have much maintainership currently.

                But I fear people will be busy XY-probleming the whole thing.

                Generally, the website team is currently not very prone to this, we mainly have a bandwidth problem, TBH. This also feeds back into the problem that I don’t want the website to become complex.

                1. 2

                  Let’s talk, please. A lot about the website is not fine :).

                  As the engineering lead of the website, but not of crates.io, I’d like to make clear that I have absolutely no problem with change requests of that kind, as long as they have:

                  Ok, sounds great! Thanks!

                  • A consistent vision for future and maintenance
                  • Don’t add extensive stack
                  • Preferably add no JS build system that needs to be run in the website build process

                  I agree on your requirements.

                  Maybe it’s best to keep the frontend out of the website repo then (or investigate other ways to switch out the CSS file without spinning up a new frontend repo, although I fear this could be pretty hacky).

                  On the crates.io-side, I sadly can’t say much, but I’m willing to research all that for you and clear your way a little.

                  This would be great!

                  All I know is that the frontend doesn’t have much maintainership currently.

                  You mean the frontend for crates.io? If yes, then maybe a more “practical” approach would be to adjust the style/design of crates.io itself, such that we don’t need to have a distinct style just for display on rust-lang.org/libraries? Ideally visiting rust-lang.org/libraries and crates.io would have the same consistent style.

                  1. 1

                    Having looked into this, I guess there are largely four different approaches:

                    1. Add a JavaScript snippet to the original site that checks whether it’s running on rust-lang.org and in that case switches out the style element for a stylesheet that looks more like rust-lang.org.
                    • Pretty hacky, would restrict changes to CSS, changing the structure would be cumbersome and require more JavaScript.
                    1. Take the frontend of crates.io, spin up a new instance that talks to the same database as the original one and basically fork the frontend.
                    • Probably easiest way to start with, but would add the whole existing crates.io frontend stack as an additional maintenance burden.
                    1. Contribute to crates.io and start aligning the style of crates.io to the one of rust-lang.org.
                    • Probably easiest way technically, hardest way socially – if crates.io devs disagree with this direction, this approach is dead and there is not much to do about it.
                    1. Use the crates.io’s REST API and build rust-lang.org’s own frontend to it.
                    • Likely more work to see any first results, would use the existing rocket stack, would allow starting from a clean slate, design-wise and think how to best present the library ecosystem to the audience of interested people, beginners, “deciders” etc. (which is probably a different one than the one on crates.io), requires that the REST API is actually usable (don’t know whether the crates.io frontend is dog-fooding here).
                    1. 1

                      Hi, sorry for the late reply. I got sick over the weekend and needed some time off, I’ll be collecting all that in an issue and be in touch. First have to follow up on email, though.

                      1. 1

                        Hey, no worries! Send me the link to the issue whenever you are ready, no hurry. Thanks!

            2. 2

              What similarities/differences did you spot?

              1. 3

                A very similar claim and layout. The yellow button with the download link in under it and a somewhat similar top bar.

                This is a little less dominant if you have a high screen.

                Continuing:

                • “Why?” as the first question with 3 claims
                • The 4 usage fields with the “learn more” call to action.
                • The misaligned “Learn more” links :D

                The Learn page with 3 top links and a list of all books below it.

                The Go page has a less colorful design, though and is a little bit more interactive, especially the integration of the package host is better.

                To be clear: I’m very happy about that, we have a lovely relationship with Go marketing team.

                1. 2

                  The Rust site looks more professional, imho. Pretty much all the pictures-as-links on the Go site have images that look like they were copied from a random Google search for that item. :-)

              2. 1

                Both feel more like marketing sites for getting management buy-in. I understand languages need to market themselves, but some of these descriptions aren’t very precise at least compared to Elm or Julia.

                • “blazingly fast” How fast is “fast”? or, “Fast compared to what?” Provide examples or real comparisons.
                • “very small memory footprints” - How small? Compared to what?
                • “eliminate many classes of bugs at compile-time” Like what?
                • “compiles really fast” How big is your code base? Are you talking about incremental or full builds?
              3. 1

                Is the source code for this new site available?