Hacker News new | past | comments | ask | show | jobs | submit login

Java SE and a fat jar... checks all the boxes and has generics and superior tooling.

I still don't get the Go love.




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.


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.


> 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.

You couldn't have described this better for me. This is my exact frustration with the ecosystem, and it's the only thing that keeps me from using Java as my default language of choice. The language itself can be used very well, just wish the tooling was more concise and functional.


Just wait when Go EE becomes a thing.

Then you will get testing frameworks, libraries each with its own generics workaround and cool interface spaghetti that looks beautiful in UML diagrams at the scrum wall room.

People don't really get that before Java there was C EE and C++ EE, all with similar sins.

One can change the language of the enterprise, but not what those architects do with them.


I fear you are right. Go's simplicity, its pattern of having one and only one way of doing anything, is likely a product of its youth and unpopularity. As the years pass and its following grows, people will come along who want to do things differently, and the ecosystem will become richer but also more confusing.

Perhaps the best thing for the language would be for it not to become too popular.


Avoid success at all cost.

-- Haskell


It should be read:

Avoid (success at all cost)

Rather than what you might be (others do at least) implying:

(Avoid success at all cost)


> JVM configuration

This is the mother of all premature optimization. Other than maybe modifying heap size or setting client vs. server, most of the default JVM configurations work for almost everything.

> build system configuration

I actually find maven pretty easy to use, but maybe it's just that I am used to it.

> IDE configuration

I don't know what crazy IDE you are using, but both Intellij and Netbeans need very little, if any, configuration out of the box.

> [Java] community goes off on some crusade

As opposed to everyone else? /s


To combine the JVM configuration and IDE configuration points, out of the box on a new 16GB Macbook Pro Retina, Intellij (at least, as PHPStorm) will spend an enormous amount of time unresponsive at startup and periodically thereafter. Why? Because of two things: the default JVM settings it ships with starve it of resources, and the default validation settings have it trying to check everything under the sun.

There's also the initial indexing, but I can live with that, since it enables beautifully fast jump-to-definition, which is hard to live without.


Why would you configure a webserver for a java process ? Just have every process include a webserver. At what address ? Well simple : any free address, then register the address you've started up on in zookeeper. Likewise, contact your dependencies by resolving them on zookeeper (this can be done using DNS if you want minimal changes. Protip: SRV records have both ip and port).

Having the webserver is useful for reasons beyond just being independant of the webserver itself, like exporting metrics. Making the logs inspectable. Getting thread dump, inspecting current state, ...


> culture really needs to learn the value of the simple and explicit.

This is true for any programming community.


This is my favorite thing about Go.

All language arguments aside, Go coders are usually pragmatic and humble and Go code is usually simple and explicit.


"Compile times must be fast"


>there are only a couple of things that I think were real mistakes in the core language.

Type erasure was a pretty big one that I've felt the impact of a few times in the small amount of Java code I've written (99% being school assignments). One of the reasons I strongly prefer C#/.NET as a language/environment. What I've tried of ASP.NET coding seemed nice.


I'm lucky that I develop Java CLI apps that only I need to maintain and one other person. But damn there are days in which I scratch my head and wonder why I have to write so much code to do simple things. But on the other hand my best work has been writing Java apps.

I have a love hate relationship with Java. I do have Java apps that runs 24x7, day after day without failure.

I think I protest too much.


> it would be very hard to persuade me to not choose Java...For better or worse, CS departments across the US produce Java programmers more than anything else.

This is actually the reason I would not choose Java. I started programming Java in the 90s and spent the better part of 2 decades writing code in it. The last 8 years of that time, I was a lead developer, so I've interviewed hundreds of Java developers. The most kind way to describe them, as a whole, is uninspired. If I were more honest, I'd say that the vast majority of Java programmers are completely unqualified. There are very few Java programmers who write code because they have a passion for it and it shows...most just learned Java to make lots of money.

On the other hand, if you were to choose a language like Go or Erlang, you'd get less than one tenth of the resumes for your open position, but the majority of those resumes would be highly qualified. The reason is that each of those candidates was motivated to learn a new language solely out of curiosity. You'd be automatically selecting for intellectual curiosity and that's a powerful tool that will save you hours upon hours sifting through Java candidates who are simply a waste of your time.

This isn't an indictment of the Java platform...it's no longer my favorite programming target, but there's nothing fundamentally wrong with it from a technical perspective. It's just a recognition that more != better when it comes to language ecosystem. Quality matters.


I have a similar experience with interviewing Java developers in offshoring projects, and I started to think like that, until I was involved into similar projects done in other languages and came to the conclusion any mass market programming language suffers from the same sins.


Do you know this essay http://paulgraham.com/pypar.html? Almost exactly your points.


> 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.

Java has long been my primary professional language, and over the past few years Go has taken on a strong secondary niche at my job. I'm big fan of both, and tend to play Switzerland in arguments between them.

That being said, the best Go IDE out there right now is the official Go plugin for IntelliJ... which again, happens to be the best Java IDE out there. If you are doing modern software development in ANY language, then you are probably traveling one of three paths:

(1) Using an IDE based on JetBrains or Eclipse.

(2) Using a variant of Microsoft Visual Studio, which is about an order of magnitude more bloated than #1.

(3) Using a plain text editor, which for a typesafe language is a bit daft.


What does the Go plugin for IntelliJ offer that Go plugins for Emacs don't? My setup right now has live error checking (highlights errors as they occur), gofmt on save, safe refactoring via gorename, jump-to-definition, proper autocomplete, and Go Oracle integration, for e.g. finding all callers of a method. Due to being Emacs it also has much better support for Vim keybindings via Evil mode.


Debugging, cross-platform, integration with a lot of other languages, and databases, local history, out of the box configuration for everything you've just mention (including the Vim key working mode, via a plugin) so that people don't spend time in doing all of that and so much more :)


In what way is IntelliJ more cross-platform than Emacs?


It's written in Java ;)


Are using go-projectile for all of that? If not, what did you use for gorename integration?



Visual Studio is more bloated than IntelliJ or Eclipse? Absolutely not.

When I had the displeasure of using IntelliJ it would use 1.2GB RAM for a fucking 5 file project. Debugging would then use another 1GB RAM.

Visual Studio uses 1GB RAM with a 150 project solution open, and it opens said solution about as fast as IntelliJ opened that tiny project.

Adding something like Resharper (by your beloved Jetbrains) will make Visual Studio bloated and slow.


> (3) Using a plain text editor, which for a typesafe language is a bit daft.

What's wrong with using Vim, Emacs, or Sublime? There are plugins out there which get you a lot of the IDE magic (including jump to definition, autocomplete, autofmt, and there probably is something for inline errors)


(4) Xcode? There are lots of iOS programmers out there.


Still in camp #1 (AppCode). As someone who also does development outside of iOS, you couldn't pay me enough to solely use Xcode.


Can you explain why using a plain text editor for a typesafe language is a bit daft?


That may be stated too strongly, but the argument is in a statically typed language you go to all the trouble to provide the compiler with sufficient amounts of information, but then don't leverage that in your editor.

E.g. if you call a statically resolved function, your IDE should be able to take you to the function's definition.


Go was designed to make tooling easy, and that tooling has been written: https://github.com/nsf/gocode/blob/master/README.md

And it's pretty trivial to get Vim super integrated with go: https://github.com/fatih/vim-go/blob/master/README.md


And you consider that an IDE, right?

An Integrated Development Environment?


No, and nobody else does. There's a lot more baggage and feature check-boxes tied up in that name.


Because if it's a text editor it doesn't have all the info and functionality you have available in an IDE. Run tests for your current function, navigate to definition, manage large projects, configure builds, see test coverage, step with interactive debuggers, REPLs, vcs integration, symbolic refactorings, autocomplete, etc.

Most of this can be added to emacs too. Then it's an IDE.


(4) Use LiteIDE, simple IDE written for Go.


The best ide for golang. It is not Netbeans or Eclipse but

it is lightweight, enough features and gets the job done.


VS is much faster than the JetBrains IDE without any plug ins. Adding JetBrains' products makes it slow.


A huge percentage of those doing #2 are using Resharper (a JetBrains plugin for Visual Studio).


I agree Erlang is probably not the correct fit for the average startup, but for some areas it is essentially unparalleled (and businesses have had great success with it). Consider the online advertising industry, for instance -- in order to guarantee the kind of uptime and debuggability that real-time bidding and decision making on ads requires, Erlang is an excellent choice (cf. https://www.youtube.com/watch?v=qURhXHbxbDU).


Go is great for RTB as well. Easy concurrency that scales very well. Anecdotally it seems a lot easier to hire for than Erlang/functional languages.


If it's just concurrency and scaling, things are a toss-up. Where Erlang really comes into its own are all the fault tolerant and distributed things that Erlang adds, like the supervision tree.


Go is such a simple language that I believe any decent developer could be productive with it within a week. I'm not sure the hiring argument is all that great.


> For better or worse, CS departments across the US produce Java programmers more than anything else.

That is real a problem of quality of those CS departments.

My humble Portuguese CS department teached me about Pascal, C++, C, Prolog, Caml Light, Smalltalk, Java, Lisp, MIPS and x86 Assembly.

Having a quick look at their current curriculum, now around 25 years later, they seem to still provide a good mix.


I have to admit I'm jealous you had such a diverse exposure to programming paradigms.

I agree it's a problem. I've always found it odd that the AP test is in Java for example. I would imagine pseudo code would be a better choice for a conceptual test.


And I only listed the official ones.

Those of us, like myself, that opted into the compiler design classes had a quite a few more to play with.

I guess the problem are those universities that tend to be more focused on "languages to get a job" than doing the real work of an university.


>I refuse to learn Java because I personally have a strong bias for native, compiled code.

All commercial JVMs support AOT compilation to native code.

Yes even some of the Oracle ones, e.g. Java Embedded.


>For better or worse, CS departments across the US produce Java programmers more than anything else.

Do you think this large pool of programmers are good?

>This makes it very easy to hire Java developers.

Yes, if you are looking for sub-par developers. I don't think Google thinks to itself "oh man we're so glad we use java, otherwise hiring would be challenging". No, they have just as much difficultly hiring as anyone else. I'd even say that considering it's the 'blub' language to use PG speak, it makes hiring harder for them.

>Java has stability, Java has concurrency, Java has hot reloading, Java has a good track record, Java scales,

No, those are things the JVM has.

>Java has really nice functional programming support,

You can't honestly believe this. How much functional programming experience do you have?


> Do you think this large pool of programmers are good?

Yes, why not? I have yet to see evidence that Java programmers are not good. Seems like a discriminatory mindset. The large pool also makes them easy to replace. I think Facebook has had an ad for an Erlang developer for a few months now. I don't think a startup needs that kind of stress.

Also, I'm sure there are Java Devi who are absolutely fantastic. That is, I think the idea of the meme "real passionate programmers use less mainstream languages" is entirely unsubstantiated. This line of thinking comes from immaturity, elitism, and a desire for validation by association.

It's just like the "the best lawyers were on the debate team" meme that's also very untrue. It sounds nice if your kid is on the debate team, though

>No those are the things the JVM has.

I meant Java as a platform. Funny, you were the only one who didn't know what it was what I meant here.

> You honestly can't believe this. How much functional programming experience do you have?

I've dabbled with Erlang and Haskell. I don't have as much functional programming experience as I would like. Also, I've only heard good things about Scala and Clojure. What was so ridiculous to you about what I said? Or are you unable to forgive an accidental conflation of Java and the JVM?

Your criticism come across as nothing more than unreasonably pedantic expectations for terminology. They either reflect your inability to use context clues effectively or your lack of common sense.

> It's the 'blub' language to us PG speak

This is a poor reason to think Java developers are incompetent. I hope this isn't the premise that led you to that inherently false conclusion.


Eh, most of my post was an emotional response because of my hatred of the java language. Your reasoning I mostly agree with.

I do agree, the JVM is a solid language choice. I also don't think going with too esoteric of a language is a good thing. Probably a little early to bet a company on Idris or Ceylon.

Still, I apologize for my tone. Let me give you purely anecdotal information about me, so you can at least see where I'm coming from with regards to my anti-java stance.

After doing java/C# for many many years, I will not do it again. I'm much more productive in Scala/F#/ML, it's more pleasant to use, and I believe the average programmer using those languages ends up being a different caliber than the java programmers.

There are absolutely good Java programmers. They just probably work at Google or Facebook and you'll be competing with Google. I would take less money (and have, though not too much less) to not work at Google because I get to use a functional language.

shrug

If a startup is using java, I think to myself 'why java? why not Scala, F#, or C# at the very least?'. Usually the answer is 'scala/F# programmers are too hard to find', but that's not really true, what they mean is they're not willing to pay the 20% premium for them. That's a strong indicator that a start up doesn't value talent.


> Still, I apologize for my tone.

It's all good! I've had the same heat of the moment responses on here, so I get it. But thanks anyways.

> If a startup is using java, I think to myself 'why java? why not Scala, F#, or C# at the very least?'. Usually the answer is 'scala/F# programmers are too hard to find', but that's not really true, what they mean is they're not willing to pay the 20% premium for them. That's a strong indicator that a start up doesn't value talent.

Definitely. If I chose the JVM or (blanking) the Microsoft VM I would not limit myself to the object oriented languages for those platforms. I was under the impression that using multiple languages was a given, but apparently not? I wouldn't know, I'm doing iOS right now (hence the username). I graduated fairly recently, so I can only go off of what I've read.

So, I would probably do Java and Scala together if that was possible. I really haven't looked into it. My startup was completely hypothetical.


Might I suggest starting with Java, but moving into Kotlin after getting the basic syntax of Java down? I have a good feeling about the language after translating a system of classes to it recently. About 60% of the code vanished, and working in it let me free up a few concepts for the resulting java code after doing my thinking in Kotlin.

Most of the stuff Kotlin does, absent much nicer functional syntaxes, I can do in Java 8 already. I think Kotlin does a better job at expressing it. I especially like the first-class nature of functions, and I know I'm just in the early days of understanding it.


Why kotlin and not scala? Kotlin is like Scala--, in addition to not really having a job market.


Some true words.

The programming language has really nothing to do with the quality of a developer. A new language is learned quickly, software engineering skills not.


[flagged]


Your comment is quite cryptic imho, and there is no need to respond in this fashion. Can you elaborate?


> I refuse to learn Java

So you willfully ignorant but will continue to spout off opinions anyway?


I've read a lot about Java. I just don't want to learn it on my free time. My opinions were based off what I read


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

[2] Just discovered this amazing guy recently, https://github.com/fogleman/ln, https://github.com/fogleman/nes


"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.


> Which means you can declare an interface that foreign packages already conform to, and then freely use them.

But you cannot do the reverse: you cannot make a type from a foreign package conform to your interface by adding new methods to it. This is because, with structural typing, it's not safe to add methods to types in other packages, since if packages B and C both were to add a conflicting method Foo to a type from package A, B and C could not be linked together. This is a major downside of structural typing for interfaces. Swift, for example, has the "extension" feature, and Java's design allows for it in principle, but it's fundamentally incompatible with Go's design.


The list of languages that permit that in a principled way is short, and the list of languages where it's a good idea is even shorter. I've come to the conclusion that it's generally not a good idea. (And it's not Go making me say that, it's more Haskell.) Keeping dependencies flowing in one direction seems to be a good plan.


I totally disagree. It's not only a good idea, it's essential for certain core functionality to work at all. Take serialization, for example: without this feature it's impossible to write a good serializer as a library without code generation (messy and brittle) or reflection (very slow). To give another example, try writing a linear algebra library that's generic over the data type without this feature (and such libraries are essential for high performance graphics programming). The only way I can think of to make it work is to make callers explictly box their numbers into wrapper types you create, which is really ugly and causes various other problems.

I don't understand the idea that not having this feature somehow helps enforce dependency order either. Extension implementations of traits don't give you any more abstraction-breaking power than downcasting interface{} to a concrete type not defined in your package does. In fact, they're pretty much strictly less powerful.


> To give another example, try writing a linear algebra library that's generic over the data type without this feature (and such libraries are essential for high performance graphics programming).

I disagree. My best, fastest to compile code has always focused on just one type. You mention graphics programming: for 99.999% of the cases you want to pick a type. Usually, this will be float, and thus for SIMD a 4 or 8-vector of these, like https://github.com/aktau/threedee-simd/blob/master/include/t.... Despite the support of recent graphics cards for doubles, the fact is that they are usually quite a bit slower. Even when precision bound, there are usually tricks that will let one keep using floats (esp. wrt to Z-buffers).


It's very useful to use different types (for example, fixed point) in VBOs in order to save space and/or reduce CPU side processing.


Are we talking about the same thing? That is the most full-throated defense of orphan instances I've ever heard. The reaction to such things is generally... less positive... to put it lightly.


Orphan instances arise when the implementation of the interface is in neither the same package as the package that defines the type nor the package that defines the interface. I'm defending the latter (which Go's rules rule out), not orphan instances.


> But you cannot do the reverse: you cannot make a type from a foreign package conform to your interface by adding new methods to it.

I thought you could.

You don't add the methods directly to it, but you can easily embed the foreign type into a new type that confirms to the interface you want.

  type FooWrapper struct {
    Foo
  }

  func (fw FooWrapper) SomeFunc() {
  ...
  }


That's making a new type, which causes a lot of friction. For example, a []Foo array is not castable to a []FooWrapper array without recreating the entire thing.


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.


I believe you can do renames with the oracle tool


> Which means you can declare an interface that foreign packages already conform to, and then freely use them.

Except that it is very difficult to find out which struct implements what interface, you'd have to go look through the code. Not to mention there is always the possibility of accidentally implementing an interface. This has already caused real issues it seems (there was a blog post about it).

There already exists a solution for this issue, via typeclasses.

But golang doesn't have generics.


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.


Startup times are largely going to be a thing of the past in Java9. Improved code cache, out of the box optional AOT compilation, and the modularization work is going to be great.

I am running several (albeit Kotlin) daemons right now that are using less than 256MB of ram on my machine. Everything on the JVM is configurable.

At some point, I think it's just simply a matter of taste. If you want to be closer to the metal, then Java (and I'd even argue Go) isn't really the right language for that.


What's your use cases where you've found startup time to be a significant issue?


Command-line programs.


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.


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.


Long running processes without a lot of events can also deal with "startup issues", in that they won't trigger JIT.


You can set the JIT threshold to 0, then it will JIT the full bytecode on startup, but it might perform worse.


Fast compilation and minimal startup time in Go allows for very fast development feedback similar to what one gets with interpreted languages.


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


> 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


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.


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...)


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.


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.


Yeah, I can believe that. However webapps(in your average startup) are far more complex, in the tools, libraries they use.


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.


emacs is an IDE wrapped inside half an OS


Don't forget the psychotherapist!


Whoops, seems like you pissed some people off :D


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

Seriously guys, grow the fk up.


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?


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.


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.


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.


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.


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.


Actually JNA is actually way better than Go or JNI. And if you are looking at Kotlin / Scala you won't find yourself inside the object-oriented pain. The JVM is actually not that bad.


I agree with you. But this code, does not compile

List<Integer>[] j=new List<Integer>[10];

and this is a a serious problem. If generics are correctly implemented, then it should compile.


That's because List is an interface, not a class. FYI this works in Scala:

val j = List(1, 2, 3)


It doesn't work for all scala interfaces, and when it is like that, it's often frustrating to find the underlying implementation.

But that's beside the point—OP was pointing out that you can't have generic allocation.


However there are mostly alternatives for Java8 something like that: Collections.singletonList(1, 2, 3) which actually gives a List<Int> by the end it all comes down to syntactic sugar.



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.


abysmal tooling? ... extremely primitive concurrency support?? Are you talking about Go?


No fully-functional debugger. Minimal instrumentation. No good code transformation or refactoring tools. No concurrent data structures.


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.


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.


Okay, ditch Java if it's too verbose and adopt one of Kotlin, Groovy (w/ @CompileStatic) or Scala.


> 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.


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.


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.


Or Clojure.


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.


How can Go be concise when you can't do f(g(x)) without two if-statements to check for errors?


Couldn't f check for g's errors?


Sure it can, http://play.golang.org/p/T6WIcT_8q5 works just fine!


No because you can't easily pass multiple return values as parameters. So annoying...



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

In any case 'thebaer continues to be my hero.


It's how html/template.Must works, isn't it?

We have a small library of functions for sweeping up error returns, and for collecting errors from multiple functions and checking them all at once. It helps a lot.

Golang is very much on to something with it's "errors are values" philosophy, but I'd be the first to acknowledge that it's not a fully baked philosophy. It is weird to discover fundamental things about how to structure basic code several years into writing in a language, but that happens somewhat regularly with Go.


I could justify my ignorance by pointing out that for all the time I've spent using Go with http, I've not had occasion to use it for html. But, that would only mask my utter embarrassment at missing a core language feature, and worse yet something I complain about as a weakness of Go.

I'll be over here muttering to myself about monadic error values...don't mind me.


Would you, by chance, be able to link or share that error lib? I'd love to see more solutions for error handling to get a better grasp.


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


Thanks, I've never seen that used and didn't know they special-cased it until I found https://golang.org/ref/spec#Calls. I wonder why it's not more common...


I'm sure there are good uses for it, but I personally haven't found one yet. I mostly use Go's multiple return values to also return errors -- and that's really like using checked exceptions in Java. So whether it's a try/catch or an if statement, you have to code for these things one way or another.


A try-catch block can cover many complex statements and pushes the recovery code down where you aren't forced to continually reread it. Even if it's possible to write concise Go, nobody seems to be interested in trying, it always seems to become a mess that spends 2/3 of its time on errors.


¯\_(ツ)_/¯ I'm personally a fan of the style, and like explicitly seeing where the fault points in functions are, rather than having to memorize what exceptions might get thrown by what. But it can definitely cover many complex situations.

That sucks to see people making a mess with error handling code, but there are examples of good uses out there. This [0] is one I quickly found.

[0] https://github.com/schachmat/wego/blob/master/we.go


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.


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.


> 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!"


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.


I agree 100%. Also, a lot of good devs have poured their heart and soul into golang. They are a part of this community, like it or not. They find go news interesting, but I totally feel for them that every conversation feels like somebody kicking their sandcastle down because "theirs is better.". Same goes for nodejs. Same goes for PHP. Same goes for every language actually.

A person may have the best of intentions, but they need to realize that their words can have unintended consequences. There are places times and ways to properly discuss go's shortcomings, but there are also times when it is wildly inappropriate.

This is a good event for a very hardworking and capable part of oyr community. They deserve a little respect.


I didn't even interpret that as politie. That's the kind of "polite" comment I would make if I thought you were being an an aggressive idiot and I didn't care to help you.

i.e. You think Andoid apps have the same revenue potential as iOS apps? That swell! Good for you buddy, whatever works for you is fine with me :) (Now go back to your cubicle and stop bothering me me.)


Well that's certainly not what I intended. Only further proves my point that our words can have unintended consequences.


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


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?!


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.


When different code needs different JVMs, it gets to be a pain. The Go advantage is a fat binary, no dependencies.


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.


> 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.


> 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.


Correct. With Java I've got at least 4 compilers (JDK's) to choose from.


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.


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.


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.



I have hundreds of jar in my Java project. I am not even sure which one are used. How does Java handle this scenario?


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.


Depends on your build system. In maven http://maven.apache.org/plugins/maven-dependency-plugin/ is the way to go.


You don't have too.


Thank you, I don't get it neither. The delusion in this thread is hard to believe.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: