2 unrelated questions. (tl;dr at bottom)

   Background
   ----------

The two major advantages of Go are its clear, unambiguous and explicit syntax (unfortunately ugly) and very small (minimal) feature set, so that it is possible to reason about anything without any high context.

The former means it is possible to pick up Go in a day or two and the latter means that there are no real tricks after a few months. That's it.

All this has been done in an excellent way. There is no class system. Everything is simple. Explicit typing works.

These design trade-offs have led to a language that is VERY easy to go back to after working in any other language. Almost all simple syntax mistakes by the programmer are caught before something successfully compiles. Once a programmer is used to it, which happens quickly, Go is the only language people write pages of code in that compiles on the first pass and does everything they hoped. "Less is exponentially more."

   History
   -------

Due to the history of Go it was meant to be a systems language. It didn't really succeed at replacing C anywhere, except the web server: I consider Go like a web-safe C. (In no small part due to Google's work meeting its own needs.)

   Question 1
   ----------

What I don't understand is that since speed and being a systems language were explicit design goals, why the Go syntax is not suitable for tiny, embedded microcontrollers.

If the answer is something about garbage collection, this doesn't really make sense for me, as good algorithms should scale from 0 upward. I don't see why there should be a huge jump from "not running Go yet" to "now you're running a Go runtime" that suddenly requires a large amount of free memory. Here is a post about this:

https://medium.com/samsara-engineering/running-go-on-low-mem...

It seems this is high.

I don't understand why Go doesn't take its core, primary strengths outlined in the "background" section above and expand it into the lowest of the low-end devices.

Why can't I compile a Go program targeting a microcontroller with 2-8 MB of RAM without issue? Go was designed as a compiled systems language, to replace C. Not as a scripting language to replace Python.

   Question 2
   ----------

Since explicit (if very ugly) syntax that keeps people from making mistakes, and whose specifications can be kept in mind all at once, is a strength of the language and syntax, why can't I develop desktop GUI's in Go? It is a fast, compiled language.

You might say the answer to that is that a windowing system needs a class system but I disagree - that can't possibly be any more true than the idea that a web app needs a class system. Clearly people make web apps in Go without a class hierarchy.

Nobody makes desktop apps (I mean the class of applications that web browsers, IDE's, photo editing software, basically everything on a list like this - https://helpdeskgeek.com/free-tools-review/best-freeware-pro... ) in Go.

Of course, when it debuted you could say, "That's just not what the team focused on", since it was backed by Google they needed it on the server. But at some point you'd expect first someone to make a make-do GUI toolkit, then other people to add on and make something better, and by now it should be an obvious language for making a Winzip or Winrar competitor. Or an antivirus. Or an Audacity or VLC-type program. Or an OpenOffice clone.

But nobody does these things. Any of these things.

Why not? The simple language has nothing missing that languages which are used for these applications have.

I don't buy the idea of the ecosystem entirely lacking these.

Why don't people make GUI stuff in Go? I don't understand why it shouldn't be an obvious language choice. I just wouldn't reach for Go when it comes to scripting a GUI application. Why not?

   Summary / tl;dr
   ---------------

1. I would like to know what it would take to make the simple specifications behind Go, which are protected by knights in shining armor, an obvious choice for embedded microcontroller applications in 2018.

2. I would like to know what it would take to make the simple specifications behind Go, which are protected by knights in shining armor, an obvious choice for desktop applications in 2018.