3 ms·

Where does this cause problems for you in practice? Where is the usefulness of goroutines limited practically? Where is the complex notion of a compiler pass ca

Where does this cause problems for you in practice? Where is the usefulness of goroutines limited practically? Where is the complex notion of a compiler pass causing problems? I’m very open to the idea that I’m suffering from a problem I don’t know I have, but right now you’re just asserting that problems exist without actually telling us how to recognize them.

valenterry 5y ago
I think OP didn't even start using go in practice, so the question doesn't help. But I can say that it's the same ad with natural languages. No one ever feels that their mother tongue is limiting, until they learn a new and very different language and learn a pattern/style that they cannot apply in the mother tongue.
- omginternets 5y ago
  That's fair, except that I routinely program in: - Go - OCaml - Python - Lisp I think I have a reasonably good sense of what each language offers and what it does not. But OP goes beyond saying "Go does not offer some features that other languages offer"; he effectively says that the language causes severe problems. Where are they?
  - valenterry 5y ago
    "severe" is certainly subjective, so you might disagree. From my perspective, none of the languages you listed allows for good error handling. But that is obviously only my perspective. I would call this a "severe" issue. In fact, all languages that k I know have at least one "severe" issue.
- masklinn 5y ago
  This actually has a name in programming circles: the blub paradox. I guess in natural langages this would be the sapir-whorf hypothesis. Blub seems like a much stronger effect though, at least anecdotally. But that might be because natural languages are rarely compared in terms of features / capabilities, and even more rarely “ranked” along various such axis.
kerkeslager 5y ago
I'm not saying a compiler pass is a problem: I'm pointing out that Go fanboys originally said that they needed a single compiler pass, and that was why Go couldn't have generics. But Go has abandoned single pass a long time ago, and Go still doesn't have generics, and when it does have generics, it will have an abstraction so complex that it makes adding another compiler pass look simple. If anything, I think compiler time is worth a lot less than developer time for the vast majority of projects, and if a compiler pass saves developers even a little time, I say add the compiler pass (within reason--don't keep doing this until the compiler grinds to a halt). This is fairly obvious and encoded into the compilers of almost every compiled programming language. But Go is learning this 12 years into its existence when everyone else knew this before Go existed. As for goroutines being limited: here's a practical example: 1. Write a basic two-person p2p chat in Go and some other appropriate language. At a high level, each user client has a message log, and the other user can write messages to it. Since the arrays are single-reader, single-writer, there's no real problem, just use an array: this is a nice demo of how simple Go is! You don't need all these fancy abstractions! 2. Expand the chat to include a third person. Again, everybody gets a message log, but now more than one person can write to it. Now, your message log is multiple writer, single reader (assuming each user can maintain their own log of messages they've sent so they don't need to read other people's logs to get those--there's an implicit copy here but that's fine). In Go, start over and write a probably-buggy implementation of a SRMW queue because Go is too simple to have that already. In any reasonable language, wrap writes to your message logs in a built-in queue that's already thread-safe. Note here that "any reasonable language" in this case includes Java (LOL!). In Erlang/Elixir/Clojure, you may literally have accidentally supported a third user already and have to make no changes. There are of course other go implementations which are maybe more idiomatic, but none of them approach the simplicity of a language that supports message passing.
- omginternets 5y ago
  Your example is super helpful for focusing the discussion, so firstly, thank you for taking the time. My immediate thoughts are: - This is rather specific. Not all programs should be using complex thread-safe data-structures. Rather, the primitives are in place to build such things, and libraries can be imported etc. - These more sophisticated data-structures have runtime costs that are a bit less straightforward to understand as compared to arrays. They require either (a) programmers to be aware of the edge cases or (b) a higher-level language where programmers relinquish some control over runtime performance. To be clear, I personally enjoy many such languages. Overall, your criticism is equivalent to saying "Go is too low-level". That may well be the case for many applications, but that remains to be argued more precisely.

valenterry 5y ago

I think OP didn't even start using go in practice, so the question doesn't help. But I can say that it's the same ad with natural languages. No one ever feels that their mother tongue is limiting, until they learn a new and very different language and learn a pattern/style that they cannot apply in the mother tongue.

omginternets 5y ago
That's fair, except that I routinely program in: - Go - OCaml - Python - Lisp I think I have a reasonably good sense of what each language offers and what it does not. But OP goes beyond saying "Go does not offer some features that other languages offer"; he effectively says that the language causes severe problems. Where are they?
- valenterry 5y ago
  "severe" is certainly subjective, so you might disagree. From my perspective, none of the languages you listed allows for good error handling. But that is obviously only my perspective. I would call this a "severe" issue. In fact, all languages that k I know have at least one "severe" issue.
masklinn 5y ago
This actually has a name in programming circles: the blub paradox. I guess in natural langages this would be the sapir-whorf hypothesis. Blub seems like a much stronger effect though, at least anecdotally. But that might be because natural languages are rarely compared in terms of features / capabilities, and even more rarely “ranked” along various such axis.

kerkeslager 5y ago

I'm not saying a compiler pass is a problem: I'm pointing out that Go fanboys originally said that they needed a single compiler pass, and that was why Go couldn't have generics. But Go has abandoned single pass a long time ago, and Go still doesn't have generics, and when it does have generics, it will have an abstraction so complex that it makes adding another compiler pass look simple. If anything, I think compiler time is worth a lot less than developer time for the vast majority of projects, and if a compiler pass saves developers even a little time, I say add the compiler pass (within reason--don't keep doing this until the compiler grinds to a halt). This is fairly obvious and encoded into the compilers of almost every compiled programming language. But Go is learning this 12 years into its existence when everyone else knew this before Go existed. As for goroutines being limited: here's a practical example: 1. Write a basic two-person p2p chat in Go and some other appropriate language. At a high level, each user client has a message log, and the other user can write messages to it. Since the arrays are single-reader, single-writer, there's no real problem, just use an array: this is a nice demo of how simple Go is! You don't need all these fancy abstractions! 2. Expand the chat to include a third person. Again, everybody gets a message log, but now more than one person can write to it. Now, your message log is multiple writer, single reader (assuming each user can maintain their own log of messages they've sent so they don't need to read other people's logs to get those--there's an implicit copy here but that's fine). In Go, start over and write a probably-buggy implementation of a SRMW queue because Go is too simple to have that already. In any reasonable language, wrap writes to your message logs in a built-in queue that's already thread-safe. Note here that "any reasonable language" in this case includes Java (LOL!). In Erlang/Elixir/Clojure, you may literally have accidentally supported a third user already and have to make no changes. There are of course other go implementations which are maybe more idiomatic, but none of them approach the simplicity of a language that supports message passing.

omginternets 5y ago
Your example is super helpful for focusing the discussion, so firstly, thank you for taking the time. My immediate thoughts are: - This is rather specific. Not all programs should be using complex thread-safe data-structures. Rather, the primitives are in place to build such things, and libraries can be imported etc. - These more sophisticated data-structures have runtime costs that are a bit less straightforward to understand as compared to arrays. They require either (a) programmers to be aware of the edge cases or (b) a higher-level language where programmers relinquish some control over runtime performance. To be clear, I personally enjoy many such languages. Overall, your criticism is equivalent to saying "Go is too low-level". That may well be the case for many applications, but that remains to be argued more precisely.