4 ms·

> Go is a bit more difficult to pin down, demographic-wise, but I'd say it's a mix between C minimalists and Pythonistas and other scripters who want something

by dualogy 14y ago

> Go is a bit more difficult to pin down, demographic-wise, but I'd say it's a mix between C minimalists and Pythonistas and other scripters who want something faster but don't want to go with a JVM-language or go all the way down to bare metal. I think it also appeals to those who first started out programming in Basic but quickly proceeded to Pascal and loved it. At least, that's it in my case. Pascal is the one I'd describe Go as being closest to -- but then I've never been a C programmer. As for Pythonists and scripters, not sure they'd ever be that happy in Go. A lot of their conveniences are "gone" in their experience. Such as custom yield iterators.

pjmlp 14y ago
I keep arguing against the missing support for generics in Go, but on the other hand I see it as a nice C replacement. And before someone answers me with the lack of manual memory management, Native Oberon and Blue Bottle are done in fully GC enabled languages with a little assembly for the boot loader and interrupt controller bindings. http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager
- gillianseed 14y ago
  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++.
- jeremyjh 14y ago
  If it were a good C replacement I'd be able to expose an ABI for other language bindings, so that I could write libraries that could be used in many different languages. There is no way to do this in Go. If it were a good C replacement, it would have dynamically linkable libraries so that I could write an extensible server that could be extended with external modules (a la Apache). If it were a good C replacement I'd have direct access to memory so that I could write device drivers.
  - pjmlp 14y ago
    > If it were a good C replacement I'd be able to expose an ABI for other language bindings, so that I could write libraries that could be used in many different languages. There is no way to do this in Go. C ABI is the operating system ABI. If the OS is written in Go, the C ABI becomes irrelevant. > If it were a good C replacement, it would have dynamically linkable libraries so that I could write an extensible server that could be extended with external modules (a la Apache). You can do this with gccgo to some extent already. Eventually this support might come to the standard compiler. This is not a language issue, rather an implementation issue. As anyone with compiler development knowledge can easily explain to you. > If it were a good C replacement I'd have direct access to memory so that I could write device drivers. The Oberon guys did not had any issue with this. Their System package API is quite similar to what Go's unsafe package offers. http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pdf http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pd... http://e-collection.library.ethz.ch/eserv/eth:26082/eth-26082-02.pdf http://e-collection.library.ethz.ch/eserv/eth:26082/eth-2608...
Evbn 14y ago
Pythonistas hate Go. Go appeals to people who like the idea and look of Python but got burned by dynamic typing.
- DocSavage 14y ago
  That's a pretty broad brush and in my case, completely untrue. Go has a lot more than static typing, particularly nice concurrency support and solid libraries even for things like image handling (no need to build PIL).

by dualogy 14y ago

pjmlp 14y ago

I keep arguing against the missing support for generics in Go, but on the other hand I see it as a nice C replacement. And before someone answers me with the lack of manual memory management, Native Oberon and Blue Bottle are done in fully GC enabled languages with a little assembly for the boot loader and interrupt controller bindings. http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager

gillianseed 14y ago
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++.
jeremyjh 14y ago
If it were a good C replacement I'd be able to expose an ABI for other language bindings, so that I could write libraries that could be used in many different languages. There is no way to do this in Go. If it were a good C replacement, it would have dynamically linkable libraries so that I could write an extensible server that could be extended with external modules (a la Apache). If it were a good C replacement I'd have direct access to memory so that I could write device drivers.
- pjmlp 14y ago
  > If it were a good C replacement I'd be able to expose an ABI for other language bindings, so that I could write libraries that could be used in many different languages. There is no way to do this in Go. C ABI is the operating system ABI. If the OS is written in Go, the C ABI becomes irrelevant. > If it were a good C replacement, it would have dynamically linkable libraries so that I could write an extensible server that could be extended with external modules (a la Apache). You can do this with gccgo to some extent already. Eventually this support might come to the standard compiler. This is not a language issue, rather an implementation issue. As anyone with compiler development knowledge can easily explain to you. > If it were a good C replacement I'd have direct access to memory so that I could write device drivers. The Oberon guys did not had any issue with this. Their System package API is quite similar to what Go's unsafe package offers. http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pdf http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pd... http://e-collection.library.ethz.ch/eserv/eth:26082/eth-26082-02.pdf http://e-collection.library.ethz.ch/eserv/eth:26082/eth-2608...

Evbn 14y ago

Pythonistas hate Go. Go appeals to people who like the idea and look of Python but got burned by dynamic typing.

DocSavage 14y ago
That's a pretty broad brush and in my case, completely untrue. Go has a lot more than static typing, particularly nice concurrency support and solid libraries even for things like image handling (no need to build PIL).