C vs GO

http://crypto.stanford.edu/~blynn/c2go/index.html

by akg • 14 years ago

202 175 14 years ago

crypto.stanford.edu

simias• 14 years ago

Damn. I can't comment on the Go listings, but could he make his C code any less readable?

What's the point of making the code so dense anyway? Without syntax highlighting I gave up pretty quickly.

adobriyan• 14 years ago

The point is to show that Go is superior to C (which obviously is true but not for the reasons mentioned in the article).

Anything counts.

Go code is obviously formatted with gofmt. C code is obviously not formatted with "indent -kr".

Liberal use of comma operator unseen in real world.

Look at example of yes(1) with error-handling.

Author doesn't use strdup(3).

But even if he did, it still doesn't make sense to call fprintf(3) once due to allegedly hard error handling. Error handling is not common path, fprintf(3) doesn't fail!

He concatenates all string into once which makes it O(n^2) because of many many times strlen(3) is called (and kernel copied argv contents before that!).

I bet he did error checking wrong on C side (just checking return value should not be enough). It'd be interesting to see same code on Go side.

Obligatory quote: "considering that bad code can be written in any language, any language comparison performed using examples must be judged by the quality of the examples in each language. it can't be all that hard to write a bad example in language A and a good example in language B, and then proclaim language B to be the winner -- this is how people compare languages all the time, so either those who read them are bad programmers in any language (or are not programmers at all) and don't know how to reject the bad examples, or they already agree with the author of the comparison that language B is better than language A. in either case, it's a waste of anything but marketing money.

...

#\Erik"

akavel• 14 years ago

> Go code is obviously formatted with gofmt.

Is not, he also inlined some things, e.g. this:

  import ("flag";"fmt")

would be expanded to multiline by gofmt, as well as this:

  if i>0 { fmt.Print(" ") }

As to other things, I can't comment now, as I don't have time to read through all of the article at the moment.

cloudhead• 14 years ago

Go is superior to C? Damn, I must have missed the memo!

shadowmint3• 14 years ago

This has been discussed before, so many times.

In fact, in pretty much every thread go turns up in. sigh I'm just going to link to my favourite review now, again (pertinent, and mentioned here only because the author of the original shared a favourite with me): http://www.math.bas.bg/bantchev/misc/on-go.html

Quote: "But I know I am not going to love Go. True beauty evades this language. Go may be practical, but is also eclectic, and has taken some unconvincing or downright ugly design choices. It definitely lacks that subtle but unmistakable touch of elegance that makes a language great."

anon_d• 14 years ago

The C code looks very nice to me. What's the problem?

gouranga5• 14 years ago

Interesting comparisons.

However (not slating Go, which I think is excellent), I genuinely think Go is going to go the same way as plan9 eventually. Unfortunately, its predecessor (C) is good enough, much as UNIX was good enough compared to plan9.

Devilboy2• 14 years ago

The big win for go over c is the goroutines - cheap and easy multithreading built right into the language.

gouranga5• 14 years ago

I agree entirely - they are great, but in all the Go I've written (which totals about 50kloc so far as a porting project), I haven't actually used them past anything I would have done with zmq in C.

jamwt• 14 years ago

zeromq or coroutine libraries like libtask (by a go author!) have greatly reduced this advantage.

nux63• 14 years ago

The devil is in details. Go is great for hi-level or simple stuff like that, but is not really usable for system programming. If things are a bit more complicated, the go runtime stays in the way. For those problems, after a while, the bare metal support was removed from the language completely...

pjmlp5• 14 years ago

Ever heard of Oberon, Modula-2 and Modula-3?

These languages also had OS fully implemented on them, just with tiny bits of Assembly to do the very low level stuff, similar to what C would require anyway.

The only advantage of C is that its runtime is so small, that in practice the OS is the C's runtime.

luriel17• 14 years ago

> For those problems, after a while, the bare metal support was removed from the language completely...

Not really true, you have direct control over the memory layout of your data structures, and if you want to do really tricky stuff there is also the unsafe package.

thdn• 14 years ago

Even the pet looks similar hehehe :P

jff2• 14 years ago

Could be because they were both created by the same person.

revelation• 14 years ago

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.

Devilboy2• 14 years ago

Right now there's Go compilers for Windows, Mac and Linux. I'm sure others will follow soon.

dchest• 14 years ago

+ FreeBSD.

Also, OpenBSD, NetBSD, and Plan 9 in the works.

vonmoltke2• 14 years ago

There is more to platforms than operating systems. I worked on an application that had to function on 8 different hardware architectures[0], though on all but one we ran Linux. We also had code that was bare metal (no OS) running on FPGAs and DSPs. Go is a long way from supporting that.

This is not to say Go will not get there eventually, if the language gains popularity. Someone had to write or modify a compiler to target all those architectures for C, after all. This is just a reaction to what I see as assumptions tying operating systems to certain hardware architectures (in this and other discussions). Go can be used on a range of operating systems on two hardware architectures. Very good progress, but the language needs to get that second number up before we can seriously talk about it replacing C.

[0] Only had to perform well on two, fortunately.

nakkiel• 14 years ago

Well, back in the days it was pretty much the same thing for C. When someone needed to target a platform it used to mean writing a compiler for the said platform.

aperture• 14 years ago

Probably, but realize that at first this wasn't true. Go needs time to grow, just as C grew to different systems.

Looking at other systems such as Haiku shows that porting Go is encouraged, the only issues have to deal with assumptions in the build (in this case, I think /bin/env/bash is included everywhere, there's no global variable to change this definition from different OS types).

One day we may see a change in Go for different platforms, but I don't think it will prove to hinder that many people, only the niche groups. And for all intents and purposes, Go is built for practical application (!! Don't kill me !!), which systems programming on plan9 or haiku may not be considered "practical" at the moment.

EDIT: for clarity.

luriel17• 14 years ago

> Looking at other systems such as Haiku shows that porting Go is encouraged, the only issues have to deal with assumptions in the build (in this case, I think /bin/env/bash is included everywhere, there's no global variable to change this definition from different OS types).

I think this is not longer a problem with the new build system that is part of Go 1.

Also AFAIK at least the Plan 9 port is almost complete, and is certainly functional.

pjmlp5• 14 years ago

That is what cross-compiling is for.

You use the compiler toolchain in OS A, while generating executables to run on OS B.

With a bootstraping compiler, you can use this technique to bring a native compiler to new platforms.

rwj• 14 years ago

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.

xyproto6• 14 years ago

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.

millerfung5• 14 years ago

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.

luriel17• 14 years ago

Go is relatively beginner friendly, is simpler and smaller than most languages around (even for example Python). Go code is concise but without dark magic (is easy to see what code does by just looking at it). And you can even read the whole language spec fairly easily.

kibwen• 14 years ago

  > smaller than most languages around

I'm not certain that this is specific to Go, insamuch as it's a property of nearly all young languages. After 1.0, language complexity can only ever increase. Even Python has followed this trajectory, although Python should perhaps be commended for being willing to shed some of its complexity along the way (depending on how you view backwards-incompatible changes, some would say it should be denounced rather than commended).

EliRivers2• 14 years ago

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

millerfung5• 14 years ago

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.

jaybill3• 14 years ago

What kind of "beginner"? If you mean someone who has never programmed before, Go is much simpler to learn than C and makes a lot more sense.

If you mean someone that is a programmer and hasn't used go before, I can tell you I went from "never having seen Go before" to "reasonably proficient" inside of two months. Further, my Go code is easier to read and maintain than anything I've done in other languages. (I came largely from Java, so maybe that's not saying much.)

I think that for beginners of either kind, the documentation and community support are just as important as the language itself. I mean, look at something like JavaScript, which is picked up by "beginners" all the time and is, frankly, obtuse as hell. Go has great docs and a really friendly and helpful community.

millerfung5• 14 years ago

Wow, that is very good. I am total beginner in coding so there is nothing much I could say but I am just saying from a total beginners perspective. What would be your suggestion for me if I am planning to build some social application? Learn C first to gain some fundamental knowledge? And because it is still the most widely used language, if I don't know it I wouldn't be able to find a work in the future?

tubbo• 14 years ago

I mean, the only other living inventor of C is working on Go...

copx4• 14 years ago

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 requirements?

Also, the author's portrayal of C is misleading. If you have 'naked' malloc() calls all over your code you are doing something wrong. Much C code never calls malloc() or follows the "no allocation after initialization" principle.

If you write C like Python you will run into problems. In C you do not wildly allocate objects on the heap all across the program. E.g. in my current program almost everything comes out of memory pools. E.g.

Object* object = ObjectNew();

..and if I forgot to release it I would know quickly because any "memory leak" would cause the (pre-allocated, fixed size) memory pool to run out of free slots. In C you should manage memory in a systematic fashion.

I think the C standard library should be seen as the very foundation of a program, something you use to build the abstractions which solve the problem, not something you use directly to solve the problem. People often warn about the dangers of strcpy() (an the author uses it). I never use it except at the lowest levels. At the high level robust C code looks more like this:

ObjectSetName(object, newName);

than this

strcpy(object->name, newName);

..the difference is that ObjectSetName() can internally guard against overflow and that the concrete details of the object data structure remain hidden and thus later code changes are easier. It is a very common C idiom to use incomplete types and such functions to achieve a very high level of encapsulation.

luriel17• 14 years ago

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 behaviour (even the definition of 'real-time' has issues, most things people call 'real-time' aren't).

nux63• 14 years ago

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.

copx4• 14 years ago

>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. Really, really small. Mostly because it did not do much compared to a modern OS.

Things like encapsulation, separation of concerns, etc. only become important once the code grows to a certain size. Unfortunately some people think you need at least C++ for that, despite the fact that for example "private" member variables are way less private than incomplete C types. C is old, but that does not mean it is incompatible with modern software development approaches. Or that you have to write code as if your compiler only parsed the first few letters of an identifier. I think C's bad reputation in some circles can be explained by people only ever seeing 1970s style code.

pcwalton4• 14 years ago

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.

jamesgeck0• 14 years ago

> but could you write an "AAA" video game in it?

Perhaps not, but an extremely large percentage of commercial indie games are written in managed languages.

regularfry• 14 years ago

My chief worry over Go at the moment isn't that is has GC (for the most part), but that the GC it does have is relatively dumb.

eswangren2• 14 years ago

Yes, but they tend to be relatively trivial (in terms of performance) in comparison to AAA titles.

heretohelp2• 14 years ago

No really; I know a number of very talented systems programmers and grew up with C myself.

Your C is not idiomatic even if you're right about avoiding naked mallocs and Go not being appropriate for systems programming.

delinka2• 14 years ago

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.

shadowmint3• 14 years ago

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

jkn• 14 years ago

According to my limited experience (small tools such as a process monitor linking to libproc) it is astonishingly easy and convenient to call C code from Go: no need to write bindings, as Cgo allows to access C symbols directly from Go. I would be interested in what are the difficulties when dealing with larger projects.

For illustration, here's how I call the openproc() function from libproc:

    import (
	/*
	 #cgo LDFLAGS: -lproc
	 #include <proc/readproc.h>

	 PROCTAB* my_openproc(int flags) { return openproc(flags); }
	 */
	"C"
    )

    func parse_procs() {
        proc := C.my_openproc(C.PROC_FILLUSR | C.PROC_FILLCOM | C.PROC_FILLSTAT)
        ...
    }

This illustrates one issue I found with Cgo: calling functions with variable number of arguments is not supported. I had to define a new C function "my_openproc" with a fixed number of arguments, which you can see in the metadata of the import statement. It also includes the compiler and Cgo directives that make editing a Makefile unnecessary. The code for the whole tool is contained in one Go file.

luriel17• 14 years ago

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

tedunangst2• 14 years ago

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

thraxil• 14 years ago

My understanding is that the static linking is a temporary measure to keep things simple and let them focus on getting the language stable. Dynamic linking will come later.

luriel17• 14 years ago

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.

comex2• 14 years ago

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

0xABADC0DA2• 14 years ago

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 thousand lines of code. It's not pretty but it works. Include something like it behind an API as 'libgrt.o' with a few other features and the rest of the code transpiles cleanly.

...but say this existed. What would be the point of writing Google Go code? A more compiler-friendly syntax, less flexibility to make simple memory/pointer mistakes? Would that be enough or would you, with perfect C linkage, just end up writing most of the code in C and Lua? It certainly seem the effect of creating their own compiler (worse than gcc), an opaque "go" tool that does everything, project layout and hosting rules, complicated FFI, etc is to make a 'toolchain island' locking you into writing everything in Google Go, where you might not otherwise.

xyproto6• 14 years ago

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

fingerprinter• 14 years ago

I guess I might be the only one to say this, but is this a joke? Some sort of prank? Not a single Go program is more readable, and I would argue that they are ALL less readable (and I like Go).

I honestly can't tell if he is trolling or if he is serious.

donnyg107• 14 years ago

I disagree. After only a brief runthrough of Go, the different types of statements are very recognizable line by line. The sytax includes less obvious breaks and parens, but I think that makes the code a lot more readable because it eliminates the nastier paren nesting you often see in C. I think the first example in chapter 2 gives clear indication of the benefits of eliminating the features of C which are more compact but less readable.

jbooth2• 14 years ago

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.

Locke16896• 14 years ago

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

eswangren2• 14 years ago

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.

shadowmint3• 14 years ago

Judging by the similarity to his much large section on C (http://crypto.stanford.edu/~blynn/c/) I'd say serious.

Also, who cares what his style is?

If _you_ ever have to work on the code, run gofmt on it; if that's how he likes his go, good for him.

scott_s4• 14 years ago

Also, who cares what his style is?

Me, because I found it unpleasant to read. Working on such code is beside the point.

angelbob• 14 years ago

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.

cantankerous2• 14 years ago

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.

dillon• 14 years ago

He is definitely serious.

I do think that all semicolons really shouldn't be used. The only time I ever use semicolons is for error checking in Go.

drivebyacct25• 14 years ago

He's not helping by explicitly stating that he's ignoring gofmt style. Those examples would look lengthier but cleaner if he would run gofmt on them.

AncientPC3• 14 years ago

I've gone ahead and reformatted his code using `indent -kr` and `gofmt`: https://gist.github.com/2932444

papsosouid10• 14 years ago

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 same area, and is semantically a vastly better language. I just wish go had been more willing to push the envelope and at least try to be somewhat modern and useful instead of being "C with modules, but slow". On the other hand, haskell is a terrible language syntactically, and from a development environment perspective. Go is near enough to perfect in those regards. Having a fast compiler, a simple, working build system, a sane and easily enforced code format all make a huge practical difference. I wish I could use go, as it is much nicer than haskell from a usability perspective. But the language is just too primitive.

drivebyacct25• 14 years ago

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

papsosouid10• 14 years ago

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.

eeperson3• 14 years ago

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

papsosouid10• 14 years ago

You certainly can suggest it, I already tried it though. ;)

Scala ends up more like the worst aspects of haskell and go combined, rather than the best aspects of both.

drivebyacct25• 14 years ago

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.

Graphon2• 14 years ago

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.

heretohelp2• 14 years ago

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

xyproto6• 14 years ago

  * 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?

Graphon2• 14 years ago

Today's embedded is not tomorrow's embedded.

In 10 years your sunglasses will have more compute power and memory than today's smartphone .

ralph2• 14 years ago

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 < 2) puts("y"); else {
      for(int i = 1; i < argc; i++) {
        if (i > 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, but in doing so my attention is being distracted from the main point of the article and frankly I have a huge pile of other things to read that are potentially more rewarding.

luriel17• 14 years ago

Yes, his code style is bizarre at best, both for C and Go.

This is particularly jarring in Go when gofmt exists and is used almost universally (I think this is the first time I see non-gofmt'd code in quite a while).

JackdawX• 14 years ago

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 people on topic.

swdunlop• 14 years ago

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 editor; you start to miss it when refactoring, because you can just shrug and say "gofmt will clean it up when I save" when you move a block to a different function or indent level.

I agree with the grandparent -- seeing non-gofmt code is jarring and deliberately distracting. It's like someone writing an entire Python program with nothing but lambdas.

AncientPC3• 14 years ago

The author's style is not idiomatic for C or Go. He uses shortcuts for compactness at the cost of readability.

Normally this alone is not an issue, but using non-idiomatic code is a weak argument when trying to describe language readability differences.

plorkyeran2• 14 years ago

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

ralph2• 14 years ago

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.

iamgopal• 14 years ago

err..sarcasm ?

kristianp• 14 years ago

Mods, the title should be "C to Go", Go is not spelled with all-caps.

C vs GO

Related Stories