Settings

Theme

Java is back? Programming language trends for 2345 teams

blog.helloworldopen.com

44 points by mikko-apo 12 years ago · 31 comments

Reader

taylodl 12 years ago

Java isn't back, it simply never went away - it's the modern Cobol. It's a good environment for backend development. Free if you need it, support if you want, no vendor lock-in, no platform lock-in, a vibrant open-source community - there's a lot to like about this old dinosaur!

  • mikko-apoOP 12 years ago

    Actually back in 2012 Java wasn't that popular. Here's the language stats for the 200 teams 1.5 years ago:

      Ruby 28.4%  
      Python 27.5%
      Clojure 10.1%
      Java 9.2%
      CoffeeScript 8.3%
      Haskell 6.4%
      JavaScript 5.5%
      Scala 1.8%
      Go 1.8%
      Groovy 0.9%
    
    This year Java rise and Ruby's drop are quite obvious when compared to the old stats.
    • simonb 12 years ago

      Considering the difference in sample size and make-up, the latest results just show the competition is gaining broader appeal and with it more mainstream languages start to dominate.

    • thinkpad20 12 years ago

      This is surprising. Your article portrayed Haskell as having gained a fair amount of ground, but actually it seems that it dropped in half or so.

nornagon 12 years ago

> describes haskell as having a "nice emphasis on functional programming"

understatement of the century

ninjazee124 12 years ago

Java is here to stay. We are a small startup, but I am building our entire backend in Java 8.

  • Edmond 12 years ago

    definitely a smart choice...especially if you are thinking of something that can adapt to evolving technology, so far I haven't found a platform quite as flexible.

  • deerpig 12 years ago

    Yup, following the herd is the best way to go. Especially if it means that everyone bigger than you can afford to hire the best and brightest at salaries you can't even dream of matching....

pathikrit 12 years ago

This is the language usage from latest Google Code Jam stats: http://www.go-hero.net/jam/14/round/0

Some observations: * C++ is the king. More people use it than next two (Java+Python combined)

* Although there were 20% more Java coders than Python coders, but 20% more Python coders qualified than Java coders.

Edmond 12 years ago

JVM languages would probably top such lists in coming years.

Think JRuby, Jython, Clojure,Javascript...etc and of course Java.

For anyone interested in trying these out, checkout HiveMind (crudzilla.com), I am the developer.

Sample screencast: http://crudzilla.com/assets/img/info-graphics/lang-demo.gif

  • tomjonesmi 12 years ago

    What's the reason to use HiveMind over another solution?

    • Edmond 12 years ago

      HiveMind is for building web apps, as opposed to being just a generic IDE.

      You can read the docs or just download and try it out...there are a lot of interesting ideas implemented on the platform.

mrinterweb 12 years ago

The name of this article is definitely leading without context. For a competition that is focused on building a race car simulator, certain languages are going to be a better choice. If the competition was to build a web app, I'm pretty sure that C/C++ would not be high on that list, and Java would be ranked lower.

  • mikko-apoOP 12 years ago

    Hi!

    Unfortunately there's quite a bit of context behind those statistics that doesn't fit in to the title nicely.

    I suspect that mentioning just HWO or Hello World Open or real time race car AI coding competition is not enough either. Do you have any suggestions on what would be a good title?

    • mrinterweb 12 years ago

      Thank you for the emphatic greetings. Normally, when I see articles with similar titles, they are articles about general programming trends. I realize that HN does not like link submissions article names to be modified. Since the article is on a website about a race car AI contest, the website does not need to provide context in the article. I'm just saying that if I was skimming through HN articles and saw the article title, I may get the impression that Java is the new old hot again.

higherpurpose 12 years ago

Android...I'm still hoping Google will soon focus on Go and deprecate the usage of Java language for Android.

  • Iftheshoefits 12 years ago

    Why would they deprecate Java? Especially why would they replace it with a relatively immature language and implementation? I'm not knocking Go--it is simply a fact that the language is immature still, just like every language that is relatively new.

  • BaconJuice 12 years ago

    Is there a specific reason on why? Just curious?

    • Moru 12 years ago

      The usual argument "You have to use the newest shiniest tech or you suck"

    • pnathan 12 years ago

      I'm not an Android programmer, but I hear that the Dalvik-based Java is Java 6ish, and will likely stay that way, while Java (from Oracle) moves forward. Much bad has been said about Java 6. So from that perspective, one might hope for a change.

  • paukiatwee 12 years ago

    Any reason why Go is better than Java on Android? Concurrency is the reason? I personally think Go is good for System Programming, e.g. Docker, GoRouter (Cloud Foundry), etc.

    • rakoo 12 years ago

      I have a personal preference for Go over Java, but I'd say Go's big focus on concurrency is a big win for mobile , where you don't need to compute many things but need to react to many exterior stimuli.

    • melling 12 years ago

      Should get faster binaries, thus better on the batteries. I think better compile times would help with the edit-compile-run cycle.

    • pmelendez 12 years ago

      Another reason would be that JNI is horrible and if you need to mix your app with native code you are out of luck.

      • paukiatwee 12 years ago

        So Go solve the problem, right? How is Go's OpenGL/OpenGL ES?

      • kasey_junk 12 years ago

        Is the Go FFI any better? How does it interact with the garbage collector? What aspects of the JNI are horrible in your mind (I have a few in mind as well) and how does the Go FFI differ?

        • kyrra 12 years ago

          The most common solution in go is to use cgo[0] when wanting to bind with another language. From C you can then do whatever you'd like. That's how people are interacting with OpenGL[1] or QT[2] for example. Though, it seems like most common use cases of Go are to stay within the libraries supported by the shipping library or 3rd party libraries written in pure Go.

          [0] http://golang.org/cmd/cgo/

          [1] https://github.com/go-gl/gl

          [2] https://code.google.com/p/goqt/

          • kasey_junk 12 years ago

            Right, but how is that different than JNI?

            For instance one of the major complaints about the JNI is that adds a pretty high performance penalty to any native calls (and typically you want native calls when performance is important). Does Go's FFI not have this performance penalty? If not, why not?

            Like with the JNI, Go's garbage collector needs to understand life cycle semantics of objects coming in/out of the native binding, how is this accomplished and does it do a good job? Does it complicate the garbage collection of other unrelated parts of the system?

            Basically, if you are going to claim that the JNI is awful (and I think that is a valid claim) and then imply that Go's isn't, I'd like to know why that is.

            • Zariel 12 years ago

              The go runtime will manage memory of thins allocated in Go land but you must manage memory in C land.

              If you allocate memory using C.malloc you must use C.free otherwise you will leak memory.

              • kasey_junk 12 years ago

                Which again is very similar to JNI. I'm genuinely curious as to how Go's FFI differs from Java's to make that a distinguishing characteristic between the 2 languages.

              • twic 12 years ago

                So how can native code get access to objects on the Go heap?

Keyboard Shortcuts

j
Next item
k
Previous item
o / Enter
Open selected item
?
Show this help
Esc
Close modal / clear selection