[COFF] [TUHS] History of popularity of C

[Andy Kosela]

On 6/8/20, Dan Cross <crossd at gmail.com> wrote:
> [ -TUHS and +COFF ]
>
> On Mon, Jun 8, 2020 at 1:49 AM Lars Brinkhoff <lars at nocrew.org> wrote:
>
>> Chris Torek wrote:
>> > You pay (sometimes noticeably) for the GC, but the price is not
>> > too bad in less time-critical situations.  The GC has a few short
>> > stop-the-world points but since Go 1.6 or so, it's pretty smooth,
>> > unlike what I remember from 1980s Lisp systems. :-)
>>
>> I'm guessing those 1980s Lisp systems would also be pretty smooth on
>> 2020s hardware.
>>
>
> I worked on a big system written in Common Lisp at one point, and it used a
> pretty standard Lispy garbage collector. It spent something like 15% of its
> time in GC. It was sufficiently bad that we forced a full GC between every
> query.
>
> The Go garbage collector, on the other hand, is really neat. I believe it
> reserves something like 25% of available CPU time for itself, but it runs
> concurrently with your program: having to stop the world for GC is very,
> very rare in Go programs and even when you have to do it, the concurrent
> code (which, by the way, can make use of full physical parallelism on
> multicore systems) has already done much of the heavy lifting, meaning you
> spend less time in a GC pause. It's a very impressive piece of engineering.
>

The real question is can Go be really faster than C/C++?  The last
time I checked it was at least two times slower on an average.  Plus
it will not run on older systems; I think you need at least kernel
2.6.23 and its executables are rather big compared to C.  In the
beginning it was fun to create some clones of classic Unix tools in
Go, but in reality they were still slower and bigger than the original
utilities.

I jumped on the Go bandwagon in 2010 (like a lot of people from the
open source community) but recently I find myself coming back more and
more to C.  It is still a superior language in almost all areas.  Plus
it works on everything from retro 8-bit micros to modern big HPC
systems.

--Andy