[loup-vaillant]

> In practice, if you were going use Go on a microcontroller you would not use the same compiler as you would use if you writing a web server.

Is that a fact? Are you telling me that today, there's a Go compiler that's best suited for web servers, and a different Go compiler best suited for micro-controllers? Could you name the micro-controller one?

> As we already discussed, one such tradeoff is in GC implementations.

The internals of the GC are less important than how they affect the language itself. When memory is very limited, I need predictable memory usage, so memory usage must be part of the language's semantics. If they're not, I can't use that language in a constrained environment, full stop.

At the very least, I need to know which subset of Go's language and standard library have predictable memory usage. If there is no such clear subset, then Go cannot reliably be used in a constrained environment.

[win311fwg]

> Are you telling me that today, there's a Go compiler that's best suited for web servers, and a different Go compiler best suited for micro-controllers?

No, I would have no reason to tell you that because, given what we're talking about, you would already know that. You couldn't possibly partipcate in good faith if weren't familiar with the Go ecosystem. This is such a strange comment.

[loup-vaillant]

First, I’m not familiar with the Go ecosystem. I have never written a single line of Go, and I learned in this thread that there was more than one compiler. Second, please don’t accuse me of engaging in bad faith. I’m not.

My question was genuine. What triggered it is when you wrote "in practice". I myself draw a sharp distinction between a language and its implementation, but the moment "in practice" gets thrown in, I have to assume we’re talking about existing implementations only. And I have to say, as unfamiliar as I am with the Go ecosystem, the existence of a compiler (somewhat?) tailored to embedded use, is deeply surprising to me.