In the original proof of concept for ranging over functions, iter.Pull was implemented via goroutines and channels, which has a massive overhead.

When I dug in to see what the released code did I was delighted to see that the go devs implemented actual coroutines to power it. Which is one of the only ways to get sensible performance from this.

Will the coro package be exposed as public API in the future? Here's to hoping ♥️

Always choose the right tool for the job? Nah. I use Go basically everywhere, which either makes me insightful or stupid. Decide for yourself! :D

On my work I'm always switching between databases and kind of tired on UX differences between psql, mysql, sqlite3. So, I'm making a small set of tools for myself in tries to solve that. It's kinda works for me already and I'd like to share it here :)

I made some Go scripts that require user input fmt.Scanln(&fileName) during the execution. When I use the Go debugger built into VSCode which is the launch type, it works but there is no way to enter any prompts when your exeuctable asks for a input. With other programming languages like NodeJS and PHP, there is way to run the scripts in "debugging mode" where it will run the code but before it executes the code, it will wait to attach to a debugger on your system and then execute the code. This has always allowed me to use the terminal for inputs in the executable.

For example to do this in NodeJS, you will use node --inspect-brk=0.0.0.0 main.js instead of node main.js and then run the debugger in VSCode to attach it to the executing script. Is there a way to do this with Go? Do I need to set something up to achieve this?

I am on Linux Mint and cannot find any commands to run go run . but to wait for a debugger to attach to the executable before executing.

From @palkan: Learn how to temporarily stream verbose logs from your @golang applications without restarts and even without changing the application-level logging settings.

https://evilmartians.com/chronicles/realtime-diagnostic-logging-or-how-to-really-spy-on-your-go-web-apps

cross-posted from: https://discuss.online/post/8349829

Hello,

We're looking for GoLang contributors to help with the federation service. We're happy to have people that contribute code or help with code reviews.

If you know anyone or if you're interested please reach out!

Email: hello@sublinks.org Mastodon: https://utter.online/@sublinks Online form: https://sublinks.org/join_organization.html

Thanks, jgrim

After asking for a first programming language here, I've decided learning Go. After some searching I've found that the beginner learning resources are some years old. Can anyone suggest some beginner resources for someone that likes to learn by doing stuff? Thank you.

go1.22.2 (released 2024-04-03) includes a security fix to the net/http package, as well as bug fixes to the compiler, the go command, the linker, and the encoding/gob, go/types, net/http, and runtime/trace packages. See the Go 1.22.2 milestone on our issue tracker for details.

cross-posted from: https://midwest.social/post/9890016

Rook, a secret service backed by Keepass 4.x kdbx

Howdy Lemmy,

I'm announcing Rook v0.0.9, software that provides a secret service a-la secret-tool, keyring, or pass/gopass, except backed by a Keepass 4.x kdbx file.

The problem Rook solves is mainly in script automation, where you have aerc, offlineimap, isync, vdirsyncer, msmtp, restic, or any other cron jobs that need passwords and which are often configured to fetch these passwords from a secret service with a CLI tool. Unlike existing solutions, Rook is headless and does not have a bespoke secrets database, full of passwords that must be manually synchronized with Keepass; instead, it uses a Keepass db directly.

While the readme goes into more detail, I will say the motivation for Rook evolved from a desire to use a Keepass db in a GUI-less environment and finding no existing solutions. KeepassXC provides a secret service, but is not headless; it also provides a CLI tool, but this requires the db credentials on every call. kpmenu exists, but is designed specifically to require human interaction and is unsuitable for cron environment scripting. Every other solution maintains its own DB back end, incompatible with Keepass.

Rook also benefits from minimal external dependencies, and at 1kloc is auditable by developers - I believe even by ones who do not know Go (the language of implementation). Being able to verify for yourself that there's no malicious code is a critical trait for a tool with which you're trusting secrets.

Rook is fit for purpose, and signed binaries are provided as well as build-from-source instructions (for auditors).

The project contains work in progress: credentials are limited to simple password-locked kdbx, and so doesn't yet support key files. Bash scripts that provide autotyping and attribute/secret selection via rofi, fzf, and xdotool are provided, for GUI environments; these have known bugs. Rook has not been tested on BSD, Darwin, or any other system than Linux, but may well work; the main sticking point is the use of a local file socket for client/server communication, so POSIX systems should be fine, but still, YMMV.

As a final caveat: up until v0.0.9 I've been compressing with brotli, which is very nice yet somewhat obscure. With the next release, everything will be gzipped. Also included in the next release will be packages for various distributions.