I was going to ask, is there a standard for this sort of thing? Then I realized that it's just references in the form of text. Hypertext, if you will. We should make a markup language for it.

This sort of thing is why packages should always be namespaced. Just "base64" without any additional qualifiers makes it seem more official and definitive than it actually is.

I get the impression that some people think of crates.io as purely a place for distributing arbitrary Rust free software, while others think it's also a place where people are building something like a community-developed "batteries included" standard library for Rust.

I think a fair amount of unpleasantness in recent years has come from this disconnect: some people think that by publishing on crates.io you're making some promises (that they might not assume simply for, say, having a repository on github).

To me, using an extremely generic name like 'base64' does suggest that you're in the second camp, and so that you might expect to have a conversation that feels more like "we're equals building this project together" than "I'm the maintainer and my judgement is all that matters".

Don't all languages, that have this kind of community developed packages, have the same problem? I expect golang, npm and python to have similar issues. Python has less issues because they have a bigger standard library but if you want to do anything advanced you need third party packages.

I feel like most of these issues stem from the very young age of Rust (2015 -> v1.0). Give it a few years and these problems will stabilize as the long term crates will survive and the short term will grow stale.

Golang doesn't because all packages are namespaces by domain name (and more often that not that domain namespace ja GitHub which has its own further "org" namespacing)

I think you are right. Though I think that one can have all the benefits of the “community-developed stdlib” with the namespaces approach as well — e.g. Java’s new Date/Time API actually comes from a third-party package called jodatime, it was just so good that it found itself implemented in the standard library of java, and then later on plenty other languages as well.

Rust has done this as well; hashbrown was an external package, but now powers HashMap and friends.

Great observation. This helps me reconcile the tension I feel between my “maintainers own us nothing” mentality and my disappointment with the way the base64 API issues have been handled.

Indeed. I have on occasion joked about starting a "crates-name squatting" business; pick a bunch of common names and buzzwords and hog them and give them up for $$, like domain squatters do.

I see the arguments against organization/namespacing in Rust (ala Maven or NPM) and I kinda shake my head. The reality is, crates.io is a crazy bazaar, people end up taking crate names and then abandoning their projects, leaving that name forever unusable.

e.g. at work we have an internal crate named "event" (on our internal repository) that conflicts with an abandoned public crate of the same name that hasn't had commits in 8 years. This leads to confusion if you get your cargo config wrong. But it's also kinda frustrating that this very generic name is ... lost to time now.

Looks like "swmon" beat you to the punch.

https://crates.io/users/swmon

It's neat how positively I can hear an idea like this and go "haha, what a fun idea," and then see it actually executed on and get a visceral "you are a terrible human" vibe, like that "Contact me if you want to use this name!" description makes me viscerally angry.

That's terrible.

Some prior discussion on namespacing packages in Rust:

https://internals.rust-lang.org/t/blog-post-no-namespaces-in...

This is a thing in Lua as well, with do-end blocks:

    local foo
    do
        local bar = 42
        -- Same as `foo = function() ... end`, so this sets the local foo variable.
        function foo()
            return bar
        end
    end

Because Lua has no significant whitespace, it can be made to look like some kind of specific syntax:

    local foo do
        local bar = 42
        function foo()
            return bar
        end
    end

Though I think this is too clever, so I like to insert a semi-colon to make it clear what is happening:

    local foo; do
        local bar = 42
        function foo()
            return bar
        end
    end

1. Use a passphrase generator to produce two or three words

2. Smash pieces of the words together until you get something that looks good.

e.g. blurred grumble ambiguity:

- Blurlamb

- Redblig

- Leguity

Don't worry about the meaning. The meaning emerges from the identity you give it.

Extra credit: Look it up to make sure it isn't a dirty word in some foreign language. Happens more often than you think.

This one amuses me. You skip the long-windedness of the front page to look at the pictures. Your eyes are caught by two example user interfaces: contact forms. The one on the left looks great. The one on the right looks awful. Yet it's the one on the left that has the big red X next to it. So you backtrack to read why they're wrong. The reason is because borders "feel" busy and cluttered. Nothing empirical. No data to back it up. Just "feelings".

This led me to believe the whole website/book is going to be like this, so I haven't read any further. I'm sure it's great.

> The one on the left looks great. The one on the right looks awful.

This is also just a mere assertion of "feelings", with nothing empirical and no data to back it up.

As long as those are the rules we're playing by, I'll say that to me, the design on the left screams "designed by a dev", in the pejorative sense, while the one on the right looks like it had a designer involved.

Whether there are actual usability improvements is an orthogonal issue, but I don't feel there's a huge gap between the two.

I feel a lot of this comes down to trends, rather than actual usability. Keeping up with the latest trends in UI design is a signal that you care enough about design and UX to employ and empower a designer/ design team.

Paradoxically, sometimes signalling you care about design might involve making the UX worse (relative to what the user base is trained on), if that's what the trends dictate. For example, the sudden overcompensated reaction against skeumorphism that was "flat design".

Just some of my feelings.

I've been calling it Pepsi Logo Kool-Aid.

I once read that either FreeBSD or OpenBSD was the "bad one". I forget which it was, but given that BSD is the Linux of Linux, I don't really think about it.

Vision: Game Boy Advance-sized website.

Problem: Very tiny.

Solution: Scale to viewport in integer increments.

Result: https://anaminus.github.io/

This disables zoom. In fact, it actively fights the zoom level to always fit the viewport. Have I committed a great sin?

Not sure what you're going for, but this probably isn't it.

https://imgur.com/a/Kgktbvs

Love it.

To be honest, It makes me recall painful WAP[1] browsing on an old Nokia phone.

---

[1] https://en.wikipedia.org/wiki/Wireless_Application_Protocol

> This disables zoom. In fact, it actively fights the zoom level to always fit the viewport. Have I committed a great sin?

Yes. Scaling to the screen size is fine, overriding the users's attempt at zooming in is not.

It's not scaled to the viewport for me. It's centered in the middle of it, but still tiny.

I figured this would happen. I've also committed the even greater sin of testing in only one environment (my own). I guess we don't quite live in the future yet.

I WILL use todo for everything! But instead of committing them inline, I will dump them into a TODO file that is ignored by the VCS. If this file starts getting too big, then I'll move some of the long-standing todos out to an issue tracker.

> Why not just go straight to the issue tracker?

An issue tracker adds a lot of overhead. It's sitting on a different system, so you have to have a separate window open. It's public, so you have to spend time producing a comprehensible issue. Every action is a commitment. Internet access is essential.

Meanwhile, TODO is just a file, so it can sit right next to your code. Its private, so you can just stream thoughts right into it and move on. Adding an item is as simple as typing out some lines, and removing that item is as simple as deleting some lines. Need to search? Just grep it. It's fast, and it doesn't leave a mess in your code.

would it help having a TODO inline linked to an issue tracker automatically? so you would never have to switch context.