What Go does better than Java and reverse from your experience?

I've started to learn Java mainly because Android development is based on it. I'm not really familliar with it, but I've a c++ background that might give me some ideas. What I'm really looking to know is where I should use Java instead of Go. There's some fields below that I'm interested in and wanna hear your opinions as well: a) Mobile Development b) Web Development c) Games Development d) Scientific Development e) GUI Development f) New field.. If you're familliar with both languages and wanna give me your opinion would be awesome! Note that I'm not looking to switch or give up one language in favor of another, but wanna learn to use them where they fits the best. <hr/>**评论：** shovelpost: <pre>The only things I can think of that Java does better: <ul> <li>Android development (Duh!)</li> <li>Usage in enterprise</li> <li>GUI in their standard library</li> </ul></pre>tetroxid: <pre><ul> <li>Generics</li> </ul></pre>shovelpost: <pre><pre><code>public static <I, O> ListenableFuture<O> chain (ListenableFuture input, Function<? super I, ? extends ListenableFuture<? extends O>> function) </code></pre> <a href="https://youtu.be/5kj5ApnhPAE?t=2m8s">dear god make it stop</a></pre>vorg: <pre>Go would choose a better syntax. For your example Go would choose something like the more readable <pre><code>func [I, O] chain (inp ListenableFuture[I], fn func[I:, :ListenableFuture[:O]]) ListenableFuture[O] </code></pre> to convey the same information. Though of course Go would convey different information, not needing to convey extends and super with prefixed and postfixed colons, for example. If ListenableFuture was defined in a different package, you would have <pre><code>import u "somedir/future" func [I, O] chain (inp u.Listen[I], fn func[I:, :u.Listen[:O]]) u.Listen[O] </code></pre> where short names u, inp, and fn make reading it easier.</pre>VirmundiUndead: <pre>I admit that is noisy, but if you take time, you can tell what that is going to do with just that line. You might need to go see what ListenableFuture is, but that line tells you everything you will need to get more information. You won't need to dive into some internals to see what's what. The strong, noisy typing, provides that info. </pre>sh41: <pre><pre><code>package task // DataᐸTᐳ where T is int. type Dataᐸintᐳ interface { IsCollection() bool GetCollection() CollectionᐸDataᐸintᐳᐳ GetElement() int } // Java's CollectionᐸEᐳ interface (partial). // CollectionᐸEᐳ where E is Dataᐸintᐳ. type CollectionᐸDataᐸintᐳᐳ interface { IsEmpty() bool Iterator() IteratorᐸDataᐸintᐳᐳ Size() int // ... more methods are available in the real Java CollectionᐸEᐳ interface, // see http://docs.oracle.com/javase/7/docs/api/java/util/Collection.html. } </code></pre> <a href="https://github.com/shurcooL/play/blob/9ee6a378d9541f5ef9d36b295915bd0818dfdaa9/103/given.go" rel="nofollow">https://github.com/shurcooL/play/blob/9ee6a378d9541f5ef9d36b295915bd0818dfdaa9/103/given.go</a></pre>xrayfur: <pre>These points are more what Java is rather than what it does. But yeah, good point!</pre>shovelpost: <pre>Yeah very true. I was debating which verb to use actually but then I noticed that each bullet technically needs a different verb so I was like screw this. :P</pre>Alaric101: <pre>It's a minor thing, but it would be nice if there was a way of denoting that a class is an implementation of an interface like Java does.</pre>shazow: <pre>This will assert that someImpl complies with someInterface when you compile: <code>var _ someInterface = (*someImpl)(nil)</code></pre>shovelpost: <pre>That already exists and it's called <a href="https://docs.google.com/document/d/1_Y9xCEMj5S-7rv2ooHpZNH15JgRT5iM742gJkw5LtmQ/edit">Go Guru</a>.</pre>Richy13: <pre>This looks great, hadn't heard of it</pre>saturn_vk: <pre>Yep. Its unfortunate that the go plugin for vscode lacks quite a few things, including that, compared to other plugins (like vim-go). asking for implementations is quite helpful.</pre>comrade-jim: <pre>oh no, you mentioned VSCode in a negative light, here comes the shill team to downvote you (even though everything you said was true). </pre>BubuX: <pre>As a VSCode user that's lazy to thoroughly test other IDEs. What editors have better support for Go than VSCode? I might try them.</pre>Alaric101: <pre>Thanks, I'd never heard of this!</pre>jeremiahs_bullfrog: <pre><blockquote> denoting that a class is an implementation of an interface </blockquote> You mean struct? Go doesn't have classes. I typically see this done in documentation, like "A is a Reader".</pre>sorenmat: <pre>XML with namespaces</pre>shark1337: <pre>Yeah, I was thinking the same. I'm pretty sure that java might handle game development better, Minecraft is a good example here..</pre>thomascgalvin: <pre>From a gaming point of view, having a GUI backed into the standard library is good, and there are a bunch of established third-party libraries that allow you to write OpenGL, so I think Java has a leg up on Go in that department. I would be curious to see how Go's garbage collection compares in a gaming environment, though. I've done some game programming in Java, and I have to be very careful to prevent the garbage collector from running. I wonder if that would be necessary with Go's lower-overhead GC.</pre>PsyWolf: <pre>You mean lower latency. Go achieves such low latency (aka low pause times) at the cost of higher overhead (aka lower throughput). In theory, Java can be configured to use a similar low latency garbage collector like go's, but I don't know how it compares in practice for game development. </pre>edapa: <pre>There is also the fact that typical go programs tend to generate less garbage than idiomatic java doing the same thing.</pre>PsyWolf: <pre>Do you have a source to go with that fact? Legitimately curious.</pre>edapa: <pre>Nothing satisfying, just internet hearsay and the crawling sensation that I get on my skin when I see how many time the word <code>new</code> shows up in a Java program :P. Sorry for spreading vicious rumors.</pre>DeedleFake: <pre>I've had a sneaking suspicion for a while that this is why Java does so well in microbenchmarks but large Java programs always feel terrible. Java's particular OO style seems to lend itself towards horrendous numbers of allocations and context switches in large projects. </pre>carsncode: <pre>And reflection. Java is a perfectly capable language, yet somehow no one can seem to use it without adding at least one or two frameworks that use reflection extensively.</pre>thomascgalvin: <pre>Right, latency. The Java GC is actually swappable, and you can drop in a version that does the "right thing" for your peculiar situation, but I don't have the kind of knowledge required to fuck around with it.</pre>hygutyughugug: <pre>I suggested this for Go awhile back, but it was shot down. Their argument was that it would be more knobs, which created more complexity - they really like to throw that word around. the type of work I was doing at the time didn't have a need for low latency, and needed high throughput, so I brought it up on go-nuts, but it was rejected. Supposedly the complexity wasn't worth the hassle. I would love to build with different gc tailored to specific goals, like throughput over latency. A few programs from that project now suffer a noticeable performance penalty, so much so that they loath rebuilding the programs with new releases. Nothing can be done on our end.</pre>edapa: <pre>The JVM does expose lots of black magic knobs for tuning the GC, but I think you can almost always just fiddle with the target GC pause time and it will mostly do the right thing. The JVM maintainers have tried hard to make GC tuning simpler recently. (Disclaimer, I'm not a java GC wizard, I've just read some stuff written by one).</pre>shovelpost: <pre><blockquote> I'm pretty sure that java might handle game development better, Minecraft is a good example here.. </blockquote> I don't think either Java or Go particularly shine at game development but neither of them have any characteristics that make them totally unsuitable for writing games either. Minecraft is a very special case and I'd argue not a very good example. It could have been written in any language and still be the success it is because... Minecraft. But I am going to agree that Java has the edge in terms of game development over Go. Not only because successful games already exist written in Java but also because Java has better graphics/engine tooling available as well. Also if we think about Android game development in particular, then obviously Java has no competition there.</pre>hygutyughugug: <pre>Show me a game written in Go. Go has nothing on java in regards to game programming. Java still rules the web. I can give hundreds if not thousands of java examples, from web, to android, to native. Biggest mistake Go ever made was focusing on server side programming. If Go had a decent graphics/gui tool kit it would have leaped past java years ago.</pre>shovelpost: <pre><blockquote> Show me a game written in Go. </blockquote> <a href="http://blockbros.net/tsugunai/en/" rel="nofollow">http://blockbros.net/tsugunai/en/</a> <blockquote> Go has nothing on java in regards to game programming. </blockquote> I don't disagree but in my comment I wanted to emphasize that it is the Java ecosystem that has had more years to develop better tooling for games. But as languages they should be pretty much equal when it comes to writing games. And by equal I mean that both languages are not particularly amazing for writing games but they are not totally unsuitable either. <blockquote> If Go had a decent graphics/gui tool kit it would have leaped past java years ago. </blockquote> I agree.</pre>hygutyughugug: <pre><blockquote> <a href="http://blockbros.net/tsugunai/en/" rel="nofollow">http://blockbros.net/tsugunai/en/</a> </blockquote> Seems it is a hybrid game. You get half credit :)</pre>shark1337: <pre>I agree with you, the only language that fits for writting game is c/c++, I don't think I'll be developing games doe..</pre>Redundancy_: <pre>Minecraft was a popular, good game, not necessarily well-engineered. There's also an important distinction between client-side and backend - game clients tend to be written on whatever the platform best supports, and backends often follow suit due to reuse of code. C++ rules the roost in professional AAA circles. That said, I know of multiple large studios using some Go in some form (usually not exclusively).</pre>alasijia: <pre>For web dev, low memory consumption, short startup time duration and no needs to use frameworks.</pre>VirmundiUndead: <pre>I think the no frameworks argument only goes so far. If you start having complex systems, or just want to decouple instantiation, you'll want a DI framework. So then you could create one, wait for some else to create one, or just use Spring. It's fairly light weight now. With spring and JPA, you'll probably get moving fairly quick. Spring and Spring JDBC is probably going to get you farther and faster than Go defaults. </pre>_ak: <pre><blockquote> If you start having complex systems, or just want to decouple instantiation, you'll want a DI framework. </blockquote> Why? I've maintained projects with literally millions SLOCs, and never needed one. Why would I need a DI framework?</pre>VirmundiUndead: <pre>So you can break your layers apart. Say you have a controller layer and a DB layer. If your controller instantiates your DB classes, you're coupled. If you have a constructor for test and a default constructor, you now have two flows. If you use DI, you only have one flow and full decoupling. </pre>lumost: <pre>DI doesn't decouple these layers, it just hides the coupling. The primary difference between the java projects and go projects I've been on has been the number of distinct types in use. Java projects tend to require DI as the type system encourages type proliferation, and longer instantiation chains to go with the resultant types.</pre>VirmundiUndead: <pre>It does decouple the code from the instansiation. If you didn't pass the DB layer in, you'd always have to run tests against the service layer with the DB on. </pre>carsncode: <pre>You don't need a DI framework or IOC container to achieve dependency injection or testable implementations. You can just have to write decent code.</pre>VirmundiUndead: <pre>I didn't say you needed them. I said they are useful. You don't need many of the features of golang, but they are useful. </pre>PsyWolf: <pre>What's so terrible about instantiating your class differently in a test? I don't see how "having two flows" as you put it is a problem. If my normal constructor takes no input, and my test constructor takes a mock db, it's clear and explicit exactly which external dependencies this class has. With a DI framework, it's all implicit and hidden away. No thank you. </pre>VirmundiUndead: <pre>While you're free to do as you wish, DI through constructors balances magic and practicality. Your dependencies are explicit. The magic of exactly how exists. </pre>_ak: <pre>I know what DI is for. But that was not my question. Why would I need a framework for that? Decoupling is just using other objects by behaviour (i.e. interfaces), and having the objects resp. the instantiation function provided from the outside. That's trivial to do yourself without requiring any kind of framework.</pre>alasijia: <pre>"no needs to use frameworks" means I understand every part of my project. I don't like DI, this is another reason I don't like web dev with Java. DI hides too much.</pre>carsncode: <pre>Nothing like reading through a codebase and having no idea what code will actually execute until you flip back and forth between the actual code and the DI wiring, until you give up and just debug execution to see where it goes. DI frameworks turn everything into "and then something mysterious happens".</pre>tmornini: <pre>For me, the things that attract me to Go -vs- Java are: 1) SIMPLICITY 2) Go's CSP style concurrency primitives 3) Tiny, single file executables</pre>AllThatIsMeh: <pre>Same here. From my brief experience with go I love the small footprint of it compared to Java. </pre>the_web_dev: <pre>The big thing for Java is existing libraries and services. Elasticsearch for example is 100% Java and is used by... everybody. There are also a couple B-tier game engines in Java that are probably the best free and open game engines out there. </pre>tech_tuna: <pre>Lucene, which is the underlying engine behind Elastic and just about any other modern and popular search stack, is 100% Java, as are many other big data tools e.g. Hadoop, Cassandra, Spark, Storm, Kafka. That being said, most of the newer DevOps tools are written in Go: Docker, Kubernetes, pretty much all of Hashicorp's tools, etc.</pre>rco8786: <pre>Unless you're a maintainer of ES the fact that it's written in Java is inconsequential. </pre>mallocc: <pre>Java's concurrent collections are stellar. It would be fantastic to have something similar in Go but probably not terribly practical given lack of generics. </pre>VirmundiUndead: <pre>I'm a fan of strong typing. Go lacks generics. When you get a collection it's up to you, the developer, to know what's in it. This works while the code is small. As more layers or users arrive you have start paying attention to it. </pre>jocull: <pre>This is something that frequently gets passed off as "not a big deal" by gophers. But then I see code generation, excess boilerplate, unsafe interface casting, and all sorts of hacks to deal with it. Generics are important for static typing safety reasons. Without them, you're just writing (truths)(interface{})lies.</pre>djhworld: <pre>Java has <ul> <li>Great tooling</li> <li>Great package management and ecosystem, although you can get yourself into a mess if you're not careful </li> <li>Great test libraries, Mockito, Hamcrest etc </li> <li>Great ecosystem, good quality libraries (e.g. Guava, CommonsLang etc) </li> <li>Great dependency injection frameworks (e.g. Guice, Dagger etc) </li> <li>Great logging libraries and pluggable architectures (e.g. SLF4J) </li> <li>Great monitoring features (JMX, JVM visualisation/monitoring/stats etc) </li> <li>Generics if you need them, although you'll probably only really use them for data structures/collections library </li> </ul> Go has the benefit of <ul> <li>Quicker compilation times</li> <li>Less ceremony in getting things going, no need for maven/gradle configuration files etc, no need to learn how Spring works if you're using Spring and wondering where all the magic happens </li> <li>Readable and less boilerplate code</li> <li>Being great for making command line tools that don't suck/require you to write special wrapper scripts </li> <li>Lower memory usage (application dependant....)</li> </ul> For things like "Scientific development" you'll probably find that neither Go or Java are suited, or have suitable community backing - a lot of the scientific programming community seems to have coalesced around Python with things like numpy etc. </pre>carsncode: <pre>For GUI and game development, the support just isn't there yet, though it's not Java's strong suit in general either; better than go for sure but not great. For servers, workers, and command line tools, Go is excellent - easy to work with, easy to deploy, extremely efficient. In the places where Java excels most, Go offers a lot of advantages. It's not perfect, so as always, pick the right tool for the job based on research and experimentation.</pre>Feribg: <pre>Java - big, convoluted language, amazing ecosystem Go - small, concise language (missing some nice stuff like generics), fairly poor ecosystem My 2 cents. For those reasons I typically stick to Java for bigger projects and Go for smaller, fun stuff, or where a lot of concurrency comes in handy.</pre>metamatic: <pre>Things I miss from Java when writing Go: <ol> <li>Parametric polymorphism.</li> <li>The J2SE collection classes.</li> <li>Good logging via a de facto standard API with pluggable backends (SLF4J).</li> <li>Being able to find libraries for everything.</li> </ol> Things I miss from Go when writing Java: <ol> <li>Not needing an IDE.</li> <li>Ease of deployment.</li> <li>Lower resource usage.</li> <li>Easier parallelism.</li> <li>gofmt.</li> </ol> Things I dislike in both: <ol> <li>Ugly date and time handling APIs (at least pre-JSR310).</li> </ol></pre>c10i: <pre><ol> <li>Go has clear separation between data and control logic rather than imposing the OOP-centric paradigm. You don't often see the Builder/Factory/Manager things in Go, which would tend to make the program more complicated and bloated than necessary.</li> <li>Go has value type so composite values can be allocated in stack explicitly.</li> <li>Go generally has smaller memory footprint because of a) no JVM required b) the mentioned in the above 1 and 2 points.</li> <li>The startup time of Go program is shorter. This might be an exclusive problem that only JVM languages have. </li> <li>Go is more readable than Java for various reasons. It's a simpler language after all. And the case-for-visibility is also very consistent among different projects (all Go project actually).</li> <li>Native concurrency primitives. In Go you have the choice to expose a channel to user code. For most other languages, callbacks or virtual function overriding is the only choice. And they are not as elegant and convenient as channels.</li> <li>(If you are a Vim user) Go has exceptionally decent Vim support thanks to vim-go. </li> </ol></pre>redditbanditking: <pre>I used Java professionally for 5 years, was a game developer, before switching to Ruby and now Go doing backend stuff. Here's my opinion: <blockquote> a) Mobile Development </blockquote> Java for Android still stands strong, unless Google decides to make Go compiler for Android. <blockquote> b) Web Development </blockquote> For frontend no. For backend (including backend of your frontend), yes for Go. I have no extensive experience using J2EE, but I would rather deal with Go backend projects. <blockquote> c) Games Development </blockquote> Between Java and Go, Java still triumphs but mainly because it's older and more mature with plenty of game development library out there. If Go community can catch up on this, I would imagine Go could become popular among game developers too due to its similarity to C. <blockquote> d) Scientific Development </blockquote> I would say Java. One thing I have yet seen in Go is a mature graphics library with GUI, which I would like to assume is needed for scientific apps. <blockquote> e) GUI Development </blockquote> See above. What I like about Go that I think is better than Java: <ol> <li>How Go handles concurrency/channels. Java isn't too bad, but Go still does it better.</li> <li>Go interface composition rather than inheritance.</li> <li>Race condition test with the <code>-race</code> tag.</li> <li>Many useful packages that come with the standard Go library, like testing, benchmarking. Other languages typically need an external library to do the job.</li> <li>Single binary, and painless to deploy to servers. Really, if you want to, you could just <code>scp</code> your binary.</li> <li>If you are building a backend server, no need for additional server layer like Apache, nginx, or unicorn. Go is efficient and fast enough to act on its own.</li> </ol> What I dislike about Go, that I think Java handles it better: <ol> <li>Tooling around the language. Even to this date, they are still discussing how to handle project dependencies, even though the language was publicly released 5 years ago.</li> <li>Packages and filenames are loosely defined. It's basically like structuring your C project like Java. Java is more strict in this regard, which yields more consistent structure.</li> <li>Dependency on the open source ecosystem. I don't like how Go forces you to download all your library code. Can't do static linking. Also, import paths must include repository names, like <code>import "github.com/foo/bar"</code>. No relative pathing. If you call your project <code>myfoo</code>, expect to write <code>import "github.com/myname/myfoo/my/sub/pkgs"</code> all over the place, even from within your own <code>myfoo</code> project. This leads to tight coupling between how your project is stored locally, how it's stored remotely, and how it's actually written, which is a big no-no IMO. Forking an OS project lead to a problem as the code will have references to the original source all over the place. People say it's no big deal and the solution is add another <code>git remote</code>, but when the solution to a compile error problem is using <code>git</code>, I find that quite disturbing. And, should you ever decide to rename your project, you'd be changing imports on ALL your files.</li> <li>Go does better than most languages when it comes to enforcing code format and documentation thanks to <code>go fmt</code>, but Java still hands down the best in this game.</li> </ol> TLDR: I like Go better than Java as a language, but the ecosystem and tooling around Go are not quite mature yet.</pre>tgaz: <pre><blockquote> Java for Android still stands strong, unless Google decides to make Go compiler for Android. </blockquote> I thought Go had been available for Android for quite a while: <a href="https://godoc.org/golang.org/x/mobile/cmd/gomobile" rel="nofollow">https://godoc.org/golang.org/x/mobile/cmd/gomobile</a>, <a href="https://github.com/golang/go/wiki/Mobile" rel="nofollow">https://github.com/golang/go/wiki/Mobile</a> Though a year ago, <a href="/r/golang" rel="nofollow">/r/golang</a> said <a href="https://www.reddit.com/r/golang/comments/40d12d/is_gomobile_ready_for_general_application/" rel="nofollow">it wasn't very complete</a>. <blockquote> Also, import paths must include repository names, like <code>import "github.com/foo/bar"</code>. No relative pathing. </blockquote> Does Java do relative imports nowadays? (Since the original question was about comparing the languages.) <blockquote> And, should you ever decide to rename your project, you'd be changing imports on ALL your files. </blockquote> That's true for any Java project that uses more than one package as well (assuming Java still doesn't do relative imports). <code>com.github.foo.bar</code> is pretty similar to <code>github.com/foo/bar</code>. <blockquote> Go does better than most languages when it comes to enforcing code format and documentation thanks to <code>go fmt</code>, but Java still hands down the best in this game. </blockquote> How does Java do it better?</pre>redditbanditking: <pre><blockquote> I thought Go had been available for Android for quite a while: <a href="https://godoc.org/golang.org/x/mobile/cmd/gomobile" rel="nofollow">https://godoc.org/golang.org/x/mobile/cmd/gomobile</a>, <a href="https://github.com/golang/go/wiki/Mobile" rel="nofollow">https://github.com/golang/go/wiki/Mobile</a> Though a year ago, <a href="/r/golang" rel="nofollow">/r/golang</a> said it wasn't very complete. </blockquote> Yeah, I wouldn't call it complete either just because it can compile things for mobile. I mean it makes sense since Android is Linux and Go just natively supports that, but there's a lot more going on on mobile development than just compiling a hello world. <blockquote> Does Java do relative imports nowadays? (Since the original question was about comparing the languages.) </blockquote> There's a misunderstanding what I meant by relative imports. In Go, everything has to be under <code>$GOROOT</code>, which is fine, but so is the import paths. So instead of taking where the current directory is, and add the import paths to it, Go is using the <code>$GOROOT</code> and add the import paths. Java doesn't dictate you where and how you save your project files. <code>com.github.foo.bar</code> can be located in <code>$ANYTHING/myjavaproject/src/com/github/foo/bar</code>, it can be even on your thumb drive, while in Go it must be located in <code>$GOROOT/src/github.com/foo/bar</code>. All Go engineers out there have the same way of storing their Go project files: <code>$GOROOT/src/..</code> Do you see that the <code>src</code> folder in Java comes after the project folder, and in Go it's before? So the way Go is seeing all your projects and dependencies, it's under one big <code>src</code> clumped together. This is why dependency management is a colossal f*up in Go. And to nitpick, while in Java I can use <code>com.whateveriwant</code>, in Go, it has to be where your remote repository is. This is what I meant tight coupling in the way Go works with how you store your project files locally and also how you store it remotely. <blockquote> That's true for any Java project that uses more than one package as well (assuming Java still doesn't do relative imports). com.github.foo.bar is pretty similar to github.com/foo/bar. </blockquote> No it's not. Related above. If I call my Java project <code>testfoo</code> located on <code>/home/redditbanditking/projects/testfoo</code>, I can use <code>com.mycompany</code> as my package name. then I decide to rename <code>testfoo</code> to <code>looksliketherealthingnow</code>, and I don't need to change <code>com.mycompany</code>. Big difference between Java package names and remote repository. In Go, your remote repository is your package name. If let's say Susan is using my library, she does not need to worry about "oh shit, looks like Joe just renamed his repository to looksliketherealthingnow. I have to update my code too then.". Then Cathy is using Susan's code, and "oh shit, looks like Susan changed something, oh no it's Joe doing it." Oh hey, Tim's code is using my library too, but he hasn't been active for a while and hasn't seen my changes. Cathy is unfortunately using both Susan and Tim, and now she's stuck between two versions of my code. This leads to a cascading dependency nightmare. <blockquote> How does Java do it better? </blockquote> Javadoc. This may be my own opinion. I prefer structured format in reading documentation. Don't get me wrong, Go is way better than other languages that most don't even care about formatting and documentation. EDIT: oh btw, want to see an example of this absurdity that's Go package names? Docker has been renamed to Moby. Their <a href="https://github.com/docker/docker" rel="nofollow">https://github.com/docker/docker</a> is a redirect to <a href="https://github.com/moby/moby" rel="nofollow">https://github.com/moby/moby</a>. Every. Single. Go project out there that is using <code>github.com/docker/docker</code> is relying on the fact that github.com does a redirect. Once this redirect stops working, it will all turn into chaos.</pre>tgaz: <pre><blockquote> then I decide to rename testfoo to looksliketherealthingnow </blockquote> Ah, yes, if you're talking about <code>GOROOT</code> rather than package name, agreed. I would like to draw parallels to what e.g. Maven does in terms of (more or less) dictating a directory structure, but I don't know if people use other tools now. <blockquote> Javadoc </blockquote> Thanks for the example. I definitely agree godoc is harder to read.</pre>goomba_gibbon: <pre><a href="http://i.imgur.com/iE1spq1.jpg" rel="nofollow">http://i.imgur.com/iE1spq1.jpg</a></pre>sheepiroth: <pre>One thing java does better: <code>/com/foobar/java/android/project/app/android/src/foobar/Foobar.java</code> but in all seriousness, I use go A LOT for very simple portable components that require like ~200 lines of code. No JVM required, everything compiled into a portable blob, it's like a dream come true for microservices. That isn't to say go can't be used for big projects or that Java should never be used for small components. I find that a huge strength of go is how it appears and feels simple and intuitive because of the amazing breadth of the standard library in go. Java has its own advantages that have been covered elsewhere in the thread, the most important in my opinion being the maturity and network effect some of its libraries come with. There isn't much that can replace a long history of a community of talented individuals contributing code and knowledge to a project.</pre>toula_from_fat_pizza: <pre>Java garbage collection is possibly the worst thing I have encountered in all my years of development.</pre>pinpinbo: <pre>There's one small thing that bugs me about Java. Why am I not allowed to use regular function and closure? Why does everything has to be an object? This changed slightly since Java 8's lambda is introduced, but it is not a true closure.</pre>hygutyughugug: <pre>java can do them all. people cry about its verbosity but 20 years of java programming has made it a non-issue for me. Go can do most of those(with the right bindings). I can easily find work in java. Go is a bit tougher. With Go I have a hard time finding work outside of the bay, or new york, or denver areas. However, my highest paying project to date was done in Go. Clearly, java has the edge, and will for some time. Edit: it is okay, down vote the factual but unflattering comment without retort.</pre>thomascgalvin: <pre>I think Java's package management is better than any major programming language out there. Maven can be a pain in the ass to work with sometimes, but it makes pretty much anything you want to do in regards to packaging at least possible. <code>go get</code> is super simple, but the fact that it requires all code to be backwards compatible forever is just ... dumb. Reproducible builds are super important in large scale applications, and that's impossible when your packaging tool just grabs <code>latest</code>. I cannot fathom when semver wasn't the default from day one. <a href="https://github.com/golang/dep" rel="nofollow"><code>dep</code></a> should fix a lot of this. On the other hand, Java's habit of littering your filesystem with JARs is a pain in the ass, and the fact that when a go build is done you can just say "here's your executable" is really nice. Trying to build a "double click to run this program" in Java is vastly more complicated than it needs to be, especially is one of your libraries has had fuckery performed on its manifest file.</pre>google_you: <pre>Go is old Java, simple, no generics, has garbage collection. It's better at brining nostalgia than modern Java.</pre>karma_vacuum123: <pre>Java actually makes use of its interface feature The Go SDK has very few interesting and useful interface definitions...it's almost as if the SDK developers don't have much use for interfaces at all beyond <code>io</code> Also, Java has real attributes so it doesn't need out-of-language hacks like structure tags</pre>carsncode: <pre>Given the way that interfaces work in Go, having a bunch of interfaces in the standard library is unnecessary. If you want to refer to something I'm the standard library by an interface, you can just write the interface you need and the standard library implements it implicitly. Struct tags aren't hacks, they're part of the language, so I'm not really sure what you mean there.</pre>snippet2: <pre>Yeah I had a guy say defer is a hack too. Idk where this"hack" thing is on the web but apparently they have access to it lol. Another thing people forget about generics is that it's where a language draws a line in the sand for versioning. They like never worked in a company that uses them on a project that has to always be updated.</pre>karma_vacuum123: <pre>the fact that struct tags are strings is in the spec what is IN the tags themselves is not in the spec. many libs inject arbitrary instructions into tags. as for having more interfaces in the SDK...of course not required, but would help focus the community. don't you think <code>io.Reader</code> is valuable?</pre>carsncode: <pre>That's true, what's in tags isn't in the spec, it's a language feature. The entire value is that you can use it as you see fit. What's in a struct or a string or a function isn't in the spec either, you can put whatever you need to into them to suit your purposes. That's the whole point of a programming language. The interfaces in the standard library are certainly useful, and I never suggested they aren't. I only said there is no reason to have extra interfaces, because you can define your own and use them with standard library types with Go's implicit interface implementation.</pre>

用户登录

今日阅读排行

一周阅读排行

最新主题