If the thinking was truly "slower", i.e. have less throughput, it would result in fewer insights overall, i.e. lower intelligence. This doesn't seem to be the case since the author describes equal success of these "slow thinkers" to neurotypical ways of thinking.
The problem therefore seems to be more accurately described as having the same insights as others, but they arrive later, i.e. "delayed" insights.
Delayed processing could be an effect of delayed context switching, i.e. monotropism [0]. Monotropism can be an indicator of mild autism.
Please note that the article merely encourages the application of some of the best practices introduced by functional programming - strong typing and more mindfulness around mutability and side effects - into all forms of programming.
Functional programming as it exists today takes these ideas to a somewhat extreme form. That has its place and value, but as experience in the real world shows, as long as it feels so mathematical, it isn't everybody's cup of tea. Hopefully, over time we find more intuitively accessible abstractions for the really useful principles that functional programming is based on.
I also don't expect that a lot of the existing Java code will be rewritten in Go. But there exists a whole array of startups/unicorns today who use Go extensively. Many of them will grow into enterprises. I predict that Go will generally hold up well for them as they scale. They will feel a lot less of an urge to switch to something more mature and scalable like Java, as many companies who started out with Ruby, Scala, or PHP did.
I often see enterprises using a mix of languages and technologies (depending on how independent the different org units within it are) and some amount of Java fatigue in developers who are not retiring in less than a decade. Go is often amongst the top choices they are exploring.
In addition to the right culture, great platforms enable great ecosystems. I have found that putting everything as Markdown on a collaboration platform like Github/GitLab works really well and enables collaboration in a number of ways:
- people don't feel awkward to modify other people's content because there is a collaboration and review process in the form of pull requests
- you can assign different people to oversee different parts of the knowledge base. They make sure the organization of the knowledge base doesn't get messed up by reviewing changes of other people to it.
- you can keep others in the loop about important updates (big and small) by tagging them in pull requests
Git Town started out as Git aliases written in Bash. Version 3 was many hundred lines of Bash, pushing it beyond what Bash was designed for. At some point it got ridiculous, and we got requests for Windows support, as well as better integration with the Github API. Hence the rewrite in Go.
Git Town covers a ton of edge cases. Just look at their "features" folder. If something goes wrong, Git Town allows to cleanly abort and undo what it did so far and go back to where it started.
That's a lot safer than the unholy mess that ensues when most people try to run "git reset --hard" or "git push --force" manually.
Edge cases handled properly may be the killer feature of this project, at least for me. With git, as long as I'm in familiar territory it's fine, but when somethings goes off rails my head's working set explodes with options.
The problem therefore seems to be more accurately described as having the same insights as others, but they arrive later, i.e. "delayed" insights.
Delayed processing could be an effect of delayed context switching, i.e. monotropism [0]. Monotropism can be an indicator of mild autism.
[0] https://en.wikipedia.org/wiki/Monotropism