4 ms·
> The endgame is "Computer, build me a Mars round-trip ship". I think nobody would argue against that endgame, in the broad strokes. But I think Go can be unde
by sagichmal 12y ago
> The endgame is "Computer, build me a Mars round-trip ship".
I think nobody would argue against that endgame, in the broad strokes. But I think Go can be understood as a response to [what the Go developers perceive as] overly expressive languages, languages that have overstepped our ability to responsibly abstract details, languages whose abstractions hide details that are still important and necessary to make explicit.
Go is "lower level" in that it purposefully eschews those abstractions, but I think it does that successfully, without a significant loss in expressivity, and with a more-than-commensurate gain in understandability, maintainability, performance, etc.
- sergiosgc 12y agoI agree. That is a correct reading. Where I do not agree is on the assumption that a basic feature set can be construed as a simpler language. While true for the language proper, it isn't true for real usage of language plus libraries. Take operator overloading. It can be used to create hellish code. It can also be used to create great libraries (numpy for instance). Because of the danger of hellish code, Go makes it impossible to create numpy in Go. In the end, while Go is simpler, a numpy in Go would be more complex[1], because the language is not expressive enough. The simplicity argument, while true for the language proper, is false for advanced usage. [1] For example, you can't write Ma * Mb, but must remember the dot product method name.
- stcredzero 12y agoIs it necessarily a good idea to make Go into a number crunching language?
- sergiosgc 12y agoI have no idea, but that is irrelevant. It is an example. I'm sure you can imagine others in the use case you define for the language.