kamstrup

joined 1 year ago
 

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 ♥️

[–] [email protected] 1 points 1 month ago
[–] [email protected] 2 points 1 month ago
[–] [email protected] 4 points 1 month ago

There is manual memory management, so it seems closer to Zig

[–] [email protected] 0 points 1 month ago

There is a dangerously large population of devs and managers that look at themselves, unironically, as the gigachads pumping out ui "upgrades"

Many of these fail to realize how disruptive it is. UI change is like API breakage for the brain.

I have lost track of how many times I've tried to help an elderly family member with an app after some pointless, trivial, ui change. Only ending with them entirely giving up on using the app after the "upgrade" because the cognitive overhead of the change is beyond the skill that can fairly be expected for them 💔

[–] [email protected] 4 points 2 months ago

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

[–] [email protected] 1 points 2 months ago* (last edited 2 months ago)

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

[–] [email protected] 2 points 8 months ago* (last edited 8 months ago)

Postgres and MySQL/mariadb are all primarily written in C.

Contrary to what other posters here claim, most programming languages are not written in C, but are self hosted. Ie. written using themselves. This usually involves a small bootstrapping component written in C or something similar, but that is a minor part of a whole

[–] [email protected] 29 points 9 months ago

That we stop fawning over tech CEOs

[–] [email protected] 5 points 9 months ago

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

 

Go 1.22 will ship with "range over int" and experimental support for "range over func" 🥳

[–] [email protected] 1 points 10 months ago

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.

[–] [email protected] 2 points 1 year ago (1 children)

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.

[–] [email protected] 0 points 1 year ago (1 children)

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

view more: next ›