HN user

ngalaiko

82 karma

meet.hn/city/57.7072326,11.9670171/Gothenburg

Socials: - bsky.app/profile/galaiko.rocks - github.com/ngalaiko - galaiko.rocks

---

Posts6
Comments24
View on HN

trunk based is the way to go, especially for small teams building web / backend services

especially combined with monorepo

amount of time people spend updating dependencies between internal services and libraries in a pursuit of semver for now reason is just absurd

for me it was functional programming. and not just fp as is, but it's relation to another popular concept - oop.

i was properly introduced only to oop, and grasped a little of fp here and there, especially learning go and javascript.

what i consider a 'click' for me is when i realised that all of these paradigms are interchangeable. like, an abstract method is just a function, or a function signature is the same as in interface with a single method.

after that i write code however it feels more appropriate for the situation i am in and don't think too much about fancy words and patterns. it really feels like programming languages are becoming 'native' for me.

How can you write code if you don't know where and how it would be running? For me it's extremely uncomfortable to know that there are "they" who will do the "unsexy" "dirty" work to make _my_ code run.

I've been painfully aware of spreading myself too thin trying to handle both feature development, CI/CD maintenance and DevOps-related tasks ensuring our cloud-based environments are deployed to and operate smoothly.

Reduce complexity.

As a code developer ... You don't have to deal with infra or packaging/deployment

This is false (and wrong). As a software engineer, you must understand and own what you do end-to-end, including:

* how to write your code

* software/hardware that your code relies on (databases, k8s, aws, whatever)

* protocols your software uses for communication

* 3rd party libraries that your software depends on

* how to build and deploy your software and environment for it (bare metal, clouds, mobile app stores - whatever necessary)

* setup testing + write tests for all of the above

* setup monitoring + monitor all of the above

at any company, at any scale.

another person who can’t get over his java stockholm syndrome in three (!) years

one particular thing that tells that is the attitude to interfaces:

while in java (and most languages) interfaces are used to tell which contracts a class implements, in go it’s reversed. you must declare interfaces to _require_ certain contracts, for arguments in your functions

for example:

type interface Operator { Operate(int, int) int }

func IntOparation(a, b int, op Operator) int { return op.Operate(a, b) }

this is a major difference highlighting the ownership boundaries: * when I write a package and rely on a 3rd party contract, instead of referencing it and adhering to it, I will copy-paste parts that I need to my package and be independent

sure. but usage of generics in go is heavily discouraged both by best practices and by the api

generics however are more available to an average gopher

i believe that such availability will eventually produce a go version of spring, or a typescript-like type system, or something even worse