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

61–70 of 184 posts

Re: C vs GO

#61

Post by millerfung »

EliRivers wrote: post #28
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.

"any new language today should be all beginner friendly" I disagree. I think any new language should be designed to best meet the kind of problem it's being created to deal with. Making it "beginner friendly" (whatever that means - I bet there are lots of different interpretations) is a nice extra, but should not come at the expense of solving the problems.

Yes I agree that new language should be developed because of the ever rapidly changing digital world to enhance everyones experience in digital products. I am sure it is going to get more complicated, however, being a beginner friendly language should still be taken into account. In fact, only the one who is more beginner friendly will survive in the long run because in the future there might be a mismatch of demand and supply of coders. Living in this moment of our planet is exciting because of the experience we have having digital products around us everyday, and there are/will be lots of teenagers who wants to get involve as well. In my opinion, coders are like "workers" in manufacturing companies in the future.

Re: C vs GO

#62

Post by luriel »

delinka wrote: post #37

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.

The C and C++ code Google runs on their servers is always statically linked, and I would call that Serious Work.

In the end, static linking is almost invariably superior to dynamic linking: simpler toolchain, simpler runtime, better reliability, better performance and better security, see:

http://harmful.cat-v.org/software/dynamic-linking/

That said, I think you can do dynamic linking with gccgo, and when linking to C libs with cgo, you do dynamic linking.

Re: C vs GO

#63

Post by pcwalton »

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…

Go is a fine language, but I do have a nitpick here: you do not "avoid the GC" by using memory pools. The GC must still trace through the pool when it does run. The more correct thing to say is that you can reduce allocations with memory pools, which make the GC run less often and make it do less work.

Furthermore, memory pools compromise safety: if you free a pointer to an object in your memory pool and you accidentally had aliases to that pointer, then you'll get subtle bugs when one of those objects gets reused.

Re: C vs GO

#64

Post by pcwalton »

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).

malloc and free are much cheaper than a mark-and-sweep. It is a much easier task to write a bounded-latency malloc suitable for real-time applications - for example, dlmalloc has a NO_SEGMENT_TRAVERSAL flag that assures bounded execution. By contrast, making GC with bounded latency is hard.

Re: C vs GO

#65

Post by 2mur »

copx wrote: post #43
luriel wrote: post #29

Earlier quoted context omitted.

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…

>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). Because we learned a lot about writing more robust and maintainable software since the 1970s. Also the original Unix source code was one thing more than anything: small.…

Do you have any resources / books for writing modern C like this or is it all experiential from the trenches?

Re: C vs GO

#66

Post by pcwalton »

pjmlp wrote: post #56
nux6 wrote: post #39

Earlier quoted context omitted.

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.

And yet there are sound manipulation tools developed in Java and .NET...

Well, to be fair, Java and .NET have generational, concurrent, incremental garbage collectors.

Re: C vs GO

#68

Post by luriel »

shadowmint wrote: post #42
delinka wrote: post #37

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.

I dont see why this got downvoted. It's the biggest issue I have with go as well. It's a royal pain writing go that talks to C code, compared to say, lua or python, and there just _isnt_ a way to make other languages pickup go libraries and run the symbols from them afaik...

> It's a royal pain writing go that talks to C code, compared to say, lua or python

This is plain wrong, you can pretty much call C code directly, while in Python and the like you really have to write a wrapper.

Of course in Go you will write a wrapper anyway to give the library a more Go-like API, but I don't see how this could be any worse than in any other language.

> there just _isnt_ a way to make other languages pickup go libraries and run the symbols from them afaik...

To get non-Go code to call Go code is trickier (also Go really wants to run your main()), but can be done, and there are even libraries to write Python extensions in Go, see:

http://gopy.qur.me/extensions/

Re: C vs GO

#69

Post by luriel »

pcwalton wrote: post #63
luriel wrote: post #29

Earlier quoted context omitted.

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…

Go is a fine language, but I do have a nitpick here: you do not "avoid the GC" by using memory pools. The GC must still trace through the pool when it does run. The more correct thing to say is that you can reduce allocations with memory pools, which make the GC run less often and make it do less work. Furthermore, memory pools compromise safety: if you free a pointer to an object in your memory pool and you accident…

In Go you can also just disable the GC if you really want to, but obviously then you have to be more careful.

Re: C vs GO

#70

Post by scott_s »

nux6 wrote: post #39
luriel wrote: post #29

Earlier quoted context omitted.

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.

That is not the definition of "hard real-time" that I, and others, use: http://en.wikipedia.org/wiki/Real-time_computing

Hard real-time generally means that you have an actual deadline to finish your computation, and Very Bad Things will happen if you miss that deadline. Both of your examples are soft real time.

Post reply on HN