I felt very similar when I started working in Go last year. Coming even from languages like Typescript and Python which are most definitely _not_ functional but do have some of the niceties like map/filter/reduce, I was missing it a lot in Go.
What I also found was that there was a whole class of errors that I hadn't seen in years due to mutable state and poorly written for loops/ranges when compared to map/filter/reduce usage.
We introduced `samber/lo`[1] which provides a lodash-like library, generics compatible, to Go. This has been a big step-up and has improved my experience with writing Go immeasurably.
My colleagues now (kindly) joke every time they see a PR from me that includes a lot of samber/lo usage that I'm slowly replacing every for loop I encounter.
Yes I agree. Bad engineering led them to not accepting the reality that technical debt is unavoidable. In a misguided attempt to avoid it, they overengineered ironically leading to more debt than might otherwise have accrued.
From my recent experience in a new team, this article strikes a chord.
Joining a team that is scared of technical debt and runs circles round themselves in a bid to avoid it end up producing more debt than they would otherwise. For example, making code overly DRY and wrong abstractions coupling unrelated parts of the system unnecessarily.
We must embrace the reality of technical debt. It is unavoidable and not something to be scared of. It can be managed by keeping things simple, clearly tested and keeping a cool head.
I like your comparison to nutrition. To stretch the analogy slightly, sometimes in life you only have time for that microwave meal rather than a freshly prepared salad. It's about ingestion of calories to keep going, not the quality of those.
The same _can be_ true with code. There can be a better way to do something but if you cannot afford the time to develop and iterate this idea then it can be advantageous to develop the simplest solution that meets your needs today and make progress.
This is one of my favourite technical sites. It is very clear and to the point about its good use cases while being clear where an alternative would be a better choice.
In a similar vein, VueJS has a comprehensive exploration/comparison of itself compared to other frameworks[0].
I really appreciate open source maintainers that have the humility to compare their work fairly with others within the domain while still taking pride in their own acheivements.
Also an ASL (in Scotland) and can confirm that it is incredibly rewarding helping to shape young people's approach to leadership and teamwork.
It's very hard and can consume A LOT of time (to a detrimental effect on my career no doubt) but I love the sense of community and fun that the young people get from it.
I'm an atheist and a Scout leader in the UK. When writing my programme I always include a spiritual component to it but leave it non-religious. We definitely discuss and explore different religions (in past year visited a Mosque, an Abbey and a Synagogue to learn about their cultures) but never focus hard on a religion or even suggest that holding a religious belief is necessary to be a Scout.
Recently at an event where I renewed my promise I took the Atheist promise which is as follows:
I promise that I will do my best
Uphold our Scout values
Do my duty to the Queen
Help other people
And to keep the Scout laws
I find the majority of Scouters I meet, despite saying the original promise follow this non-denominational one throughout their Scouting. We promote the "worldwide family of Scouts" more than a religious grouping.
If you do look for a Scout group for your son, make sure to talk to the leader there. Different groups approach the issue differently so try to find one that suits you and lets your son avoid being 'forcible subjected to the propaganda' though it can be good for a young person to experience it and make that decision for themselves.
What I also found was that there was a whole class of errors that I hadn't seen in years due to mutable state and poorly written for loops/ranges when compared to map/filter/reduce usage.
We introduced `samber/lo`[1] which provides a lodash-like library, generics compatible, to Go. This has been a big step-up and has improved my experience with writing Go immeasurably.
My colleagues now (kindly) joke every time they see a PR from me that includes a lot of samber/lo usage that I'm slowly replacing every for loop I encounter.
[1]: https://github.com/samber/lo