Being comfortable with basic back-of-the-envelope math can be a huge benefit. (Full disclosure: i am a math major who is now a programmer)

Over my career I have several examples of projects that have saved weeks worth of dev time because someone could predict the result with some basic calculations. I also have several examples where I have shown people some basic math showing that their idea is never gonna work, they don’t listen and do it anyway, and I see them 1 month later and the project failed in the way i predicted.

A popular (and wise) saying is that “Weeks of work can save you hours of meetings”. I think the same is true for basic math. “Weeks of coding can save you minutes of calculation”.

You can definitely be a successful programmer career without great math skills. Math is a tool that can help you be more effective.

Must include CHANGELOG…

The changelog:

• misc fixes
• pls work
• fixe a typo

Interesting observation! The most simple explanation would be that it is memory claimed by the Go runtime during parsing of the incoming bson from Mongo. You can try calling runtime.GC() 3 times after ingest and see if it changes your memory. Go does not free memory to the OS immediately, but this should do it.

2 other options, a bit more speculative:

Go maps have been known to have a bit of overhead in particular for small maps. Even when calling make() with the correct capacity. That doesn’t fit well with the memory profile you posted well, as I didn’t see any map container memory in there…

More probable might be that map keys are duplicated. So if you have 100 maps with the key “hello” you have 100 copies of the string “hello” in memory. Ideally all 100 maps qould share the same string instance. This often happens when parsing data from an incoming stream. You can either try to manually dedup the stringa, see if the mongo driver has the option, or use the new ‘unique’ package in Go 1.23

The context package is such a big mistake. But at this point we just have to live with it and accept our fate because it’s used everywhere

It adds boilerplate everywhere, is easily misused, can cause resource leaks, has highly ambiguous conotations for methods that take a ctx: Does the function do IO? Is it cancellable? What transactional semantics are there if you cancel the context during method execution.

Almost all devs just blindly throw it around without thinking about these things

And dont get me startet on all the ctx.Value() calls that traverse a linked list

Depending on your needs you can also break it into a columnar format with some standard compression on top. This allows you to search individual fields without looking at the rest.

It also compress exceptionally well, and “rare” fields will be null in most records, so run length encoding will compress them to near zero

See fx parquet

That we stop fawning over tech CEOs

Thank you for saying this. Sometimes I feel like I sm the only one thinking like this 🙇♥️

Pet peeve: don’t use string keys. It invites key collision errors. Use the fact Go supports structs as keys in maps. Safer and more efficient.

You should probably change page content entirely, server sizey, based on the user agent og request IP.

Using CSS to change layout based on the request has long since been “fixed” by smart crawlers. Even hacks that use JS to show/hide content is mostly handled by crawlers.

I am super excited for this release. I think varargs min/max() built-ins are my favorite feature. Closely followed by clear() and improved type-param inference