Comment by patio11 | Hacker News Reader

Comment by patio11 | Hacker News Reader

Parent Full thread

Some context would help, since it depends on what you already know, what your longer term goals are, and how you think learning Java will help you achieve that.

Some reasons in favor of learning Java: it's an incredibly entrenched technology in a wide variety of industries, and it will be running incredibly valuable line of business code for long after both of us are dead. The language itself is competent and C-style, and it handles memory management. The JVM is a wonderful platform. The Java ecosystem interoperates with everything, has copious developers available no matter your region/price point/industry/desired level of experience, and has a vibrant community which has libraries available for whatever you'd want to do.

Reasons against: I'll spare everyone the "Good God man, it's Java." (Though, having cut my teeth on it and used it professionally for most of my career, they're not totally wrong.) Mostly, my concerns would be directed at "Is learning a new programming language really the highest priority for you given your particular goals?" Learning the syntax will only take you a few weeks (assuming you've programmed before), but getting conversant with e.g. the J2EE stack is a multi-year project, and there are many things you could accomplish in the same time which would be more intellectually rewarding/credibly promise more career growth/etc.

> I'll spare everyone the "Good God man, it's Java."

I always get a kick out of this. If someone says a language's expressiveness is one of her biggest pain points, she probably is not working on anything significant. There is a reason that so much Java is used in Google, Amazon, etc. Performance, maintainability, tooling, and ecosystem are more important than whether or not you have anonymous inner classes vs. true language support for closures.

J2EE, like Applets, gave Java a bad name. And Spring has become more complex and nasty than J2EE ever was. Java sucks when you have to deal with those environments.

But if you use a modern Java stack - Jersey, Jetty, Guice, Guava, etc. - it is a pleasant experience.

>> There is a reason that so much Java is used in Google, Amazon, etc.

There is a reason why some companies are still running COBOL, C++ or even FORTRAN. Replacing them en masse is expensive, and often you can hire cheap labor and throw some bare minimum funding to keep those systems up and running, until there is no business case to keep them running any more.

When these companies started up, Java was the latest tool that gave tremendous productivity benefits over C++. Newer tools have arrived, now and Java is in the same place as C++ was.

And just like how it doesn't make business sense to re write old legacy systems in new languages. It also doesn't make business sense to write new systems in older languages.

Choose where you want to be.

> When these companies started up, Java was the latest tool that gave tremendous productivity benefits over C++. Newer tools have arrived, now and Java is in the same place as C++ was.

Which languages/tools give tremendous productivity benefits over a modern Java stack? Serious question. I have done a lot of work in a lot of different environments and IMO for the big and maintainable things it's hard to top the Java ecosystem.

(edit: I do agree with you - it is ridiculous to rewrite enormous legacy systems. But I don't think there's a clear-cut order-of-magnitude-better replacement for Java yet)

Is there any good material on learning the modern Java stack? I know Java SE from using it quite a bit in college, but it seems beyond that everything is geared towards JEE.

>>it will be running incredibly valuable line of business code for long after both of us are dead.

Good for Java, bad you us as a career option. Unfortunately the more entrenched it is the more legacy projects you get to work on. The new things, the important things, sort of things which people are ready to invest big money on will happen in some other stack.

I know of a few friends of mine who've so far worked mostly on COBOL their whole career so far. Through COBOL is still pretty much in use, they have problems getting into good projects, switching jobs, getting good compensation. People seem to look legacy stacks like a burden they need to carry on unwillingly. So tend to provide the bare minimum funding to keep it up and running. Most of the times they are only running, until something better is found to replace them.

Learn Java if you want. You will still get a job, but you shouldn't be surprised if something like scala has more interesting projects, good money and better opportunities.

This happens with all technology. As with these things, the sooner you adapt to something- the better.

It maybe more appropriate to ask, should I have a portfolio of Java applications/solutions to interesting problems. Learning the pitfalls of a language is undoubtedly useful and I would argue that learning the process of project start-up, testing, maintenance and deployment would perhaps put you in a much more valuable position for learning.

> The JVM is a wonderful platform. The Java ecosystem interoperates with everything

I hear this over and over but it never strikes me as true. The best and most widely used libraries and interfaces for a given problem always seem to be C++ or C. There's typically some slower and less comprehensive library for Java or .Net.

The best and most widely used libraries and interfaces for a given problem always seem to be C++ or C.

I think it differs hugely per case. E.g. there are not great C++ or C libraries that provide functionality of Akka, Guava, or Java persistence.

On the other hand, nothing in Java-land beats Qt, Cocoa, or Eigen.

But I agree on interoperability. Interoperability within JVM-land is pretty great. But it is far easier to write a good binding for a C library in e.g. Python, Ruby, Go, or Haskell, than it is in JNI.

I also don't fully agree with the statement that Java (or other JVM based languages) is the pinnacle of interoperability. Try interfacing between e.g. Python and Java some time and you know what I mean. Besides JNI or some other JVM based language, interfacing between Java and something else basically means doing some form of IPC, which isn't fun.

If you do interoperability right, then you would use Apache Camel which interoperates effortlessly with everything including Python. The right way to interoperate between tools in different languages on different VMs, is to use something like AMQP or ZeroMQ both of which are supported in Camel and in Python.

Now if you don't want to use Camel and want to build a Big Ball of Mud, that is your choice, but do not pretend that it is a best practice in the 21st century. The standards for software engineering have moved on.

>> Now if you don't want to use Camel and want to build a Big Ball of Mud, that is your choice, but do not pretend that it is a best practice in the 21st century. The standards for software engineering have moved on.

I don't even understand what you are saying here. Are you implying that if I have a Python application and a Java library that solves some very specific part of what the application does (say, applying some very complex algorithm to a few numbers, or decode some arcane undocumented file format), that I should use something that sells itself as:

Apache Camel ™ is a versatile open-source integration framework based on known Enterprise Integration Patterns.

Camel empowers you to define routing and mediation rules in a variety of domain-specific languages, including a Java-based Fluent API, Spring or Blueprint XML Configuration files, and a Scala DSL. This means you get smart completion of routing rules in your IDE, whether in a Java, Scala or XML editor.

Because 'the standards of software engineering have moved on'?

Not everyone is building large-scale enterprise software running on clouds of servers or whatever you have in mind. I can make up a million examples of pieces of software that perform only one single one-shot task (like a command line script) that may want to call out to some external library that implements some part of what the script is supposed to solve, and for those kind of applications, 'the standards of software engineering' should not have to dictate I have to use message queues or a versatile open-source integration framework based on known Enterprise Integration Patterns, amirite? If that library I need to call is written in Java and I need to call it from Python or some other non-JVM language (or even C/C++ because JNI is a pain in the ass as well), I'm SOL :-S

For enterprise applications usually you would use REST. And that is pretty easy, almost automatic.

Can you expand on this? I've never seen this opinion before. I would have guessed rest is too loosely defined for the structural rigidity of most enterprise applications?

There's no need to interface cpython and java. Looks like jython is already faster than cpython, so just use it, interface is ok.

Then you can't use C libraries with it.

C++ library would crash your process or ruin your threading. Java one won't. Interfaces tend to be more stable. For complex things like Excel parsing Java is the way to go.

Thats not an answer to the question about interoperability. Java/C interop is a complete pain so the world is divided into two, C (native) libraries, which the non JVM languages can mostly interop with, and the JVM libraries that JVM languages can use. Most stuff is implemented eventually twice.

A lot of people are using the word "interface" to mean sticking two bits of object code together with the compiler and linker. In plain English, the word "interface" covers a lot more than that specific technique. Even most Java developers make a distinction between what the "interface" keyword does, and the broader CS term "interface".

Why on earth would you want to stick some C code (or God forbid, C++ code) inside the same process as the JVM? If you control the OS, there are better ways to do the same thing with two separate proceses. And even if you don't control the OS, we do have techniques (most of them implemented inside Apache Camel) for hooking up a Java process and some other kind, without sharing bodily fluids.

Apache Camel is safe hex, use it!

"to mean sticking two bits of object code together with the compiler and linker" That's what I mean here. You drop your .jar into a folder and it tends to fit. Even if build options or library version differ. And you always have tests to check that!

Java libraries can ruin your threading too. Java doesn't magically make everything you write threadsafe.

You can guard against that. In Java, making things thread-safe is usually straight-forward.

Java libraries tend to mis-handle classloader recycling, but most projects can ignore that.

Additionally, Unicode is a nightmare in Java.

Mozilla's HTML5 parser is written in Java. One of the reasons java was chosen was the unicode support [1] The Java code is converted to C++ in build time I think [2]

[1] https://news.ycombinator.com/item?id=6204760

[2] http://ejohn.org/blog/html-5-parsing/

Did you ever tried it in C and C++?

> The best and most widely used libraries and interfaces for a given problem always seem to be C++ or C.

Where are the enterprise C and C++ libraries and server stacks?

The enterprise is all about Java and .NET nowadays.

java and C are strong in different areas. I would rather say that choice of C libraries for enterprise or just for any useful web backend is poorer than for java ;)

The only thing Java is tier one for is shoveling around XML/HTML and talking to databases. As soon as you leave that CRUD territory and need to work more seriously with algorithms or have high performance requirements, the available stuff is second tier. Off the top of my head, consider computational geometry. CGAL and boost.geometry are amazing. JTS is very slow and missing a lot. It's the same thing over and over with many sorts of libraries.

So why are the banks moving to Java and .NET for real time transactions?

https://github.com/LMAX-Exchange/disruptor

Well-designed libraries usually trump poorly-designed libraries, performance-wise, regardless of which language they're implemented in. C++ isn't a magic bullet; it's plenty easy to write bloated, poorly-performing software in C++, just as it is in Java, C#, Ruby, etc.

Here's just one counterexample to your claims: http://stackoverflow.com/questions/4257659/c-sharp-versus-c-...

Reply on news.ycombinator.com