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

151–160 of 184 posts

Re: C vs GO

#151

Post by xyproto »

papsosouid wrote: post #96
drivebyacct2 wrote: post #94

Earlier quoted context omitted.

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

You can create a tool that lets you inline Haskell code in your Go sources. The resulting code could be compiled and called via C, some sort of IPC or even as a network service.

Re: C vs GO

#152

Post by xyproto »

Noughmad wrote: post #140
luriel wrote: post #122

Earlier quoted context omitted.

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

Using something, then reaching a conclusion that is on the "next level" often have surprising similarities to conclusions made by people that haven't started using it at all.

See also: http://www.zenguide.com/zenmedia/index.cfm?id=303

Re: C vs GO

#153

Post by xyproto »

luriel wrote: post #68
shadowmint wrote: post #42

Earlier quoted context omitted.

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

Also, there's assembly. http://stackoverflow.com/a/6535590/131264

Re: C vs GO

#154

Post by xyproto »

0xABADC0DA wrote: post #123
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.

Somebody should write a Google Go to C transpiler. Mostly Google Go features are limitations or different styles in order to 'improve' C, so it should produce fairly readable C code. Then you could use any compiler, linking type, combine with any language, etc. You could probably even use LD_PRELOAD to replace coroutines with pthreads. For instance Russ Cox did coroutines and channels in his C libtask in a few thousa…

You write "worse than gcc", but Go has been included in GCC since version 4.6: http://gcc.gnu.org/gcc-4.6/changes.html

Re: C vs GO

#155

Post by delinka »

tedunangst wrote: post #131
shadowmint wrote: post #42

Earlier quoted context omitted.

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.

Let me help you out so you don't feel belittled or insulted. Serious Work is anything that will ever leave the confines of my experimental system to be used, viewed, or edited by anyone else. Doesn't matter if it's a trivial script-like tool or if it's a complex app.

Re: C vs GO

#156

Post by ralph »

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…

I'd just point out that I'm not complaining about something trivial, e.g. open braces on their own line, or a matter of taste, but something fundamentally weird, unexpected, and almost designed to mislead.

Re: C vs GO

#157

Post by ralph »

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…

I'd just point out that I'm not complaining about something trivial, e.g. open braces on their own line, or a matter of taste, but something fundamentally weird, unexpected, and almost designed to mislead.

Re: C vs GO

#158

Post by xyproto »

rwj wrote: post #53
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.

Go is not a replacement for C. As many people have said, Go is not suitable for most purposes where C would currently be the best choice. Go is a replacement for Python, Ruby, etc. Garbage collection, duck typing, an excellent library. Go is a language with the same level of abstraction of many other "scripting" languages, but is unique because it uses static typing and is compiled.

I would say Go is a replacement for C++, Java and C# instead. Python and Ruby are great at quick prototyping, but Go fixes several of the major problems with those three. C++ takes forever to compile, code quickly becomes stale and the modularity isn't great. Java and C# lacks brevity, native compilation and the error handling is overly verbose and is in the way more than it helps.

Re: C vs GO

#159

Post by xyproto »

heretohelp wrote: post #104
Graphon wrote: post #99

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

Go is highly inappropriate in embedded environments so your pipedream betrays a naivete to systems programming.

  * You can turn off the GC.
  * You can compile with gccgo.
  * You can call assembly code from Go.
What is the major hindrance from using Go in embedded environments?

Re: C vs GO

#160

Post by plorkyeran »

wickedchicken wrote: post #149
Locke1689 wrote: post #147

Earlier quoted context omitted.

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.

In 1983, 24 years before starting work on Go. That's a lot of time to fall behind on new research.
Post reply on HN