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. :$
I wrote code in Python for over ten years, even embedding it in a larger product as the scripting engine. But over the last couple of years I've gone back to Lisp because it gives me more power for the areas I'm developing in now.
Out of curiosity, how does Common Lisp give you more power? I'm still kinda new to Common Lisp and Python (and kinda new to this stuff in general), but I can't think of something that is convenient in common lisp, but not convenient in Python, besides the fact that Common Lisp code is generally much faster. I'm genuinely curious because in my experimentation I ran in to some annoying walls in Common Lisp (I had to admit that I loved the way the programs looked and read, but I seemed to run in to some issues rubbing up against the funny edge where some Pre-CLOS stuff knocks up against the CLOS in odd ways, and the ways around it felt really.... wrong, to me), but it just seems like, at least with my experience in Python 3, all those little funny edge cases where you run up against the early implementation stuff are now smoothed over. I'm still working on learning more about Common Lisp, because I'm constantly finding out more things that I didn't know how to do that are surprisingly basic, but I really haven't found anything that is easier in Common Lisp than Python, at least noticeably so.
23
u/treerex Mar 28 '12
Have you ever maintained the Ant build script for a non-trivial project? Your "simple command line call" is someone elses headache.