15 ms·

Java SE and a fat jar... checks all the boxes and has generics and superior tooling. I still don't get the Go love.

• taf2 11y ago
  Go starts very fast compared to jvm. Go compiles into a binary that does not require a jvm to be installed... Go does not require an IDE to develop in... Go is also less verbose
  • cgh 11y ago
    1. Not an issue for web services, which is what the OP was referring to. 2. See #1. 3. Neither does Java, although of course it can be helpful. 4. Error handling is certainly not less verbose. None of the above overcome the lack of tooling, libraries and generics, at least for me.
  • fomojola 11y ago
    Java doesn't require an IDE either: emacs/Ant/Maven is all I've ever used. Barring specialized platform-specific toolsets (like Android Studio) you don't NEED anything else (you might WANT something else, but that's a separate issue...)
    • xiaoma 11y ago
      emacs is an IDE wrapped inside half an OS
      • Cyph0n 11y ago
        Whoops, seems like you pissed some people off :D
      • AnimalMuppet 11y ago
        Don't forget the psychotherapist!
      • znpy 11y ago
        I would like people that keep saying stupid stuff like this to try and compare the size of GNU Emacs to the size of, say, NetBeans, Eclipse or Visual Studio. There is an enormous amount of stuff that "conventional" IDEs to and emacs does not do. Consider NetBeans: there are a lot of people that use the NetBeans platform to create stuff that have nothing to do with programming, the very same way emacs users create modes that have nothing to do with programming: https://platform.netbeans.org/screenshots.html https://platform.netbeans.org/screenshots.html Seriously guys, grow the fk up.
        • xiaoma 11y ago
          I'll set your less civil commentary to one side and simply ask this: In what programming language could Emacs possibly not be feasible option for a seasoned Emacs user?
          • tokenizerrr 11y ago
            Anything that there aren't plugins for. Same as for Netbeans, Eclipse, IntelliJ, and yes, even notepad. They're all just glorified text editors with plugin/scripting support.
    • abc_lisper 11y ago
      Either you are very good, or you are working on small projects. Can't say which! Java is 100-ton dinosaur to be working with using a simple editor. Spring, it dependencies, hibernate, junit alone make you want to work with an IDE.
      • groovy2shoes 11y ago
        I once wrote a forest fire simulator based on a cellular automaton in Java using nothing but a terminal and Leafpad. It's doable, I promise.
        • abc_lisper 11y ago
          Yeah, I can believe that. However webapps(in your average startup) are far more complex, in the tools, libraries they use.
    • placeybordeaux 11y ago
      I try to use CLI editors for everything (for me it's vim, but lets not make that a big deal :P), but I have never been successful in doing so with java.
  • pjmlp 11y ago
    > Go compiles into a binary that does not require a jvm to be installed. Java also does not need a JVM to installed. 1 - Use a fat jar 2 - Use the upcoming Java 9 linker which bundles everything together 3 - Spend some money and get a commercial JDK with AOT compilation to native code. All the major ones support it. 4 - Eventually Java 10 Oracle JDK will support AOT compilation to native code, but it remains to be seen if will remain commercial only
• mtrn 11y ago
  I am reading and writing Go and Java almost daily. Java has a tendency to be written in an over-engineered way. The Go community has an inclination towards cautious abstractions. Take interfaces. In Java you might start with them. In Go - in the best case - they emerge, when it's time for them. Java has more mature tooling, but then, I cannot remember gathering runtime insights with Java quicker than with Go pprof[1]. Java is rock solid and more and more libraries are written in lightweight and clean way. Go has more momentum and also a growing number of curious users, who explore the language in creative ways[2]. [1] Google image search for "go pprof": https://goo.gl/6l7t1b https://goo.gl/6l7t1b [2] Just discovered this amazing guy recently, https://github.com/fogleman/ln https://github.com/fogleman/ln, https://github.com/fogleman/nes https://github.com/fogleman/nes
  • jerf 11y ago
    "Take interfaces. In Java you might start with them. In Go - in the best case - they emerge, when it's time for them." And it's a relatively subtle language feature that does this, the way that any struct that implements a given interface automatically conforms to that interface without having to be declared. Which means you can declare an interface that foreign packages already conform to, and then freely use them. Which means that you can code freely with concrete structs to start with, and then trivially drop in interfaces to your code later, without having to go modify any other packages, which you may not even own. I completely agree that on paper Java and Go look virtually identical. But the compounding effect of all those little differences makes them substantially different to work with. Good Go code does not look like good Java code. You'd never confuse them.
    • kasey_junk 11y ago
      There is a big downside to structural typing as golang implements it though. Refactoring tools. They quite simply cannot do the same kinds of safe refactoring something like a Java refactoring tool can do, because you can't be sure if the function you are trying to rename, add parameter too, etc. is actually the same function in question. There are times when I love the structural typing aspects of golang (trivial dependency inversion) and there are times when I hate it (nontrivial renames), its one of many trade-offs you have to be prepared for in golang.
• geodel 11y ago
  I have hundreds of jar in my Java project. I am not even sure which one are used. How does Java handle this scenario?
  • kasey_junk 11y ago
    Depends on your build system. In maven http://maven.apache.org/plugins/maven-dependency-plugin/ http://maven.apache.org/plugins/maven-dependency-plugin/ is the way to go.
  • Nullabillity 11y ago
    If you use Maven/Ivy then your transitive dependencies are automatically managed based on your direct dependencies. If you don't, or if that's not enough, use ProGuard to get rid of all the classes that you aren't actually using.
• sinatra 11y ago
  Yes, I'd say modern Java is a good candidate too. However, the verbosity is a deal-killer for me. Go's error handling can be verbose, but while scanning the code, if I want/need to, I can easily skip through the error handling parts mentally. Java, though, is verbose everywhere. EDIT: Actually mtrn said it better: Java feels over-engineered.
  • meddlepal 11y ago
    Okay, ditch Java if it's too verbose and adopt one of Kotlin, Groovy (w/ @CompileStatic) or Scala.
    • jimbokun 11y ago
      Or Clojure.
    • vorg 11y ago
      > adopt one of Kotlin, Groovy (w/ @CompileStatic) or Scala Scala's the only one of these three languages with any adoption right now. Groovy is virtually only used in its original dynamic mode from 2003 for things like scripting and Gradle build files, and very few people use the @CompileStatic mode introduced in 2012. Kotlin 1.0 has just been released, was subjected to stringent QA, and I expect JetBrains to use it more and more in its own products like IntelliJ, so it's a good bet it will become more popular with developers. So I'd say use Scala and Kotlin if you need static typing. Clojure, though it doesn't have static typing, has other features like syntactic macros for terseness, default immutability, and concurrency that would recommend it in many situations.
    • pjmlp 11y ago
      I would forget about Groovy and focus in Scala, Clojure, Kotlin instead. Here in Germany you almost don't hear about Groovy anymore in any JUG event. If it wasn't for Gradle and Android adopting Gradle, I bet we would hear even less about it.
    • jug 11y ago
      I've heard complaints about Scala and binary compatibility often breaking, and it remains to be seen if Kotlin will even be successful enough to catch on.
• bsg75 11y ago
  When different code needs different JVMs, it gets to be a pain. The Go advantage is a fat binary, no dependencies.
  • meddlepal 11y ago
    Embed the JRE then. You have to build packages for each platform you want to support, but that's no different than Go. Besides that, different JVM's? Very rarely does code depend on a specific JRE unless we're talking between versions (say 7 vs. 8), but you would have the same problem in Go if significant language changes were made between releases.
  • twistedpair 11y ago
    > When different code needs different JVMs With the JVM you can use HotSpot, Dalvik, WebSphere, or OpenJDK. The JVM is just a spec. With Go, you've only got one runtime to choose from. That said, if you code to the JVM spec, then you don't care what implementation you run on.
    • loudmax 11y ago
      > With Go, you've only got one runtime to choose from. Since Go compiles to a binary, the concept of a runtime doesn't apply the same way it does for Java. You can compile a Go program with the Go project's compiler or with the GCC. The GCC Go compiler uses different optimizations and may produce faster binaries in some circumstances. Since the Go language is also a spec, other compilers may arise if there's a demand.
      • twistedpair 11y ago
        Correct. With Java I've got at least 4 compilers (JDK's) to choose from.
• bmurphy1976 11y ago
  You don't have to "get" anything. If Java works for you, great!! Go just works better for some of us, and that's all the justification we need.
  • Myrmornis 11y ago
    This type of comment is common, but specious. It sounds nice: "what works for you; great! this works for me" but it undermines a large category of important discussions: e.g. analyzing which, out of several competing discussions, is a better fit for large classes of people, or on average. In other words, I think this sort of comment strays too far in the direction of niceness, and tends to undermine simple, and desirable, notions of better vs. worse, etc. TL;DR being nice and polite is over-rated. Some things are wrong and it is helpful to say so.
    • bmurphy1976 11y ago
      > TL;DR being nice and polite is over-rated. Some things are wrong and it is helpful to say so. And thus continues the never ending cycle of "You're wrong! No you're wrong!"
      • krylon 11y ago
        The problem, I think, or at least part of the problem, is that it is hard to discuss the relative merits and problems of languages (frameworks, operating systems, ...) without feeling like somebody is trying to push his/her favorite piece of tech on somebody else. If we discuss what e.g. Java does better than Go and vice versa for purely technical interest, there is little emotional pressure. But if I feel that somebody is trying to make me use Java (or Rust, or C++, or Visual Basic) over whatever I prefer and feel comfortable with, I get defensive. When people get defensive, they become unwilling to admit shortcoming in their preferred language/framework/OS/..., and so the debate devolves into "You're wrong! - No, you're wrong!" and namecalling.
        • bmurphy1976 11y ago
• autoreleasepool 11y ago
  I don't like Oracle. I don't like the JVM. I refuse to learn Java because I personally have a strong bias for native, compiled code. In fact, I really dislike everything about the Java way of programming. The mental image of a huge ram sucking IDE with code completion for frameworks is simply incompatible with what I would consider the ideal creative process for me as programmer. That being said, if I were starting a web service as a business today, it would be very hard to persuade me to not choose Java. It's simply the best platform from a business perspective. For better or worse, CS departments across the US produce Java programmers more than anything else. This makes it very easy to hire Java developers. Java has stability, Java has concurrency, Java has hot reloading, Java has a good track record, Java scales, Java has really nice functional programming support, and Java is very popular with the everyday programmer. It Java has so many benefits outside of it's technical or philosophical specifications, that it's almost an obvious choice to me for web. What's funny is that Erlang is the ideal platform for me from an idealist perspective, but I don't think I have the luck or experience it takes to successfully start an internet company with Erlang.
  • deleted 11y ago
    [deleted]
  • deleted 11y ago
    [deleted]
  • johan_larson 11y ago
    For my money, Java is a pretty good language; there are only a couple of things that I think were real mistakes in the core language. And the JVM certainly performs. But the ecosystem around Java is very complex and hard to manage. Dealing with JVM configuration, webserver configuration, build system configuration, IDE configuration and God knows what else takes up all kinds of brain-space. And every so often the community goes off on some crusade. Everything must be Design Patterns. Everything must be specified in XML. Everything must be a Bean. No, everything must be Injection. No, no, everything must be Annotation. The Java culture really needs to learn the value of the simple and explicit.
    • 11y ago
• duaneb 11y ago
  Green threads are awkward to express with the JVM threading/memory/io model. The runtime is massive (contrasting to the go model of statically linking deployment binaries). Some semantics (such as unsigned 64-bit integers) are difficult to express. Java's JNI is a PITA. I don't believe go's c bindings are much better, but the JVM definitely has its sore points. Finally, the object-oriented nature of the JVM is sometimes a pain. This can be worked around, but there is something to be said for preferring the typing of Go.
  • alblue 11y ago
    FWIW there have been methods added to the Math class that perform math operations on unsigned integers, allowing a Java int to be treated as an unsigned int (cf long). In addition there have been other libraries such as JFFR and JNA that make it more sane to inter operate with C libraries in a much less painful way. There's even a future enhancement request to add this info a future release of Java.
    • duaneb 11y ago
      Yea, I wouldn't read my above list as a list of roadblocks. The JVM is a serious work horse and every year the list of complaints I have shrinks. Go certainly has its own problems as well, and the performance profiles that pain java are probably not going to fare much better under Go. The major win is probably goroutines.
      • kasey_junk 11y ago
        It's not even goroutines. Its the scheduler. I am continuously impressed by the amount of quasi-generic performance they can get out of something so simple. You can understand the entirety of the golang scheduler in minutes, and it works out of the box for most of my golang use cases. That said, the JVM scheduling is pluggable, so I have options for a much bigger variety of use cases. With go if the default scheduler doesn't do what I want, I'm stuck.
  • Manishearth 11y ago
    FWIW: https://github.com/kilim/kilim https://github.com/kilim/kilim
• kasey_junk 11y ago
  There are less options in golang so its easier to get started or to jump into the middle of a project. For certain classes of problems the golang standard library is dramatically better than the java ones so you don't have to spend as much energy researching alternatives. It tends to perform well by default for web service and/or cli applications. Compared to java it is more terse (though not compared to some jvm alternate languages, but that is a whole different barrel of fish). The TLS stack in golang is finicky but I trust it. And gofmt. No really, the best part of golang is gofmt. For those benefits you trade off vs the jvm a) abysmal tooling b) extremely primitive concurrency support c) a more primitive type system and d) a much smaller ecosystem. I very much like golang for 2 classes of problem 1) http/s based microservices and 2) command line programs that are a touch more complex than bash. I would never choose golang for a system that I thought was going to have a high LoC count or had a complex domain to model.
  • cdelsolar 11y ago
    abysmal tooling? ... extremely primitive concurrency support?? Are you talking about Go?
    • tptacek 11y ago
      No fully-functional debugger. Minimal instrumentation. No good code transformation or refactoring tools. No concurrent data structures.
    • mahmoudimus 11y ago
      It is pretty much an undisputed fact that modern Java tooling beats mostly everything else out there for any other language. If you're coming from a more modern JVM background, yes, the first thing I have felt was that most plang tooling is abysmal ... relative to the JVM.
• lobster_johnson 11y ago
  For me, I like Go's slim profile. Native compilation, aggressive allocation, low memory usage, static compilation. JVM suffers from slow startup times and tends to eat a lot of RAM, even when the app doesn't technically need it around. It has an object model that spawns a bazillion tiny objects, and much of the JVM's GC design exists to cancel out those tiny object allocations. JVM has many upsides (the portability and pluggable nature of JAR files is a huge one), but I think a lot of people are attracted to Go's bare-bones approach. Closer to the metal, a "better C", smaller overhead.
  • jdcarr 11y ago
    What's your use cases where you've found startup time to be a significant issue?
    • lobster_johnson 11y ago
      Command-line programs.
    • kasey_junk 11y ago
      Long running processes without a lot of events can also deal with "startup issues", in that they won't trigger JIT.
      • pjmlp 11y ago
        You can set the JIT threshold to 0, then it will JIT the full bytecode on startup, but it might perform worse.
    • jahewson 11y ago
      Short-lived processes are an issue, because while startup time can be ok, code won't perform well until it's hot enough to be JITed.
      • pjmlp 11y ago
        You can set the JIT threshold to 0, assuming the impact would still be worthwhile. The alternative is a commercial JDK, almost all of them do support AOT compilation.
• vidoc 11y ago
  Java doesn't exactly check the box of a community that prefers the use of standard libraries for most work. Java community is all about Frameworks with a Big, MVC, F where you need only 200 lines of code and XML for an hello world :P
• zphds 11y ago
  The JVM is awesome. Not a big fan of Java as a language. The 'less is more' is lost on most Java programmers I know of. Golang fits in nicely in such cases. If I want the JVM, I rather build a clojure'ified uberjar.
• fixxer 11y ago
  Depends on the usecase. I deal with java in the hadoop/big data space and I constantly wonder how much better the ecosystem would have been had it been implemented in a solid systems language. I also find the tooling for go vastly superior out of the box compared to what i end up using with java/Scala. XML?! Wtf?!
• jbeja 11y ago
  Thank you, I don't get it neither. The delusion in this thread is hard to believe.
• aacanakin 11y ago
  Please watch this. https://www.youtube.com/watch?v=5kj5ApnhPAE https://www.youtube.com/watch?v=5kj5ApnhPAE
• matt_wulfeck 11y ago
  If I may also chime in with one idea as to why someone might prefer Go: Java simply is not opinionated enough. Compare two developers Java code and it looks, flows, feels completely different. Go forces people more into boxes and leaves a lot less up to discussion. This is annoying for the individual contributor, but I believe is a net plus for a team of contributors.
• thebaer 11y ago
  Java also can't beat Go's concise syntax. Even compared to writing in IntelliJ, an awesome IDE for saving keystrokes, I relish the simplicity and brevity of Go code.
  • prodigal_erik 11y ago
    How can Go be concise when you can't do f(g(x)) without two if-statements to check for errors?
    • eggnet 11y ago
      Couldn't f check for g's errors?
      • kasey_junk 11y ago
        No because you can't easily pass multiple return values as parameters. So annoying...
        • thebaer 11y ago
          Actually you can: https://play.golang.org/p/a-qhe_vRvo https://play.golang.org/p/a-qhe_vRvo
          • kasey_junk 11y ago
            Oh my god...is that new? I swear I've tried that and it didn't work. You are my new hero. [edit] Though maybe I was thinking of adding parameters like https://play.golang.org/p/FKUMlQzCI5 https://play.golang.org/p/FKUMlQzCI5 In any case 'thebaer continues to be my hero.
            • thebaer 11y ago
              Haha, I'll take it. Go forth and wield your new power! I'm not able to find anywhere official documenting it, but yeah I don't believe it's new. Edit: prodigal_erik found it: https://golang.org/ref/spec#Calls https://golang.org/ref/spec#Calls
• fithisux 11y ago
  You don't have too.
• omginternets 11y ago
  Setting up a Java ecosystem is an enormous pain in the ass, and the language is anything but simple/minimal. Much of the Go love comes from doing (almost) everything Java does with a lower cognitive load... and goroutines are really useful, too.
• farawayea 11y ago
  Oh, wait, Java 7 is no longer the one you need, you've got to use Java 8 because nobody uses 7 now. BAM, not so easy any more.