Countless companies, huge and small -- from Apple and Amazon, to Google and your friendly local startup, plus all the enterprise world that's not a .NET shop...
In what parallel universe is not Java immensely popular or not used for green projects?
On what concerns the JVM, Kotlin hype will be over in a couple of years, and it will get as much use as Scala, Clojure, Beanshell, Groovy enjoy nowadays.
Guest languages never get to own a platform, and with time all platform languages end up getting enough features that the large majority of developers never bother with extra tooling, debugging layer and idiomatic wrapper libraries of the guest languages.
>On what concerns the JVM, Kotlin hype will be over in a couple of years, and it will get as much use as Scala, Clojure, Beanshell, Groovy enjoy nowadays.
And we know that because?
>Guest languages never get to own a platform
That depends on the platform, who is running it, and how. You couldn't have a worse steering than Oracle.
And most "guest languages" are smaller affairs, they don't have companies the size of Google chosing them for Android app development (a huge niche in itself). Or have first class support from the most popular IDE of the host environment.
Plus, anything is anecdotal, as we have so few cases of major parent/host language rivalries, and even fewer cases with similar dynamics, that there's no real prediction.
Scala was too complex for most Jave-ers, too slow to compile, didn't have a Google pushing it to its platform devs but an insignificant company, etc. Clojure was a Lisp (= doomed), Beanshell and Groovy where from small, insignificant origins, and not pushed by anyone really mainstream the size of Google/FB/etc.
UNIX and C, Web and JavaScript, Windows and .NET/C++, macOS and Objective-C/Swift, Android and J̶a̶v̶a̶/Kotlin/C++....
Google only cares to push Kotlin on Android, and it only matters because Google visibly doesn't want to move Java beyond the Java 8 subset that Android currently supports, so the choice is between an handicapped Java support or Kotlin.
Until there is a JVM written in Kotlin, and Kotlin gets first class support in all Java IDEs instead being a tool to sell InteliJ licenses, it is just yet another language that happens to target the JVM.
This ignoring that Kotlin already has a couple of impedance mismatches with the JVM, sequences vs streams, lambdas vs SAM, co-routines vs fibers, inline classes vs data classes.
Elixir is doing well because many developers seem wary to learn Prolog/Erlang syntax.
> Guest languages never get to own a platform, and with time all platform languages end up getting enough features
They do up to the point where they differ philosophically. Java is never going to turn in to a Clojure, nor is it going to adopt the type of dynamic scripting features Groovy offers.
Can't say about new ones, but after a couple of years of working on a huge Python project, I would accept rewriting it in Java without a whim. I have equal experience in Python and Java by now. Funny thing, I returned from my vacation a few months ago, and started writing my first code after it. Of course, I was more concerned with thinking what am I writing instead of how. Then I looked up and noticed I started typing Java instead of Python. And that's three years after the last time I've written some Java code.
Oh, just Apple, Amazon, Google, Netflix and likely every hospital, utility company, police force, military, or bank you depend on. And the people programming the robot swarms that pack your groceries (https://www.infoq.com/presentations/java-robot-swarms/).
For large scale projects, Java and C++ remain the go-to languages. I've seen a little bit of Go start to show up but no others. Other languages are used for libraries (Rust, C), only at certain employers (OCaml, Erlang), or for small-scale projects (nearly everything else).
On C++, inertia is a wonderful thing. Java has the benefits of extensive dependency injection and JVM/ecosystem tools that lower the risk of deployment of code. .NET also provides the controlled "managed code" environment of CLR.
Why any enterprise would use C++ for standard "business" or "large scale" programming makes no sense to me.
Enterprises want stability, not speed to market. Most of their infrastructure changes slowly (as in features deployed once or twice a year maybe). They have stable support mechanisms for this, including long and complex processes of approval.
As ex-C++ dev, that lives in the Java/.NET worlds since 2005, because they still don't cover all use cases where C++ might be needed.
So while you might not write it as full stack C++, a couple of native libraries might be required as dependency, to access OS features, give some help to the AOT/JIT compilers, or in Java's case implementation of more machine friendly data structures.
One of my clients handles 90% of all the pbm routing in the US, which is millions of transactions per second. They started to completely modernize the application on java... primarily Spring Boot and Apache Geode. After some optimizations they are very happy with the performance and expressiveness of modern java.
Exactly right. Java has lots to improve on but there seems to be unsubstantiated hate towards Java on HN which I find contrary to what happens in the real world. In the real world companies find hiring Java programmers relatively easy (maybe not the best and brightest) who can get a project off the ground easily
C++ is mostly in a different but overlapping use case these days, used for system software or where performance is critical. Go is still a niche language most developers haven't heard of and with no readily available for hire talent pool.
I'm not a fan of the language, but java has a huge number of developers, a rich mature ecosystem of software and is quite productive (enterprise patterns aside), it's a good sweet spot for most companies.
C++ is a hydra of complexity, sure it has it's place, but it's not nearly as productive as Java for your typical web application.
Go is almost the opposite, so simple it lacks features like generics.
The last time I used Go it had fundamental usability issues around dependency management(although I think recent versions have improved on vendoring a little).
> C++ is a hydra of complexity, sure it has it's place, but it's not nearly as productive as Java for your typical web application.
Modern C++ well is as productive ( probably even more productive ) as Java. The main issue with C++ is recruitment, C++ engineers are rare because C++ is barely teached.
C++ is barely taught in ProgrammerGenerationFactories because "modern" C++ still allows "old" C++ and makes it difficult to stop developers from doing that.
Just like MISRA tries to constrain C programmers from doing dumb things in the embedded world, "modern" C++ tries to the same in the business world. But there isn't an easy way to enforce it, especially when you're outsourcing to some code sweatshop.
Every mature enough language has a subset that you need to avoid. Including Java. This is precisely due to this kind of things that every company need to have coding guidelines and proper static analysis tools.
> especially when you're outsourcing to some code sweatshop.
If you outsource your dev to cheap, other side of the world, low quality engineers. Then you deserve your problem, in any language.
I worked in the past for a company (embedded programming) that had an entire team of expensive engineers in Luxembourg just to fix the stupidities of an other team of outsourced engineers in India.
And yet you only offered a misinformed platitude in the form of a question.
Google does all kind of new Java work (Golang contrary to myth, is just one of the languages Google uses for internal stuff, and niche at that), Amazon of course, most of Apple's backend services are Java, Twitter, AirBnB, Uber, LinkedIn, TripAdvisor, and tons of others use Java, and write green stuff in it all the time...
Twitter, and they write some really good open source stuff too. If you're writing rpc services in java I'd almost argue you should default to considering Finagle:
