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

141–150 of 184 posts

Re: C vs GO

#141

Post by kd0amg »

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…

"Go is not meant to innovate programming theory. It's meant to innovate programming practice."

I don't think GP was saying that Go should have provided some advance to programming language research, but that it doesn't show much awareness of advances that have already been made.

Re: C vs GO

#142

Post by comex »

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…

> And with magnitude orders more RAM.

Doesn't mean I want to waste it. Some systems don't really have much RAM to spare, such as the iPhone.

> And just because there are large libraries doesn't mean they are either necessary or desirable.

This is an old argument, but short of rewriting the world there isn't presently much alternative.

> Interestingly most apps that depend on Qt, WebKit or ICU include their own copies of this libraries.

Not sure which system you're talking about. As far as I know, Linux distros tend to link everything against system libraries. Here on OS X, Qt is usually bundled, but WebKit and ICU are part of the system and dynamically linked against. Independently distributed Linux programs are an exception and arguably a bad idea.

> I'm a fan of many small tools working well together but I can't help but feel that when you have systems with 4,000 binaries in your PATH, something has gone terribly wrong.

Most of it I don't use and thanks to MacPorts, I have a lot of duplicate copies of tools. (Maybe not the best system, but disks do have enough room to waste some.)

> There is no reason why Go binaries couldn't be much smaller, other than so far it has not been a problem for anyone building systems in Go.

Fair enough. It is a problem for me mainly because I value very fast compilation of small tools.

> Which is not helped by dynamic linking for reasons both of complexity (see http://harmful.cat-v.org/software/dynamic-linking/versioned-.... )

This does sound awful but I have not really seen it anywhere outside of libcs. OS X libc has only a few switches (UNIX2003, INODE64) and uses them to provide wide backwards compatibility.

> and because most programs anyway use their own version of such 'shared' libs (update your system's ffmpeg and chrome will keep using its own copy).

And indeed this can cause serious problems (I remember a vulnerability report or two about some program shipping an out-of-date library), but luckily you're exaggerating its prevalence. Chrome will keep doing its own thing, but when WebKit gets another of its innumerable security updates, I don't have to redownload the 32 applications I have that link against it.

(ffmpeg might be an exception because it doesn't care about stable releases, but I also remember a blog post complaining about Chrome's (former?) gratuitous forking and bundling of libraries. It's a bad idea.)

> Dll-hell has security implications too.

Only on poorly organized systems. On a Linux distro, the package manager takes care of dependencies and generally gets it right. OS X is uniform (and willing to break backwards compatibility) enough that when there are problems, the developers update their apps.

> In practice people end up doing things that either nullify the alleged benefits of dynamic linking,

in a small minority of cases, yes; in the vast majority of cases where, on a well-organized system, I just want this security or framework update to make it to everything, no.

> or simply using static linking (Google deploys statically linked binaries, sometimes multiple Gb in size to their servers).

Facebook also does the gigabyte binary thing. It's a ridiculous waste of space, but if they don't care, they don't care; servers don't have as many constraints as user-facing computers (they have a fixed workload and expected disk usage), and are often less vulnerable to library security issues, not having to expose the full web stack + PDF rendering + Flash + GL to to any random web site the user navigates to. :)

Re: C vs GO

#143

Post by wickedchicken »

Locke1689 wrote: post #139
wickedchicken wrote: post #117

Earlier quoted context omitted.

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

> If this is what you're referring to, this is just a return value. There isn't really an exception system here.

Yes, which is awesome.

> 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 would be an 'in-band' error, as opposed to 'out-of-band.' It's terminology borrowed from communications theory. You also see it used to describe an 'out-of-band' console that is a secondary way to SSH into your machine if your network is hosed.

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

I think the point is that this is intentional. I love super high-level languages, but they're experimental for a reason -- things haven't 'settled down yet' and until they do, it will be difficult for the average person to reason about what is going on. Take garbage collection: this was technology that had been around for decades, but computers and garbage collection algorithms had to be sped up and tuned before general adoption. Large systems demand predictability and integrity on nearly every dimension. Luckily as time goes on, the experimental stuff becomes the expected; advanced programming language theory gets built into larger systems and we all benefit. Go is part of that evolution.

Re: C vs GO

#144

Post by redbad »

kd0amg wrote: post #141
wickedchicken wrote: post #117

Earlier quoted context omitted.

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

"Go is not meant to innovate programming theory. It's meant to innovate programming practice." I don't think GP was saying that Go should have provided some advance to programming language research, but that it doesn't show much awareness of advances that have already been made.

    [Go] doesn't show much awareness of advances that have
    already been made.
Go's response would be to question that the things you're talking about are, in fact, unqualified advances. Especially in the context of large (ie. LOC) systems applications, maintained by large (ie. dozens to hundreds) of developers.

Re: C vs GO

#145

Post by genwin »

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?

That depends on the city. Guage demand by checking out monster.com, indeed.com and other job sites (craigslist?) for the city or cities you're interested in. Job postings tell you the skill sets too (no two of them alike!).

Re: C vs GO

#146

Post by vilya »

luriel wrote: post #69
pcwalton wrote: post #63

Earlier quoted context omitted.

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.

How well does that work if you're using some thirdparty libraries? Just curious - I haven't used Go yet so don't know what happens there.

Re: C vs GO

#147

Post by Locke1689 »

wickedchicken wrote: post #143
Locke1689 wrote: post #139

Earlier quoted context omitted.

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…

> If this is what you're referring to, this is just a return value. There isn't really an exception system here. Yes, which is awesome. > 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 would be an 'in-band' error, as opposed to 'out-of-band.' It's terminology borrowed from c…

I think the point is that this is intentional. I love super high-level languages, but they're experimental for a reason -- things haven't 'settled down yet' and until they do, it will be difficult for the average person to reason about what is going on.

No, sorry, I should have been even more explicit: it looks like the designers were not even aware of new advances in PLT. As far as I can see, defer/panic/recover is objectively worse than an exception system for all of the goals which they lay out in their paper.

You like return values--ok, I can see that. I prefer that the type checker actually enforce error checking when using error return values, but fine.

Adding defer/panic/recover is an attempt to add a simpler and more constrained exception-like system to the language, but I think it is objectively (both from a PLT perspective and compiler-design perspective) worse than a more traditional exception system. Breaking beta-reduction is very unfortunate and I can't see a good reason to do it in this case.

Re: C vs GO

#148

Post by Locke1689 »

redbad wrote: post #144
kd0amg wrote: post #141

Earlier quoted context omitted.

"Go is not meant to innovate programming theory. It's meant to innovate programming practice." I don't think GP was saying that Go should have provided some advance to programming language research, but that it doesn't show much awareness of advances that have already been made.

[Go] doesn't show much awareness of advances that have already been made. Go's response would be to question that the things you're talking about are, in fact, unqualified advances. Especially in the context of large (ie. LOC) systems applications, maintained by large (ie. dozens to hundreds) of developers.

Java, C#, Python, Lisp, and Erlang would all criticize Go for an unqualified new exception system which has not proven that it can handle itself in the context of large systems applications, unlike all the previous languages.

Re: C vs GO

#149

Post by wickedchicken »

Locke1689 wrote: post #147
wickedchicken wrote: post #143

Earlier quoted context omitted.

> If this is what you're referring to, this is just a return value. There isn't really an exception system here. Yes, which is awesome. > 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 would be an 'in-band' error, as opposed to 'out-of-band.' It's terminology borrowed from c…

I think the point is that this is intentional. I love super high-level languages, but they're experimental for a reason -- things haven't 'settled down yet' and until they do, it will be difficult for the average person to reason about what is going on. No, sorry, I should have been even more explicit: it looks like the designers were not even aware of new advances in PLT . As far as I can see, defer/panic/recover is…

> No, sorry, I should have been even more explicit: it looks like the designers were not even aware of new advances in PLT.

Ken Thompson won a Turing award, dude.

Re: C vs GO

#150

Post by eeperson »

papsosouid wrote: post #88

Go is the best worst language I've used. Most of what I do fits pretty much right in the sweet spot for go, network services and web development. Stuff I would have previously used C and (insert scripting language here) for respectively. Go fits into both of those areas really nicely, and I prefer it over C and scripting language X for these tasks. But the problem is, I've already tried haskell, which also fits that…

Might I suggest Scala[1]? It is a modern languages with mature build tools and development environment. It also has a lot of nice tools surrounding network services and web development[2].

[1] http://www.scala-lang.org/ [2] http://typesafe.com/stack

Post reply on HN