5 ms·

> if you read the Go manifesto to why the language was created, you can read between the lines that C++ getting in the way where enginners were fighting hard to

> if you read the Go manifesto to why the language was created, you can read between the lines that C++ getting in the way where enginners were fighting hard to deal with language complexity. My understanding was that the push from C++ to Go was largely motivated by long C++ compile/linking times. Go is designed to compile large code-bases much faster than C++. I've experienced this myself, it's pretty frustrating to wait 2-5 minutes for a C++ app to compile / link just so you can debug it for 30 seconds and start all over again.

oscargrouch 7y ago
But this is a by-product of their initial motivation. I mean, how could they know their link times would be that much better? I know that Pike et al. worked on compilers for Inferno, and the Ken´s C compiler used some tricks to know beforehand they could make it compile and link very fast, but they couldnt know if the language they were designing would be as fast (to compile) as C or Limbo. They could say confidently: "we could do better", but they would need more pragmatic motives, even to convince Google to support that effort. And i bet Google was struggling with C++ enginnering, specially within the newcomers on the team. I think, both things are true, but developer ergonomics play a very important factor into the why of a language and where it fits in the scheme of things.
hermitdev 7y ago
> I've experienced this myself, it's pretty frustrating to wait 2-5 minutes for a C++ app to compile / link just so you can debug it for 30 seconds and start all over again. That's quaint. When I first started working in C++ professionally, we were at +16 hours for a clean build and link of just one of our systems (circa 2004). Over the years, reduced the amount of code (without sacrificing functionality), shared common code (object model) between client and server (went from about 2M LOC to about 250k LOC), reduced the number of external dependencies, introduced precompiled headers on both windows and Linux, and a clean build was down to about 30 minutes. An incremental build and link could be less than 30 seconds, depending on the scope of the change. But, yeah, C++ leaves a lot to be desired in terms of edit, build, test, repeat cycles.

oscargrouch 7y ago

But this is a by-product of their initial motivation. I mean, how could they know their link times would be that much better? I know that Pike et al. worked on compilers for Inferno, and the Ken´s C compiler used some tricks to know beforehand they could make it compile and link very fast, but they couldnt know if the language they were designing would be as fast (to compile) as C or Limbo. They could say confidently: "we could do better", but they would need more pragmatic motives, even to convince Google to support that effort. And i bet Google was struggling with C++ enginnering, specially within the newcomers on the team. I think, both things are true, but developer ergonomics play a very important factor into the why of a language and where it fits in the scheme of things.

hermitdev 7y ago

> I've experienced this myself, it's pretty frustrating to wait 2-5 minutes for a C++ app to compile / link just so you can debug it for 30 seconds and start all over again. That's quaint. When I first started working in C++ professionally, we were at +16 hours for a clean build and link of just one of our systems (circa 2004). Over the years, reduced the amount of code (without sacrificing functionality), shared common code (object model) between client and server (went from about 2M LOC to about 250k LOC), reduced the number of external dependencies, introduced precompiled headers on both windows and Linux, and a clean build was down to about 30 minutes. An incremental build and link could be less than 30 seconds, depending on the scope of the change. But, yeah, C++ leaves a lot to be desired in terms of edit, build, test, repeat cycles.