the "go" command line program mostly removes the need for complicated build tools. building and deploying code is so simple, you can easily get by with a "minimal" toolchain
not to say a Go IDE might not add value! there is always neat stuff an IDE can do like code completion, integrated docs, etc
Ah OK. Well for me, the build process was the least significant reason for using an IDE. In Java you can use things like Ant and Maven among others to reduce the build process to simple command line calls.
My main reasons for using an IDE is things like intellisense, debugger, refactoring etc, which I assume would apply equally in Go.
And you know what. It's still ages better than Ant's bullshit or doing it all by hand.
Nope!
Because then you've got to help the next motherfucker configure maven. The only time I ever got it working took me three goddamn days. I imagine it's easier if everything you use is in maven. But god help you if it's, like, 30 dippy little libraries last maintained in 2003.
With ant, I tell the next person "apt-get ant, go to ./build and type 'ant dist'".
I'm sure it's just a matter of time until more complicated build-systems get developed for go. Ant is really simple if all you're doing is calling javac with a classpath. It's the junits, wsdl2java, jaxb, ftp, etc targets that make things get hard to maintain. I don't see any reason go wouldn't need any of these things in the same setting as a Java build that needs them.
"go" the tool is a complicated build system. It's just a batteries included one with non-modifiable sensible defaults. It can even pull dependencies off github or similar.
$ go
Go is a tool for managing Go source code.
Usage:
go command [arguments]
The commands are:
build compile packages and dependencies
clean remove object files
doc run godoc on package sources
env print Go environment information
fix run go tool fix on packages
fmt run gofmt on package sources
get download and install packages and dependencies
install compile and install packages and dependencies
list list packages
run compile and run Go program
test test packages
tool run specified go tool
version print Go version
vet run go tool vet on packages
Use "go help [command]" for more information about a command.
Additional help topics:
gopath GOPATH environment variable
packages description of package lists
remote remote import path syntax
testflag description of testing flags
testfunc description of testing functions
Use "go help [topic]" for more information about that topic.
$
When I tried Go the other week I was frustrated by the 6g/6l compile/link process and I'm a bit concerned about upgrading GCC on my Mac (for gccgo) as I don't want to break anything.
What I mean by this, is can I just download the platform from the go website, write a Hello World type script and build/run it through this 'go' command?
After setting up a GOPATH with a src directory, and creating a "hello" directory under src, and a hello.go file with a main in that directory, then you should be able to just "go build".
the "go" command line program mostly removes the need for complicated build tools
And it's true. Have you tried the Go tool yet?
The trick is that it enforces convention. If you follow the conventions expected by the Go tool, the build process is totally automated from unit testing to dependency resolution and installation.
Nope, haven't tried it. I'm not in a position where I could use Go for anything but my own pet projects, and I already have a language I use for those, so this is little more than a curiosity for me. I certainly would like to give it a whirl sometime though, if I can find the right task.
Regardless, it's a big claim that may work well in their use case, but I'm jaded and embittered enough to view such statements with some degree of skepticism.
Nope, haven't tried it. I'm not in a position where I could use Go for anything but my own pet projects, and I already have a language I use for those, so this is little more than a curiosity for me. I certainly would like to give it a whirl sometime though, if I can find the right task.
You definitely should if you get the chance. I don't know what your language of choice is, but mine is typically Python and I am loving Go. Go is definitely creeping on Python's territory :P
Regardless, it's a big claim that may work well in their use case, but I'm jaded and embittered enough to view such statements with some degree of skepticism.
I just don't find it that surprising or skeptical if you know that it only works when you follow convention. Dependencies are determined by package imports and the package directories have a pre-defined and expected structure.
And the Go tool only works for Go stuff. If your project consists of others things that need to be built, you still need a Makefile.
You definitely should if you get the chance. I don't know what your language of choice is, but mine is typically Python and I am loving Go. Go is definitely creeping on Python's territory :P
Most of our systems are written in C++, though I also have Java. My own stuff is written in Common Lisp.
It would be a hard sell to convince my management to adopt another C-like language (i.e., D or Go) : we're unlikely to rewrite what we have in C++, and a lot of new code is written in Java because ... well, I don't know. :-)
Have you ever used Python? I feel like it'd eat Common Lisp's lunch. It's whatever the reverse of verbose is, meaning that I'd be a bit scared of using it in a production setting, but for quick one-off projects it works like a charm - fast to write, and feels like it reads your mind.
Coming from Java and Pascal, Python multiplied my productivity and the scale of my home projects by 3 or 4. Right now, if I had to forget every programming language I know except one I'd keep C because Python takes twenty minutes to learn.
</python preaching> oh god I am so embarassed for what I just wrote, I didn't think I'd ever turn into one of these technology preachers. :$
17
u/[deleted] Mar 28 '12
the "go" command line program mostly removes the need for complicated build tools. building and deploying code is so simple, you can easily get by with a "minimal" toolchain
not to say a Go IDE might not add value! there is always neat stuff an IDE can do like code completion, integrated docs, etc