4 ms·

Your last paragraph contains some spurious statements: "proudly declares that it will not use any modern advances to compiler technology" Where? I've read mos

Your last paragraph contains some spurious statements: "proudly declares that it will not use any modern advances to compiler technology" Where? I've read most of the available documentation, blog-posts etc. and have yet to come across a statement even vaguely resembling this. "what the final program looks like is secondary concern" Have you read about "go fmt"? The entire idea of it is to format the code to a standard. You don't need to use it, but it's recommended and, frankly, makes every other language without a similar feature seem like "what the final program looks like is secondary concern". You're welcome to your opinion, but I think you'd best do some more research before making such statements without references.

artagnon 13y ago
> proudly declares that it will not use any modern advances to compiler technology My apologies: this is an opinion, rather than an explicit declaration from the project. Their compiler "gc" starts with a traditional recursive descent parser using bison, and chose not to use llvm. Although one can argue that llvm doesn't provide enough information to implement a great jit, all aot compilers are moving towards using it. By having a common compiler infrastructure, compilers can focus on what is important. They currently have a simple parallel mark-and-sweep garbage collector, and there is some scope for development in the context of concurrent programs (wasn't it their goal to make it easy to write concurrent programs with goroutines?). Nothing spectacular though: the garbage collector in a mature JVM or V8 (which has to deal with a weakly typed language!) is far ahead; that's where the garbage collection research happens. > what the final programs looks like is secondary concern The grammar has been specifically engineered so that the language can be analyzed and parsed without a symbol table. "go fmt" is just syntactical sugar: you cannot change the underlying parser. I'm not bikeshedding about which syntax is "better", but pointing out the motivation behind the current syntax. For instance, it's very different from ruby, which was designed ground-up to resemble human language as closely as possible (hence Poignant Ruby etc). [edit: gc does not use a gcc backend; gccgo does]
- kisielk 13y ago
  The gc compiler does not use a gcc backend. You're confusing it with gccgo. The llgo project is working on an llvm-based Go compiler.
  - artagnon 13y ago
    Right, gccgo. However, that does seem to be the dominant implementation: llgo is being developed as an education exercise (excerpt from project page). From the Go FAQ: We also considered using LLVM for gc but we felt it was too large and slow to meet our performance goals.
    - dosaywhatnow 13y ago
      The 'dominant' implementation is gc, not gccgo. IIRC, gc is based off the Plan 9 compliers which Pike et al write. gccgo is an alternative implementation which (generally) trails gc.
    - Intermernet 13y ago
      Most go programs that don't need to be linked with existing C libraries are using the gc compiler. Currently there are a lot of really good C libraries that haven't been ported to go, so anyone who wants to link to those is using the gccgo compiler, but it will probably be less used as the native 3rd party libraries catch up, or the C libraries are ported (this is happening at a furious rate)
- Intermernet 13y ago
  No need to apologise to me :-) As I said, you're entitled to your opinion. You'll probably be interested in some of what was talked about in the "Go Fireside Chat" (http://youtu.be/p9VUCp98ay4 http://youtu.be/p9VUCp98ay4) in regards to re-designing the compiler, alternate compilers, LLVM etc. It sounds like they're aware of exactly the issues you're concerned about.
- gngeal 13y ago
  Although one can argue that llvm doesn't provide enough information to implement a great jit, all aot compilers are moving towards using it. Actually, all serious Common Lisp implementations, for example, do incremental AOT compilation these days, and none of them is ever going to "move towards using LLVM". In the broader landscape of programming language implementations, as far as IR generality is concerned, LLVM is actually not significantly better than Java bytecode, and for many languages, trying to use it would probably generate more problems than actually using it would solve.

artagnon 13y ago

> proudly declares that it will not use any modern advances to compiler technology My apologies: this is an opinion, rather than an explicit declaration from the project. Their compiler "gc" starts with a traditional recursive descent parser using bison, and chose not to use llvm. Although one can argue that llvm doesn't provide enough information to implement a great jit, all aot compilers are moving towards using it. By having a common compiler infrastructure, compilers can focus on what is important. They currently have a simple parallel mark-and-sweep garbage collector, and there is some scope for development in the context of concurrent programs (wasn't it their goal to make it easy to write concurrent programs with goroutines?). Nothing spectacular though: the garbage collector in a mature JVM or V8 (which has to deal with a weakly typed language!) is far ahead; that's where the garbage collection research happens. > what the final programs looks like is secondary concern The grammar has been specifically engineered so that the language can be analyzed and parsed without a symbol table. "go fmt" is just syntactical sugar: you cannot change the underlying parser. I'm not bikeshedding about which syntax is "better", but pointing out the motivation behind the current syntax. For instance, it's very different from ruby, which was designed ground-up to resemble human language as closely as possible (hence Poignant Ruby etc). [edit: gc does not use a gcc backend; gccgo does]

kisielk 13y ago
The gc compiler does not use a gcc backend. You're confusing it with gccgo. The llgo project is working on an llvm-based Go compiler.
- artagnon 13y ago
  Right, gccgo. However, that does seem to be the dominant implementation: llgo is being developed as an education exercise (excerpt from project page). From the Go FAQ: We also considered using LLVM for gc but we felt it was too large and slow to meet our performance goals.
  - dosaywhatnow 13y ago
    The 'dominant' implementation is gc, not gccgo. IIRC, gc is based off the Plan 9 compliers which Pike et al write. gccgo is an alternative implementation which (generally) trails gc.
  - Intermernet 13y ago
    Most go programs that don't need to be linked with existing C libraries are using the gc compiler. Currently there are a lot of really good C libraries that haven't been ported to go, so anyone who wants to link to those is using the gccgo compiler, but it will probably be less used as the native 3rd party libraries catch up, or the C libraries are ported (this is happening at a furious rate)
Intermernet 13y ago
No need to apologise to me :-) As I said, you're entitled to your opinion. You'll probably be interested in some of what was talked about in the "Go Fireside Chat" (http://youtu.be/p9VUCp98ay4 http://youtu.be/p9VUCp98ay4) in regards to re-designing the compiler, alternate compilers, LLVM etc. It sounds like they're aware of exactly the issues you're concerned about.
gngeal 13y ago
Although one can argue that llvm doesn't provide enough information to implement a great jit, all aot compilers are moving towards using it. Actually, all serious Common Lisp implementations, for example, do incremental AOT compilation these days, and none of them is ever going to "move towards using LLVM". In the broader landscape of programming language implementations, as far as IR generality is concerned, LLVM is actually not significantly better than Java bytecode, and for many languages, trying to use it would probably generate more problems than actually using it would solve.