
Java for Everything - cousin_it
http://www.teamten.com/lawrence/writings/java-for-everything.html
======
msluyter
There's the language and there's the ecosystem. A lot of negative feelings
that still linger are, IMHO, directed more at some of the painful historical
aspects of the ecosystem: J2EE XML configuration hell, EJBs, bloated
application servers, XML for everything, JAX-WS, SOAP, ant, classloader
problems, maven dependency hell, 10 different logging libraries, etc... A lot
of this stuff truly sucked.

But I feel things have improved over time. Dropwizard, gradle, embedded jetty,
jersey, guava, Spring boot, etc... The trend is towards minimizing
configuration and overall, the ecosystem has become somewhat more manageable.
I wouldn't necessarily call it _pleasant_ , but it's better.

An as for the language itself, Java8's lambdas + streams provide significant
improvements.

Compare this (Java 7):

    
    
      public static List<Integer> sortDescending(List<Integer> ints) {
    
          ints.sort(new Comparator<Integer>() {
              @Override
              public int compare(Integer o1, Integer o2) {
                  return o1.equals(o2) ? 0 : o1 < o2 ? 1 : -1;
              }
          });
    
          return ints;
      }
    

to this (Java 8):

    
    
      public static List<Integer> sortDescending2(List<Integer> ints) {
    
          ints.sort((o1, o2) ->  o1.equals(o2) ? 0 : o1 < o2 ? 1 : -1);
    
          return ints;
      }
    

(Example is contrived, since you could use the built in Collections.reverse()
to achieve the same result. My main point is that we have eliminated ~4 lines
(counting braces) of ceremony.)

All that said, I'd rather be using Clojure.

~~~
MarkMc
Ant has a bad reputation? I clearly didn't get the memo - I find Ant to be a
great little tool.

~~~
jimbokun
Some of us don't care for XML as programming language syntax.

------
lmm
Verbosity matters for reading and maintenance far more than it does for
writing. IDEs can make the writing faster, but they can't make the code as
easy to comprehend as it would be in a more expressive language. And remember
that lines of code is the _only_ proven risk factor for bugs.

Most sites are not Twitter. They're not Stack Overflow. They're not even
Nanowrimo. I've watched a company spend two years, dozens of developers, and
over a million in ESB license fees failing to write a site that was expected
to have, at peak, 100 users/day. Their competitor had four guys writing Ruby,
and was profitable after the first month. Nor are the performance advantages
"permanent"; even if you use Java, you will probably have to rewrite if you
reach Twitter scale, because your initial app won't be clusterable (or if it
is, it's massively overengineered and your business will fail). So do it the
way twitter succeeded - write the first version in Ruby, and then worry about
performance when you need to.

The advantage of using the same language on both sides of a boundary are real
but overstated. If you have a system with multiple components, you probably
need to evolve the interfaces between them, and you need to be able to upgrade
without downtime. Which means you need well-defined interfaces for which you
understand the compatibility implications - in other words, you need something
like Thrift. I've used Thrift even for Java-Java interfaces, but once you're
using something like that it doesn't matter which language is on the other
side.

Still, the library point is valid, as is the point about spending time with a
language. Better to have one language that you know very well than ten in
which you dabble. But by the same token it's worth taking the time to make
sure that language is the very best available. I use Scala for everything, and
there's plenty to learn - maybe even twice as much as a "normal" language. But
if I'm focusing on that one language, I can afford to take the time to learn
it really well. And Scala combines the expressiveness, clarity and scripting-
suitability of Python (yes, it can be unclear if you use silly method names or
libraries that use silly method names - don't do that then) with the strong
type-safety and performance of Java. It's a great language in any case, but
especially if you want a single language for everything, I don't think
anything else comes close.

~~~
twic
> I've watched a company spend two years, dozens of developers, and over a
> million in ESB license fees failing to write a site that was expected to
> have, at peak, 100 users/day.

I'm sorry to hear that. But you understand that this had nothing to do with
Java, right? Java didn't make those people do that. That was just good old
fashioned human stupidity. It's entirely possible to write simple things in
Java, without ESBs and a person-century of effort.

It's even possible to write simple things in Java EE - there's an enjoyable
little book about it: [http://press.adam-bien.com/real-world-java-ee-night-
hacks-di...](http://press.adam-bien.com/real-world-java-ee-night-hacks-
dissecting-the-business-tier.htm)

> Nor are the performance advantages "permanent"; even if you use Java, you
> will probably have to rewrite if you reach Twitter scale, because your
> initial app won't be clusterable (or if it is, it's massively overengineered
> and your business will fail).

I don't think this is true either. The normal approach to writing scalable
apps these days is the twelve factor approach:

[http://12factor.net/](http://12factor.net/)

And that works just as well for tiny deployments as huge ones. It doesn't
involve doing anything arcane and expensive up front. It's mostly common
sense. Scaling out will involve a lot of changes, but incremental ones.

~~~
userbinator
_It 's entirely possible to write simple things in Java, without ESBs and a
person-century of effort._

That I don't disagree with (see Java4K and various other demoscene-like
competitions), but when the mainstream _culture_ of Java is oriented towards
architecture-astronautism and "enterprisey" bureaucratic excesses of
complexity, that's what the majority of Java developers you find are going to
do. Ask them why a simpler (and less time-consuming) solution wouldn't suffice
and they'll respond with things like "robustness", "extensibility",
"modularity", "encapsulation", "abstraction", etc. even when none of these
properties are truly applicable to the situation at hand. If I were to guess
why, they're just so accustomed to writing code with such indirectness that a
simple solution feels "wrong" to them. I worked very briefly for a Java shop
and on one occasion my code was rejected, and was told to "refactor" a fairly
trivial 20-line method in one class into 8 separate classes each containing
1-line methods on account of the fact that my original code was not
"extensible" nor "modular" enough. I was suggested to introduce a design
pattern to do this. Any advantage of that extra flexibility was never realised
since the application was eventually completely scrapped in a rewrite. (I left
shortly after that.)

~~~
fsloth
"was told to "refactor" a fairly trivial 20-line method in one class into 8
separate classes each containing 1-line methods"

How typical is this level of non-value adding misguided pedantism? I
understand that big software consultancies would want to milk their clients
for all the work they can for implementing function points. But what
profitability models drive developers to this level of weirdness? Is it just a
cultural pathology?

~~~
pjmlp
Enterprise. It is just how the enterprise world works.

~~~
markbernard
No it is not. Just because you have a one bad experience, doesn't mean that is
how the enterprise works. There are hundreds of thousands of enterprise shops
out there. We don't do anything like the craziness you guys are talking about.
We make it work with the easiest code possible. If necessary we refactor when
we need to make a solution more generic.

------
Osmose
A significant amount of the article is arguing that Java for everything is
better because the author and his coworkers already knows it. I can make the
same argument for Python _for me_. And for my company too; we have a ton of
Python developers already, so it makes sense to write things in Python if
possible in case someone needs to change or improve anything.

The author also talks about how Java's verbosity is a trivial issue, and in
terms of "stuff you have to type", I agree. The point isn't to save a few
characters to type. To me, the problem with Java's verbosity is that it
_impedes understanding_. The excessive notation required by type declarations
and generics and so on are visual noise that distract from what the code is
doing.

There are some valid points raised too, such as concerns about Python's
scalability, but that's an argument for _choosing the right tool for the right
job_, which, while mocked at the beginning of the post as a way to avoid an
interview question, is still good advice. For a lot of projects, Python is
fast enough to handle the expected processing, has an ecosystem with libraries
that handle all of the things the project might need to do, and is portable
enough to run on the platforms necessary. For some projects, it fails one of
these, and another language may be a better choice. That's okay!

I think the best takeaway here is that it is sometimes useful to see if you
can leverage your existing knowledge in one programming language by applying
it to a task you don't normally use it for. By all means, write shell scripts
in Java, maybe that's really useful! Or maybe write a GUI in Haskell!
Transpile BASIC to frontend code!

(For context, I use Python for web development (both small and large sites),
scripting, and a few personal projects like a music player or emulator. I did
a bunch of Java in college and some internships.)

~~~
edwinnathaniel
Though the lack of noise could also translate to parsing things in my head
trying to understand what is happening in this super short code....hence it
takes longer to read the code!

~~~
lmm
Maybe, but what are the examples? "Foo f = new Foo()" takes longer to read
than "f = new Foo()". An anonymous class is longer than a lambda and also less
readable, as Java folk have thankfully finally realized. "public static void
main" does not clarify anything. Getters and setters are the bane of my Java-
reading life, because 99.9% of them are the exact same autogenerated four
lines, but you still have to read them all in case one of them is different.

Also, there's a huge jump in readability at the point where a method or class
fits on a single screen. So if 4 lines of Java = 1 line of Brand X, but it
takes me the same amount of time to read 4 lines of Java or 1 line of Brand X
- that's still a win for Brand X, because it's much easier to write classes
that fit on a single screen.

------
one-more-minute
The problem with verbosity and repetition is _not_ that it takes longer to
type the code, at all. The problem is that it creates dependencies which you
have to manage by hand.

Changing `Foo a = new Foo()` to `Bar a = new Bar()` doesn't seem that bad...
except when you have to propagate that change through the code base. Half of
Java's tooling is dedicated to solving a problem that doesn't exist in good
duck-typed languages or those with type inference.

Verbosity is also a warning sign for lack of expressive power. If you have a
pattern like `if (cmd == "run") run();` in multiple places in your codebase,
you want to make it so that changing one changes them all. Java won't let you
factor this out easily, but worse, it won't catch you when you make a mistake
(better languages will either do first-class functions or pattern matching and
exhaustiveness checks).

Note that this has nothing to do with static vs. dynamic; verbosity is a
problem that can be solved in many ways, but it _is_ a problem. The author
also spends a lot of time equating statically typed with fast; well, there are
plenty of very fast dynamic languages.

There certainly are reasons to like Java, but these aren't them.

~~~
rzwitserloot
DISCLAIMER: I write mostly java, at home and at work.

Refactoring goes a lot further than just renaming types. A refactor script
_WILL_ rename both sides of 'Foo x = new Foo();' to 'Bar x = new Bar();', so
given the right utilities (and if you use java for everything, it's _MUCH_
easier to become an expert at the tools!) this is not any more effort at all.

However, there are refactors for things that are much more difficult in a duck
typed language. For example, if I have a bunch of methods named 'execute()' in
my code, and I decide that this is a sad state of affairs and ripe for a
refactor, I can refactor one of them to a different name and the tools will
'get it right', renaming the right calls (calls into this type) and not
renaming the wrong ones (calls to another type's execute() method which has no
relation to this type's execute() call). In python, you just can't do that.
You'd have to rename all of them, defeating the point.

Similar concerns crop up for 'find callers', or 'add argument to method'.

There are also refactor scripts that are equally possible in both python and
java, but which nevertheless require either a lot of manual editing, or an
intelligent tool that can automate it, such as 'extract method' (taking the
selected code and turning it into a (helper) method, figuring out which
variable(s) would have to be passed along to make it all work as needed.

The point is: Duck typing does not obviate the need for refactors. It does
make certain refactors impossible to 'safely' automate ('safely' in the sense
of ensuring that, post-refactor, the code does the same thing as it did pre-
refactor).

As far as 'dynamic == slow, static == fast' being a bit of an
oversimplification, yup, that's true. Java _IS_ a heck of a lot faster than
python, but that's mostly an implementation detail; you could make a pretty
quick python. dynamic definitely does not help, but it can be worked around.
Javascript JIT engines are seeing a lot of serious improvements right now, and
a large part of it is guesstimating type info. They're getting pretty fast.

In the spirit of the article, though, static typing isn't just a boon for
speed reasons (based on the practical upshot that java IS fast, and most
dynamic solutions simply aren't, even if they could be with more engineering
efforts): It becomes quite useful when you start having to read the additions
to your code written by someone else, or rereading your own code half a year
down the line when updates are required. explicit static typing also helps
with refactoring, which is useful especially when you have to fix or extend
your project.

~~~
desdiv
_Refactoring goes a lot further than just renaming types. A refactor script
_WILL_ rename both sides of 'Foo x = new Foo();' to 'Bar x = new Bar();', so
given the right utilities (and if you use java for everything, it's _MUCH_
easier to become an expert at the tools!) this is not any more effort at all._

Ctrl-Shift-R B A R

No, not much effort at all. Just twice as many keystrokes.

I wouldn't even mind the verbosity if it actually gave me some speed
improvements, but it doesn't. There are plenty of statically typed languages
where you just write _x = new Foo()_ and the compiler will figure out the
types for you.

~~~
tormeh
It will give you faster compilation speed, though.

~~~
desdiv
Think about it, does it really?

To parse _Foo x = new Foo();_ , javac has to perform type inference on the
right hand side to figure out its type, and then check whether that type is a
subtype of the left hand side. Telling the compiler: "hey, trust me, variable
x is of type Foo" doesn't make the compiler's job any easier at all.

~~~
one-more-minute
In that case specifically, no, but in general doing type inference means
running a constraint solver over the entire program, which will definitely add
some overhead to the compilation time.

~~~
avita1
Yup, the best example I know of is resolving implicit scopes in Scala.

------
linuxhansl
Committer to Apache HBase here:

I agree with the author on some level. All of HBase and Hadoop (except for a
little bit of native stuff) is implemented in Java.

I found that to be + and a -.

Java is easy to understand and to follow, lends itself _very_ well to large-
team development, and performs well in most situations. The alleged verbosity
I do not mind. I have tools, and well structured code is easy to follow.

Java (or the JVM really) does have limits, though. What I miss by far the most
are simple pointers and access to the RAM outside of the Java heap. Then again
I am working on a low-latency database. Yes there are DirectByteBuffers but
they are annoying to use, just gimme a struct (some IBM folks are working on a
proposal for that for Java). Everybody in this space who is using Java invents
their own off-heap code to avoid heap allocations and the inevitable garbage
collections. G1 will make it better, but not eliminate this.

I still user other tools: Python, Ruby, Bash (yes), JavaScript, C/C++, etc,
and I disagree with the author's premise. It depends very much on what I
attempt to do which language/ecosystem I will use for that.

Edit I: In the end I prefer to versatility of Java over the limits I face with
it. Would I write a Kernel in Java: No. At least not with the current JVM.

Edit II: We should not conflate Java with the JVM.

~~~
pjmlp
I guess you aren't aware of

[http://openjdk.java.net/projects/panama/](http://openjdk.java.net/projects/panama/)

[http://openjdk.java.net/projects/valhalla/](http://openjdk.java.net/projects/valhalla/)

[http://openjdk.java.net/projects/sumatra/](http://openjdk.java.net/projects/sumatra/)

Some of the features will come in Java 9, others in Java 10.

------
ridiculous_fish
You have to appreciate bombastic statements like this for forcing you to
confront your assumptions. "Everything in Java? Even a kernel? That's absurd."
you think, and then wonder what makes it absurd, and realize that it could
perhaps be done with some modifications, and remember Singularity, etc.

But on the other hand, this is well trod ground. Everything WAS going to be
Java. Remember picoJava, the bytecode-native processor? Remember Cocoa Java,
for OS X desktop apps? Remember HotJava, the pure Java web browser? These
things were tried, and they failed. Performance issues, especially around
startup and memory usage. The weightiness of the JVM, what Jobs called a "big
ball and chain." The weird foreignness of Swing apps. The generalized misery
of applets. Etc.

So honest question: what's different this time?

~~~
marktangotango
Great perspective! I don't think 're-implement the world in java' was the
point of the blog post. I do follow you're line of thought however. Vala is a
Java like language (in the same way C# has a subset that is Java like) that is
AOT compiled by translating to C.

Interestingly, it has a few departures that make it very un Java like. For
example, Vala uses reference counting for memory management and provides a
'weak' keyword, passing reference cycle management off to the programmer. And
voila, no gc (edit: or rather no centuries level of effort garbage collector
implementation, with associated performance indeterminism). Another departure
is no dynamic class loading.

Point: I use Vala as a proof by example there's a language out there that's
statically typed, highly productive, GC'd, and AOT friendly, for which some
formulation of "X Everywhere" is not far fetched.

------
jrochkind1
I am more convinced by the part "write everything in one language", and less
convinced that Java is a great choice for that language.

On the other hand, if you're going to write everything in one language, you do
need a language that is capable of doing nearly everything, and doing it well.
And I see how Java is a reasonable choice.

But yeah, I think "pick the right language for the job" (and the corresponding
"when all you have is a hammer...") under-estimates the extent that the right
language for the job is the one you know best, because you'll be able be most
effective in it.

------
jim_greco
The biggest thing for me is that the tooling around Java makes maintaining
large projects extremely easy. Being able to refactor hundreds of files in a
few keystrokes without worry lets me sleep well at night. It's certainly a lot
faster to get up and running with a dynamic language, but the initial build
out is a small percentage of the overall time you are going to spend with a
codebase.

I've also built just about everything in Java from HFT algos, to an exchange,
to a web server, to thick clients so I have an idea in my mind about how to
solve any new problem that comes up.

~~~
pimlottc
I think this is the key point in the debate - weighing initial development
time against ongoing development and maintenance. It's something that's hard
to grasp until you've been around for a while working on real-world large-
scale projects. And it's a hard thing to get the sense of when you're in
school, writing throwaway code that doesn't last past the end of the semester.

When you understand this, then you can make an honest assessment - is it
really important to get the first build out that much quicker? Sometimes it
is. But I think it's overemphasized. The first one to market doesn't always
win. And the shift from new development to maintenance happens quicker than
you might think.

~~~
hvidgaard
First to market has never ever been about using a dynamically typed language.
Getting the ideas from talk to concepts, testing, bugfixing and marketing
takes vastly more time than actually developing the code. So while Python
might enable me to show my prototype on Monday, while that Java version
wouldn't be seen until Friday, there still is quite a lot of time before you
can say it's properly released.

Where these "fast" to develop languages shines are throwaway prototypes. For
some people their ideas flow out much faster with dynamically typed language.
But it is all too well known that even though the manager said you could throw
it away, they change their mind because "it's basically finished, right?".

That said, you are spot on. Initial development is likely not where you want
to focus at all, for any kind of project that needs to be maintained for more
than a few months.

------
exabrial
If you're _actually using_ good tools (Something like IntelliJ or Eclipse, and
something like Maven or Gradle), and you use sane variable and function names
(business oriented instead of tech oriented) verbosity is one of the worst
arguments against Java.

The verbosity, static typing, etc, of Java contributes information to the
"next guy" about developer intent and is incredibly valuable.

~~~
mlvljr
"You just don't get Rails [Python / ...], ri-ight??"

;)

------
zwetan
I completely buy the idea "write everything in one language", even if I do it
with a different language for completely different reasons.

In general I think "use the best tool/language for the job" and anyway any
tool/language will have pros and cons, nothing is perfect.

My context is I was a big ECMAScript fan, then I moved to use something called
ActionScript 3.0 and there I just found the "right balance" between verbosity,
correctness, speed, etc.

That's the work part, I use AS3 and AIR to build mobile app for iOS/Android.

Then there is the hobby part, in 2006 Adobe open sourced their ActionScript
Virtual Machine (AVM2), I started to work on it (OSS project RedTamarin) in
2008 because I had this silly idea "it would be fun to run AS3 on the command
line".

So, few months ago, with a not too bad release of this RedTamarin project, in
the spirit of "use your own dog food" and trying to push the limit of what can
be done with this open source project, I kind of decided to use only AS3 for
all development, either work or home.

I don't do that because I think it is better or faster, but mainly to see how
much I can reuse in code and logic, and if ultimately it make things easier
for me (as any dev I'm lazy).

The result is quite interesting, so far I can run AS3 in shell scripts, as
server side CGI, as command line tool, and tons of different use case I would
have not necessarily explored if I didn't forced myself to use the same
language for everything.

My point here is the same way you can learn a different programming language
every few months/years to learn new stuff, there is also a value of forcing
yourself to use only one programming language for everything.

In my case it forced me to explore some context deeper instead of taking them
for granted, sure some ppl could say you waste your time because you're
reinventing the wheel, but I would argue you learn a lot more when you try to
know all the little details that make a wheel works :).

~~~
aikah
interesting,I need to check it out,you should add a link to the project. I
definetly like AS3,it's a good compromise between javascript and java.

~~~
zwetan
here you go [http://www.redtamarin.com/](http://www.redtamarin.com/)

and the g+ community
[https://plus.google.com/communities/111596731002136630496](https://plus.google.com/communities/111596731002136630496)

and yeah it's kind of why I'm doing that, AS3 is for me a good balance

as a side note, the way redtamarin is implemented you have access to almost
all POSIX C functions from AS3 which can also be seen as a "Friendly Dialect
of C"

------
austinz
First of all, I want to say that if you like Java, and know it well, and
believe it to be the right tool for your particular application, that you
should absolutely use it.

> That Java is the right language for _all_ jobs. _(Emphasis his.)_

> The advantages of C and C++ [...] don’t apply to my work.

So, choose the right tool for the right job.

As for the examples given:

> At one company I wrote a simulator that allowed me to run my Java services
> without a fully-functional site. _(The unit under test is Java, so it makes
> sense to write the simulator in Java, rather than Javascript)_

> My partner Dan Collens suggested Java [for a log parser], since it’s right
> there and we know it and it’s fast. _(The log parser is used so often that
> the amortized opportunity cost of developing in Java is more than paid off
> by faster processing, therefore Java is the right tool for the job)_

> And finally, I went to write a simple program that put up a web interface.
> _(This is something the author has done many times before and knows how to
> do well in Java, and his primary goal is getting it running ASAP, therefore
> Java is the right tool for the job)_

I still think you should choose the right tool for the right job. It just
happens that the author's work is constrained in such a way that Java turns
out to be the right tool in most, if not all cases.

Honestly, though, I would rather choose the same tool for a job each time by
deciding that it's, by merit and virtue, the best tool for the job, rather
than relying upon the author's silly heuristic.

~~~
banachtarski
This is the correct response to this article. He makes a big deal out of
saying he doesn't need to "choose the right tool" anymore. But then later, he
feels compelled to qualify that Java is the right tool for him, which sort of
invalidates his former point.

In other words, I viewed this article as a large waste of time. Nothing has
been added to what is already conventional wisdom.

------
lkesteloot
It's not so much that Java is great at everything. It's more like it doesn't
suck at anything. Every other language has, somewhere, a deal-breaker for some
particular use. I've not found one for Java. And Java's biggest downside,
frankly, is that it hasn't attracted fresh young talent in a while, so it
doesn't have really hot frameworks and libraries.

~~~
iolsantr
Java's start up time makes it pretty crappy for command line utilities.

~~~
mike_hearn
When did you last try it? Startup time was optimised heavily some time ago and
nowadays I don't notice any real difference unless I wrote some toy app and
used "time". The JVM starts fast enough that you can write command line
utilities just fine.

~~~
saosebastiao
It is certainly _substantially_ better than it used to be, but it is still
pretty far away from an AOT compiled native executable. And forget it entirely
if you are running Clojure or Groovy code.

~~~
peterashford
The class of tasks for which Java's startup time is an issue is very very
small. I wouldn't use it for a device driver because of resource issues but
there aren't many command line commands where 0.08s is an issue.

------
Mithaldu
He learned something that most good Perl programmers learn fairly quickly:

The interpreter/compiler is just the VM; the real language is the combination
of all libraries available for it.

~~~
andor
There's no shortage of good libraries for Python. He just chose to not learn
about them.

~~~
pjmlp
And all the fast ones aren't implemented in Python....

~~~
lmm
So what? For most problems there are fast, well-designed libraries available
with idiomatic python interfaces; why would you care about the implementation
details?

~~~
BuckRogers
Note, this is coming from the same guy who programs in x, which was also
implemented in C(++). Like the JVM, CLR ad nauseum. :)

~~~
pjmlp
Do you know that there are JVM and CLR meta-circular implementations, right?

And that the reference implementations get less C++ code with each release.

------
bonobo3000
This is exactly how I feel about Scala now.

I really wanted to like Java because of the ecosystem and the JVM, but there
ARE a few warts that you will face everywhere - verbosity is one, all the
Spring stuff using annotations to wire up dependency injection and AOP and
whatnot is another.

Scala has the whole JVM ecosystem, static typing and forget about DI/AOP/OOP
patterns. Feels like best of both worlds for me.

~~~
justinsb
I find Java much more pleasant without Spring; I much prefer
Jetty+Jersey+Guava+Guice. It sounds like that's pretty similar to how you're
using Scala.

~~~
lmm
80% of the problems with java as it's usually written are bad policy rather
than fundamental language problems. But there are real cases where language
limitations mean you have to either use an unpleasant framework or write
unpleasant code.

Jersey's annotations are pretty nice, but they're still annotations, not
really part of your code. You can be bitten by silly errors like an
implementation's annotations not quite matching those on its interface, and
when (as is often the case) the annotations get repetitive for a group of
similar services, there's no way to factor the common part out. In Spray I can
write route definitions that are just as neat as the Jersey ones, but it's
_plain old code_ which is an enormously powerful concept; a route can be
refactored just like any other code.

Guice is similar, e.g. declarative transaction support; better than managing
database transactions by hand, but annotation-based proxying is a bit "magic"
and confusing to debug. In Scala I can use a monad for transactional
operations; the code (using for/yield) is almost as effortless as annotations,
but operations which use the database show that in their type and the type
system enforces that my transaction boundaries are in the right place. Even
more importantly, refactoring in the normal way is safe.

(Also e.g. the lifecycle features in Spring are really valuable (and virtually
impossible to do without annotations in Java, at least pre-8). In Scala
there's scala-arm, which achieves the same thing in a monadic way, with the
same advantages as doing that for database transactions. And since the same
abstractions are used in both cases, you can write types and helpers that work
with both "database operation" and "requires lifecycle-managed resource")

~~~
edwinnathaniel
So here's the thing about annotation and Jersey, I believe you can annotate
the seralization of return type once at the top of your resource class, the
rest, like http verb, needs to be repeated unless you take the convention one
more level up a'la Rails. But that's Rails, a web framework that people said
does not fit for microservice. Sinatra is.

But if you take a look at how Sinatra (or Rails) serialize the returned
object, you notice the duplicated code. Especially if you want to return both
JSON or XML based on the request header. To add to this, both frameworks do
this serialization as part of the code logic that you have to write, instead
of slapping annotation once...

Let's take this further: exception mapping to http response code. In JAX RS,
you can map application exception to certain WebApplicationException with
specific http response code, I believe you have to handle them manually in
Sinatra. You would have to catch the exception and convert it to the intended
one per method on your controller.

~~~
lmm
> But if you take a look at how Sinatra (or Rails) serialize the returned
> object, you notice the duplicated code. Especially if you want to return
> both JSON or XML based on the request header. To add to this, both
> frameworks do this serialization as part of the code logic that you have to
> write, instead of slapping annotation once...

I can't speak for Sinatra, but in Spray I'd just write a directive for this -
maybe it exists already, but if not, it's a couple of lines - _and then I can
use it just like any of the built-in directives_. And this is a perfect
example of why "just code" is so powerful. Jersey is a very well-designed
framework and I'm sure you can find examples where the built-in Jersey thing
is better than the built-in Spray thing. But no framework is perfect, at some
point you find yourself having to extend these things - and in Jersey's case,
IIRC once you want to write your own annotation you need a magic .service file
containing a class name to use to interpret that annotation. And then the only
way to pass dependencies to that processor is by static global variables. Good
luck refactoring that, and don't expect to be able to use hot code replace
when debugging it. And good luck remembering how the mechanism works in six
months' time. "Plain old code" has a lot to recommend it here.

> Let's take this further: exception mapping to http response code. In JAX RS,
> you can map application exception to certain WebApplicationException with
> specific http response code, I believe you have to handle them manually in
> Sinatra.

Again, trivial in Spray - I do my error-handling with Either and then I have a
meta-marshaller that knows what to do with the error case. Better still, error
handling isn't a special case - I do exactly the same thing if I have async
code in my methods (can JAX-RS handle Futures? Can it handle a different kind
of Future from a non-standard third-party library?). I can do exactly the same
thing with a database-transaction monad, and then I can have session-in-view
but in a principled, safe, zero-magic way. I can do the same thing to e.g.
show debug traces if a special header is present - like Jersey's dynamic
choice of serialization format that you were so impressed by, but it doesn't
have to be built into the framework, it's just code that I can write myself.

~~~
edwinnathaniel
I've been using Jersey since 2010 and I have never need to write my own
annotation. Maybe I'm lucky enough that Jersey fills my need perfectly and
maybe you're right that once I needed to write my own annotation, I may run
into a bit of trouble (though some people do write annotation only to be
consumed by reflection, hence bypassing the service file) but I guess...
that's like.. what... 1-5% extreme use-cases? Like... LISP macros that makes
programmer reached nirvana or something?

But in my case, Jersey fills my need without me writing low-level REST code
(dealing with exception to HTTP status code, marshalling objects to different
formats) embedded in my controller/business logic.

> I can do exactly the same thing with a database-transaction monad, and then
> I can have session-in-view but in a principled, safe, zero-magic way.

You sound like programming in another level higher than mine. I applaud that.
I'll revisit Spray/Scala _when_ I found a definitive use-case for this. For
now, Java seems to fit the bill for pretty much 99% my use-cases and fit my
taste as well (less low-level code stuff because it is built-in the framework
that is well-architected/well-designed so that I can focus on business logic
code).

~~~
lmm
> You sound like programming in another level higher than mine. I applaud
> that. I'll revisit Spray/Scala _when_ I found a definitive use-case for
> this. For now, Java seems to fit the bill for pretty much 99% my use-cases
> and fit my taste as well (less low-level code stuff because it is built-in
> the framework that is well-architected/well-designed so that I can focus on
> business logic code).

Sometimes you don't need it, but there are blub-paradox cases as well; I tried
to sum up a few of the things I retrospectively recognize I was missing in
Java in [http://m50d.github.io/2014/05/16/signs-your-java-
program.htm...](http://m50d.github.io/2014/05/16/signs-your-java-program.html)

A lot of it is just being able to track things in the type system that you
wanted to track in Java anyway, but it seemed too hard. I mean, I've worked in
Java codebases where it would have been very nice to see which methods
accessed the database as part of their type. I've even seen one that used a
kind of Hungarian notation to express this - in fact if I can point to a
single place that set me on the road to Scala, it's
[http://www.joelonsoftware.com/articles/Wrong.html](http://www.joelonsoftware.com/articles/Wrong.html)
. Because I read that and then thought: hang on a minute, why not just make
whether a String is encoded part of its type-type, the type that's enforced by
the compiler?

~~~
edwinnathaniel
Hey, Thanks for your article. I've read that and I can see how/where Scala is
useful!

I'm definitely going to learn Scala once my adventure in JavaScript world
wrapped up.

------
mythz
What he said, but C#.

C#'s one of the most versatile languages which can target most of the popular
platforms, e.g: iOS/Android (Xamarin), WindowsPhone, Windows, Linux, OSX,
Silverlight, PS4, XBox (announced), Unity3D and NaCL.

C#/.NET's biggest weakness of sub-optimal cross-platform support should also
be resolved in the near future now that .NET's compiler, core runtime and
class libraries are OSS and with Microsoft announcing support and plans to
release official distributions for Linux and OSX - so .NET will finally have
multi-platform support of a single code-base resolving earlier issues or
running .NET on OSX/Linux due to different impls.

~~~
georgemcbay
My version would be "what he said, but choose any well-supported statically
typed language, particularly one with decent type inference, since that gets
you a lot of the convenience of dynamic typing without all of the very many
runtime-error downsides".

------
fenesiistvan
Java is perfect also for client side. We have a client app (a complex VoIP
softphone) with different codebase for all platforms (C++ for windows, java
for android, ObjectC for iOS). Right now we are in the way to reduce all this
in one single codebase written in Java and the user interface in
html/css/javascript, so the user interface is always running in a webview.

-Java for windows desktop (there are pretty installers which automatically download and install the JRE if not present)

-Java for MAC and Linux desktop (same as for windows desktop. the same installer tools can generate also Linux and MAC packages)

-Java for Android (with a very minor conversion for which we already wrote a converter app)

-Java for Web (currently using a java Applet which works perfectly. We plan to use GWT to transform to JavaScript in the future)

-Java for iOS (will see)

This way we plan to cover 99% of all devices with java only (with some minor
transformation for some platforms). What is your opinion on this? I am in the
right direction?

~~~
drivingmenuts
> Java is perfect also for client side.

Unless you want it to look totally native client-side. The extra effort
required to make a Java app look platform native is something that (near as I
can tell) no one has ever attempted.

~~~
mike_hearn
IntelliJ has historically looked pretty native on MacOS X. At least until
Yosemite pointlessly reskinned Aqua to look more ugly. Now I find myself quite
happy that IntelliJ is not a native Mac app because I preferred the old look
anyway :)

You can make the apps look native, if you really care. But in an era when web
apps are the shizzle why would you even care? No web app even tries to look
native. They just do their own thing and nobody cares.

~~~
Redoubts
>IntelliJ has historically looked pretty native on MacOS X.

Because they require the use of Apple's hand-rolled Java 1.6

[https://youtrack.jetbrains.com/issue/IDEA-117324#comment=27-...](https://youtrack.jetbrains.com/issue/IDEA-117324#comment=27-706613)

------
rcarmo
I've mostly embraced the JVM (as opposing to hating it), but I find myself
reaching for Clojure a lot more than Java (although I have an Android app that
I'm tinkering with). I find that an IDE helps (I use NetBeans for pure Java),
but whereas I can hack just about anything in Clojure, Python or Go without
much hassle, Java slows me down for some reason - I suspect it's the humungous
class hierarchies and the time required to find whatever I need to accomplish
simple tasks.

~~~
Xorlev
Once you get used to working in Java (and have a relatively stable toolchain
you can depend on), it's realistic to develop applications in Java almost as
quickly as Clojure, though complex aggregations that Clojure makes one-liners
will often be vastly slower to develop.

IntelliJ makes a lot of things easier as well.

When it comes to Java, you just need to really get familiar with your tools
before you can be as productive, but once you are you can move quickly. Using
Java 8 doesn't hurt either, streams are pretty decent.

~~~
spullara
In Java 8, those one liner aggregations are now possible and part of the
standard library.

~~~
Xorlev
I love Java 8 streams, but they're still awkward compared to Clojure.

------
chadrs
This whole "expressive vs. performance" is a false dichotomy. Languages like
Scala and Haskell are performant like Java and expressive like Python. Not to
mention the work being done on JIT compilers by V8/HHVM/PyPy that are helping
to close the performance gap for dynamic languages.

~~~
BenoitP
I am maintaining at the moment some Scala code I did not write. Sometimes you
wish for less expresiveness.

~~~
swah
A couple years ago there were several people complaining that is was a write-
only language.

(Of course, others said that it was a matter of educating your devs about when
not to use some features...)

When I first tried it, the slow compilation killed it for me (not a problem
for Clojure because a connected Emacs makes for a killer setup...)

------
prohor
I would just add one more thing - I doubt there is another language where you
write native apps for Android, iOS and Web sharing 70% of the code:
[http://arstechnica.com/information-technology/2014/11/how-
go...](http://arstechnica.com/information-technology/2014/11/how-google-inbox-
shares-70-of-its-code-across-android-ios-and-the-web/)

~~~
grimlck
C++ (Using something like emscripten for the web)

Although, i'd pick java over C++ unless i'm doing some very performance
critical

~~~
pjmlp
While true, it is a pain on Android, given how the Android team treats the C
and C++ developers.

The official set of APIs is quite limited and JNI is required for any app that
isn't a game.

Even C++ libraries that are wrapped in Java classes, like SKIA, are only
accessible via JNI.

------
harvestmoon
Java doesn't seem too popular here but used right it can work pretty well,
imo.

For instance, I use Java for the backend of a name generator web app. It's
astonishingly fast and displays results almost instantaneously despite running
a good amount of backend calculations.

This speed became an issue because you'd push the go button and the names
would update - but it seemed like nothing happened. So I ended up adding an
artificial delay twice (the first time it wasn't enough of a delay).

On the other hand, its structure and methods can at times be frustratingly
complex.

------
nickbauman
In real-world benchmarks in a real app I have tried to make Clojure slower
than Java. I can't. In rare cases Java will beat it in insignificant ways in
insignificant amounts, but I found that Clojure sometimes beats it in
significant ways because of the runtime's tendency toward laziness.
Furthermore, Clojure is a very dynamic language that can leverage every
library Java has plus all its own.

As a result I will not program in Java willingly. There's just no reason to do
it. Not with at least one language that's far better in real, quantifiable
ways. There are other languages that run on the JVM that could tell a similar
story. Unfortunately those are not Jython or JRuby.

~~~
swah
Its hard to explain, but I feel like Java would be a better choice for doing
something like audio decoding, while Clojure is orders of magnitude more
productive to prototype a webapp.

------
mangecoeur
You have to admit that for coders, the joy of writing helps a lot for job
satisfaction. I write both Java and Python (for very different applications)
and I just always feel like Java makes it hard to write anything elegant
almost on purpose. The proliferation of huge frameworks and FactoryFactories
clearly doesn't help.

I think you can underestimate the value in actually enjoying writing - I'm
just more motivated every day I can write elegant python code. Conversely
every day I spend fighting Java for an elegant solution and winding up
inevitably with something a bit half-arsed because of some limitation in the
language I just feel grumpy.

~~~
Terr_
The problem is that one guys "Joy Of Writing" rapidly becomes the next guy's
"Torture Of Reading", and with enough of a time-interval those two can be the
same person.

~~~
mangecoeur
I feel Python is good in this regard compared to other interpreted languages.
There's a lot of emphasis on "Pythonic" style which you tend to pick up as you
learn, so people are discouraged from excess magic (Explicit is better than
implicit) and the syntax at the very least lends itself to sane formatting
(especially with PEP8). Personally I've rarely had any true WTF moments
reading either my own code or code from (reputable) OSS projects.

------
larrys
Having literally deciding to learn java last week for no particular purpose
other than having enough understanding to be able to comprehend our software
(which is written primarily in java) and prevent brain deterioration, I'm
encouraged by the fact that the comments in this thread (so far) don't appear
to be very negative (like when reading about php).

While I did buy a book, I wonder if anyone has any suggestions on a good java
beginner's book assuming someone has "prosumer" programming knowledge (shell
programming, some perl, some php, sysadmin skills and so on). Suggestions?

~~~
scalesolved
Welcome to the Java world! Like some of the comments so far I think the Java
world is actually a pretty cool place to be right now, the language and
approaches are becoming a lot less verbose. I blogged about some of the best
Java books, hope it'll help you out! [http://scalabilitysolved.com/dont-hold-
back-your-java/](http://scalabilitysolved.com/dont-hold-back-your-java/)

~~~
larrys
Thanks for that.

Question though. The first book you listed (which got excellent amazon reviews
as well) was published in 2008. Typically I've been biased into thinking that
a book had to be somewhat recent. Obviously this isn't the case here though.
(Do you agree with that in some situations btw?). I would have never purchased
this book if you hadn't pointed it out so thanks it's in my cart.

~~~
allengeorge
Effective Java is a solid choice, and a lot of the advice is still relevant
six years later :) Also, JCIP is a go-to if you want to get more than a
passing handle on concurrency in Java.

~~~
scalesolved
Agreed, the java books I listed still provide more value to my core Java than
more recent books. I do the majority of my Java work now in the Play
framework, when I use a new framework or library blogs and stackoverflow are
my go to resources, for a deeper understanding of the library then those books
are the way forward.

------
ks
_> Map<String,User> userIdMap = new HashMap<String,User>();_

1.7 introduced a simplified version:

Map<String,User> userIdMap = new HashMap<>();

~~~
justinsb
And Guava has Map<String,User> userIdMap = Maps.newHashMap() which uses Java's
type inference rules, and works in 1.6 (I think even in 1.5)

------
zmmmmm
I think that the argument about verbosity is a subtle red herring. It's not
that you just have to write slightly longer words to do the same thing. It's
that you _can 't_ do the same thing at all because the underlying constructs
of the language are lacking in key powers of abstraction that make it easy to
simplify the problem you are trying to solve. You end up inventing whole class
hierarchies and patterns to emulate things that are either just built into
other languages or are easy to achieve because they offer more powerful
language features (like reified generics, etc.). Java 8 helps a lot, but there
are still fundamental weaknesses.

Having said that, I'm still a fan of Java. There's no other language that I
can sit down and reliably navigate through someone else's code in as easily -
and that comes partly because it's powers of abstraction are so limited.

------
mataug
I've been writing Python and Java(Android) side by side for a few months. I
feel that for all the advantages of initial speed that python offers it takes
a lot away. Especially in large projects. I spend a significant amount of my
python time trying to understand Types, and if those areas are not covered by
tests then I'm F __ked, I 'll have to spend hours trying simulate the exact
conditions of how an error occurred.

Don't get me wrong, I love python, but writing python requires a lot of
restraint and experience. Novice programmers who build a python code base just
screw things up, especially those who don't yet understand the value of
readability and maintainability.

I'd much prefer novice code on Java than on Python.

------
x3ro
The headline does not match his conclusion at all, in my opinion. What he's
trying to say is that "dynamic scripting languages are slower and more error-
prone than compiled, statically typed languages". And to determine whether or
not a scripting language is ever a good idea from 3 or 4 examples does not
seem like a good idea. E.g. Lua seems to be a pretty good fit for the WoW UI
scripting stuff and EA used Python (apparently successfully) for their Sims 4
scripting (sorry for it both being examples of games, those were just the
first that came to my mind :D)

------
tawy3
That's where Go comes in very well in the interviews assuming interviewer also
knows or can understand Go. It has short and precise syntax and the code
usually doesn't need explanation.

~~~
frowaway001
It's also not very useful.

------
overgard
You know, one of the things I notice about Java adherents: they think
programming is hard. There's this weird conservativeness to their culture. The
only times I've worked on Java teams, I felt like the biggest hurdle was
convincing people that things could actually be done. Its like they're
convinced that every programmer sucks.

I don't even hate java the language. It's far too mediocre to even bother to
hate. I just dislike java the community. It's so depressing.

------
einrealist
> I’m even taking this to an extreme and using Java shell scripts.

Having a strong Java background, it is a pleasure to write Groovy for shell
scripts.

I like the blog post. Whenever I looked into other languages/platforms, I
found the "tradeoffs" of Java (as pointed out by the other
languages/platforms) to be less important for me. Java/the JVM may be evolving
slowly. But it evolves and does it in a reasonable way (JCP, frameworks).

~~~
minthd
Why not just use Groovy for everything instead of java ?

~~~
sgt
Speaking of - how is Groovy doing these days? I looked at the Groovy webpage
and I saw ads splattered here and there - never a good sign, I also see that
the mailing lists are pretty quiet. Is Groovy dying?

~~~
frowaway001
I'd say not too good.

Of course there are those two projects everyone mentions, Grails and Gradle,
but I would say it's more correct to describe them as the only two niches
where Groovy is actually used a bit, it's not like Gradle and Grails are just
"flagship products" of a greater ecosystem.

For both, there are already better replacemens available, so I don't think
they will grow much in the future.

~~~
atomi
What do you replace Gradle with?

~~~
frowaway001
I'm extremely happy with SBT.

------
koffiezet
Everything in Java? Thanks but no thanks. I understand the author's point, but
he's choosing the wrong language. Does the perfect language for this purpose
exist? No - sorry. I've been charmed by Go lately and replacing python, small
C/C++ and shell-scripts with small tools written in it. It has great potential
for services and small tools and has a surprisingly large amount of libraries
available for it given the language's age. But would I say Go is perfect for
everything? Hell no - but it happens to be pretty good for what I need.

My view of Java may be a bit biased, since I also tend to look at things from
the sysadmin pov nowadays. I can only tell that I never disliked Java until I
had to take care of the monstrosities the Java developers bring to life, and
mind you - I started out as a Java dev back in 2000.

The main issue I have with Java is the JVM and memory usage and leaks. No
matter what people claim - no memory leaks in Java is a fairy-tale. We run
both custom C++ and Java services (about 50/50) on a few hundred servers - and
I cannot find a single issue in our ticketing system related to memory
problems with any of our C++ services. Java services? Every. Single. Week.
When I get an alert some JBoss unexpectedly died or became unresponsive -
"java.lang.OutOfMemoryError" is most likely going to be the problem. A lot of
those are permgen space errors, and yes you can try all the "fixes" like
increasing the permgenspace, permgensweeping, enabling class unloading, ...
but these don't always fix the problem and slow down your services. Every time
this happened in our own services, this had to be fixed by our developers. It
takes weeks to locate the problem, and you end up deploying new versions,
upgrading JBoss, JSF, Bouncycastle, ... whatever.

~~~
sandGorgon
can you talk about your jboss configuration ? We are thinking of building our
API stack in java and are considering wildfly (undertow). Honestly, you are
the first person who has talked about problems in Jboss and would appreciate
some more info.

~~~
koffiezet
The problems aren't really JBoss related. I have very little problems with
Wildfly itself. It is a clear improvement over previous versions, I had some
problems with v7 which required me to upgrade the JSF modules, otherwise JBoss
would suddenly die (in a crash & burn way) with a certain application we had.

It's mostly the "memory is not an issue" attitude most java devs have. It's
not JBoss specific, we also have some services written in pure Java suffering
the same problems - but the majority of the Java apps run in JBoss here.
Stress tests in test/qa usually don't bring up the issues I've seen, which
sometimes only occur after weeks of running flawlessly with production-grade
loads.

The 'fix' is then running the critical apps twice behind a load balancer,
waiting for one of the 2 instances to die (for logs/memory dumps),
automatically restarting them - and hoping they won't go down simultaneously.
Truth is - memory management in Java is HARD. When problems pop up, apparently
finding the source of it is very difficult. I can't count the times I've heard
"we think it should be fixed now", only to be confronted with another alert
that the service died again a few weeks later. If it was one service we'd run,
it would be fine, but we run quite a few more - resulting in weekly
interruptions, tickets, sending of memory dumps to developers, convincing them
- again - that it is their problem and not mine, ...

So well - I'm sick and tired of Java. The only thing worse to deploy and
manage are Ruby apps. But that's a personal opinion.

------
yawboakye
The article could be appropriately titled to reflect this wisdom: solve every
problem in whichever language is your strong suit. It's not always Java, and
arguing that Java is the one-size-fits-all would earn you few friends. For web
services the importance of the language is diminishing with solutions such as
cache, messaging queue, etc. I'd go on a limb to say getting your cache right
is the most important web service optimization.

All statements of the form "it's relatively faster to write programs in
language Y than language Z" are incorrect because it disregards important
parameters such as programmer experience with languages Y and Z, and whether
or not it's a comparison between 2 different programmers.

Also there are some performance gains that only pay off at Twitter or Facebook
scale [1]. Sometimes shaving milliseconds costs time but rakes in little to no
benefits.

[1]:
[http://carlos.bueno.org/optimization/](http://carlos.bueno.org/optimization/)

------
jpiabrantes
It's easy to make python faster, you have PyPy, you can even program
everything in python and then make a simple C code for the bottleneck and wrap
it with python.

Php it's another example, Facebook uses php and it made changes to its
compiler in order to make it way faster.

So bottom line, if people feel better writing in Python let's write Python and
improve it to make it faster.

------
BuckRogers
The problem with 'use the best tool for the job' is that everyone's 'best
tool' is selected from a relatively small pool. The choices for some use-cases
have a multitude of similarly worthy choices. Thus, not likely really the best
available. Just another subjective choice.

That said, I don't understand the obsession with 1 language to rule them all
that the Java and Javascript crowd seem to share. I do understand having 1 go-
to that you reach for to build projects. Something broadly applicable like
Java, C# or Python.

But shell scripting in Java? Seems a bit extreme, I'd never bother. You can
pull out a Python/Powershell script that does whatever you're trying to do and
do it much easier and faster. There's a reason Windows has C#/Powershell, and
Linux has (as an example) Java/Python.

------
otikik
...For a very personal definition of "Everything".

------
evanx
I'm thinking "Node.js for everything." It's way more fun, more productive, and
runs small and fast. Forget threads. I too used to believe "Java for
Everything." Over it. Write microservices in Node. Build front-ends in
Angular. Talk JSON.

------
davelnewton
No no, not Java for everything. I know Java, use Java, and don't hate it. Some
of the best tooling available (similarly C#, but .NET isn't my thing.)

Here's my issue: no matter what problem you try to solve the solution looks
like Java. I want my solutions to look like my problem.

Static imports go part of the way there, and if you're good at naming and
architecture, the learning curve for any particular system remains relatively
low. It's a hack/sugar, but it helps.

But that's about as far as you can go using only stock Java, e.g., no syntax
extenders, no byte code treachery, etc. AOP can help, but everyone has to be
aware of it, and comfortable with a system designed with AOP from the
beginning.

Java for shell scripts? No thanks.

------
zoobert
I read and liked your post. I like you love python but have to deal daily with
Java at work and have the same kind of thinking. With the age, I guess that
what matters is the result and not with what it has been built. Of course I
like experimenting with new technologies but I have abandoned to spend energy
and time in church battles because in the end you realize that you can very
often answer a problem with your usual tools in computer science at the
moment. Anyway I liked your java_launcher trick and would like to benefit from
it if it is freely available of course. However I could not find it in the
teamten repository ? Thanks for letting me know.

------
leke
I like how the author made the point about the commenting. I never realised it
until I started my work training at a big company. I'm reading my colleague's
C# (ASP.NET MVC) code and find it requires no commenting to understand even
though I started learning C# pretty much on the job.

I then had to laugh when I needed to explain some JavaScript (and jQuery) I
wrote to him and exclaimed, "What the hell is this doing!". I had to get back
to him a few minutes later on.

As for Java and C# on the web. I just wish it was more accessible to smaller
companies. 100% of my freelance stuff are using cheap hosting that rarely
support anything more than Perl/PHP.

~~~
gred
> As for Java and C# on the web. I just wish it was more accessible to smaller
> companies. 100% of my freelance stuff are using cheap hosting that rarely
> support anything more than Perl/PHP.

One year ago I would have agreed with you, but I have since discovered some of
the newer PaaS solutions like CloudFoundry / Pivotal CF [1] and OpenShift [2].

I'm using Pivotal CF for my current side project (a public website + web
service) and am paying about $7/month.

[1] [http://www.pivotal.io/platform-as-a-service/pivotal-
cf](http://www.pivotal.io/platform-as-a-service/pivotal-cf)

[2] [https://www.openshift.com/](https://www.openshift.com/)

------
assertnotnull
Sooo.. Why Paypal switched from Java to Node then?

[http://www.informationweek.com/cloud/software-as-a-
service/p...](http://www.informationweek.com/cloud/software-as-a-
service/paypal-finds-nodejs-secret-to-successful-makeover/d/d-id/1127734)

BTW. I work with Java & GWT and I find it overkill for our needs. It took 5
months to make a 4 views, each with image or video grids and upload button.

On the side. I have on my free time working with Django and have a website
with Authentification, comments, categories... In the end, my personal project
has more features.. less lines.

Instragram uses Django and so is Disqus. Are those slow?

~~~
emilburzo
> BTW. I work with Java & GWT and I find it overkill for our needs. It took 5
> months to make a 4 views, each with image or video grids and upload button.

I work with the same stack and don't understand what could have taken so much?

Or did you include time spent reading the docs?

------
swah
Do Java/JVM folks miss the simple deployment of Go? I haven't used Java for a
while (used Jetty to deploy), but words like "application servers" are the
things that make Java sound "heavy".

~~~
ecopoesis
I think most people are using embedded Jetty or Netty (or even Tomcat in
embedded mode) so deployment is just a jar that can be run with any old JRE.

------
mercurial
"Java for everything, because it's the only statically type language with a
fast runtime I know well".

Ok, Java is not terrible (PHP is terrible), and the JVM is a marvel of eat-
your-RAM engineering, but this makes me sad, because there are only two things
that can be said about Java: it's not terrible and it has a big ecosystem.
There is nothing brilliant about it. It is slowly crawling toward convenient
feature, but it's never going to be at the same level as a well-designed
functional language in terms of correctness and readability-to-expressiveness
ratio.

------
CSDude
I cannot keep my sanity when I use dynamic languages in fairly big projects. I
just cannot organize my code and all the functionality good. So, I looked at
the options at Java and most of them looked either very complicated(Spring) or
insufficient.

I am developing a very simple framework, insipred from Sparkjava and Play
Framework:
[https://github.com/mustafaakin/WebOM](https://github.com/mustafaakin/WebOM)
It basically maps either HTTP requests or Websocket connections to Java
objects with typed parameters.

~~~
mercurial
I'm not sure what you're trying to do. If you're talking about dependency
injection: 1) be aware that you're ditching some safety by relying on it 2)
look at Guava

~~~
CSDude
I just map a request like /users/:groupId?orderBy=name to A java object like
"int groupId", and "String name" and it puts them automatically by converting,
and if you wish you add some checks, notnull, range etc. and It replies bad
request to client. Therefore, I do not do this conversion and checking each
time.

------
S4M
This post makes me wonder, what about Jython? I don't use it, but it would be
a nice fit for the OP (writing performance critical code in Java, and use
Jython as a glue).

Are there any drawbacks with it?

~~~
rcarmo
Jython 2.7 isn't quite all there yet, and last I used the betas it wasn't that
practical.

------
freshflowers
The same argument can be made for any mature language with a solid ecosystem
of tools and libraries.

Except the part about scalability, that's just BS. It has little to do with
language and is all about architecture. Sure, at some point language can help
you squeeze every ounce of performance out of the hardware (although my money
would not be on Java for that), but that's only in cases where either
performance is critical or the scale is so huge that saving on hardware makes
a big difference.

~~~
waps
You forget just how much difference there is between languages. Comparing
Python and Java for example, it's easy to find things that take 1-2 cpu cycles
in Java (or even 0), that take thousands of cpu cycles in Python (e.g.
function calls).

[http://benchmarksgame.alioth.debian.org/u32/python.php](http://benchmarksgame.alioth.debian.org/u32/python.php)

I mean, I would agree that 1s versus 1.3 seconds doesn't really matter. But
look at those numbers we're talking 40-50 TIMES faster in half the cases. The
number I tend to use is that one programmer is worth 10 servers. But this has
diminishing returns : the larger the site gets, the more you'll focus on
servers.

But even for small sites. Python is about double java's productivity, no more.
That only helps you for very small programs.

So for large sites, python would have to be 40-50 times more productive than
java. This is exactly python's weak point, and java's strong point ...

And from experience I know. Large python programs are horrendously difficult
to change. They're like how large perl programs used to be. Changing a tiny
thing in one far removed part of the program affects 10 other places in the
program, with absolutely no warning, until the site crashes. And then you put
a try-catch in your main loop and AAARGH.

~~~
TheLoneWolfling
And yet there is a benchmark in that particular set you linked in which Python
runs in 3/4 the time.

Also, I don't like the CLBG - it removed PyPy and a bunch of other
implementations of various languages. I would be intrigued to see the speed of
PyPy on that particular set of benchmarks, for instance.

~~~
igouy
I would be pleased if you took the program source code and the measurement
scripts and published your own measurements.

[http://benchmarksgame.alioth.debian.org/play.html#languagex](http://benchmarksgame.alioth.debian.org/play.html#languagex)

But we all seem feel the same way about this, we all feel that we should sit
on our hands and wait for someone else to do the chores we don't wish to do.

------
V-2
"No, actually, typing Foo one extra time does not “really suck”. It’s three
letters"

Hah, if only it was always just three letters... :)) Usually more, and it's
called NOISE. That's why C# has "var" and C++11 has "auto" (with all the
benefits of strong typing still in place, obviously)

"And other languages like D and Go are too new to bet my work on."

I'd argue that D isn't really that knew, only niche. It's been around for over
10 years now.

------
diltonm
>> Whatever time was saved by the developer when writing the Python code (if
any) were lost many times over as dozens of users had to wait ten times longer
each time they fished through the logs.

I was first exposed to Python in 2002. The sentiment in the quote above is
reminiscent of the reasons I came back to Java. With a little Bash and some
Java or a little Python and some Java I can do pretty much anything I need
from system services to web to rich clients.

Edit: Great article.

------
divs1210
This post relies on the assumption that all dynamic languages are an order of
magnitude slower than java. Not very long ago, the OP would have used the same
argument in favor of C++, and against java. In fact- many dynamic languages
have proven To perform better than traditional ones in some areas, such as
javascript on node for web-dev. Clojure, for example is WAY faster than
python. Incremental typing can squeeze out some additional power as well.

------
grannyg00se
"With few exceptions (such as parsers), unit tests are a waste of time."

I was in full agreement aside from this. Unit tests are more than just a
substitute for static typing.

~~~
jtheory
That surprised me as well; though perhaps it's just that "such as parsers"
applies to more code than the author realized.

A parser is a discrete chunk of code that's general-purpose (likely to be
called from lots of places with different content), but with a fairly
straightforward list of cases that you can/should test to see how correct and
robust it is.

There's a lot of code that fits into this category; not just parsers.

------
jafaku
Does anyone know a good starting point for learning not just Java, but how to
install everything I need? I consider myself the Neo of OOP and a master
devops, but every time I tried to use Java I hit a wall of unreadable
manuals/guides , software impossible to install/maintain, and mixed opinions
among Java devs. Like it can't be used without a dedicated sysadmin.

~~~
allengeorge
That...sounds surprising. Basically you need:

1\. An IDE (I highly recommend IntelliJ IDEA)

2\. A build and dependency management tool (I prefer Gradle, but Maven is a
reasonable choice - though way more verbose)

Beyond that point, a lot depends on what you want to do. Some of my
preferences (YMMV):

* logging: slf4j over logback

* json serialization/deserialization: jackson

* db access (if you don't need or want ORM): jdbi

* db migrations: flyway

* REST services: jersey

* networking: netty

* embeddable http server: jersey

* http client: apache-commons http client

* metrics: codahale's metrics

If you're building a backend webservice I highly recommend looking at
Dropwizard, which handles a lot of the boiler plate for you.

~~~
paulddraper
Great suggestions. Do you have a web framework suggestion, e.g. something with
templating?

I like Play, but that's 'cause I use Scala. It has a Java version, but IDK how
good it is.

~~~
allengeorge
I've heard mixed things about Play's Java version. YMMV, but the last I heard
it was a "second-class citizen". Unfortunately I don't work with any
templating myself, but I note that Dropwizard supports both Mustache and
Freemarker. Would those work for you?

------
ionelm
The argument can be made both ways. One can say that Python is better cause
readability.

Many can give examples of successful or failed projects in both languages but
it's just conjecture.

The only correct way to look at language choice, and the only objective one,
is to use the language _you_ are productive in. The best language is the one
you master.

------
applecore
_> You can complain all day about public static void main, but have fun
setting up 500 servers. The downsides of dynamic languages are real,
expensive, and permanent._

Love this quote. This is a thought-provoking article, even if you don't agree
with everything as stated.

~~~
Turing_Machine
500.times {ec2.instances.create(:image_id => "ami-foobar")}

Or if you want to own the hardware, you can do the equivalent with a Chef
script, or a Puppet script, or..

No one is going to set up 500 servers by hand.

~~~
Turing_Machine
The point being that you can start 500 servers with a trivial amount of
effort, rather than it being some kind of major undertaking as the author
pretends. This is 2014, guys. You don't have to unbox and plug in all the HDs
yourself.

If they're (e.g.) ec2 microinstances, 500 servers would cost you about
$6,000/month, which is comparable to the monthly cost of just one extra
programmer (maybe much less, if you're in a high wage location and you add in
all the benefits, etc.) And remember, that's assuming you're operating at
reddit scale, which, to be blunt, you're not likely to be doing.

The article is full of similar handwaving (e.g, "it's only 3 extra characters"
when most class names are far longer than 3 characters, and you also have to
multiply that extra typing by the number of lines in your codebase).

I'm glad Java works for him. Me, I abandoned it around the year 2000 and have
never looked back.

------
jimbokun
Ok, now your boss asks you to write an iPhone client.

Or web client with a lot of logic in the browser.

Or even a custom, native windows client. (Ok, Swing or SWT, but, ...really?)

" _Language X_ for Everything" is simple not possible, regardless of the value
for _X_.

~~~
hhandoko

      * C# (and/or F#) to build iPhone, Android, and Windows Phone apps [1] 
      * F# code that compiles to JavaScript for front-ends [2] 
      * C# (and/or F#) code for Windows and *nix clients [3] 
    

They are not perfect (nor the tooling are free), but it is possible.

[1] - [http://xamarin.com/](http://xamarin.com/)

[2] - [http://websharper.com/](http://websharper.com/)

[3] - [http://www.mono-project.com/](http://www.mono-project.com/)

~~~
zamalek
There is also a project that can convert MSIL to Javascript. So, add to that
list

    
    
        * C# code that compiles to Javascript for front-ends [1]
    

Or, indeed, any .Net-targetted language like Nemerle, Boo and <gasp> VB.

[1]: [http://jsil.org/](http://jsil.org/)

------
untitaker_
The JVM is not usable for short-living processes such as command-line tools.

Apart from the ecosystem and the language itself, it's often the reference (or
only) implementation which makes it unsuitable for a particular job.

~~~
pjmlp
There isn't "The JVM", there are certified JVMs and quite a few of those allow
for AOT compilation to native code.

~~~
Teckla
_...quite a few of those allow for AOT compilation to native code_

Do you know of any _good_ and _free_ ahead-of-time Java compilers that produce
native binaries without any additional dependencies?

I haven't been able to find any, but perhaps my Google-fu is weak. gcj is
obviously not a good answer.

~~~
pjmlp
gcj is dead.

For good ones I only know of commercial like Aonix, Websphere Real Time,
Excelsior JET, JamaicaVM and a few others.

If you want to go free and are happy just with GNU/Linux and Mac OS X/iOS,
then RoboVM might be an option.

If you want to go research, there is Graal/SubstrateVM from Oracle Labs and
JikesRVM, a meta-circular JVM.

------
binsch
You can get IDE features in vim:
[http://vim.wikia.com/wiki/Use_Vim_like_an_IDE](http://vim.wikia.com/wiki/Use_Vim_like_an_IDE)

------
abalone
iOS got this far on Objective-C. Seems like nobody _really_ complains about
that one the way they complain about Java.

I think he goes a bit too far with "unit tests are a waste of time" (maybe he
just means for type checking). But other than that this perfect captures my
very pragmatic view towards Java. There's a lot to be said for consolidating
on one server language, and if you're going to pick one language, that's the
one.

~~~
peatmoss
The Obj-C stuff always had a very low cost to bring in C stuff. I've not done
a lot with Java's FFI in terms of writing code, but every time I've tried to
manage a _build_ with Java that uses external C libraries, I want to cry. That
alone pretty much erases the differences in hassle between Java and Obj-C in
my opinion.

------
songco
It's a great idea to make java run like a script...

------
0800899g
Great not to see a another java bashing post on HN

------
hunnypot
"HAS-KELL! HAS-KELL!"

------
smegel
I maintain and develop a large code base written in (mainly) Python with some
C thrown in here and there. It was maintained and developed by a number of
people before me over several years, who have come and gone. And yes while
there is rust and cobwebs, I don't attribute any maintenance issues to the
fact it is Python or a dynamic language, but rather higher level design
decisions about interfaces and boundaries and responsibilities. Often some
module that wasn't supposed to know something all of a sudden needs to know
due to some new/changed requirement, and redrawing data flows and structures
to ensure the right information is where it needs to be can be challenging.
But this situation can be applicable to a system developed in any language -
if anything Python's flexible data structures makes it easy to accomplish such
re-engineering.

The last time I tried to do anything in Java, I was instructed to "just run
the maven build script". After watching that flaming train wreck I walked away
and haven't looked back since.

------
frozenport
Not until they support more than 2^31 elements in my array!

------
fleitz
LOL, I spend all day next to java programmers trying to get GUIs to work in a
performant manner.

Just pickup any Android device and you can see the lag, ever wonder why all
the java phones have 4 GB of memory and a quad core processor just to draw a
1920x1080 screen?

------
facepalm
How do you even parse JSON in Java? I remember in the days of XML, there was a
kind of specification standard for the xml (a specification for how to specify
a specification?). From that you could generate Java classes that would
correspond to the elements of the XML. But for JSON there is no such meta
description, so you are stuck with manually parsing the JSON and hoping you
catch all nuances?

~~~
cgh
Have a look at the Jackson library. There are many others.

