The basic problem is that identifiers can be either types or variables, and without a keyword letting you know what kind of statement you’re dealing with, there’s no way of knowing without a complete identifier table. For example, what does this mean:

foo * bar;

If foo is a type, that is a pointer declaration. But if it’s a variable, that’s a multiplication expression. Here’s another simple one:

foo(bar);

Depending on how foo is defined, that could be a function call or a declaration of a variable bar of type foo, with some meaningless parentheses thrown in.

When you mix things together it gets even more crazy. Check this example from this article:

foo(*bar)();

Is bar a pointer to a function returning foo, or is foo a function that takes a bar and returns a function pointer?

let and fn keywords solve a lot of these ambiguity problems because they let the parser know what kind of statement it’s looking at, so it can know whether identifiers in certain positions refer to types or variables. That makes parsing easier to write and helps give nicer error messages.

A system I work with gives all keys a string value of “Not_set” when the key is intended to be unset. The team decided to put this in because of a connection with a different, legacy system, whose developers (somehow) could not distinguish between a key being missing or being present but with a null value. So now every team that integrates with this system has to deal with these unset values.

Of course, it’s up to individual developers to never forget to set a key to “Not_Set”. Also, they forgot to standardise capitalisation and such so there are all sorts of variations “NOT_SET”, “Not_set”, “NotSet”, etc. floating around the API responses. Also null is still a possible value you need to handle as well, though what it means is context dependent (usually it means someone fucked up).

is-number is a project by John Schlinkert. John has a background in sales and marketing before he became an open source programmer and started creating these types of single function packages. So far he has about 1400 projects. Not all of them are this small, though many are.

He builds a lot of very basic functionality packages. Get the first n values from an array. Sort an array. Set a non-enumerable property on an object. Split a string. Get the length of the longest item in an array. Check if a path ends with some string. It goes on and on.

If you browse through it’s not uncommon to find packages that do nothing but call another package of his. For example, is-valid-path provides a function to check if a windows path contains any invalid characters. The only thing it does is import and call another package, is-invalid-path, and inverses its output.

He has a package called alphabet that only exports an array with all the letters of the alphabet. There’s a package that provides a list of phrases that could mean “yes.” He has a package (ansi-wrap) to wrap text in ANSI color escape codes, then he has separate packages to wrap text in every color name (ansi-red, ansi-cyan, etc).

To me, 1400 projects is just an insane number, and it’s only possible because they are all so trivial. To me, it very much looks like the work of someone who cares a lot about pumping up his numbers and looking impressive. However the JavaScript world also extolled the virtues of these types of micro packages at some point so what do I know.

I don’t really care about the declarative/imperative thing, to me how many commands you “really need” is beside the point. This is essentially the same argument as the people who say “git is not complex because you only really need checkout/commit/push, just ignore all the other commands.” This doesn’t matter when the official documentation and web resources keep talking about the other billion commands. Even home-manager has this warning at the very top of the page that basically tells you “you need to understand all the other commands first before you use this,” and “if your directory gets messed up you have to fix it yourself.”

These are exactly the same kinds of problems people have with git.

The confusion arises because there are 5 different ways to do the same thing, the non-experimental methods shouldn’t be used even though they’re recommended in the official docs

I appreciate what you’re trying to say, but you’re kind of illustrating exactly the point I was making about conceptual simplicity and atrocious UX.

Nix has the same mix of conceptual simplicity and atrocious user interface as git, but somehow magnified three times over. I’ve tried it multiple times, but could never get over the unintuitive gaggle of commands.

Micro services always require more maintenance, devops, tooling, artifact registries, version syncing, etc.

The initial transition is so huge too. Like, going from 20 to 21 services is no big deal, but going from 1 service to 2 is a big jump in the complexity of your operations.

Yeah, Nvidia really sucks on Linux unfortunately and they simply do not care very much.

Seems like there’s a bunch of solutions out there:

As of 2020, there are several projects that use these methods to provide GUI access to remote computers. The compositor Weston provides an RDP backend. GNOME has a remote desktop server that supports VNC. WayVNC is a VNC server that works with compositors, like Sway, based on the wlroots library. Waypipe works with all Wayland compositors and offers almost-transparent application forwarding, like ssh -X.

Do these not work for your use case?

Lots of tools ignore xdg, and issues asking to add support get bogged down in backwards compatibility problems. The best they achieve is to introduce yet another env variable to control where the config goes. It’s really annoying.

I have a bunch of TOOLX_CONFIG="$XDG_CONFIG_HOME/toolx" stuff in my bashrc.