Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C vs GO

crypto.stanford.edu

Post reply on HN
Print view View original

31–40 of 184 posts

Re: C vs GO

#31

Post by luriel »

rwmj wrote: post #26
mkup wrote: post #17

Earlier quoted context omitted.

It's not the only advantage. Another, more important advantage of C and C++ over Go is a lack of stop-the-world garbage collection (and predictable memory usage under high load).

You can predict the time that malloc(3) and free(3) take to run? You know they are backed by very complex data structures that need to manipulated and iterated over? The point you mention is only valid when using entirely static memory, which is a very rare case in real C code (only really used in a few small embedded codebases).

> The point you mention is only valid when using entirely static memory

Exactly, and you can also do that in Go to avoid the GC.

Re: C vs GO

#32

Post by pjmlp »

rwmj wrote: post #26
mkup wrote: post #17

Earlier quoted context omitted.

It's not the only advantage. Another, more important advantage of C and C++ over Go is a lack of stop-the-world garbage collection (and predictable memory usage under high load).

You can predict the time that malloc(3) and free(3) take to run? You know they are backed by very complex data structures that need to manipulated and iterated over? The point you mention is only valid when using entirely static memory, which is a very rare case in real C code (only really used in a few small embedded codebases).

> You can predict the time that malloc(3) and free(3) take to run?

Thanks for pointing this out.

This is often a misunderstanding from manual memory management fans. In many cases malloc()/free() also behave non-deterministic.

This is the main reason why for special types of applications, you need to have malloc()/free() implementations specially targeted to the use case at hand.

This is no different from the GC runtimes, which are coded specifically for real time applications, like avionics, for example.

Re: C vs GO

#33

Post by luriel »

nux6 wrote: post #11
gouranga wrote: post #4

Interesting comparisons. However (not slating Go, which I think is excellent), I genuinely think Go is going to go the same way as plan9 eventually. Unfortunately, its predecessor (C) is good enough, much as UNIX was good enough compared to plan9.

The devil is in details. Go is great for hi-level or simple stuff like that, but is not really usable for system programming. If things are a bit more complicated, the go runtime stays in the way. For those problems, after a while, the bare metal support was removed from the language completely...

> For those problems, after a while, the bare metal support was removed from the language completely...

Not really true, you have direct control over the memory layout of your data structures, and if you want to do really tricky stuff there is also the unsafe package.

Re: C vs GO

#34

Post by vonmoltke »

Devilboy wrote: post #7
revelation wrote: post #5

I can't do system programming using Go on a platform for which there is no compiler. There is probably a reasonable C compiler for every platform in existence out there.

Right now there's Go compilers for Windows, Mac and Linux. I'm sure others will follow soon.

There is more to platforms than operating systems. I worked on an application that had to function on 8 different hardware architectures[0], though on all but one we ran Linux. We also had code that was bare metal (no OS) running on FPGAs and DSPs. Go is a long way from supporting that.

This is not to say Go will not get there eventually, if the language gains popularity. Someone had to write or modify a compiler to target all those architectures for C, after all. This is just a reaction to what I see as assumptions tying operating systems to certain hardware architectures (in this and other discussions). Go can be used on a range of operating systems on two hardware architectures. Very good progress, but the language needs to get that second number up before we can seriously talk about it replacing C.

[0] Only had to perform well on two, fortunately.

Re: C vs GO

#35

Post by mkup »

rwmj wrote: post #26
mkup wrote: post #17

Earlier quoted context omitted.

It's not the only advantage. Another, more important advantage of C and C++ over Go is a lack of stop-the-world garbage collection (and predictable memory usage under high load).

You can predict the time that malloc(3) and free(3) take to run? You know they are backed by very complex data structures that need to manipulated and iterated over? The point you mention is only valid when using entirely static memory, which is a very rare case in real C code (only really used in a few small embedded codebases).

Not that complex really, if we are talking about buddy allocator or jemalloc. They both have predictable and limited running time.

Default platform malloc(3) and free(3) can be a crap indeed, but they are drop-in replaceable with the above at any time, unlike Go GC - if practical testing suggests such replacement is necessary (e.g. Firefox, Facebook servers)

Re: C vs GO

#36

Post by copx »

rwmj wrote: post #26
mkup wrote: post #17

Earlier quoted context omitted.

It's not the only advantage. Another, more important advantage of C and C++ over Go is a lack of stop-the-world garbage collection (and predictable memory usage under high load).

You can predict the time that malloc(3) and free(3) take to run? You know they are backed by very complex data structures that need to manipulated and iterated over? The point you mention is only valid when using entirely static memory, which is a very rare case in real C code (only really used in a few small embedded codebases).

>You can predict the time that malloc(3) and free(3) take to run?

The correct answer would be: depends on the concrete implementation. There are implementations with real-time guarantees.

However, assuming standard desktop OS malloc()/free() the answer is: No. These functions can execute very quickly.. or very slowly, depending on their current internal state. But you can control when they get called, which can be an important difference.

>The point you mention is only valid when using entirely static memory, which is a very rare case in real C code (only really used in a few small embedded codebases).

Depends on what you mean by "entirely static memory". No malloc() calls at all? Yes, that is rare and pretty much limited to the embedded realm I think. Memory pools however are very common in performance critical code.

Re: C vs GO

#37

Post by delinka »

My complaint about Go centers around its mechanics of code reuse: static linking for all Go code; making anything Really Useful requires using other libraries, which includes those written in C, which require use of a tool to help you write your wrapper ...

If we could get dynamic linking and something less cumbersome for interfacing with existing libs, I could use Go for Serious Work.

Re: C vs GO

#38

Post by vonmoltke »

rwmj wrote: post #26
mkup wrote: post #17

Earlier quoted context omitted.

It's not the only advantage. Another, more important advantage of C and C++ over Go is a lack of stop-the-world garbage collection (and predictable memory usage under high load).

You can predict the time that malloc(3) and free(3) take to run? You know they are backed by very complex data structures that need to manipulated and iterated over? The point you mention is only valid when using entirely static memory, which is a very rare case in real C code (only really used in a few small embedded codebases).

Not sure exactly what you mean by "entirely static", but in the signal processing application I worked on we used an allocate once/deallocate once design where we allocated gigabytes of RAM per node up-front and reused the buffers and data structures during operation. We took over the entire node, essentially, and we were a closed system, so this design didn't cause most of the problems this normally would.

Re: C vs GO

#39

Post by nux6 »

luriel wrote: post #29
copx wrote: post #27

I like Go but it's not a replacement or even just competition for C. Garbage collection alone ensures that. C is for low-level code, where you usually want deterministic, real-time behavior. Go cannot deliver that because of its GC. You can certainly write web server software in Go (what Go was designed for), but could you write an "AAA" video game in it? Or a mission critical embedded system with real-time requireme…

Your C code looks very unidiomatic to me, but I guess that is relatively a matter of taste (still I don't understand why would somebody use C if they don't like to write code in the 'classic' C style as seen in the original Unix and Plan 9 source). That aside, in Go you can also do fixed allocations and manage your own memory pools to avoid the GC. And I would also question how many C programs require real-time behav…

E.g. any app with [record] button need to meet 'mostly' predicted system latency, that's 'soft-real-time'. Any professional app with [play] and [record] button needs a minimal warranted latency, that's 'hard-real-time'. Go is unsuitable for both.

Re: C vs GO

#40

Post by kibwen »

luriel wrote: post #24
millerfung wrote: post #15

In my opinion, any new language today should be all beginner friendly, there are large pool of people who are interested and it means a great future of our world.

Go is relatively beginner friendly, is simpler and smaller than most languages around (even for example Python). Go code is concise but without dark magic (is easy to see what code does by just looking at it). And you can even read the whole language spec fairly easily.

  > smaller than most languages around
I'm not certain that this is specific to Go, insamuch as it's a property of nearly all young languages. After 1.0, language complexity can only ever increase. Even Python has followed this trajectory, although Python should perhaps be commended for being willing to shed some of its complexity along the way (depending on how you view backwards-incompatible changes, some would say it should be denounced rather than commended).
Post reply on HN