med-mastodon.com is one of the many independent Mastodon servers you can use to participate in the fediverse.
Medical community on Mastodon

Administered by:

Server stats:

343
active users

#golang

9 posts9 participants0 posts today

hmm, what's a disk efficient way to binary search for the existence of a key?

I hit RAM limits and I want to offload a map[string]nil to disk (but have it have set intersection fast)

I guess rocksdb exists and I could do map[string]nil

but I'm not sure if those pages would be optimal in lookbacks (or optimal across parallel #golang threads)

Hey, my Observability team at Upgrade is hiring. We do metrics, tracing, Golang tooling, and some open source contributions. Fully remote, nice vacation policy. If you're a friend of a friend, DM me and I'll put in an internal referral for you. Come work with me and approve my PRs!

Linking to the Canadian listing, but there's a separate US listing on there

job-boards.greenhouse.io/upgra

job-boards.greenhouse.ioPrincipal DevOps Developer, Infrastructure PerformanceCanada (Remote)

So... I've had this under wraps for months, whilst I've been adding features and ironing out bugs...

I've already been showing:

The next logical piece is:

  • zenas: Z80 assembler (WIP)

zenas is a new Z80 assembler (work in progress) following a simpler design than my earlier attempt. This is designed to work together with zen80 and zenZX, to hot test and benchmark the code the assembler emits

I'm already seeing some promising results. I think it's a cool feature if your assembler can actually run the code it emits (using zen80) with the potential to verify your object code actually works, and every single cycle is accounted for. I can imagine in the future we can expect to have things like register colouring and other neat features.

If we consider the zenXX tools together with the tape handling tools, and with the floppy image tools, we're approaching the status of lovely toolset that could one day be quite useful.

#zen80#zenzx#zenas

Finally took some time to try out the upcoming json/v2 package in #golang. And it delivers! Absolutely enjoying it so far, so thanks everyone involved in that work.

What I also found last night is that this new package makes extensive use of internal names like "arshal" and "arshaler". Surely I can't be the only one having to stop and reread those names every time they appear? Is this some elaborate joke or did someone really write a function named "lookupArshaler" with a straight face? Profiling some of the marshaling code I wrote last night and seeing pprof report the amount of "cum" in "typedArshalers" is absolutely sending me.

It's refreshing using #golang's ecosystem after spending time with other languages' tooling. Over the past few years, things have become really slick.

I'm not talking about the language itself; it's still full of `if err != nil`. But the tooling and ecosystem is *pleasant*.

Go 1.25 came out a few weeks ago, and we've decided to upgrade at work so we can use a few new features.

There's no drama. There are no backwards-incompatible changes. We don't need to get everyone to upgrade to a new version of tools. There are no mandatory "upgrade this library that everything depends on" steps.

You just change the version number in `go.mod`. The next time you run `go build`, in addition to downloading any new Go modules, it also downloads the new version of the compiler backend. It takes a couple seconds.

If you run into bugs (IIRC early releases of Go 1.23 had a few doozies) then reverting is trivial. Just change the version back in `go.mod`.

Package management? Just add code that you need to `import` in your source code. When you build, new imports will be mapped to a specific version, it'll be downloaded automatically, and the version and checksum will be added to `go.mod` and/or `go.sum`. If you download the source onto a new system and build there, it should compile byte-for-byte identical executable. Assuming that you're building for the same CPU and OS, of course.

Upgrading dependencies is a bit of work, but it's not bad. Edit the version number in `go.mod`, run `go mod tidy`, then build. By default, the system is optimized for stability.

It's still possible to get supply-chain attacks, but mostly only by explicitly requesting something that turns out to be bad. Go doesn't auto-upgrade module versions (directly or transitively), and it verifies checksums when (re-)downloading. Unlike NPM, Go style mostly doesn't depend on hordes of tiny third-party modules. So it's not flawless, but it's about as good as we can get today.

The language isn't everyone's cup of tea, and doesn't try to be. Like it, don't like it, whatever. But it'd be great if more languages could use Go's tooling as an example.

I got tired of playing hide-and-seek with Go's examples in the pkg.go.dev's documentation viewer over the years, so I made a change to bring them out into the open! Now examples are front and center — where they've always belonged:

matttproud.com/blog/posts/go-p

As small as the change may appear (went live only yesterday), it means a lot for developers in the Go ecosystem in the form of compounding productivity dividends. Give a read why, connecting it to the bigger picture.

matttproud.com (blog) · Go: Improving Example Visibility in pkgsite (pkg.go.dev)
More from mtp