What's the sell, these days for java?
What's the sell, these days for java?
But java has so many great languages on the JVM. That inter op flawlessly with it. Kotlin is my favorite, and allows both java and kotlin files in the same project.
The language is palpable. But I feel that there are higher level features, that can ease development and improve readability. Yes, yes the IDE can generate boiler plate. But that shouldn't be necessary.
It's not hard to send a Java app to a Windows user and expect them to be able to run it, which is more than I can say for Python.
And Java also has Maven, which is by far the best dependency management system I've used. It's extensible too... aside from managing dependencies, you can also have Maven perform code generation (which is wonderful if you're working with Avro) and other things (such as handling OSGi bundle metadata).
I actually question why anyone would use Node except in a few cases (like backend for front end), but maybe I'm just old school :)
Developing a web application using javascript and having it served by a javascript platform (node js) makes everything so much easier. From simple code re-use, back-end to front-end, to not having to mentally switch contexts if you are developing back and front end at the same time.
Node is "simple" but today you need 3 package managers to install the dozens of small libraries needed for even a simple project
Really. When I found out express.js needs an extra library to read POST data I was stumped
It's a Flask clone for Java. No XML configuration needed.
None.
As the others mentioned, Spring has not required XML config files in a long time. Spring boot requires nearly zero configuration, although it's a good idea to move out environment specific configurations out of the app. Speaking of, out of the box Spring works with yaml, properties, environment vars, command line vars, and the list goes on.
It really is a nice environment to work in, and if you don't like Java there is Kotlin which has worked fine within the stack IME. So many people only remember Java 5 and Spring where beans had to be wired up through XML configs.
In a couple of years, probably they'll be much closer. But that also depends on what the Spring guys and gals have to say :-).
People have a tendency to trash talk it for being verbose, but writing the code is a vanishingly small portion of the engineering effort, and if you're hand wringing about whether it's fun to write then you're optimizing for the wrong things.
It's hard to imagine what kind of career that attitude would lead to. I very much worry about whether things are fun to write. And I've been lucky that, so far, I've had jobs that were very fun. Not necessarily easy, but fun.
Java is pretty modern, has quirks, but you can be pretty productive, not a particularly bad language. Helps you get stuff done. Awesome tools, pretty good concurency support. It is very hish performance. It is a proven tool, just don't buy into the IBM/RedHat enterprise stuff. There are nice microframeworks available. Java is a good choice to start a project in.
What makes Java powerful is that it's good at everything. That's incredibly valuable for Amazon and Google, because they have an insane amount of code. So whether they need concurrency, or tooling, or whatever they can throw any 4-5 engineers at the problem and they'll be able to get it done.
For a startup, they aren't going to need the greatest General Purpose language ever made. They generally have specific problems. And there are simply better languages out there for almost all of them.
Go is hardly a "modern language" from a language design perspective so you're not gaining much over Java here. It has horrendous package management and the IDEs, debuggers, profilers and live monitoring tools are probably a decade or more behind the tools available for Java and the JVM. It's also much harder to find Go programmers than it is Java programmers.
Python is a very slow dynamically typed language with a horrible deployment and concurrency story. A lot of big companies justifiably won't even consider a dynamically typed language. Again all the tooling from package management to profilers to debuggers is way behind what's available for Java and the JVM.
C# is a real competitor but for the most part it's still tied to Windows. This is slowly changing but the vast majority of C# libraries still require the full .NET runtime on Windows and the open source community around C# is a small fraction of the size of the community around JVM languages.
You're just wrong there. There are plenty of languages that do something better than Java, but none of them do everything better than Java.
> I don't use Java much but out of the languages you named none of them are better at much and with the exception of C# all of them have far, far worse tooling
Now we are traversing into "my opinion is fact here".
> Python is a very slow dynamically typed language with a horrible deployment and concurrency story.
Who the hell uses Python for concurrency? It has a global interpreter lock... if your use case obligates concurrency and you pick Python you just don't understand what you are doing.
> C# is a real competitor but for the most part it's still tied to Windows.
Yes, let's dismiss every other language because Python is bad at concurrency and you don't like Go's package manager... Give me a break.
I agree and I never said otherwise. I specifically addressed three of the languages you named (Python, Go and C#).
> Now we are traversing into "my opinion is fact here".
I'd love to see someone argue that Go or Python have superior tooling to Java and the JVM.
> Yes, let's dismiss every other language
I'm not dismissing every other language, I don't even use Java regularly, I'm dismissing two of the "modern" languages you named.
By pointing out things that they do decidedly worse than Java, which was exactly the opposite of my point.
> I'd love to see someone argue that Go or Python have superior tooling to Java and the JVM.
I never said they did, because they don't, in general. But Python is absolutely superior in some areas (statistical modeling, machine learning) because the tools it uses are, objectively, better.
> I'm not dismissing every other language, I don't even use Java regularly, I'm dismissing two of the "modern" languages you named.
Right, you're dismissing them for decidedly stupid reasons. Literally no one on the planet is going to think Python is a good option for concurrency. And you're opinion on Go is literally just an opinion, that many (myself included) would absolutely disagree with.
Bullshit. Python is often used for early exploration but the people doing serious work in ML almost always end up using C++, Java or Scala.
> you're dismissing them for decidedly stupid reasons
So having relatively poor tooling, poor package management, poor performance and bad concurrency support aren't good reasons for dismissing a language? Go and Python aren't even particularly well designed languages. That's far more than you've given for dismissing Java and claiming that alternatives are "vastly better for a typical startup."
LOL. What? Did you poll every company doing ML work to arrive at that conclusion? C++, sure. Java and Scala? I've literally NEVER seen actual ML work done in either language at either of the 2 companies (both big 4) I've worked at.
> So having relatively poor tooling,
No. Is Java's tooling generally better? Probably. Does that make all other tooling poor? No.
> poor package management
Stop treating your preference as if it's fact.
> poor performance
Which matters sometimes, but not always. If performance were a metric that made a language live or die, nobody would use anything but C/C++.
> bad concurrency support
Only in Python. But that's moot, you don't need concurrency in every application. Do you realize there are ENORMOUS applications, in-use today, that scales dramatically and they are written in a variety of languages, including Python?
> Go and Python aren't even particularly well designed languages.
Your arguments here indicate you have very little understanding of basic language use-cases, so pardon me if I don't hold your opinion on language design to a very high standard.
> aren't good reasons for dismissing a language
They aren't reasons. They are your opinions and a fundamental misunderstanding of basic use-cases. Frankly, based on what you've said so far, your judgement about languages in general is on-par with what I'd expect for a new grad CS major that only used C++ or Java while in college.
> That's far more than you've given for dismissing Java and claiming that alternatives are "vastly better for a typical startup."
And yet I clearly explained why Java is generally not a good choice for a startup. And it seems, most startups agree since the majority don't use Java.
I work at one of the big 4 right now and almost all the serious ML is done in C++ and Java. Python is purely used during exploratory phases and even that is being phased out. Most of the other things I said aren't even controversial so I'm just going to ignore you from now on. Enjoy thinking Python and Go are well designed languages.
Most of the things you said were a straw man and nothing more. Go and Python are good at what they do. I see them as tools in a vast tool box. You think everything is a nail. Enjoy thinking that's a valid viewpoint.
If I'm a startup, I generally have ONE thing that I need to excel at. If that's computer vision, why would I use Java when C++ (and arguably Python/OpenCV) is decidedly better at computer vision? If I need a simple REST service for my particular project, why in the world would I use Java over Python, Ruby or Go?
The value of Java is that it does everything well, but the ecosystem is enormous. It's overkill for most projects, unless you happen to have projects that scale across multiple domains that Java does well.
I find it odd that I'm getting so much push back here. There's a massive amount of cognitive overhead in utilizing Java. There's also a huge cost (both cognitive and entry) in using of Java. (The difference between a Java programmer and a generalist? How much the latter has to learn to catch up.)
Well, CIOs tend to think so. I think they are wrong, and that this is one of the reasons enterprise-internal technology is so bad.
You aren't actually going to.move engineers between those tasks very much, because each of them relies on fairly deep domain knowledge, and, in any case, it's unlikely that the size of demand between those tasks shifts enough that it makes sense to shift a lot of people around. And, those you do shift around are going to have a lot of work coming up to speed on domain knowledge (which is going to have a huge impact on how the language is used), which will dwarf any language-transition effects. And, furthermore, the places that do stuff like this aren't the kind of places that attract the kind of talent that could manage to the transition between these divergent domains well; what they almost invariably end up doing to deal with short-term shifts is hiring specialist contractors in the more in-demand area, and for longer-term shifts reducing headcount in one area and hiring new people in the other.
At the same time, you are inhibiting productivity in most or all of the individual domains by not choosing the right tool for the specific job.
I agree, but wanted to specify "big" examples to make it clear what my point was. That said, while they do require domain knowledge, I've seen people move into entirely different domains at the same company. It's not common, but it absolutely happens.
There are also some high profile pieces of technology written in Java, so if you want to leverage them, having JVM expertise is a bonus. You may even get better bindings for JVM languages than others and since many are open source, having Java expertise allows you to work on them.
I find it a little odd you'd buy in to the CLR family (C#, F#, etc), but say the JVM family has nothing to offer. They're not really substantially different in my experience -- both are sort of staid enterprise-y ecosystems. (But maybe I'm missing something really cool in CLR land besides good MS product support -- please let me know! It's one of my language blindspots.)
I just find C# to be a better language. It has its youth to thank for that. I have no issues with JVM. Hell, if I were to start a project today Kotlin and Scala would also be very real possibilities. They are both amazing languages.
C# probably shouldn't have made my list, but I threw it in there to cover OOP where the other languages were decidedly not. At the end of the day, language choices for a start up largely reflect it's goals. If I want to do statistical modeling, I'm going to use R. For ML, probably Python. For a systems program, likely Rust.
The bottom line with Java is that it can do any of those things. But the languages I mentioned do their specific job better. And that's the thing with a startup. You don't need a great general purpose language, you need whatever language suits your niche. But at Amazon/Google scale, Java is an absolute beast, largely because it can do everything.
Why does anyone need to sell anything? So we can all go ahead and spend 5 years getting good at clojure and haskell?
And if you do not want to use Java the language, there is always Kotlin (and Scala).
Cons: Oracle's shadow of semi-legitimate FUD, higher memory consumption, ecosystem is rife with over-engineering and the language seems to almost encourage it.