programming is programming. i don't buy this "used in different areas" thing. if it is all the same at the level of execution, then everything else about the language doesn't matter, except that it doesn't waste the programmer's time or impede debugging.

i have written GUIs in go and given the right API design it is no more difficult to do than in some language "designed for GUIs"

in actual fact, the origin of the majority of Go's syntax WAS a language designed for GUIs, using atomic FIFO queues (channels) called NewSqueak (a language for mice).

is there REALLY justification for this common expression about "languages for use cases" when everything needs if, for, functions, methods, types. the fact that you can write in Go almost the same way as if it was C for embedded systems using TinyGo tells me, nope.

- can do servers

- can do GUI

- can do embedded programming

no, i strongly disagree. i don't think there is anything that i can't do with Go, just that this silly attitude prevails and so people invent new languages with extra wingdings and features that bloat and bloat and bloat the compilation, impede debugging, make for unreadable code, require you to basically maintain almost identical code across multiple files (looking at you, C/C++) and the worst, is either the performance is abysmal, or the compilation time is eternal.

the facts are that as far as performance, Go is only like 5% behind java, C++/C and Rust. considering how abrasively the fanatics of these language consider GC to be, that tells me they are masochists who like to sit around twiddling their thumbs for 5% extra performance, and bragging rights. i think bragging rights is the main reason.

i only credit bragging rights to assembler programmers. everyone else can get off their arse and write their code properly, for humans to read, and not just retardedly complex rube goldberg compilers