Do you realize that "HN" isn't one single monolithic entity that needs to achieve 100% consistency in its views? Like if one person here says "use existing libraries" but then a different person says "don't use this existing library", that doesn't actually mean that someone was being hypocritical.
You might also consider that not all advice (especially when presented in an extremely limited form like a comment box on a website) should be interpreted as black or white, full compliance or complete rejection, but might better be treated as a general guideline or recommendation and that standard disclaimers or tradeoffs ought to be implied.
Almost 200 different dependencies. Most of them to handle some niche use-case that are likely not what a given user needs. For some people certbot, with its downsides still might be the best solution. For others, there might be a more appropriate solution that still avoids reinventing the wheel. Eg, I prefer to use a single Go library to do ACME stuff or to just use Traefik or Caddy or some other reverse proxy/load balancer that supports ACME transparently without pulling in a ton of extra packages that aren't relevant to me. But sometimes, cerbot is still the simplest solution, so I use that. I still reserve the right to wish that it had fewer dependencies.
Take advice with a grain of salt is my advice to you. Advice for the average person is not necessarily advice for everyone.
The official client stopped supporting older os like centos 6. Using a third party libruary might be important for some.
People heard using 'goto' is forbidden so many will get upset if one is found in a code base. You can use gotos and in some situations it becomes a better tradeoff. Advice in general is just advice in general..
> People heard using 'goto' is forbidden so many will get upset if one is found in a code base. You can use gotos and in some situations it becomes a better tradeoff.
I'm going completely off-topic on a tangent, but no modern language even supports the goto from the "Goto Considered Harmful" paper. All you can use nowadays (unless you write assembly) is a much weaker version that has none of the problems you'll find there.
> The problem the goto solves in a language that have predefined line numbers like basic just doesn't apply with numberless line code bases.
That's not true. There are useful times to use goto, but the main issue with its use doesn't have to do with line numbers... Using goto leads to spaghetti code that is difficult to maintain or reason about.
the amount of code in existence in languages that support "goto" is mindblowing. I would wager that the majority of developers have encountered it in a code base. even though it's not modern, it's certainly a relevant example for most people
My suspicion is that the majority of developers today haven’t used anything besides JavaScript or Typescript professionally, with maybe a bit of Ruby or Python.
C hasn't supported the Dijkstra's bad version of goto since the last century. Gcc was one of the first to add a verification against it, so if your code compiles on gcc without any "ancient code" flag, it's not there.
As a sysadmin I can examine the code path of, and wrap my head around, one of these much more easily than the other. If something breaks I can throw in a "set -x" in the shell script and start getting debugging information.
Well, if a student driver is given the advice, "always drive to the right," that doesn't mean to turn left out of the right lane! Use some critical thinking, like the person you are laughing at did.
Free advice over the Internet is worth exactly what it sounds like - free advice from nameless, anonymous people.
