Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Replace - simple and fast search and replace tool for command line

solovyov.net

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Go Replace - simple and fast search and replace tool for command line

#41

Post by artagnon »

Intermernet wrote: post #34
artagnon wrote: post #22

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 assump…

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 standa…

> 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]

Re: Go Replace - simple and fast search and replace tool for command line

#42

Post by alexchamberlain »

piranha wrote: post #11
madisp wrote: post #10

For x86 binaries: go get github.com/piranha/goreplace go install github.com/piranha/goreplace is another way to get it if you have GO and GOPATH set up. I personally aliased it to 'gor' in my zshrc as the git plugin already occupied the 'gr' (short for git remote).

Ha-ha, I've got an issue asking to add some notes about conflict with oh-my-zsh alias. :) I hastily suggested `gp`, but it's already taken by same plugin, so I changed it to `gor` there, thanks for idea.

Is tab completion not enough?

Re: Go Replace - simple and fast search and replace tool for command line

#43

Post by piranha »

alexchamberlain wrote: post #42
piranha wrote: post #11

Earlier quoted context omitted.

Ha-ha, I've got an issue asking to add some notes about conflict with oh-my-zsh alias. :) I hastily suggested `gp`, but it's already taken by same plugin, so I changed it to `gor` there, thanks for idea.

Is tab completion not enough?

It's often is. But somehow people end up with 'git remote' aliased to 'gr', and I ask the same question. :) I use gr very often and so not have to tab complete is a plus.

Re: Go Replace - simple and fast search and replace tool for command line

#44

Post by kisielk »

artagnon wrote: post #41
Intermernet wrote: post #34

Earlier quoted context omitted.

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 standa…

> 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 i…

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.

Re: Go Replace - simple and fast search and replace tool for command line

#45

Post by artagnon »

piranha wrote: post #27
artagnon wrote: post #22

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 assump…

> 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…

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?

Re: Go Replace - simple and fast search and replace tool for command line

#46

Post by artagnon »

kisielk wrote: post #44
artagnon wrote: post #41

Earlier quoted context omitted.

> 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 i…

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.

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.

Re: Go Replace - simple and fast search and replace tool for command line

#47

Post by Intermernet »

artagnon wrote: post #41
Intermernet wrote: post #34

Earlier quoted context omitted.

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 standa…

> 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 i…

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) 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.

Re: Go Replace - simple and fast search and replace tool for command line

#48

Post by dosaywhatnow »

artagnon wrote: post #46
kisielk wrote: post #44

Earlier quoted context omitted.

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.

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.

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.

Re: Go Replace - simple and fast search and replace tool for command line

#49

Post by Intermernet »

artagnon wrote: post #46
kisielk wrote: post #44

Earlier quoted context omitted.

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.

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.

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)

Re: Go Replace - simple and fast search and replace tool for command line

#50

Post by murkt »

artagnon wrote: post #45
piranha wrote: post #27

Earlier quoted context omitted.

> 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…

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…

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.

Post reply on HN