5 ms·

Okay, so what I learnt from this: 1. You've imported droundy/goopt, wsxiaoys/terminal really easily. The first provides option-parsing, and the second provide

Okay, so what I learnt from this: 1. You've imported droundy/goopt, wsxiaoys/terminal really easily. The first provides option-parsing, and the second provides helpers for emitting ANSI escape codes. 2. Practically everything is overloaded. You can == to strcmp(), + to concatenate strings. 3. path/filepath gives you some nice goodies for path manipulation. But you have to deal with the fallouts of making naive assumptions like whether or not to recurse symlinks (why isn't this a flag in filepath.Walk?). This has resulted in ugliness in your walkFunc callback. 4. You have been able to abstract quite a bit without using Java-like factories, although your inconsistent error passing has me somewhat confused. 5. Since it's so strongly typed and there are no raw pointers, it's not going to be hard to debug at all. Overall, I'd say Go is an effective language. But not beautiful, or novel in the slightest. It resembles Algol-68 (yes, a 1968 language) quite strongly, and I don't think it will drive compiler technology. Their syntax is specifically engineered to be parseable quickly (and hence super-fast AOT compilation): what the final program looks like is secondary concern. I'm not sure I see the appeal. [edit: clarified that the note on compiler technology was an opinion]

gngeal 13y ago
and proudly declares that it will not use any modern advances to compiler technology Where do they say anything of the kind?
piranha 13y ago
> your inconsistent error passing has me somewhat confused. That was my first somewhat big program in Go plus coming from Python made a bit of hustle here. I still believe exceptions to be much better than this error-returning. :\ Never learned to do it nicely. :\ > Overall, I'd say Go is an effective language. But not beautiful, or novel in the slightest. Yes, this is more or less my feelings nowadays. It's good for certain cases and if I ever need something fast, I'll use Go and not C. > I'm not sure I see the appeal. There is some. It's still much simpler than C (GC + stricter compiler), plus it has goroutines (not much in this app, though), plus interfaces are really wonderful (you don't need to declare that you implement interface, just implement it and you're done).
- artagnon 13y ago
  On C. C has been around for _much_ longer than Go, and a lot of people understand C inside out. The C ecosystem is fantastic: there are extremely good implementations of virtually everything that you can use to build a production-grade application. On Go. It'll take time for a programmer to fully understand how to use a new language, and it'll be a long time before great implementations appear. If the language isn't that much of an improvement, why will an existing C programmer take the effort to learn it? Aren't the returns diminishing? Computers will only get faster, llvm will only improve (tooling + compile time + link time): in that respect, doesn't Go seem a bit short-sighted?
  - murkt 13y ago
    And there is a whole lot of people who don't know C inside out and don't want to dive in it. One needs to explicitly manage memory, deal with raw pointers, ugly header files and all that stuff. No interfaces, too.
  - genwin 13y ago
    In the respect of existing C programmers, maybe. Having myself never mastered C because of its complexity, in a few months part-time effort starting from getting a book on Go I built a sophisticated website. In the respect of non-C programmers, Go is extremely useful.
    - agentultra 13y ago
      C isn't any more difficult to understand, IMO. Obviously Go has the advantage of hindsight and an opportunity to go back on the trade-offs that were made for compiler efficiency before C was standardized. However, at it's core I think C is much more simple than Go and theoretically should be easier to understand. I find GC to be a useful tool but have you ever looked into the implementation of one? Or have you run into a situation where it was necessary to reason about the performance characteristics of a GC in relation to some algorithm or tight main loop? I don't find C's lack of GC any more complex than GC. In fact I find it much more simple. It requires more discipline on the part of the programmer (and perhaps that is where the appeal of a GC comes from). Perhaps it's because I started programming with addressing memory and building up a mental model of how it works and have only encountered GC as a useful addition to my programming toolbox (instead of an always-present assumption). As well, co-routine trampolining (which is what I assume the playful pun go-routines are referring to... please correct me if I am wrong) isn't a very "simple" thing to understand either. At least they are not any more simple than threads so I don't understand how they make learning Go any more easy for non-C programmers (except perhaps exposure to co-routines in a language that already has them like Python). I guess what I am saying is that you could have just as easily mastered as much C in those few months as you did Go.
Intermernet 13y ago
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.
realrocker 13y ago
>Overall, I'd say Go is an effective language. But not beautiful, or novel in the slightest You are right on target. Go was designed to be boring[1][2]. Programming language should not be about tricks and traps. It's a tool. Tools are not built for beauty. They are built for functionality. [1]http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article [2]http://aeronotix.pl/blog/go-is-boring http://aeronotix.pl/blog/go-is-boring In [1](2.Introudction) even the inventors agree that Go can be boring to some people. Guess what, It's boring by design.

gngeal 13y ago

and proudly declares that it will not use any modern advances to compiler technology Where do they say anything of the kind?

piranha 13y ago

> your inconsistent error passing has me somewhat confused. That was my first somewhat big program in Go plus coming from Python made a bit of hustle here. I still believe exceptions to be much better than this error-returning. :\ Never learned to do it nicely. :\ > Overall, I'd say Go is an effective language. But not beautiful, or novel in the slightest. Yes, this is more or less my feelings nowadays. It's good for certain cases and if I ever need something fast, I'll use Go and not C. > I'm not sure I see the appeal. There is some. It's still much simpler than C (GC + stricter compiler), plus it has goroutines (not much in this app, though), plus interfaces are really wonderful (you don't need to declare that you implement interface, just implement it and you're done).

artagnon 13y ago
On C. C has been around for _much_ longer than Go, and a lot of people understand C inside out. The C ecosystem is fantastic: there are extremely good implementations of virtually everything that you can use to build a production-grade application. On Go. It'll take time for a programmer to fully understand how to use a new language, and it'll be a long time before great implementations appear. If the language isn't that much of an improvement, why will an existing C programmer take the effort to learn it? Aren't the returns diminishing? Computers will only get faster, llvm will only improve (tooling + compile time + link time): in that respect, doesn't Go seem a bit short-sighted?
- murkt 13y ago
  And there is a whole lot of people who don't know C inside out and don't want to dive in it. One needs to explicitly manage memory, deal with raw pointers, ugly header files and all that stuff. No interfaces, too.
- genwin 13y ago
  In the respect of existing C programmers, maybe. Having myself never mastered C because of its complexity, in a few months part-time effort starting from getting a book on Go I built a sophisticated website. In the respect of non-C programmers, Go is extremely useful.
  - agentultra 13y ago
    C isn't any more difficult to understand, IMO. Obviously Go has the advantage of hindsight and an opportunity to go back on the trade-offs that were made for compiler efficiency before C was standardized. However, at it's core I think C is much more simple than Go and theoretically should be easier to understand. I find GC to be a useful tool but have you ever looked into the implementation of one? Or have you run into a situation where it was necessary to reason about the performance characteristics of a GC in relation to some algorithm or tight main loop? I don't find C's lack of GC any more complex than GC. In fact I find it much more simple. It requires more discipline on the part of the programmer (and perhaps that is where the appeal of a GC comes from). Perhaps it's because I started programming with addressing memory and building up a mental model of how it works and have only encountered GC as a useful addition to my programming toolbox (instead of an always-present assumption). As well, co-routine trampolining (which is what I assume the playful pun go-routines are referring to... please correct me if I am wrong) isn't a very "simple" thing to understand either. At least they are not any more simple than threads so I don't understand how they make learning Go any more easy for non-C programmers (except perhaps exposure to co-routines in a language that already has them like Python). I guess what I am saying is that you could have just as easily mastered as much C in those few months as you did Go.

Intermernet 13y ago

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.

realrocker 13y ago

>Overall, I'd say Go is an effective language. But not beautiful, or novel in the slightest You are right on target. Go was designed to be boring[1][2]. Programming language should not be about tricks and traps. It's a tool. Tools are not built for beauty. They are built for functionality. [1]http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article [2]http://aeronotix.pl/blog/go-is-boring http://aeronotix.pl/blog/go-is-boring In [1](2.Introudction) even the inventors agree that Go can be boring to some people. Guess what, It's boring by design.