• 2 Posts
  • 15 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle

  • 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





  • 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 💔


  • 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











  • I have written a bunch of Clojure in previous positions. But it has undergone the same fate that almost all functional code bases I have knowledge of (in corporate product settings): Colleagues have hard times getting into the functional mindset, and it becomes hard to maintain. Over the years it gets replaced with some more pragmatic hybrid- og OO language.

    I have seen the same with projects written in Haskell, Erlang, and Elixir.

    It’s all a really nice idea, but in practical reality it runs into issues with “social scaling”

    EDIT: Realizing this was not super helpful. If you want to look for positions where fp can be employed I think something academia related, or a startup where there is greater technical flexibility is something to look for