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
Java is back? Programming language trends for 2345 teams
21–30 of 32 posts
Re: Java is back? Programming language trends for 2345 teams
#22JVM 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
What's the reason to use HiveMind over another solution?
You can read the docs or just download and try it out...there are a lot of interesting ideas implemented on the platform.
Re: Java is back? Programming language trends for 2345 teams
#23Android...I'm still hoping Google will soon focus on Go and deprecate the usage of Java language for Android.
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.
Re: Java is back? Programming language trends for 2345 teams
#24Java 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!
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.
Re: Java is back? Programming language trends for 2345 teams
#25Android...I'm still hoping Google will soon focus on Go and deprecate the usage of Java language for Android.
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.
Re: Java is back? Programming language trends for 2345 teams
#26Java is here to stay. We are a small startup, but I am building our entire backend in Java 8.
Re: Java is back? Programming language trends for 2345 teams
#27Android...I'm still hoping Google will soon focus on Go and deprecate the usage of Java language for Android.
Re: Java is back? Programming language trends for 2345 teams
#28The 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.
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?
Re: Java is back? Programming language trends for 2345 teams
#29Some 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.
Re: Java is back? Programming language trends for 2345 teams
#30Earlier quoted context omitted.
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…
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 nativ…
If you allocate memory using C.malloc you must use C.free otherwise you will leak memory.