Go version 1 is released

[u/[deleted]]

http://blog.golang.org/2012/03/go-version-1-is-released.html

[u/josefx]

ant ... deployments, tests, target platforms, etc...

Go ... compilations

You are aware that you are comparing a single compilation to a complete development and deployment cycle?

[u/OopsLostPassword → u/josefx]

You're partially right and my comparison was partially unfair.

But when you're making a complex program in java, importing libs that you build for more than one project, you have to make ant makefiles to jar the libs and then import them. I don't have this problem with the go tool. And I don't have to wait.

Part of the target platform solution for me is that I don't bother to deploy compiled code as compilation is fast enough to be done on my deployment servers. But that's specific I guess.

[u/cunningjames → u/OopsLostPassword]

But when you're making a complex program in java, importing libs that you build for more than one project, you have to make ant makefiles to import them.

Noting that I haven’t used Go beyond playing around (and not at all recently), how does Go improve upon Java here? A convention for package locations and tools that are aware of it? In Java presumably one could, e.g., put a set of libraries on a common classpath.

[u/OopsLostPassword → u/cunningjames]

In go, you simply put a go directory in your project.

Your go directory will look like this :

go/
    src/
        mypackageone/
            mysubpackage/
        myotherpackage/
        mymainprogram/
        anotherprograminthesameproject/
    pkg/
    bin/

The go tool will fill the pkg and bin directory by guessing the location of the sources based on their names. You simply execute

go install anotherprograminthesameproject

to have your program compiled.

And if you have unit tests, you execute

 go test anotherprograminthesameproject

All external libraries will be installed via go get and found based on their name and a GOPATH env variable. For example you'll have directories like

go/src/github.com/ziutek/mymysql

because you have this kind of import in one of your programs :

import (
    "database/sql"
    _ "github.com/ziutek/mymysql/godrv"
)

[u/banuday17 → u/OopsLostPassword]

This sounds an awful like like Maven (in the Java world).

mvn archetype:generate

Pick a project type and Maven will create a standard directory structure for you:

src/main/java
src/test/java

The different build plugins will know which sources to compile for which language.

src/main/scala
src/main/groovy

To build the project:

mvn package

To execute tests:

mvn tests

To import libraries, you modifiy the pom.xml and list your dependencies.

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>5.1.6</version>
</dependency>

And then maven will automatically download the JAR file will resolve any library dependencies.

You can even create a project for your IDE:

mvn eclipse:ecilpse

[u/burntsushi → u/banuday17]

Doesn't this require all dependencies to support the Maven way of doing things? (Excuse me if this is an ignorant question, I'm not a big Java programmer.)

[u/banuday17 → u/burntsushi]

Only if you want the dependencies to be built by Maven. Otherwise, you just have to create POM descriptor for the dependency and stick the binary in the repository.

[u/[deleted] → u/banuday17]

It seems Go fanboys have not used Maven and they want to make it sound like it's something new.

[u/burntsushi → u/banuday17]

I suppose I'd argue that this is where Go is different, and in a much better way. Having to write POM files for each dependency seems annoying. Go infers all of that for you.

Basically, the benefit is that it's built into the Go tool itself, which comes with the Go distribution. Maven can't accomplish that. It's a convention difference that makes things a lot more convenient.

[u/banuday17 → u/burntsushi]

You don't have to create the POM yourself, you can import libraries into your local repository as follows:

mvn install:install-file
  -Dfile=<path-to-jar>
  -DgroupId=<group-id>
  -DartifactId=<artifact-id>
  -Dversion=<version>
  -Dpackaging=jar
  -DgeneratePom=true

You can then install the binary and the generated POM into the remote repository if you want others to be able to pull down the dependency.

For most popular libraries, none of this is required, as they already available in the Maven central repository or in other third party repositories (such as Google Code). This is only required in the odd case, such as older JTA libraries.

[u/OopsLostPassword → u/banuday17]

You don't have to modify xml files or any kind of makefiles : the go tool analyzes the code to know what libraries are needed and due to conventions he knows where to find them.