cli-guidelines VS go

I can't think of any cli tools with great UX :( usually the important tools have lots of obtuse commands, and the small neat tools only have a couple trivial options.

But here's some guidelines as you make your own tool: https://clig.dev/

I always appreciate tools with examples and a good help text. Also the ability to pipe with stdin/stdout if possible.

The Command Line Interface Guidelines [1] says:

> Do not read secrets from environment variables

> Secrets should only be accepted via credential files, pipes, `AF_UNIX` sockets, secret management services, or another IPC mechanism

Which one of these do you use? On github it seems common for projects to use environment variables for secrets.

[1] https://clig.dev/#environment-variables

Seems they took a small step back from their previous "don't bother with man pages" stance. Now it's "Consider providing man pages."

I still find it a rather shocking order of priority, honestly.

https://clig.dev/#documentation

- E. `blah project foo --edit`

Wondering if there was any guidance on this from the UNIX people. Perhaps scoping should be done using the file system. `cd path/to/project && blah edit`. Like git does with `git --cwd=path/to/project`. Maybe a virtual FS could even be used. Then you wouldn't have to continuously type in the scope with each command. Interesting thinking about how to maintain state in the terminal...thinking about how Python's virtual env bin/activate modifies the shell.

Found an interesting guide here: https://clig.dev/

Capturing these guidelines is one of the primary reasons that https://clig.dev/ exists.

Go instalado

This melding of the sync and the async is actually kinda interesting to me. I know that at least in lots of environments, the sync and async paths are effectively separate for things like I/O[1]. I wondered (and still do for some cases) how Go handles this.

For those curious I looked at Windows and Linux, but not much else.

Linux: no io_uring support. There's debate on even whether to use it as people are discussing security implications[2]. It looks like (from perusing this issue, but could be wrong) AIO wasn't used.

Windows: it looks like they're using IOCP everywhere. Seems sensible enough.

General case: there seems to be an open issue regarding this[3].

[1]: For example, Windows has IOCPs, Linux has io_uring, FreeBSD has kqueue, POSIX has... POSIX AIO, etc.

[2]: https://github.com/golang/go/issues/31908

[3]: https://github.com/golang/go/issues/6817

In today's fast-paced software development landscape, efficient workflows and clear responsibilities between development and design teams are crucial. One effective way to streamline these workflows is by automating component generation from design tools like Figma to code using powerful programming languages like Golang. This article will explore the process of converting Figma components to code, focusing on the clear differentiation of responsibilities between development and design teams.

> The Go database/sql package actually executes ROLLBACK in the SQL engine.

No: https://github.com/golang/go/blob/beaf7f3282c2548267d3c89441...

Nice write-up.

It's a shame that errors.Is is slow for general use, and at least some of that seems attributable to the Comparable change requiring reflection. Multi-errors seems to have bloated the switch. And of course the lack of a happy-path that was fixed in [1].

Since Go already has two ways of handling exceptional state: return or panic, it does feel like a stretch to also introduce a "not found" path too. All bets are off in tight inner loops, but I think as a general coding practice, it'll make the language (de facto) more complicated/ambiguous.

But my take away is that the question has been kicked off: can wrapped errors be made more efficient?

1. https://github.com/golang/go/commit/af43932c20d5b59cdffca454...

I know that at least two engineers from the runtime team have seen the post in the #darkarts channel of gopher slack. One of them left a fire emoji :).

I'll probably bring it up in the by-weekly Go runtime diagnostics sync [1] next Thursday, but my guess is that they'll have the same conclusion as me: Neat trick, but not a good idea for the runtime until hardware shadow stacks become widely available and accessible.

[1] https://github.com/golang/go/issues/57175

I guess the meta programming that most often gets used with //go:generate ends up being text/template.

The Go sort algorithm (pdqsort) is implemented in this way so the same algorithm can be used to implement the various existing sort APIs.

https://github.com/golang/go/blob/master/src/sort/gen_sort_v...

it's a known issue https://github.com/golang/go/issues/31866