3 ms·
<>
by smittywerben 8y ago
<>
- logicallee 8y agoFirstly, wow! Thanks. Feedback on draft #2.5: You removed too much praise. Go's syntax is amazing. Can you put that part back in? (Maybe you removed it because I also called it ugly - as opposed to a beautiful syntax like Python's - but that was not a design goal and doesn't bother me. Nobody meant for Go's syntax to be beautiful.) The summary you got down to "I appreciate Go since" is too weak. Its syntax is the best of any language on planet Earth, which is why people can write pages of Go that work on first compilation and always do exactly what they imagine. (The second fact that leads to this is that its specifications and feature set is very small, so that it can be kept in mind by the programmer entirely.) So add stronger praise. If not for such strong praise, why would I want to write everything from desktop applications to microcontroller code in Go, and not any other syntax? I also have a very strong impression that its syntax and specifications are appropriate for both memory-sensitive applications and for desktop applications. (Not really a question). It is due to this strong impression that I want to know what the impediments are. (Maybe this was not clear.) I can see no reason why a Go executable can't be made targeting 100 KB of RAM to do its GC and everything else. I also see no reason why bindings against QT or other GUI frameworks aren't made in the Go language syntax - this is a mystery to me. There must be some impediment. What is it? Can you reply with another draft that incorporates these? I greatly appreciate the thoughts you added to the draft. I think Go is the best language syntax for general programming in any environment from a microcontroller with 150 KB of RAM to a major, 2 Gigabyte desktop behemoth's scripting language. I don't think the lack of class system is an issue (which is the only thing that comes to mind for me.) So you need much stronger praise, please. Go is beautiful (despite its visually ugly syntax) and its use for web apps shows/proves its total appropriateness to all applications. I want to understand the impediments. It should be much farther along to replacing C and C++. Also: >But I worry that Go is moving away from this mantra over the initial specification I don't have such a worry. I guess you could say: "But my impression is that the Go compiler leaves a lot of the huge benefit that is still in its specification: that is, a safer replacement for C and C++. It is perfectly viable as a replacement for nearly all C and C++ language work." I'd like to understand why it isn't doing so yet and what it will take to get there. Hope this helps clarify my thinking. Turn up the praise.