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

131–140 of 184 posts

Re: C vs GO

#131

Post by tedunangst »

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

There's no single definition for Serious Work. It's just an insult to belittle people whose work is different than your own.

Re: C vs GO

#132

Post by plorkyeran »

JackdawX wrote: post #118
ralph wrote: post #107

I gave up reading this very early on. The striving for compactness of the source, in both C and Go, makes it misleading to read. Take if (argc 1) putchar(' '); printf("%s", argv[i]); } putchar('\n'); } A casual skim sees the if followed by an indented block, but that isn't the then-path but the else-path. Now yes, I can read it carefully and follow it, just as if I was debugging someone else's poorly formatted code,…

Your post adds nothing useful to the discussion. There is no point arguing about indenting style in a 7 line program, it's needless pedantry! This is almost exactly the same thing as grammar nazi-ism, and seems to have a similarly negative impact coding related websites. I think we need to coin a new term - indent-nazi, style-nazi, or something similar - for the purpose of dismissing this kind of post and keeping peo…

That code is along the lines of #define true false for reader-hostility. When the formatting makes the code look like it does the exact opposite of what it does, then complaining about it is not in any way "needless pedantry".

Re: C vs GO

#133

Post by tedunangst »

eswangren wrote: post #101
jbooth wrote: post #48

Earlier quoted context omitted.

I think Go's strengths over C really start to shine when you're writing programs longer than 100 lines. Not having an exception mechanism, interfaces, single namespace, no attaching methods to structs etc are fine in a small program, but they make bigger programs harder to digest pretty quickly.

Well, the operating system you used to write that comment was probably written in C, so apparently it does in fact work in large projects. It has weaknesses to be sure, but I don't think lack of OO (I.e., structs with functions) is one of them.

It's worth noting that the bulk of the code in the kernel comes from 900 different network drivers, each of which could be considered a small program in its own right.

Re: C vs GO

#134

Post by jlgreco »

cantankerous wrote: post #124
angelbob wrote: post #75

Earlier quoted context omitted.

He's picking a bunch of problems C is really good at and then roughly, fairly mechanically translating to Go. I don't think he's trolling, but I do think he's playing to C's strengths and Go's weaknesses, possibly by accident.

I agree. I don't see anything wrong what he did, but somebody should offer to submit counterpoints that better emphasize what Go is able to do.

I think many counterpoints should be fairly obvious. Anything from "return a return value and an error code from a function" (trivial in both, way nicer in Go though) to "write a webserver from scratch. Which did you just schedule more time for?"

Re: C vs GO

#135

Post by drivebyacct2 »

swdunlop wrote: post #128
JackdawX wrote: post #118

Earlier quoted context omitted.

Your post adds nothing useful to the discussion. There is no point arguing about indenting style in a 7 line program, it's needless pedantry! This is almost exactly the same thing as grammar nazi-ism, and seems to have a similarly negative impact coding related websites. I think we need to coin a new term - indent-nazi, style-nazi, or something similar - for the purpose of dismissing this kind of post and keeping peo…

Actually, "indent-nazism" is a big thing in the Go community. The Gofmt utility, which takes an AST of your code and normalizes it to a common style. Nobody agrees that the style is perfect, a lot of people have religious preferences when it comes to brace placement. But Gofmt ensures that all these people can find a consistent format when it comes time to diff. GoSublime and go.vim both integrate gofmt into the edit…

It's not just diffs, you learn to scan code. The same way that you can't use i++ inline, having consistent indentation and treatment of syntax allows for quicker at-a-glance human parsing.

Re: C vs GO

#136

Post by StephenFalken »

dllthomas wrote: post #116
eswangren wrote: post #101

Earlier quoted context omitted.

Well, the operating system you used to write that comment was probably written in C, so apparently it does in fact work in large projects. It has weaknesses to be sure, but I don't think lack of OO (I.e., structs with functions) is one of them.

Particularly given that you can write OO code in C, and can decorate structs with functions, it's just messier.

"Object oriented programming with ANSI-C":

https://ritdml.rit.edu/handle/1850/8544

Re: C vs GO

#137

Post by jaybill »

millerfung wrote: post #114
jaybill wrote: post #112

Earlier quoted context omitted.

I think that really depends on your goals. If your goal is to bash out a web application and get a startup off the ground, you ought to learn something that is tailored to doing that. Ruby on Rails and Django(Python) aren't bad choices. I'd avoid PHP, but that is my opinion and you'll find lots of people who disagree. Research your options and learn something that makes sense to you and will enable you to bring other…

Thanks. Currently, in your opinion, what kind of programmers are high in demand and what skill set does it require?

Two part answer. First, I don't know the answer to that off the top of my head. Second, though, is that I don't think it matters. You need to find something you like to do and then get someone to pay you to do it. If you don't do that, the money won't matter, because you'll be miserable.

Re: C vs GO

#138

Post by Locke1689 »

luriel wrote: post #108
Locke1689 wrote: post #97

Earlier quoted context omitted.

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…

I disagree that panic/recover is worse than exceptions, I find it a more pleasant and lightweight mechanism, but the big difference is that panic/recover are not used like exceptions at all in Go, they are basically used only for programmer errors. They can be used for other things, but in those cases they never cross API-calls so you never have to worry about whatever a library you call might panic, you can basicall…

Well, we can argue about whether or not an exception mechanism is the best way to deal with program error conditions, but my first point still stands, which is that Go does not have a proper exception mechanism. If defer/panic/recover were to be used as a true exception system you would run into all the issues Andreas details.

Re: C vs GO

#139

Post by Locke1689 »

wickedchicken wrote: post #117
Locke1689 wrote: post #97

Earlier quoted context omitted.

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…

> It really looks like no one with an up-to-date PLT background was consulted in the design. "Go is not meant to innovate programming theory. It's meant to innovate programming practice." I really like the out-of-band errors since they make control flow very explicit. With languages that rely on exceptions a lot (python, for example) I feel less in control of my program since 'anything can happen' remotely from my co…

Sorry, by "out-of-band errors" do you mean the error return value? This is not a terminology I'm familiar with.

For any function which produces values of the form (a -> (b,e)) I'd refer to that as a product type. If this is what you're referring to, this is just a return value. There isn't really an exception system here.

If you think about how return values work in C you'll note that it's usually some subset of the range which is defined for an actual value and some subset defined for an error condition. This is basically the same as (b,e), just worse type safety. Easy and efficient tuple constructions are hard to create in languages with manual memory management.

Edit: Also, I didn't mean that Go should have innovated in PLT, only took advantage of innovations already established.

Re: C vs GO

#140

Post by Noughmad »

luriel wrote: post #122
comex wrote: post #98

Earlier quoted context omitted.

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

> Today we are very much blessed with quite a few large libraries And with magnitude orders more RAM. And just because there are large libraries doesn't mean they are either necessary or desirable. > not just X but Qt on top of that and KDE on top of that. WebKit. ICU. These come out to dozens of megabytes. Interestingly most apps that depend on Qt, WebKit or ICU include their own copies of this libraries. > Static l…

Ok, you have no idea what you're talking about.

> Interestingly most apps that depend on Qt, WebKit or ICU include their own copies of this libraries. So you're not a Linux user, ok. In that case there really are not that much shared libraries. Using a free desktop means that a large majority of all programs you use requires the same set of shared libraries. And as least in KDE and Gnome, there is a large number of small programs running in the background.

> I can't help but feel that when you have systems with 4,000 binaries in your PATH, something has gone terribly wrong. A quick "ls /usr/bin | wc -l" gives me 3135. Considering this is not the whole PATH, I think 4000 is a normal number.

In Linux distributions, programs don't have to ship their own versions of anything. Maybe you should try it.

Post reply on HN