There's also `std.fmt.allocPrint()` which functions similarly to `format!()`. Although I'd argue its rather poorly named, like many of the functions in the stdlib...
For wanting to avoid fiddling with multiple repeated alloc/defer-free, it's often convenient to use the arena allocators that allow you to release everything with a single `defer arena.deinit()`
I would (coming from a C background) guess that `allocPrint()` owes its name from the C standard library function(s) `as(n)printf()`[1]. At least that would make sense, the naming is modernized by being made longer, to gain clarity.
Was the need for optimization work something that was on your mind the whole time? Like a nagging feeling in the back of the head that the code is not working as well as it _should_ be working? i.e. stress.
And when you finally "fixed" the issue through optimization, your mind allowed itself to let go of these open loops (borrowing the GTD terminology), leading to relaxation?
Isn't the new one also horribly type-unsafe? Since you can put (parent) objects of any kind into the list without any mechanism to detect which is which?
Zig builds a statically linked library called "cgo_static_linking" from Zig sources. Zig places the artifact into "./zig-out/lib/cgo_static_linking.a" (or maybe some other extension). The library is exported with C ABI, which Go (cgo) compiler supports.
The #cgo line tells the Go compiler to add custom compilation flags: -l flag tells the compiler that you wish to link to a library called "cgo_static_linking" in to the binary. However, the cgo compiler can't find it since it is not in the default search paths for libraries. The -L option extends the library search path to "./zig-out/lib/", allowing "cgo_static_linking" to be found.
The "#include" line inserts the header file contents as-is into the source file (main.go), bringing the definition of the function available to the compiler. The compiler is then able to compile the Go source, and later link it with the other build artifacts to produce the final executable.
The key here is the "C ABI" which acts as common ground for both languages. The rest is just scaffolding to let the compilers find and connect appropriate files together.
Last I touched it they only had glitchy make files and I don't like cmake particularly, I was just like "bespoke make files are fine if they're posix compliant, but these aren't"
I mean, it's possible that at some point evolution produced such nuclear reactored individual, but who got "naturally selected" rather quickly for obvious reasons
If you read some of the Dune supplementary materials, the sandworms are biological nuclear reactors. It's kinda handwavey but it's a cool concept - how do you keep a creature the size of a freight train moving constantly in a very thick medium... how about harvesting fissionables?
See the Isaac Asimov story "Pâté de Foie Gras" from the September 1956 issue of Astounding Science Fiction, available here [1] on the Internet Archive.
VScode devcontainer can build from existing Dockerfile. You can develop the project image as usual, and then reference the Dockerfile from devcontainer.json. This means you can build and run from the command line via `docker` command if needed. The VScode extension just makes this slightly easier.
Not sure how GP's company does it, but that is how I would configure it.
Caveat: the default devcontainer initialization workflow does _not_ create the Dockerfile, only the .json.
At $work we don't use devcontainer.json, but we can launch the development environment image such that you can SSH into it as if it was a regular VM.
If you think about it, a CLI argument parser takes in a sequence of tokens and transforms the information into some kind of internal repsentation, which is then later interpreted. Just like what a compiler/interpreter does, except now the input is already tokenized. So there does not seem to be a practical way to "standardize" this interface any more than you can standardize a compiler for all languages.
It's kinda whacky to think about that every sufficiently complicated CLI app out there implements its own ad-hoc, informally-specified, bug-ridden, slow implementation of half of common lisp _just_ to prepare running the actual program payload...
