3 ms·

There are legitimate reasons to chose Go over Java, starting with the build system and the amount of effort needed to produce a single binary. I use Java for 20

There are legitimate reasons to chose Go over Java, starting with the build system and the amount of effort needed to produce a single binary. I use Java for 20 years and Go for ~2. I am not actively hating Java but I value my time, specially that was wasted on maven + co.

DrScientist 3y ago
Maven isn't Java. I've used java for over 20 years and managed to almost completely avoid it. As with npm - I think automatic dependency management at the library level pulls in far too much of the world - most of which your code doesn't actually depend on because the one function you need in lib A, doesn't actually require lib B, and therefore lib B dependencies C&D etc etc etc. Madness. If you do dependency management at the source level ( using the compiler.... ) then life is generally much simpler ( reflection being the only aspect you need to manage ).
- datadeft 3y ago
  > Maven isn't Java. The wheels aren't the car. Sure, try to drive around without wheels.
  - peterashford 3y ago
    I've used Java since it came out and I have never used Maven
  - DrScientist 3y ago
    In my experience using Maven is like driving around with a set of powerful magnets tied to the back with string. You gradually pull in more and more c*p.
- za3faran 3y ago
  Could you elaborate on what you mean by "dependency management at the source level"? Do you mean manual JAR inclusions into the project?
  - DrScientist 3y ago
    The key thing to remember is the transitive nightmare of dependencies that you let Maven manage is largely created by the way Maven works! So if you don't do it that way, just you need to manage the dependencies yourself, but they are much much simplier! In a bit more detail - at the top of your source code is: import someorg.somepackge.class; If you have the source code for someorg.somepackage in your sourcepath/classpath ( and the source of any transitive dependencies ) then the compiler will magically find all the transitive dependencies for class at the class level at compile time. [1] This results in the minimal number of classes you have to ship and as a result the minimal number of transitive dependencies. Now your build tool/script ( whatever tool you use ) will need to bring in those dependencies from a versions repo somewhere - but that can be your own source code repo ( vendoring I think it's called ). Yes - you need need to keep that build config yourself - but frankly that's time well spent as it results in you have proper control over your dependencies, and they don't balloon out of control. Occasions like some random third party has added dependency D to C which is brought in via an A->B->C chain and then you have some library version clash are much much less as a result. That's not to say I don't occasionally use jar files in the classpath - but that's typically only if that library is self contained, single focus and small - and again you can put that in your build script. In my view, Maven magic is part of the problem, not a solution - and to sum up why - it hides the cost of the dependencies - if people had to manually add the chain of true dependencies when they decided to use a apache utility class, they might think twice about whether that chain of dependencies is well designed or not. [1] With the reflection proviso I mentioned above.
lenkite 3y ago
"..and the amount of effort needed to produce a single binary." A couple of minutes ? Even timed this with another HN Java disbeliever who said its too much effort.
- datadeft 3y ago
  I understand that you mastered producing a single binary with your favorite build tool. In my experience if a language does not have an official way to build projects it does end well. Go, Rust and Zig are the prime example that a language should not be separated from its build system. How to produce a single binary: go build cargo build zig build <project> ... <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <version>3.4.1</version> <executions> <execution> <phase>package</phase> <goals> <goal>shade</goal> </goals> <configuration> <artifactSet> <excludes> <exclude>classworlds:classworlds</exclude> <exclude>junit:junit</exclude> <exclude>jmock:*</exclude> <exclude>*:xml-apis</exclude> <exclude>org.apache.maven:lib:tests</exclude> <exclude>log4j:log4j:jar:</exclude> </excludes> </artifactSet> </configuration> </execution> </executions> </plugin> </plugins> </build> ... </project> Can you spot the difference?
  - lenkite 3y ago
    I would like to point out that the language compiler in Rust (rustc) is certainly separated from its modular build system (cargo). Also, how so wonderfully and utterly balanced of you to give an old-school Maven pom.xml file with the maven-shade-plugin and exclusion lists, but omit the Cargo.toml and go.mod files. Also, its as simple in Java as: Gradlefile: apply plugin: 'java' command: gradle build Can you spot the difference ? EDIT: Ok you were asking about creating single all-in-one fatjar ? Add the below to your Gradlefile: Gradlefile: plugins { id 'com.github.johnrengelman.shadow' version '8.1.1' } apply plugin: 'com.github.johnrengelman.shadow' command: gradle shadowJar

DrScientist 3y ago

Maven isn't Java. I've used java for over 20 years and managed to almost completely avoid it. As with npm - I think automatic dependency management at the library level pulls in far too much of the world - most of which your code doesn't actually depend on because the one function you need in lib A, doesn't actually require lib B, and therefore lib B dependencies C&D etc etc etc. Madness. If you do dependency management at the source level ( using the compiler.... ) then life is generally much simpler ( reflection being the only aspect you need to manage ).

datadeft 3y ago
> Maven isn't Java. The wheels aren't the car. Sure, try to drive around without wheels.
- peterashford 3y ago
  I've used Java since it came out and I have never used Maven
- DrScientist 3y ago
  In my experience using Maven is like driving around with a set of powerful magnets tied to the back with string. You gradually pull in more and more c*p.
za3faran 3y ago
Could you elaborate on what you mean by "dependency management at the source level"? Do you mean manual JAR inclusions into the project?
- DrScientist 3y ago
  The key thing to remember is the transitive nightmare of dependencies that you let Maven manage is largely created by the way Maven works! So if you don't do it that way, just you need to manage the dependencies yourself, but they are much much simplier! In a bit more detail - at the top of your source code is: import someorg.somepackge.class; If you have the source code for someorg.somepackage in your sourcepath/classpath ( and the source of any transitive dependencies ) then the compiler will magically find all the transitive dependencies for class at the class level at compile time. [1] This results in the minimal number of classes you have to ship and as a result the minimal number of transitive dependencies. Now your build tool/script ( whatever tool you use ) will need to bring in those dependencies from a versions repo somewhere - but that can be your own source code repo ( vendoring I think it's called ). Yes - you need need to keep that build config yourself - but frankly that's time well spent as it results in you have proper control over your dependencies, and they don't balloon out of control. Occasions like some random third party has added dependency D to C which is brought in via an A->B->C chain and then you have some library version clash are much much less as a result. That's not to say I don't occasionally use jar files in the classpath - but that's typically only if that library is self contained, single focus and small - and again you can put that in your build script. In my view, Maven magic is part of the problem, not a solution - and to sum up why - it hides the cost of the dependencies - if people had to manually add the chain of true dependencies when they decided to use a apache utility class, they might think twice about whether that chain of dependencies is well designed or not. [1] With the reflection proviso I mentioned above.

lenkite 3y ago

"..and the amount of effort needed to produce a single binary." A couple of minutes ? Even timed this with another HN Java disbeliever who said its too much effort.

datadeft 3y ago
I understand that you mastered producing a single binary with your favorite build tool. In my experience if a language does not have an official way to build projects it does end well. Go, Rust and Zig are the prime example that a language should not be separated from its build system. How to produce a single binary: go build cargo build zig build <project> ... <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <version>3.4.1</version> <executions> <execution> <phase>package</phase> <goals> <goal>shade</goal> </goals> <configuration> <artifactSet> <excludes> <exclude>classworlds:classworlds</exclude> <exclude>junit:junit</exclude> <exclude>jmock:*</exclude> <exclude>*:xml-apis</exclude> <exclude>org.apache.maven:lib:tests</exclude> <exclude>log4j:log4j:jar:</exclude> </excludes> </artifactSet> </configuration> </execution> </executions> </plugin> </plugins> </build> ... </project> Can you spot the difference?
- lenkite 3y ago
  I would like to point out that the language compiler in Rust (rustc) is certainly separated from its modular build system (cargo). Also, how so wonderfully and utterly balanced of you to give an old-school Maven pom.xml file with the maven-shade-plugin and exclusion lists, but omit the Cargo.toml and go.mod files. Also, its as simple in Java as: Gradlefile: apply plugin: 'java' command: gradle build Can you spot the difference ? EDIT: Ok you were asking about creating single all-in-one fatjar ? Add the below to your Gradlefile: Gradlefile: plugins { id 'com.github.johnrengelman.shadow' version '8.1.1' } apply plugin: 'com.github.johnrengelman.shadow' command: gradle shadowJar