4 ms·

Interesting development, but to be a bit crusty, statements like: "It is easier to write correct Go code than to write correct C code." and "It is easier to

Interesting development, but to be a bit crusty, statements like: "It is easier to write correct Go code than to write correct C code." and "It is easier to debug incorrect Go code than to debug incorrect C code." and "Go is much more fun to use than C." Really are very subjective and don't add much beyond setting a POV for reading the article.

tptacek 13y ago
I've been a C programmer since '93-94, and it is my absolute favorite language, and I'm not sure how anyone could suggest that any of those 3 statements are false. Large-scale correct C code is very difficult to build and debug. Subjective or not, since the whole project is about eliminating C from the codebase, they seem very relevant as well.
- shadowmint 13y ago
  You mean the first 2 I take it. It's pretty obvious fun-level is blatantly subjective.
  - xkarga00 13y ago
    I have a good knowledge of C off last years and recently started programming in Go. I find the later to be much more fun doing.
- jmspring 13y ago
  In the last three years, for the day job, I've written code in C, C++, Objective C, Java, NodeJS, and C#. A recent project that was back to C was really a breath of fresh air. Simple syntax, sure you have to pay attention to memory, but you have full control and need to pay attention, at the same time very little is hidden from you. Personal projects, I prefer Python but dabble in other things as needed. I evaluate the task and the language options. If I needed to prototype out a web service where the server was up to my control, I'd likely shy away from C/C++. In cases where I was writing a module, it would depend on the architecture/framework. Anything low-level or system related, C is my goto well above C++. Stakeholders, external components, and team factor in. I do love how simple and straight forward C is. Calling it hard to debug or write code correctly for is wholly based on the person making such statements.
  - enneff 13y ago
    > I do love how simple and straight forward C is. Calling it hard to debug or write code correctly for is wholly based on the person making such statements. The statements were that Go is easier to write and debug than C, not that C is hard. Considering that Go is memory safe and a significantly simpler language, it's hard to argue otherwise. As for the person making those statements, you should take a look at Russ Cox's resume. > Stakeholders, external components, and team factor in. Indeed they do. In this case, the stakeholders use Go, the external components are written in Go, and the team is the Go team. Go seems like a good fit.
    - jmspring 13y ago
      The context of the link and the intended audience (go contributors) are not obvious within the context of a link posted to HN. Sure, you can read through it and look around, but most will read the initial document with their own mindset and experience, so a lack of context is problematic.
      - enneff 13y ago
        I can see how lack of context is problematic for people who simply must share their opinions without delay. But even without the context, your comments are in response to a misreading of a very small part of the overall document. Hardly seems worth your time.
  - tptacek 13y ago
    I am alarmed by anyone who believes C code is easier to build and debug than a modern memory-safe language. C does indeed make it pleasant to build programs that are fast and seem resilient. But the best secure C programmers in the world still routinely manage to get things wrong. qmail, for instance, had an LP64 overflow.
- Iftheshoefits 13y ago
  Those statements are entirely subjective and, frankly, come off as filled with more than a little hubris, not to mention an air of pettiness and childish language-flamewar-bait. Correct large-scale programs are very difficult to build and debug, full-stop. It isn't a "feature" unique to C, or any other language. Likewise for correct code, and incorrect code: they're both actually trivial to do in any language in the small scale, and see above for the large scale. That said, I view the effort to make a Go compiler using Go is something akin to "eating your own dogfood."
  - enneff 13y ago
    Consider the audience: this document was written for the contributors to the Go project. It wasn't intended to be on the front page of Hacker News. It's not trying to convince anyone that Go is good and C is bad. It's just explaining the rationale for the move to Go. For the intended audience, these statements are pretty much self-evident, or we wouldn't be working on Go in the first place. Also I think you severely underestimate the benefits of memory safety.
  - dpark 13y ago
    C is around 40 years old. Go is about 4 years old. If Go isn't easier to write correctly, easier to debug, and more fun to write, then it's got to be the most tragic and wasted programming language effort ever.
  - SwellJoe 13y ago
    So...it's worth keeping in mind that some of the creators of go are some of the same people who helped create C and UNIX (Rob Pike and Ken Thompson, specifically are two of the three founders of go). They have earned the right to "hubris". And, if they believe they've made a better, easier to debug, more fun language than C (and they do believe that, as it's clear based on their own discussions of the language), I don't think I'd feel any right to argue with them.
  - girvo 13y ago
    Uh... It's Rob Pike and Ken Thompson...
deleted 13y ago
[deleted]
krakensden 13y ago
I don't know why you're surprised or grumpy at the fact that someone who did a lot of work on designing and implementing a language likes that language more than others.
twotwotwo 13y ago
It's an introduction to a Go change proposal, stating a premise that the Go devs share even if you don't; it's like the intro to a C++ change proposal referring to C++ as a good embedded-systems language and the STL as a versatile, easy-to-use data structures library. You can argue, but that's not really part of the conversation about the change any more; you're going off and starting your own conversation about what languages people like. (The plan to transition over by automatic translation, not the bullet points up top, is the interesting part of the document to me. I hope they're able to achieve it without too-serious compiler-performance regressions, since I really like the zippy compilation I get now.)

tptacek 13y ago

I've been a C programmer since '93-94, and it is my absolute favorite language, and I'm not sure how anyone could suggest that any of those 3 statements are false. Large-scale correct C code is very difficult to build and debug. Subjective or not, since the whole project is about eliminating C from the codebase, they seem very relevant as well.

shadowmint 13y ago
You mean the first 2 I take it. It's pretty obvious fun-level is blatantly subjective.
- xkarga00 13y ago
  I have a good knowledge of C off last years and recently started programming in Go. I find the later to be much more fun doing.
jmspring 13y ago
In the last three years, for the day job, I've written code in C, C++, Objective C, Java, NodeJS, and C#. A recent project that was back to C was really a breath of fresh air. Simple syntax, sure you have to pay attention to memory, but you have full control and need to pay attention, at the same time very little is hidden from you. Personal projects, I prefer Python but dabble in other things as needed. I evaluate the task and the language options. If I needed to prototype out a web service where the server was up to my control, I'd likely shy away from C/C++. In cases where I was writing a module, it would depend on the architecture/framework. Anything low-level or system related, C is my goto well above C++. Stakeholders, external components, and team factor in. I do love how simple and straight forward C is. Calling it hard to debug or write code correctly for is wholly based on the person making such statements.
- enneff 13y ago
  > I do love how simple and straight forward C is. Calling it hard to debug or write code correctly for is wholly based on the person making such statements. The statements were that Go is easier to write and debug than C, not that C is hard. Considering that Go is memory safe and a significantly simpler language, it's hard to argue otherwise. As for the person making those statements, you should take a look at Russ Cox's resume. > Stakeholders, external components, and team factor in. Indeed they do. In this case, the stakeholders use Go, the external components are written in Go, and the team is the Go team. Go seems like a good fit.
  - jmspring 13y ago
    The context of the link and the intended audience (go contributors) are not obvious within the context of a link posted to HN. Sure, you can read through it and look around, but most will read the initial document with their own mindset and experience, so a lack of context is problematic.
    - enneff 13y ago
      I can see how lack of context is problematic for people who simply must share their opinions without delay. But even without the context, your comments are in response to a misreading of a very small part of the overall document. Hardly seems worth your time.
- tptacek 13y ago
  I am alarmed by anyone who believes C code is easier to build and debug than a modern memory-safe language. C does indeed make it pleasant to build programs that are fast and seem resilient. But the best secure C programmers in the world still routinely manage to get things wrong. qmail, for instance, had an LP64 overflow.
Iftheshoefits 13y ago
Those statements are entirely subjective and, frankly, come off as filled with more than a little hubris, not to mention an air of pettiness and childish language-flamewar-bait. Correct large-scale programs are very difficult to build and debug, full-stop. It isn't a "feature" unique to C, or any other language. Likewise for correct code, and incorrect code: they're both actually trivial to do in any language in the small scale, and see above for the large scale. That said, I view the effort to make a Go compiler using Go is something akin to "eating your own dogfood."
- enneff 13y ago
  Consider the audience: this document was written for the contributors to the Go project. It wasn't intended to be on the front page of Hacker News. It's not trying to convince anyone that Go is good and C is bad. It's just explaining the rationale for the move to Go. For the intended audience, these statements are pretty much self-evident, or we wouldn't be working on Go in the first place. Also I think you severely underestimate the benefits of memory safety.
- dpark 13y ago
  C is around 40 years old. Go is about 4 years old. If Go isn't easier to write correctly, easier to debug, and more fun to write, then it's got to be the most tragic and wasted programming language effort ever.
- SwellJoe 13y ago
  So...it's worth keeping in mind that some of the creators of go are some of the same people who helped create C and UNIX (Rob Pike and Ken Thompson, specifically are two of the three founders of go). They have earned the right to "hubris". And, if they believe they've made a better, easier to debug, more fun language than C (and they do believe that, as it's clear based on their own discussions of the language), I don't think I'd feel any right to argue with them.
- girvo 13y ago
  Uh... It's Rob Pike and Ken Thompson...

deleted 13y ago

[deleted]

krakensden 13y ago

I don't know why you're surprised or grumpy at the fact that someone who did a lot of work on designing and implementing a language likes that language more than others.

twotwotwo 13y ago

It's an introduction to a Go change proposal, stating a premise that the Go devs share even if you don't; it's like the intro to a C++ change proposal referring to C++ as a good embedded-systems language and the STL as a versatile, easy-to-use data structures library. You can argue, but that's not really part of the conversation about the change any more; you're going off and starting your own conversation about what languages people like. (The plan to transition over by automatic translation, not the bullet points up top, is the interesting part of the document to me. I hope they're able to achieve it without too-serious compiler-performance regressions, since I really like the zippy compilation I get now.)