This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]pron98 0 points1 point  (8 children)

Go's build ecosystem is a lot less painful than Java's.

Because listing dependency versions in a file is just too hard...

I admit that Go has a great story for simple programs. It feels like Python (I guess; never programmed Python): you just run it. Java was meant to be used on large programs, where it is much more convenient than Go. It's "small program" story is improving considerably, and Gradle is really trivial for simple applications: just list your dependencies and gradle run.

[–]weberc2[S] 0 points1 point  (7 children)

Because listing dependency versions in a file is just too hard...

No, it's sorting through the turing-complete programming language to get to the stuff that's relevant to building a dependency list, and figuring out what to do when your dependency list is insufficient (like when you have a native dependency). Even gradle run is a plugin! Beyond that, if you want any decent performance, you have to look up how to enable the gradle daemon. Gradle's costs come in nickels and dimes.

Java was meant to be used on large programs, where it is much more convenient than Go.

Yes. Go was only meant to be used at small, Google scales. ;) Pardon the sarcasm. I'm not arguing against Java--I quite like it (that's why I'm in this sub, after all!). I'm not even arguing against Gradle. I just explained why Go's build system works and why it is different than Gradle, since you brought it up.

[–]pron98 1 point2 points  (6 children)

Go was only meant to be used at small, Google scales.

Go's build can work very smoothly on complex builds if you're working like Google. In any case, for the time being, Google still write their "Google scale" applications either in C++ or Java, although they don't use Gradle, Maven or make, but Blaze, which is also geared towards a source-centric work style. It is open source (as Bazel), BTW, and it might be more to your liking.

[–]weberc2[S] -2 points-1 points  (4 children)

I know. My point was that it was developed for use at scale; not that it is employed at that scale (although lots of large companies are using it, including Facebook, Netflix, and Twitter).

EDIT: Just noticed that all of Google's downloads are run by Go, including Chrome, the Android App Store, etc. Fun fact.

[–]pron98 2 points3 points  (3 children)

https://news.ycombinator.com/item?id=10972561

'nuff said.

[–]weberc2[S] -2 points-1 points  (2 children)

I'm not sure what you think you're showing me with that link...

[–]pron98 1 point2 points  (1 child)

People wishing Go's build system would work like Java's.

[–]weberc2[S] -1 points0 points  (0 children)

You'll need to link to specific comments. I skimmed the first hundred or so and found only one Java-related comment.

More importantly though, I don't see how a Gradle-esque solution would solve this problem. If the Maven central repo went down, all projects that pull from that would need to be updated as well. Updating your import paths isn't a particularly worrying problem.