5 ms·

I don't even get why Golang is considered a good language. Because it's a more 'get shit done' language (with a fast solid runtime, good stdlib and and fast co

• zozbot234 5y ago
  The 'get shit done' feel of Go and the like is quite illusory, because you're left with a mountain of bugs and general technical debt to be addressed. Rust is designed to 'get sh!t right', where once it's "done" there's at least a fighting chance that it's really done and can actually be delivered in production.
  • vlunkr 5y ago
    > you're left with a mountain of bugs and general technical debt to be addressed Unless you can elaborate more, this is pretty meaningless. I could make the same statement about Rust or literally any language and it would be just as substantial.
    • Yoric 5y ago
      I haven't done any serious go, so I cannot debate this in depth. However, seen from a distance, it feels like: - people who code in Rust and hate it do so because they keep fighting the borrow checker; - people who code in go and hate it do so because their code is buggy. Now I code regularly in Rust, I enjoy it very much and I very much understand why some people dislike the borrow checker. I prefer Rust but I very much understand why some of these developers may prefer go (or Python, or TypeScript, etc.). On the other hand, I don't code in go (sufficiently) to know whether go is as full of gotchas as developers who hate go make it look.
      • lanstin 5y ago
        Given that the data seem to suggest more code is written in Go, perhaps it's just that code is in general buggy and that is a hateful thing, but it means the language isn't getting in the way also.
        • Yoric 5y ago
          > Given that the data seem to suggest more code is written in Go, perhaps it's just that code is in general buggy and that is a hateful thing Maybe? I'm not convinced. If that was the case, I assume that I would have seen someone accusing Rust of shooting them in the foot. Again, while Rust is my current favorite language, I make no claim that Rust is perfect by any metric. > but it means the language isn't getting in the way also. Probably? I don't practice go sufficiently to be a judge of that. I know that the Rust community would definitely assume that the compiler (or at least clippy, the standard linter) should get in the way of anything that is obviously (or not-so-obviously) going to cause a bug sooner or later.
      • int_19h 5y ago
        I don't know about full, but when the correct way to add an item to a collection is: slice = append(slice, item) Note that you must have the assignment for this to work correctly. But if you don't, it'll work correctly some of the time - whenever the backing array doesn't have to be reallocated. Now, yes, the linters do catch it. But it's hard for me to consider a language mandating such a pattern as well-designed.
        • philosopher1234 5y ago
          This strikes me as very shallow. I would grant that this is an unusual pattern, but I don't think it follows that the language as a whole is poorly designed because of that. It's simply a different design, not necessarily a worse one.
          • zozbot234 5y ago
            It seems weird enough for a language that's supposed to be "simple" and "easy to learn" in the first place. Note that a lot of the not-so-intuitive complexity in the Rust borrow checker is intended precisely to avoid having code be affected by lower-level details such as storage reallocation.
            • philosopher1234 5y ago
              I agree, it is not the easiest possible api to learn, so perhaps there was a trade off made. Concluding the language is bad because you don’t understand a decision is lazy.
          • Yoric 5y ago
            Well, if a call such as `append(...)` (without the assignment) can either succeed or fail silently depending on side-conditions, this specific example seems to suggest that a developer cannot trust the result of tests. That... doesn't feel me with much confidence in the language (or, well, its stdlib).
            • philosopher1234 5y ago
      • vlunkr 5y ago
        > people who code in go and hate it do so because their code is buggy. My experience is that these people hate go because it's less expressive and more repetitive. See `if err != nil` as an example.
        • Yoric 5y ago
          I haven't heard much from these people, but perhaps their anecdotes are simply less funny than bugs in go :)
  • lanstin 5y ago
    I've had two servers I wrote in Go go into production (and a variety of command line tools, and a library used in other servers). Having code that is effectively bug free is the norm. I think one time I had an FD leak that took a few days to show up (bad TCP connection state handling in my code, not really something that Rust would avoid, I guess), but every thing else was feature requests (and sometimes fixing bugs in the new feature's logic, but that's sort of different). I wouldn't guess it's super fast, but the super-power of Go is you can use all those cores efficiently without getting dragged down and murdered by a lot of mutex/lock stuff, and it's efficient and fast with medium-high volumes (few K/second of messages per core, that sort of thing). Both of those servers were left behind and maintained successfully by other people, so I don't think they are examples of a pile of tech debt. They are invisible network appliance type code, but customized to be super-precisely what was needed for specific network problems. It is as fast to dev in as Python, lets me mix and match data structures and algorithms via problem-specific structs, and is able to use my hardware.