3 ms·

You might be surprised to find that Talos os (linux distro for kubernetes) mostly uses Go: https://github.com/siderolabs/talos https://github.com/siderolabs/tal

• pjmlp 3y ago
  Not really, I belong to those dreamers of systems programming languages with automatic memory management support. Even though I don't really like most of Go's design decisions, I appreciate it can perfectly fine being used as C replacement, regardless of that anti-GC/RC folks say about it.
  • anttiharju 3y ago
    What of Go's design decisions do you not like? Perhaps a somewhat off-topic question but I'm early in my career and have found Go to be a rather pleasant language to work with so I'm really curious. For example when I was working in a large microservice system, some of the java/typescript repos were a pain to work in because some of the developers had written crazy-looking oneliners. I mean it's possible to write difficult-to-read Go code as well, but I wasn't seeing it anywhere near as much.
    • amenghra 3y ago
      Not the GP, but the error handling mechanism for one. You are less likely to silently/accidentally drop an exception vs Go's tuple return values. Thankfully, there’s linters for Go to catch some common mistakes, still feels fragile imho.
      • jacobr1 3y ago
        My experience has been the opposite. The idiomatic patterns is to have errors handled at the callsite, rather than bubble up. In java codebases I've worked on, you tend to have catch-everything parts of the code that are unable to address the specific problem, and mitigate it by restarting work, or just logging largely because they don't know what went wrong. Not that can't address the issue with exceptions more specifically (it happens all the time) but that often it is easier not to, and just to group all exceptions by their class and move on. In go codebases, In production go-codebases I've tended to see if/else logic for every case. This makes the code horrible to read IMHO, to get a general sense of what is happening, but make much more of specific logic explicit and directly handled.
        • amenghra 3y ago
          You could imagine a language which discourages bubbling exceptions by forcing you to catch and either handle or rethrow each possible exception -- while still making it hard to accidentally forget to handle an exception.
          • jacobr1 3y ago
            Certainly, and go already comes pretty close that explicitness via returned errors. At that point, we are down to a style choice between exceptions and error returns. Honestly I'm not sure it matters and depends upon other factors being balanced in the ergonomics of the language. I don't see any reason why you couldn't accomplish the objective in either style of language. My point is that Go today, both as matter of language features and how it tends to be used via communal norms, incentivizes explicit error handling. The parent comment stated, "You are less likely to silently/accidentally drop an exception vs Go's tuple return values" and while I could easily imagine language features that discourage bubbling exceptions ... in practice, I think that tends to be more the norm than explicit handling of tuple returns.
          • jcranmer 3y ago
            That's Java's checked exceptions...
    • pjmlp 3y ago
      All of these: http://lambda-the-ultimate.org/node/4554#comment-71504 http://lambda-the-ultimate.org/node/4554#comment-71504 You can take the point regarding supporting generic types out of the list.
• vbezhenar 3y ago
  Everything around kubernetes mostly uses Go. That's kind of tradition, I guess.