Why we choose Java instead of a polyglot stack
product.hubspot.com
product.hubspot.com
Say what you will about Java the language (I agree it's not particularly "sexy") but the JVM is a performance beast. You can write Java or pick from one of several other languages that range across different paradigms from static functional to dynamic (current gen: Scala, Groovy, JRuby, Jython, next-gen: Kotlin, Ceylon). Integration is usually painless between these languages. It's also highly configurable and can be tuned to virtually any workload.
You get the huge benefit of a very mature and common shared infrastructure and tooling environment. Your operations team will thank you for solidifying on a single runtime environment.
Java is great. The whole ecosystem is really really solid in general and it's truly a pick what you want platform at this point. The JVM is magical for web applications and services.
It's really easy to administrate Java applications. You can connect to the JVM and examine what objects are in the heap, or request a thread dump and see what threads the application has launched and what they're doing. There are rarely any (JVM-level) correctness issues since code is safe and has a simple exception model - JVMs are rock solid and virtually never crash. There are advanced profiling tools available, and simple ones built in. It's easy to deploy applications due to Java's jar and class model. You can inspect a class and see its code as-deployed. Building Java code is simple, so there are rarely any build tooling or reproducibility issues.
Java also has excellent tools for logging and metrics emission, like Log4j / Slf4j and utilities like Metrics. These are just a few of the system-level features that are critical in large-scale deployments, and in practice these elements matter quite a lot for managing production apps. The language itself is only part of the story.
The Java language has also been improving substantially. Java 1.8 launched a lot of great features, like lambdas, functional interfaces, streams, and other modern elements that give me most of what I expect from a modern language and allow me to write clear and concise code that is statically typed, in the context of really strong IDEs. Java's portability makes it straightforward to develop an application from any platform (not just the server platform you deploy on).
IDE support is crucial and frequently overlooked. Automatic code completion, refactoring, and inspection ("show all usages of this method") are essential to working on large code bases together as a team. Java also has style enforcement and static analysis tools like FindBugs, Fortify, CheckStyle, etc. Java's open source community is extremely strong - look at all of the work happening under the Apache umbrella such as Hadoop, Spark, and Hive [1] or Google's umbrella, like Google Guava [2] or the Dataflow SDK [3]. There are excellent concurrency tools like java.util.concurrent, Guava's futures, and Akka.
I agree with meddlepal on this one. It's hard to do better than Java for the backend.
[1] https://projects-old.apache.org/indexes/language.html#Java
Can I easily develop Haskell from any platform (Windows, Mac, Linux) and are good IDEs available on all of them? My team is diverse and I don't want to tell my engineers what platform they have to use for development. Can I meaningfully develop my server software on those platforms and deploy it to another OS (Linux)?
I agree that Haskell's type system will catch problems made in refactoring, but it's about avoiding the effort. If I wish to rename a method or a class, I don't want to spend time updating the text manually everywhere that is relevant and working through compiler errors - I just want to say "rename class", "rename method". In large code bases this prohibits people from improving the code over time and doing maintenance work.
Are there Haskell IDEs of equivalent quality to Eclipse and IntelliJ? My software development is a lot slower if I need to remember the standard library precisely and type its methods and classes, rather than typing TPE and allowing the IDE to auto-complete it to ThreadPoolExecutor; and it's a lot slower if I can't highlight a method and quickly invoke the IDE command for "show me all methods that call this method", or "show me the implementation of this class / method". I've personally found that this kind of code authoring and navigation assistance has a dominant impact on practical development speed.
When I've written a unit test, can I easily select the test in my IDE and run that single test with a keystroke, attaching a debugger if needed? (Maybe Haskell needs fewer unit tests, but for business software I doubt it.) That same test suite will be run by my build system at build time to make sure everything passes.
How would I accomplish in Haskell the equivalent of what Metrics helps you solve in Java? https://dropwizard.github.io/metrics/3.1.0/ Or Log4j and Slf4j? Managing log messages from large applications is important, since log messages are the primary after-the-fact record of what processing took place. They're often all you have to go on, aside from any metrics you've produced. (I would not buy the idea that Haskell code is so defect-free that these kinds of tools are unnecessary. In any case, Metrics is about performance metrics and business-relevant metrics.)
Are there profiling tools comparable to JProfiler? Can I easily get stack traces and heap dumps at runtime? In Java there are great interactive tools to explore these, to inspect every object and its properties and GC state. If the application crashes (not the runtime), is good troubleshooting information available to figure out what went wrong? It's more difficult, though still possible, to attach debuggers to production code and step through, so log messages are a poor man's after-the-fact trace. That said, I can still attach a debugger to a JVM remotely over the network and inspect the threads, heap, etc., and step through code execution. Is it easy to debug (attach a debugger to) a Haskell program as-is over the network in production?
How would I write a distributed map/reduce job with Haskell and execute it across a large fleet, like I would with Java using Hadoop, Spark? Are there distributed actor frameworks with the quality of Akka, or messaging systems like Kafka? Are there good RPC libraries for Haskell to interact with other applications written in Apache Avro, Google Protocol Buffers, Cap'n Proto, and so on? The tools I mention are solid, and very widely deployed - they're not obscure.
There are a lot of practical large-scale problems that I can solve easily in Java, ones where many other programmers would be familiar with the solution I'd use. If there are good ways to solve these problems then I'd love to learn more. I've always been a fan of the Haskell language and its concepts, as well as F# and Scala. However, despite my wish to use them, I've run into a lot of practical challenges. These extra-linguistic factors involved in running software in production dominate the linguistic ones.
For those who do use Rails the Torquebox environment is available http://torquebox.org/
TorqueBox 4's web server is powered by Undertow. Check out the performance benchmarks: http://www.techempower.com/benchmarks/#section=data-r9&hw=i7...
undertow edge 183,150 requests per second on the JSON benchmark
The open source community isn't there around .NET the way that it is around Java, however. Java's libraries are a big part of what make it so effective. Perhaps Microsoft's recent change in stance and decision to open source a lot of the toolchain will influence that, but it will be playing catchup for years. I see .NET as being an engineering coup from Microsoft with intrinsic value comparable to Java, while Java has that plus a large community and better cross-platform support.
When I work in Java, the wide availability of libraries and frameworks really helps. Take a look at the number of Apache projects written in Java: https://projects-old.apache.org/indexes/language.html#Java - many of those are very high quality and useful, and those are just the Apache ones.
There are a lot of great languages/frameworks, and it depends on the needs you have and your team.
(I'm so fatigued by this view I hear so regularly expressed in web dev that "X is the solution to everything" - no, it's very rarely the case)
But if you're saying that everyone who is in Javascript, Ruby, Python, Go, PHP (and others) should all refactor into Java because it's the one and only ideal web backend in 2016 (or design new apps exclusively in Java) - I could pick a 1000 holes in that argument. The original comment I reacted to was:
> If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake
My apologies if this comes across negatively (which I don't intend, as this is a respectful debate among people who care deeply about their craft) - but I'm just not convinced that you're really a full supporter of the original commenter. Your blog seems to show a fair degree of pragmatism (you consider other languages/frameworks, might use them, are ok if your friends are not using Java). I'm totally fine with "I think the majority of people should use Java" (I don't fully agree with that, but in a world where many people knew that ecosystem, I think it's a great choice) - but the commenter went much further. If s/he is looking to start a debate, then I'm fine; if that person would join any company and religiously uphold that viewpoint, I don't think they'd be the right person for many companies.
P.S. If I'm wrong, and if Java is the ecosystem that for the next few years the rules them all, I really want to make a Lord of the Rings-inspired meme about it
The NodeJS 3rd-party ecosystem is really really fragile at the moment.
That allows Express third party middleware to add missing parts like Strong Params and easier HTTP Caching.
It would be nice to have batteries included but not at the cost of a giant box still design that I suspect Sails and other have. Pipeline design is important and Express does that really good.
Imagine if your core app consisted of all different third party libs and you wanna update Express/Koa?
Then we have typedefinitions for all those libraries. Which why I'm looking for alternatives with typed languages.
You might have misunderstood my question or I'm getting things wrong again. :-)
Personally, my go-to choice is always something simpler (eg Netty, Vertx, Spark etc - those are more like Express.js or Sinatra than Rails).
There's also JavaLite, which explicitly tries to look like Rails (including database migrations, an ActiveRecord-style ORM, etc)
I work in Scala and I use Wicket for HTML pages (technically a framework (though decoupled from any database access), but it gets out of your way a lot, has a very clean separation between the framework and your code (no magic)); it's probably the best example of good OO I've seen, in any language, with a component model that really works where all your pages are reusable components made of reusable components that are themselves made of reusable components, and there's a really clear separation between markup and logic.
If I'm writing a "web API" I use spray. It has this DSL that lets you write routing definitions which are as clear as a config file but are ordinary code obeying all the rules of the language, so you can safely refactor them the normal way. And it works very nicely with the scala type-system, letting you separate out cross-cutting concerns like logging or database transactions in ways that are low-overhead but visible and safe (and it's natively async, so can be incredibly high performance, not that I've ever needed that). For a "single page application" scenario I've used a TypeScript frontend (in angular) talking to a spray backend (I'd like to try out Scala.js soon).
[1] And frankly if there's nothing it can do that Scala can't and the design isn't any cleaner than Scala (arguable, but I feel Kotlin is very ad-hoc and will look worse than Scala by the time it reaches the same age) then I'll just stick with Scala - whereas Ceylon can make at least some case for migrating from Scala.
Honestly, unless you are operating on thin margins due to your business structure ... this isn't really an issue.
Pretty much anyone with well padded margins that the primary cost is engineering time or product costs [e.g. Physical products to ship] this is a complete non-issue as long as the datastore/service architecture is designed for horizontal scaling.
I'm constantly amazed by the tribalism of developers and the delusion that language performance is in any way relevant.
The reality is you need to just stick with one language so you can keep your engineering talent, tooling, etc. consistent due to the economies of scale of avoiding duplication of effort [libraries, learning time, tooling, etc]. The gain is in terms of engineering costs, not hardware costs.
The language, honestly, just does not matter when we can have a 10 man IT team with ~$50k/year in hardware handling a $100mil/year in business with good margins. It just doesn't even register.
Simply because it is correct for a subset of organizations does not make it true for all organizations as the OP implied.
It just sounds as though the advantages of Java help large, complex systems of services and developers more than they help the vastly more numerous small-med systems.
Can someone with experience comment, because I'd like to understand the options a bit better.
Another anecdotes: I was part of a team of 3-4 developers delivering a portal solution for British Columbia compensation board (WorksafeBC, http://bit.ly/1QhUH8L NOTE: it's a few pages of PDF to show the size of the app).
The thought of Java is slow, not agile, and probably overkill for small team, small project, small this and that is probably not warranted.
I've mentioned this in another thread: choose Java and you'll set for at least 5-7 years with minimum problem, focus on solving business problems and less on infrastructure, upgrades of software/libraries, choices of latest du jour). Those open source libraries are damn solid and I very rarely need to worry much whenever I upgrade those libraries. Open the pom.xml, bump up the version number, sit back and enjoy the latest version.
Do you want to write a mobile app? 1/2 of the popular platform is already covered with Java so you just have to worry about the other one.
I'm having a very very hard time justifying the use of Go for "Web Application". I just can't see the benefit over Java (I'm scoping this to just those 2 platforms).
PS: My experience might not reflect other people.
Java has a more powerful type system (though still poor by modern standards). Both have weaknesses regarding error handling - Go encourages you to err on the side of repetitive code, Java encourages you to err on the side of handling errors only at very high level, I'm not sure which is worse. Java has a much bigger ecosystem and better tool support, though a lot of it is written for pre-C10K days and assumes a "1 thread per connection/request" model - but frankly for a small business type situation that's fine. The go concurrency model is overkill at the low end and not flexible enough at the high end, but if you're in the sweet spot then you can write code more efficiently there than in Java.
That sounds like a fantastic problem to have. Airbnb, Teespring, (Rap) Genius, Github and many others have run into it and I don't see how one could wish more for a friend building out a new wep app in 2016.
The best part is that if you build quickly and hit scaling problems, you have the resources to invest into making your product performant. The second best part is that if you don't hit scaling problems, at least you haven't wasted time on optimizing something the market didn't want.
That said, Clojure + Java is a sweet combination, they are pretty complementary IMO.
The Java ecosystem truly saved itself from its own enterprise madness. Libraries and frameworks today look nothing like they did in the past. I think that is somewhat due to language features (annotations, lambdas, etc) but also due to a cultural shift in what is valued.
One of the things I've appreciated more than I would have expected is by having a single back-end language we have very strong community of developers. There is no split among different factions. (I hear rumors of sharp divides between python and node camps at Uber, for example.) Even though technically we have a platform capable of running languages in many languages, the value of the community focused on a single back-end language toolchain is extremely valuable.
Last time I used it was when EJB, JSP and co. were "big". And it always felt like a struggle to get this strange overload of "design patterns" running. Maven and code generators did their fair share to add some "what is even happening"-moments to my experiences.
I just sticked to get things up and running fast with JavaScript and throw in some C if the performance suffers too much.
The other issue is that the "IE effect": the language stopped evolving for years. In the meantime, Microsoft launched C#, and Java is only catching up now in terms of convenience. But even with Java 8, as far as I know, a lot of things are still strictly worse than in many other languages (no import aliases in 2016, no shorthand for getters/setters...). To a large extent, it's still a language that forces you to live in a IDE even for trivial things, due to the amount of boilerplate you need for even simple things.
Of course, compared to C#, it still benefits from a considerably larger and IMHO higher-quality ecosystem, as well as working very well with some non-Java open-source solutions (eg, Postgres), though it's generally poorly integrated on all platforms it runs on.
Maybe so, it's been over a decade since I've coded in Java back in the days of java servlets.
But what MS has done with C# is great. It's turned out to be an awesome language with lambda, linq, async features that's really hard to beat.
edit: Looks like java 8 has lambda now.
http://www.oracle.com/webfolder/technetwork/tutorials/obe/ja...
This isn't a strong defense of Java, because I think the JVM and its ecosystem isn't super great either. I really like C# and I pay for ReSharper despite not doing C# professionally (I've been using it for about a decade but never taken a job in it). But while C#-the-language has greatly improved, the ecosystem still feels five-plus years behind.
data class Person(var name: String, val age: Int)
So with Kotlin you get many of the benefits of C# and some features that C# is only just introducing now, or in its next versions, but it all interops seamlessly with Java.
Ceylon has all the advantages of Kotlin, but put together a lot more coherently, and with a really compelling fundamental feature (union types).
But we also use a number of other databases with native java clients, such as HBase and ElasticSearch.
Last year I had to work on a Spark application and I was honestly a bit uneasy when I started but I was quite surprised at how much nicer it was to develop in Java 8 and how well IntelliJ worked (first time in probably 20 years that I wasn't using emacs for development) and the performance was quite surprising as well.
I still mostly work in python day-to-day, but if I was looking at starting something from scratch, Java would definitely something I'd look at quite seriously.
But I have to admit that the most threatening counter-argument to using Java in 2016 is that Scala is, to all appearances, a strictly better language. It's similar to Java and does everything Java does, but better- it has type inference, it does away with primitive types and arrays, it has compiler-checked string interpolation, it has declaration site variance, it has a richer collections library, powerful syntactic sugar, robust mechanisms for dealing with asynchronous programming... I could go on and on. And it's deeply interoperable with Java so it should be a no-brainer to use it wherever possible.
Java's saving grace in my opinion is, ironically given Java's history, its culture. When you find that you need to use a small class from a library, you pray that it's written in Java, because most of the time you can just go to its source in your IDE and see painstakingly detailed Javadoc describing exactly what each public method does and common pitfalls. And Java isn't very expressive so all code looks the same- you just have to understand how the components interact with each other. If, on the other hand, the class is written in Scala, you're vastly more likely to crash into a brick wall of undocumented one-liners that are complicated greatly by uses of the downright tricky bits of Scala's type system. Using typesafe's libraries (akka/akka-stream/slick) is an exercise in poking your code experimentally until it magically compiles, usually due to some random undocumented import. And scala culture's love of DSLs and lifted types is downright hostile to ease of debugging. It's hard to overstate how much of an impact these factors make throughout a workweek.
And yes, lots of Scala code is good and lots of Java code is bad. But I think the stereotype generally holds true.
Scala is like a Haskell. It's very powerfull, but to understand and use the entire language, one should make a serious investment.
I'm not sure that extension methods are a particularly fitting example here.
Scala adds a lot of boilerplate for — in my view — very little gain. Of course, Scala's extension methods are actually a special case for implicit conversions; yet, the Scala we write today in my experience tends to avoid implicit conversions per se.
E.g., I'd rather be explicit about a type conversion when that is what I want to achieve: for instance, I'd rather read `javaListMethod(mySeq.asJava)` than `javaListMethod(mySeq.asJava)`. Thus, I'd rather have a first-class construct for extension methods rather than having to write `implicit class RichSeq(val s: Seq) extends AnyVal { def asJava = ... }`
In this case I do prefer Kotlin.
I actually agree that implicit conversions are to be minimized. But you do need a way of doing the equivalent of the magnet pattern - which in Kotlin is either a different language-level feature, or simply impossible. I'm hopeful that a simpler underlying abstraction can be found - but Kotlin feels to me like it's just piling on a bunch of special cases without making any effort to be consistent or unified.
> def addInt( a:Int, b:Int ) : Int = {
> var sum:Int = 0
> sum = a + b
> return sum
> }
You have to relearn how a function looks like in the first place. Return types are at the end, parameter types are after the parameter name separated by a colon.
If you want a language which runs on the JVM Clojure is a way better option. You don't have to learn its syntax since there is hardly anything you can call one. It is binary compatible with itself which is not true with Scala, you can choose whether you want a type system or not since it is optional (look at clojure/core.typed). It is also interoperable with java but it has a much better functional approach to programming compared to Scala since everything is immutable but it is not wasteful because of persistent data structures and for concurrency you have the STM which IMHO is a strict upgrade to the Actor model. Writing DSLs with the powerful macros Clojure has is more usable than any non-lisp language and the result is more expressive.
So to add it all up with Scala you add a lot of complexity and a lot of pitfalls you can fall into while with Clojure you take away complexity while retaining the vast Java ecosystem for interoperability. Don't take my word for it but take a look at Uncle Bob's talk "Clojure is the new C" : http://www.infoq.com/presentations/clojure-c
template<class T, class U>
auto add(T t, U u) -> decltype(t + u) // return type is type of operator+(T, U)
{
return t + u;
}
protocol Numeric {
func +(lhs: Self, rhs: Self) -> Self
}
func<T: Numeric>(a: T, b: T) -> T {
return a + b
} func add<T: Numeric>(a: T, b: T) -> T {
return a + b
}baroque syntax?
Like these:
- https://swift.org/getting-started - https://doc.rust-lang.org/book/functions.html - https://golang.org/doc/effective_go.html#functions - https://kotlinlang.org/docs/reference/functions.html
Sorry but you pretty much say clojure is the best, however it has a lisp syntax, which IS baroque and most people aren't use to this. These days if you want to have a functional style. You eiter use Scala or Kotlin. Clojure is too much of a unicorn. People won't learn this. Also people doesn't care how good the language is or what design patterns were used. People use these languages cause they think the language has a actual value for them (as you think about clojure)
> People won't learn this.
Say that to Uncle Bob or the guys who maintain ClojureScript, Cursive (JetBrains based Clojure IDE) or Om which is a port of React not to mention Apache Storm which was written in Clojure.
Yeah there are a few people who know lisp, you also forgotten about Walmart, which is a lisp user, however the majority of people in functional languages still won't learn Clojure.
But still don't care about, use the tool/language you are familiar with, especially if you could use it in your company. I also see a lot of pressure against scala, and I'm a scala user, but I just don't care.
Not sure what the var/return business is about; have you even used Scala?
An optional type system is almost useless (believe me I spent a lot of time trying to use the checker framework in Java before switching to Scala), because libraries don't have to follow it, and you never know whether the type definitions for a given library are true or not.
Scala is generally immutable by default and has persistent data structures.
STM is great but you can do it fine in Scala. It's just not a language-level feature because it doesn't need to be - Scala is expressive enough that you can write an STM implementation in a library.
Scala's DSL support is great (look at e.g. Spray route definitions) and can usually done in ordinary code without macros, which in turn means you have full IDE and tool support for them. The trouble with lisp DSLs is that your syntax still has to look like lisp - the support for e.g. infix operator syntax is quite limited (you have to use reader macros which are more complicated and harder to work with). But for a lot of business domains the natural language of the domain uses infix operators.
I have to say, this is the big plus for Java for me. I find myself in the weird position that while I dislike writing Java, I love reading it. The simplicity and constrained nature of the language, the incredible IDE support, the JVM features (connect to a running VM and start setting breakpoints to answer questions like "when does this method get invoked"), etc. It's hard to escape the logic that if I want people to like reading my code, I ought to be writing it in Java.
And then there's the in-language tribalism. You find people that work/worked in Twitter, that tell you that anything that Typesafe, the company that does most of the development of the language, is not worth using: They have their own stack for everything. Then, you have the Scalaz tribe: They also dislike the standard library, along with the Twitter libraries. And now we have TypeLevel, which splinters from the scalaz group. You don't have one camp: you at least have three or four, and having talked to prominent members of each of those subcultures, good luck ever getting them to try to unify anything: There is much intra tribe hate in public, and it gets even nastier when they are in private.
Having worked with people from each tribe at one point or another, I think that the situation is pretty hopeless, and the community knows it. The best way for Scala programmers to bond is to hate on a tribe that neither of them belongs to!
Just look at the two keynotes in Scala exchange 2015: One by Jessica Kerr, the other by Miles Sabin. Two people that come from very different backgrounds, writing very different code (business scala vs shapeless). But what both were talking about was how far the community has to go to make the language more approachable. And yet, I am pretty sure that the code Miles finds approachable, Jess would find completely unapproachable, while Miles might hate on how Jess doesn't really use enough types.
It's a very unfortunate problem.
I last used Java two years ago, writing an Android app, and at the time I think Yegge's critique still stood. Not to mention the fact that it was a colossal amount of typing and boilerplate in order to do anything.
We're using Go at the current place, and I'm loving it. Android development in Go would be a sheer joy.
[1] http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
Experienced Java programmers will most often be indoctrinated/trained/used to over-engineering and wrapping everything in layers upon layers of abstractions. And the existing Java learning books, tutorials and examples still tend to follow that mindset.
The more abstracted your code is, the slower it will run, the more memory it will consume and most especially the more difficult it will be to get a new developer up to speed.
I believe you that there are ineffective programmers of any language who over engineer, but I haven't seen that from personal experience with Java programmers. To the extent that it's a problem, it sounds like a hiring problem rather than a Java problem.
Being a big company doesn't imply good Java code. Just look at Lotus Notes, SAP, Eclipse, the whole IntelliJ ecosystem... all slow-as-fuck, resource-eating monsters that have fast, non-Java alternatives that prove that the job can be done in "fast and lean" (except SAP, though. But SAP rants, I tend to get carried away in these).
I also don't see tutorials or books that create too many layers for a while (especially post EJB2/EJB3.0 days).
While the trolling you responded to about Java and RAM is untrue, this also is not really true (I assume you meant exorbitant, not absorbent). Concurrency happens just fine in MRI in many cases because the blocker is the global interpreter lock; if you're doing I/O, threads operate concurrently in MRI. In addition, the overhead of a process in Ruby isn't all that much, and in the rare case where it is (typically a web application) you've got tools such as Unicorn that will prefork and allow you to share/COW that overhead.
The overhead for a unix process is significantly more than a lightweight JVM thread. In some cases this memory overhead can prevent you from utilizing the smaller cloud instance types which are sometimes the most cost efficient.
Also with MRI you can't light up all 4 cores, or 8 or 16 without spawning extra processes which burn memory and that can make your server less cost efficient if your app can use the RAM.
I also suggest you look into preforking and copy-on-write and ensure that you are clear on how Linux works with regards to memory usage; modern Linux systems indeed do not necessitate "burning RAM" to use multiple processes (indeed, the fork paradigm is the standard Unix approach for a reason, it only makes sense to make it performance-friendly). I would also note that while a Ruby or a Python can do this, Java, in standard configurations, cannot, were one to desire the ability to do so (and I've had reasons to run JVM applications in a multiprocess mode before).
I don't dislike Java, don't get me wrong. I write a great deal of Kotlin. But accuracy is important.
The memory overhead of a MRI ruby process running on linux is much higher than the overhead of a native JRuby thread, they are apples and oranges, surely we agree on that point because you can check it via a simple ps aux command.
Perhaps I am mistaken, but from what I've read to run unicorn following their recommended guidelines you need to spawn at least 1 MRI process for every CPU core, but if your application blocks on IO rather than CPU during it's request cycle which is common then you will need more processes than CPU cores in order to handle concurrent HTTP requests. At that point you're wasting many orders of magnitude more memory than JRuby for every "unit of concurrency" so to speak.
by the way Kotlin looks interesting, thanks for pointing it out I was not familiar
The difference in memory usage between a forked process on a shared-page/copy-on-write OS and a thread is infinitesmal. You'd have better luck arguing about having a JIT and better perf (and there you'd be incontrovertibly correct, but I don't think it really matters for 95% of everything).
Like Eclipse only plugins whose functionality I would have to take time I can't justify to duplicate. Plus the additional maintenance cost of the dev team no longer having a homogeneous environment. All to allow me to be able to... do what I already do.
Don't get me wrong, I'd really enjoy taking a week to explore the options and put together a better development environment for myself and my team. I do make improvements where I can already. But we're already an effective team despite Eclipse's flaws, the RoI just isn't there from a business perspective.
But seriously, I'm a huge JVM fan yet I know that if memory is a limiting factor, I should look elsewhere. I just don't current work in any environments where my program has less than 64mb to use.
Not sure how many Grails 2.x systems out there have been upgraded to Grails 3.x, or how many new Grails systems have been started in version 3.x. I don't think it's many though, which suggests a general decline in Grails use.
That said, not sure I'd pick it for simple side-projects. Part of the benefit here is how it works for a large dev team, with a large codebase, etc.
It's easy to get up and running, and I've grown to appreciate the emphasis on stable, mature libraries in Dropwizard compared to some of the more bleeding edge libraries that I've fought with in other "opinionated" Java frameworks that try to approximate the RoR experience.
Dropwizard gives you the option of using either JDBI or Hibernate for an ORM. My suggestion would be to go with Hibernate, even though it's a beast and you will waste time deciphering cryptic error messages and hunting down crippling N+1 select performance problems. Even with those issues, I feel that Hibernate is worth using, as even on small projects it can save you from writing thousands of lines of monotonous database access code.
Very elegant introduction to Java Land, it uses Java EE 7 and by default two servers Payara or Wildfly(around 100MB).
Not mentioned in my initial post, but I also like to keep my code portable between server and client. Firstly, there's no way I'm going to require clients to have Java installed. Secondly, a truly native GUI is practically impossible, so I would already corner myself into needing a second language anyway.
Java 8+ has a "javapackager" tool that makes native installers/packages for each platform which contain a bundled JRE. So your users no longer need one installed themselves. And finally SWT lets you use native widgets if you want them.
Groovy's only close to the Java 1.7 syntax. Java 1.8 uses the -> symbol in a completely incompatible way to Groovy.
And the most common use case for Groovy, i.e. Gradle, only uses some DSL syntax which is totally unlike anything you've seen in Java. There's no overlap at all.
Maybe your definition of "most respects" doesn't include the Gradle DSL or Java 8 lambdas.
Nowadays I use Clojure for those quick'n'dirties testing Java code. A well-placed macro eliminates plenty of boiler-plate specific to the test at hand.
Another option is Scala, but Kotlin is superior for most projects IMO.
I can certainly imagine a future where Java is the top performing language for any application.
Kotlin is best of both worlds, highly expressive, good compatibility and pretty simple.
I'm still writing Java to make money to buy music. Just like the 90's.
There is nothing like Javascript for the frontend, and if its for developing micro-services and not monoliths I think Javascript is also a pretty good choice for the backend as well. There are some good solid libraries like express, sequelize, passport.js that be used to build solid micro-service backends, in every way comparable in functionality and performance to Java.
Definitely not for me and for a few of my buddies who happened to use NodeJS already. NodeJS is a good "glue" appserver for gateway to other microservices I give kudos that far but not more.
This is not Java's fault, per se. You can write simple, performant, sane code in it. It's just that 95% of people choose not to.
I have a feeling that this is part of the reason why Go is gaining popularity (even though I dislike Go as well, for different reasons): much of this garbage (such as DI frameworks, AOP/runtime bytecode modification out the wazoo) are either impossible or deliberately inconvenient there, and writing overly complicated code is socially unacceptable.
-=-= Another thing I am realizing, over the period, specially shift in architecture style because spring (aka IOC pattern), it has made programmers better. We can't blame everything on EJBs etc any more. Early JAVA programmers were treating java as magic bean instead of putting good effort on learning & writing programs right away.
Oracle should thank Apache & Spring.. in my opinion.
Java / JVM is the right tool for some jobs, and not the right tool for many others.
It's definitely not an essential for core services and web applications, but is a valid option.