5 ms·

I don't understand why you continously want to pitch Go as a C replacement. In my experience the domains in which C is the most appropriate choice does not wor

I don't understand why you continously want to pitch Go as a C replacement. In my experience the domains in which C is the most appropriate choice does not work well with GC's, and even overhead like that coming from automatic boundary checking is an unwelcome performance impact. What exactly are the areas of C use in which you expect Go to replace it?

Evbn 14y ago
Small fast simple web apps. The point of Go isn't that it replace existing C programs, it is that Go appeals to C programmers who want to extend their rrach, it is that is reshapes C to fit in areas it didn't fit before (and, yes, to not fit in areas it fit before), without being as radically different as Java or Python or Haskell.
pjmlp 14y ago
> I don't understand why you continously want to pitch Go as a C replacement. Because we should move away from languages that are designed for security exploits. > In my experience the domains in which C is the most appropriate choice does not work well with GC's, and even overhead like that coming from automatic boundary checking is an unwelcome performance impact. I hear the complaint about automatic boundary checking since the early Pascal days. Yet most compilers, even Go, provide a compiler switch to disable bound checking. Lets not forget how many security exploits we have to thank C for exactly this mis-feature. Modula-3, Oberon, Active Oberon are three examples of GC enabled languages with given proofs that is possible to write operating systems in GC enabled languages with zero C code. The Native Oberon and Blue Bottle operating systems were even used for several years as desktop systems at ETHZ. > What exactly are the areas of C use in which you expect Go to replace it? Well, actually it does not have to be Go. Rust and D are also good candidates. The only area where I concede it is hard to replace C is in embedded space, specially if we consider many developers are still using Assembly. As for the areas where human life is at risk we are better off with Ada, Spark or ATS. In these cases I surely wouldn't want a GC issue to cause deaths.
- gillianseed 14y ago
  >Because we should move away from languages that are designed for security exploits. Are you seriously claiming that C was designed for security exploits? >Lets not forget how many security exploits we have to thank C for exactly this mis-feature. No actually we have to thank sloppy and/or naive programmers. The C language is clear in that it doesn't hold your hand. >The Native Oberon and Blue Bottle operating systems were even used for several years as desktop systems at ETHZ. You can write an operating system in lots of languages besides C (and it has been done aswell), yet all the operating systems/kernels in wide use these days are all mainly written in C or a combination of C/C++. That you can write an operating system in language X is nothing new, the performance you get with language X however is. We've seem numerous 'safe language' operating system attempts which have died due to inactivity or as in Singularity's case been passed off to academia because MIcrosoft realised it had no commercial relevance. >The only area where I concede it is hard to replace C is in embedded space, specially if we consider many developers are still using Assembly. I disagree, in everything where performance and/or footprint is paramount there will be a need for languages such as C, as always there is room for competition but Go certainly isn't a candidate in my opinion. I haven't really looked into Rust yet, D on the other hand seems to have gained zero traction and is from what I gather primarily positioning itself against C++.
  - prodigal_erik 14y ago
    C requires a level of unassisted perfection that we spent forty years demonstrating nobody can attain. Every programmer is sloppy and naive in comparison. Tools that fail in human hands, shouldn't be.
    - gillianseed 14y ago
      >C requires a level of unassisted perfection that we spent forty years demonstrating nobody can attain. So there is no exploit-free C code out there? It is just impossible to write C code without buffer overflow bugs? >Tools that fail in human hands, shouldn't be. If so why don't we throw out all programming languages? You can create buggy code with far-reaching implications in any sufficiently complex programming language, buffer overruns are but one type of bug. And relating back to 'tools', we have lots of great tools at our disposal these days which can be automated to help identify possible vulnerabilities in our code. There really isn't a 'either you use a safe language or your code will by definition contain exploits' situation which some people try to paint.

Evbn 14y ago

Small fast simple web apps. The point of Go isn't that it replace existing C programs, it is that Go appeals to C programmers who want to extend their rrach, it is that is reshapes C to fit in areas it didn't fit before (and, yes, to not fit in areas it fit before), without being as radically different as Java or Python or Haskell.

pjmlp 14y ago

> I don't understand why you continously want to pitch Go as a C replacement. Because we should move away from languages that are designed for security exploits. > In my experience the domains in which C is the most appropriate choice does not work well with GC's, and even overhead like that coming from automatic boundary checking is an unwelcome performance impact. I hear the complaint about automatic boundary checking since the early Pascal days. Yet most compilers, even Go, provide a compiler switch to disable bound checking. Lets not forget how many security exploits we have to thank C for exactly this mis-feature. Modula-3, Oberon, Active Oberon are three examples of GC enabled languages with given proofs that is possible to write operating systems in GC enabled languages with zero C code. The Native Oberon and Blue Bottle operating systems were even used for several years as desktop systems at ETHZ. > What exactly are the areas of C use in which you expect Go to replace it? Well, actually it does not have to be Go. Rust and D are also good candidates. The only area where I concede it is hard to replace C is in embedded space, specially if we consider many developers are still using Assembly. As for the areas where human life is at risk we are better off with Ada, Spark or ATS. In these cases I surely wouldn't want a GC issue to cause deaths.

gillianseed 14y ago
>Because we should move away from languages that are designed for security exploits. Are you seriously claiming that C was designed for security exploits? >Lets not forget how many security exploits we have to thank C for exactly this mis-feature. No actually we have to thank sloppy and/or naive programmers. The C language is clear in that it doesn't hold your hand. >The Native Oberon and Blue Bottle operating systems were even used for several years as desktop systems at ETHZ. You can write an operating system in lots of languages besides C (and it has been done aswell), yet all the operating systems/kernels in wide use these days are all mainly written in C or a combination of C/C++. That you can write an operating system in language X is nothing new, the performance you get with language X however is. We've seem numerous 'safe language' operating system attempts which have died due to inactivity or as in Singularity's case been passed off to academia because MIcrosoft realised it had no commercial relevance. >The only area where I concede it is hard to replace C is in embedded space, specially if we consider many developers are still using Assembly. I disagree, in everything where performance and/or footprint is paramount there will be a need for languages such as C, as always there is room for competition but Go certainly isn't a candidate in my opinion. I haven't really looked into Rust yet, D on the other hand seems to have gained zero traction and is from what I gather primarily positioning itself against C++.
- prodigal_erik 14y ago
  C requires a level of unassisted perfection that we spent forty years demonstrating nobody can attain. Every programmer is sloppy and naive in comparison. Tools that fail in human hands, shouldn't be.
  - gillianseed 14y ago
    >C requires a level of unassisted perfection that we spent forty years demonstrating nobody can attain. So there is no exploit-free C code out there? It is just impossible to write C code without buffer overflow bugs? >Tools that fail in human hands, shouldn't be. If so why don't we throw out all programming languages? You can create buggy code with far-reaching implications in any sufficiently complex programming language, buffer overruns are but one type of bug. And relating back to 'tools', we have lots of great tools at our disposal these days which can be automated to help identify possible vulnerabilities in our code. There really isn't a 'either you use a safe language or your code will by definition contain exploits' situation which some people try to paint.