O look another amazing and riveting discussion on emerging technology with real world implications… o wait it’s just a bunch of cranky people complaining about crypto.
That's the point I was trying to highlight in the "Treating product engineers as customers" sin section – the duality goes both ways. Sometimes the best thing for the company is to make the lives of product engineers better, sometimes it's to make them worse. You do whatever is best for the company, not for the product engineers.
What is the difference between print debugging and logging? With most deployments setups now days you can pipe prints to some logging solution anyways.
Logging lets you refine the level of printing and is designed to make sense in the long term. There are many technical differences (structured logging, MDC etc.) that I won't get into but they are important.
To me it's mostly about the way you write the logs vs. the way you write a print. A log tries to solve the generic problem so you can deal with it in production if the need arises by dynamically enabling logs. It solves the core issue of a potential problem. A print is a local bandaid. E.g. when print debugging one would write stuff like "f*ck 1 this was reached"... In logs you would write something sensible like "Subsystem X initialized with the following arguments %s". That's a very different concept.
totally agree re: structured logging. my intro to that was w/GCP Logging and it changed my mind on when and what to log. proper structured logging and keying metrics/alerts from those metrics is extremely satisfying and legitimately useful.
Switching from JSON to Jsonnet to get comments and trailing commas is like switching from a butter knife to a chainsaw because your steak is too tough. Jsonnet is literally Turing-complete!
Why would it be sold cheaper in Mexico when you can go on a dex and trade it for any number of tokens and cash it out. This just doesn’t make sense and im not signing up to read their stupid articles.
Likely this will be upvoted here though because it paints crypto in a negative light. Enjoy HN.
I did, multiple times with multiple countries. All of them had some sort of call rotation. Someone was always at the helm, _specially_ in infrastructure and security.
There are whole startups designed to solve this, like PagerDuty.
I am now very curious to understand where your question comes from. There must be some misunderstanding here. You never went on-call or seen a friend do it?
OP said it’s malicious or incompetent to release this on a U.S. holiday weekend. You asked if similar consideration would be given to Brazil. Multiple people chimed in that it would. You’re now pivoting to on-call capacity.
Any amount of on-call capacity can be saturated. That’s why competent multinationals avoid releasing while markets they’re likely to impact are sleeping or drunk. This is a high-level scheduling operation, however, so it’s reasonable for those lower in the organisation to be unaware why an update is being pushed next Tuesday instead of this.
Rotation or always-on isn’t a substitute for being aware of your customers. Good culture permeate this throughout the organisation. Competent ones have someone at the top ensuring controls are followed.
Hard disagree on this. Large production apps that use channels have very subtle bugs that cause all kinds of annoying issues that only come up under load in prod. I have been using go for ten years and still pick it as my language of choice for most projects however I stay away from channels and especially any complex use of them unless it’s 100% required to scale the application. Even then you can most of the time come up with a better solution by re architecting that part of the application. For pet projects go crazy with them though.
What are you disagreeing with exactly, are you trying to argue against testing? Are you trying to argue that using a library protects you from bugs somehow?
You stay away from something you don't understand after 10 years of working with it? What kind of logic is that? Channels aren't magic.
Subtle bugs in what? Have you considered that maybe you have bugs because you aren't writing tests?
If you aren't unit testing that stuff, then how are you able to fix/change things and know it is resolved?
My experience is that I built a binary that had to run perfectly on 30,000+ servers across 7 data centers. It was full of concurrency. Without a litany of automated tests, there is no way that I would have trusted this to work... and it worked perfectly. The entire deployment cycle was fully automated. If it passed CI, I knew that it would work.
It wasn't easy, it took a lot of effort to build that level of testing. But it was also totally bug free in production, even over years of use and development.
You asserted that bugs are hard if you write unit tests. The parent stated that some issues only occur under production load and a unit test will not catch it. Nowhere was it implied that unit tests are useless.
Perhaps a less defensive posture might invite more discussion.
> The parent stated that some issues only occur under production load and a unit test will not catch it.
I can't think of a single production problem that can't be replicated with a unit test. If you're seeing a problem in production, you need to fix it. How do you fix it? You write a test that replicates the problem and then fix the code, which fixes the test.
> If you write comprehensive unit tests, it is not easy to have bugs in golang.
First you claimed before that unit tests will catch your subtle concurrency bugs before they happen, and that's just not often the case. They are subtle, might involve many systems and weird edge cases and often don't get caught BEFORE they happen. Of course anyone can write a test to replicate the problem after seeing it in production and spending hours/days debugging it.
More importantly, "Write comprehensive tests" is technically a strategy to avoid any bug ever. You can tell C programmers not to segfault by writing comprehensive tests but that doesn't negate the point that the language makes it easy to write segfaults. "Write more tests" is not a rebuttal to saying C makes some classes of errors easy to write. Writing comprehensive tests often takes a lot of time, is often not prioritized by companies, and is especially hard with distributed systems, concurrency, mocks and complex applications. If we just said "git gud noob" in the face of error prone and difficult abstractions, we might as well all be using assembly.
Thank you for sharing your perspective. I genuinely appreciate honest feedback. My goal is always to add value to discussions, but it seems I’ve fallen short in this instance. If there’s a specific way I could clarify or improve my comments, I’d be grateful to hear it.
Regarding my company, I respect your decision, but I hope that if our paths cross again, I might have the opportunity to change your mind through actions that demonstrate the value we provide to our customers.
The original comment was about how concurrency expands / makes it easier for there to be errors in go (which avoids LOTs of other errors just with compile time / type safety stuff).
"very easy to have bugs when working with channels and the way it handles errors etc"
If you've done some programming you'll find this to be true. You have to think a LOT harder if doing concurrency, and you generally have to do a lot more tests.
Go - WITHOUT that much testing, is often surprisingly error free compared to more dynamic languages just out of the box both language side and how a lot of development happens. Python by contrast, you can have errors in dependencies, in deployment environment (even if code is fine), based on platform differences (tz data on windows), and plenty of runtime messes.
Channels are not as default safe / simple after compile as a lot of other go.
Try programming without channels in go and this may become clearer.
