3 ms·

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 could

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.
LaPingvino 5y ago
No, the documentation stated that Go was designed for reading without backtracking. That results in single pass compilation being possible and thus being faster, but that was never a limitation that was imposed. The reading without backtracking is still valid: go generate DOESN'T work on .go files, only on any other tool that generates .go files. About the second part, you seem to mix up goroutines and channels. In a concurrent system, you would need locks for your example, and channels fix this. Goroutines are just the representation of independent processes and can be implemented and ARE implemented differently per compiler, check e.g. how tinygo and gopherjs do this. Your example point 2 doesn't make any sense, check fan in and fan out patterns with channels. Go supports message passing, that is what channels are. You really didn't try Go and it shows.

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.

LaPingvino 5y ago

No, the documentation stated that Go was designed for reading without backtracking. That results in single pass compilation being possible and thus being faster, but that was never a limitation that was imposed. The reading without backtracking is still valid: go generate DOESN'T work on .go files, only on any other tool that generates .go files. About the second part, you seem to mix up goroutines and channels. In a concurrent system, you would need locks for your example, and channels fix this. Goroutines are just the representation of independent processes and can be implemented and ARE implemented differently per compiler, check e.g. how tinygo and gopherjs do this. Your example point 2 doesn't make any sense, check fan in and fan out patterns with channels. Go supports message passing, that is what channels are. You really didn't try Go and it shows.