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

91–100 of 184 posts

Re: C vs GO

#91

Post by ori_b »

pjmlp wrote: post #32
rwmj wrote: post #26

Earlier quoted context omitted.

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 runt…

It's very different in one significant regard: it's very easy to write your own acceptably performant and deterministic malloc and free, compared to the effort it takes to write a GC that would fit in to those constraints.

Re: C vs GO

#92

Post by drivebyacct2 »

I've been using Go exclusively in my personal projects for the last 8 months now, am in love with the simplicitly and fun of writing it (and goroutines), but this is a horrid way of introducing the language. To anyone who doesn't appreciate the Go syntax style, this is an instant turn off. There is a reason there is an idiomatic style used by... every single Go project I've ever seen.

Further, these examples are so trivial that one doesn't see an advantage over C and so this comment thread is like every other. Those who've written "Hello World" dismiss it as neither C nor Haskell and most others seem to be generally happy with it.

Re: C vs GO

#93

Post by ori_b »

pjmlp wrote: post #32
rwmj wrote: post #26

Earlier quoted context omitted.

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 runt…

It's very different in one significant regard: it's very easy to write your own acceptably performant and deterministic malloc and free, compared to the effort it takes to write a GC that would fit in to those constraints.

Re: C vs GO

#94

Post by drivebyacct2 »

papsosouid wrote: post #90
drivebyacct2 wrote: post #89

Earlier quoted context omitted.

What have you written in Go that you'd wished you'd written in Haskell?

Everything, and the same in reverse. That's the problem. Using haskell, I wish I was using go because the downsides of haskell bother me. But when I am using go, I wish I was using haskell because the downsides of go bother me.

Ah the quest for the perfect mix of everything. I sympathize but I've generally found that there are some things that are better solved in Haskell and others in Go and have found a generally pleasant balance.

Re: C vs GO

#95

Post by nice1 »

papsosouid wrote: post #90
drivebyacct2 wrote: post #89

Earlier quoted context omitted.

What have you written in Go that you'd wished you'd written in Haskell?

Everything, and the same in reverse. That's the problem. Using haskell, I wish I was using go because the downsides of haskell bother me. But when I am using go, I wish I was using haskell because the downsides of go bother me.

You may want to see a doctor.

Re: C vs GO

#96

Post by papsosouid »

drivebyacct2 wrote: post #94
papsosouid wrote: post #90

Earlier quoted context omitted.

Everything, and the same in reverse. That's the problem. Using haskell, I wish I was using go because the downsides of haskell bother me. But when I am using go, I wish I was using haskell because the downsides of go bother me.

Ah the quest for the perfect mix of everything. I sympathize but I've generally found that there are some things that are better solved in Haskell and others in Go and have found a generally pleasant balance.

I see. For me I haven't found anything like that, where task X would be better in go and task Y would be better in haskell. Everything I've done was always better in haskell. It was just an annoying pain in the ass the whole time because of super slow compile times, or running out of RAM compiling, or package conflicts from cabal hating me, or .cabal files requiring spaces instead of tabs, or haskell code I want to modify being some giant mess of arbitrarily aligned with a million spaces craziness that makes cool things like "diff" useless. It just feels like rather than "haskell needs to stop being so crazy", the "go needs to gain modern features" approach is more likely to actually be possible.

Re: C vs GO

#97

Post by Locke1689 »

sirclueless wrote: post #85
Locke1689 wrote: post #84

Earlier quoted context omitted.

Calling Go's panic/recover system a proper exception mechanism is quite a stretch.

I think he is referring more to go's "defer" functionality and out-of-band error return values more than panic/recover.

All of these things are just really poor exception mechanisms, in my opinion. It really looks like no one with an up-to-date PLT background was consulted in the design. I agree 100% with Andreas Rossberg (who now, somewhat ironically, works at Google):

It is ironic that their motivation is to tame and restrict the use of exceptions, and then they replace them by something even richer and much less structured. I fail to see any pros of this proposal. It seems mostly equivalent to exceptions, i.e., you can easily express raise/try/finally as syntactic sugar, and likely the other way round. But it is (1) much more ad-hoc -- you cannot give a simple reduction semantics for this, (2) much less orthogonal -- tying `defer' in with function definitions, (3) dependent on mutation -- for recovering and returning alternative results, and implicitly in the semantics of `defer'. One consequence is the loss of beta-convertibility, which means that you as a programmer cannot take an arbitrary piece of code and turn it into a function anymore, or vice versa, eliminate a function by inlining its body. Such abstractions/refactorings are impossible in general under this proposal, or at least require transforming the relevant code in potentially non-trivial ways.

Re: C vs GO

#98

Post by comex »

luriel wrote: post #62
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…

> (Remember that the real impetus for adding them to Unix was X11 and its big and badly-factored libraries, which most of us aren't blessed with.)

Really? Today we are very much blessed with quite a few large libraries - not just X but Qt on top of that and KDE on top of that. WebKit. ICU. These come out to dozens of megabytes. Static linking would add somewhat less by eliminating unused symbols, but you'd still end up with massive bloat for your GUI processes; maybe with today's disk and memory sizes and SSDs that's not the end of the world, but it would be a rather pointless performance drag. That's not counting the difference between Go and Plan 9: I count 4,000 odd binaries in my PATH; if they each had the 1 MB overhead of hello world in Go, I'd be out 4 GB, more than I pay for the entire set of libraries on my system (with some redundancy). (And I hope you don't mind waiting for your programs to compile; despite the Go compiler's vaunted speed, it actually takes over 4 times as long to build hello world as clang for the same in C, the vast majority of which is spent in the linker.)

Security? Today's security environment requires frequent patches to library code. If you have a system to automatically re-link all the programs that link against libraries with security updates, great (make sure you don't miss any, such as manually compiled or copied binaries); otherwise, your system is impossible to keep secure.

Re: C vs GO

#99

Post by Graphon »

People suggesting that Go is a potential replacement for Python, Lua or Ruby are missing the point. IMO, Go isn't designed to compete with those existing languages for existing opportunities.

The key opportunity in the future is smart devices everywhere. Embedded, connected intellgence, everywhere. Everything is a communication device. Today your phone and your car; tomorrow: Your shoes, your office, the grocery store, your refrigerator. Think of xbox Kinect-type sensors embedded into everything.

Writing solid C code for all those systems will be too hard. We also definitely do not want an serendipitously-designed language (Javascript). Yes, that leaves Python Ruby and so on, which brings us full circle. Go will compete with those languages but not in the domains that are evident today. Not in web browser, and not in a new! improved! web server. It seems to me that Go is a forward-looking design, aimed to meet the challenges of the everything-connected world of tomorrow.

To make tomorrow happen, we need a better C. Go is that.

Re: C vs GO

#100

Post by copx »

2mur wrote: post #65
copx wrote: post #43

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

>Do you have any resources / books for writing modern C like this

No, sorry.

>is it all experiential from the trenches?

It's mostly about applying general principles of software construction like separation of concerns, encapsulation, robust interfaces, etc.

Post reply on HN