I read your story there and one thing immediately leaped out to me. Isolation. You isolated yourself from your family and your friends. You removed your emotional support structure and then went full burn in a high stress endeavor for an extended period of time.
Nobody not even extreme introverts can survive emotionally without a social support structure. You're feeling the aftermath now. The good news is it looks like you've reconnected with that support structure. You aren't going to start feeling better overnight though. Give it some time and learn from this experience. You need your family and friends support and you need to go at a pace that your health can support.
Right now you need to heal and that might takes months. Don't despair when it looks like the healing is going slowly. You will heal and then you can try the entrepreneur thing again once you've recovered.
Mutexes are absolutely idiomatic Go code. In fact the Core developers on the ML will often suggest them as a simplification over goroutines for synchronizing access to a shared resource. I'm not sure where you get the idea that they aren't idiomatic.
"Do not communicate by sharing memory; instead, share memory by communicating.
This approach can be taken too far. Reference counts may be best done by putting a mutex around an integer variable, for instance. But as a high-level approach, using channels to control access makes it easier to write clear, correct programs. "
There are no implications here, it's stated pretty explicitly:
"Reference counts MAY be best done by putting a mutex around an integer variable, for instance. BUT as a high-level approach, using channels to control access makes it easier to write clear, correct programs."
There is a difference between what someone with a background from other mainstream programming languages might think would be the best approach to locking (mutexes) and the idiomatic Go approach (unbuffered channels).
Data IO, formatting, pre and post processing and presentation.
My standard approach is to use python to read in all my data, parse it, format it and beat it into the shape I want. Then, if I need the performance, I pass the data to a highly tuned C function for slowest number crunching parts. Then I take the data back from C and parse it, format it, summarize it and write it out to the file formats I want using python. C may be faster for number crunching, but python is much nicer for data handling, and there the performance difference is negligible.
Nothing in that article fixes the issues that make PHP unpalatable to me. They are all new features added to the current broken set. Even if they are new and shiny they don't make the rest of the language suddenly better.
Which is really kind of the problem with PHP. All of that broken stuff was allowed to be broken for so long that it's effectively impossible to fix it. All you can do is layer on more features.
Complaining is often a result of comparing our situation to the rest of the environment. When you are sitting in your car in traffic you see that other lane moving faster than you and you get frustrated. When you are at that amazing job you see that other guy two job levels above you with even more perks.
If you only surround yourself with an environment where you don't quite measure up then your baseline gets set two high. You need to recalibrate.
I recalibrate by doing Charity work. And I don't mean just writing a check. I roll up my sleeves and actually engage with people in less fortunate circumstances. Work in a soup kitchen or a food pantry. Volunteer to repair or rebuild someones house when they can't afford to or a tragedy has struck.
It exposes you to people who haven't had the breaks that you had and also helps raise the standard of living for someone less fortunate or lucky and that helps keep your baseline from getting to high.
I remember minimizing the terminal window to make a script run faster. Taking the text rendering out of the execution path actually had a substantial speedup for long running scripts in some cases. It was one of those things you sort of picked up from other people along the way and assumed everyone knew.
Nowadays I don't know if the difference is noticeable enough to be common knowledge though.
If bringing your team together is the goal, it cannot be served by labeling those who choose to bring a lunch as "boring types". I know my feelings would be hurt if my coworkers decided to exclude me for that reason.
How does bringing lunch from home prevent team lunches? If it's scheduled ahead of time, it's easy to bring less. One might even be able to justify budgeting N lunches/month out with coworkers.
Also, lunches together don't always have to be in a restaurant. Buyers can get food to go, bringers can take theirs with them, and then you can either meet in a conference room, at a park, etc.
byteHandler is not a struct it's a byte slice. This is actually somewhat important since it highlights a nice feature of go where you can declare methods on any baseType by aliasing them to your own type.
There is no struct involved here and there doesn't need to be which is nice.
You are right that there is near to zero chance of that occuring. Which is probably what the previous poster meant. Since you can show up with a life threatening issue at a hospital and get stabilizing life saving treatment regardless of your insurance anyone who doesn't have insurance is effectively already leeching.