[bsdetector]

> The replacement to segmented stacks is copying stacks ...

Which again is not an answer. Why are segmented stacks necessary? Why are copying stacks necessary?

This reasoning, which is their best apparently, amounts to saying that they had to implement their own compiler, linker, assembler, and runtime because they decided they had to implement their own compiler, linker, assembler, and runtime.

[mseepgood]

> Which again is not an answer. Why are segmented stacks necessary? Why are copying stacks necessary?

Because Go wants to provide very lightweight goroutines for highly concurrent and scalable services.

[crawshaw]

Lightweight goroutines depend on small stacks. General API design in Go depends on lightweight goroutines.

In particular, Go style is to never write asynchronous APIs. Always write synchronous blocking code, and when you need to work concurrently, create a goroutine.

You cannot do this in C with pthread, because OS threads are too heavyweight. So you end up in callback-based APIs that are harder to use and harder to debug (no useful stack traces).

This small feature has a surprisingly wide-ranging effect on the use of the language. It is a very big deal.

Go is very much about reinventing these low-level things.

[bsdetector]

Threads and stacks are orthogonal. You can have coroutines with contiguous stacks, and threads with non-contiguous stacks.

Furthermore it's extremely easy to use non-contiguous stacks in C just by knowing the stack amount used by functions, which the compiler already knows.

This is a totally absurd reason to reimplement an entire toolchain.

[crawshaw]

I'm not sure what about my comment is worth downvoting, but to try one more time:

If you came to me tomorrow and said "I want to build a language just like C but with non-contiguous stacks" I agree, I would use LLVM or GCC. But that's not what happened.

The history is three engineers decided to see if they could do better than C++ for what they did every day. That meant trying lots of things. One of the many was goroutines, but they needed a flexible platform on which to try lots of ideas that didn't make the final cut.

It just so happens, two of them had worked on a toolchain before. Ken's from Plan 9. (Which long predates the existence of LLVM.) And as he knew his compiler well, it was very easy to modify it to try these experiments.

In the end the language stabilized with several unusual features, several of which would be difficult to add to other compiler toolchains they were not familiar with. Is that the point they should switch to using LLVM?

Building on a toolchain you know that lets you experiment makes a lot of sense. Knowing a toolchain means you get to work quickly.

The end result still has useful features that LLVM does not. For example, running ./all.bash does three complete builds and runs all the tests. It takes about 60 seconds on my desktop. Last time I tried LLVM, it took minutes. Go programmers love fast compilers.

[bsdetector]

> If you came to me tomorrow and said "I want to build a language just like C but with non-contiguous stacks" I agree, I would use LLVM or GCC. But that's not what happened.

Except that is exactly what happened. Russ says: "segmented stacks; we had to build that, so it was going to be incompatible from day one."

That's the rationalization though. It wasn't about features that you can all but do in plain ANSI C being 'too hard'. We all know what really happened is that they were comfortable with their Plan 9 toolchain and made a demo using it... which is fine. Then they continued to develop their demo for 5 years instead of throwing it out and doing it right, and now they are stuck having to make excuses for why their compiler and assembler and linker and runtime and tools are sub-par.

[crawshaw]

I don't think the tools are sub-par. My programs are compile and run quickly on a variety of platforms. My toolchain builds quickly too.

And now it is written in Go, the preferred language of the compiler engineers.