Your jab at TS was lame as Java itself has complete type erasure for generics.
>by crystallizing type definitions and guaranteeing type guards by default.
Not so crystallizing if you know.. if you've ever used a Java List, Set or a Map. i.e., List<icouldbeanythinginhere>. such guarantee. wow.
Honestly, I'd prefer TS with strict mode over Java any day because nullability is explicit, don't have to watch out for the dreaded NullPointerExceptions left and right.
Thank you, good point. I forgot about HashMap's type unsafety even though I wrote the following monstrocity a few days ago to loop over a HashMap<UUID, ExpiringEntityPlayer>
However, it's a sham. The generic types are stripped at runtime. The compiler will prevent you from putting values in the map that are not an ExpiringEntityPlayer, as long as you are diligent in using generics everywhere, and don't fall in the few traps where the wrong type can slip by without a warning, but you can still be hit by a ClassCastException at runtime if you're not careful.
I'm curious which editor/IDE you used while writing typescript? I've recently started writing typescript and I've been finding it more or less a mecca of good editor completions and LSP support, compared to what I was doing previously (Python in an old school editor) (I'm using VS Code for typescript).
One thing to bear in mind as you read the comments is that the great majority of people commenting clearly do not have good up-to-date experience of working with Java. They're arguing against the Java that they used a decade ago, or perhaps even just repeating flames they read a decade ago.
The INCREDIBLY VAST majority of people that are working with Java/JVM for a living most likely have never even heard about HN.
And yes, there are countless shitty projects in maintenance mode maybe even written in pre-1.5 Java. If I were stuck in such projects for years I would also be super-bitter about Java
Java is under hyped in the same way Toyota Corollas are under hyped.
Nothing is exciting about it since it's so common. I personally dislike Java since I just find it hard , you'll never want for work as a skilled Java developer
That's a great analogy, but I'm a bit confused about the later part, is it "you'll never be wanted for work as ..." or "you'll never want to work as ..."?
That is not wrong, but "want for" is also a common and old idiom.
Akin to "for want of a horse"
Another way to think of it is simply another slightly different meaning for the word "want". Just like in "for want of a horse", or "was found wanting", you can replace the word "want" with the word "lack" in all these examples.
"You'll never lack for work", "the project stalled for lack of engineers", "the code was found lacking"
"Want" may be used as a drop-in for "lack" in each of those.
You could also just say "lack work" instead of "lack for work". But that doesn't really make the "for" redundant. Though I can't explain the reason why not.
Maybe the "for" in "lack for X" or "want for X" is like the "for" in "look for X" or "wish for X"
"Want" is a synonym for "lack." "Want" to mean "desire" is a euphemistic usage that doesn't have a citation until over 500 years after the original usage.
> You could also just say "lack work" instead of "lack for work". But that doesn't really make the "for" redundant. Though I can't explain the reason why not.
I think it's just that "want" in its original usage is a noun. "Wanting" in "found wanting" is really a gerund of "have a want," not a gerunding of "want." "Wanting" as a gerunding of the verb "want" doesn't necessarily imply a lack. "Wanting to go to the park on Wednesday" doesn't mean you lack anything.
While attneding university, Java made an appearance in 4 different classes, the first two clases students take are Java classes.
One interesting thing to note, is that for these classes, none of the students were allowed to use any of the Java libraries, or external libraries, everything had to be built from scratch. So I didn't actually learn about using external libraries or Maven until later when I started developing for Android.
>"How many languages can you think of that meet the following conditions?"
I think that dlang comes pretty close. The Dlang community isn"t super large, but I've found everyone I've interacted with to be polite and helpful.
I have never been a java developer but I get the impression it is similar to C++ in the way that they were not that great early on in their history but have since been dramatically improved, but the old reputation persists to outsiders.
Java is the most in-demand technology in my home country, Estonia. Java also has around 800 open positions at any given time where I live now (Buenos Aires, Argentina). In fact, pretty much everywhere I've looked, Java is consistently one of the best ways to get a job simply because it has the most jobs available.
HN favourites like Go and Rust? I haven't yet found a city in Europe that would have more than 10 job offerings for either of them.
Go/Rust will get you hired in Silicon Valley working on "cool" teams. I believe a bunch of AWS teams are deep diving into Rust, and not to mention the hundreds of startups working in Go/Rust.
However, the sausage is still made Java. Amazon, Google, and Apple are, as far as a I know, primarily Java shops. It's just no one ever starts a blog with "Here's something cool I did in Java".
Ah yes, I keep forgetting that HN folk are American-centric and often either do not know or forget that the vast majority of developers do not actually live there, or work for FAANG.
Outside of USA, a little digging I did via Glassdoor:
Buenos Aires, Argentina:
- Rust: ~5 jobs
- Go: ~3 jobs
- Java: ~800 jobs
Lisbon, Portugal:
- Rust: ~6 jobs
- Go: ~30 jobs
- Java: ~278 jobs
Barcelona, Spain:
- Rust: ~1 job
- Go: ~50 jobs
- Java: ~751 jobs
These are just places I've lived at and while I can see Go slowly becoming a thing, Rust is still half a decade away from anything tangible for the real world I would say. So if anyone asks me what should they become an expert in for the next 10 years, I would not hesitate to say Java.
Yeah, I've been on HN for a decade now (back when Ruby was the new hotness), and I remember looking through the engineering jobs in Ireland and almost entirely Java and C#.
Additionally, pretty much all the distributed data processing tools run on the JVM, which is a big deal if that's what you do for a living.
I don't that find Java as a language has fewer idiosyncrasies (perfect term btw). For example, the many modifiers: public, private, "package-private", protected, default, abstract, static, final, volatile, synchronized, etc. How much of that is relevant to a fledgling programmer?
If you extend your consideration to build systems and other tooling, it's easy to see that students have a lot to overcome with Java as an intro language.
I think purpose-built languages like the HtDP languages or Logo are better choices. Students can get started with zero faff, learn the essential concepts, and move on.
Java is a fine choice for higher level courses, with students that are already capable programmers.
I don't think concepts such as public/private/abstract are idiosyncratic because scoping and non-instantiable entities are common in programming.
Yes - 'Logo' is a good choice for the most entry-level users, maybe for high schoolers who are taking CS as a 'required' part of the curriculum, but anything beyond that Java is fine.
I think Generics, Java9++ 'Modules', jar files and class files might be the idiosyncrasies to worry about.
That said, it's weird that in 2021 we don't have a universally 'basic' programming language that is essentially the 'vanilla' of programming.
Somewhere inside JS/Python/TS/Java/Dart I think is that 'basic vanilla' imperative language I think.
- The programs are very verbose for the functionality they provide. There are countless lines of getters, setters, and trivial constructors. While IDE helps to write them, it makes reading existing programs slow and frustrating. Lombok helps, but very few programs use it.
- If you do want to use Java ecosystem, there is Scala. It also has strong type system, nice IDE support and big ecosystem of third-party libraries, but is much more expressive and easier to read and write that Java.
- Finally, if you have to run medium to large java programs, you need to constantly tune the JVM. Unfortunately, you can't "confidently trust the JVM to do what's best" -- you need to get familiar with GC algorithms, manual heap sizing, GC tracing options and so on.
Java still has plenty of uses because it has so much code written in it, but luckily, the new projects are using it less and less. I really look forward to the day when I can stop tuning -Xmx option in start.sh files!
Is the Scala language finally stable? I looked at it and discarded it multiple times over the last decade because every significant language revision required changing source code.
It's more unstable that ever with Scala 3 around the corner (which is basically a new language) and the May 1st Bintray shutdown that'll be massively breaking for the ecosystem. SBT builds were failing the other day from the Bintray brown-out cause all SBT plugins are still in Bintray: https://www.reddit.com/r/scala/comments/mph43t/sbt_build_fai...
3 month warning that they'd blow up the ecosystem. I have no idea why a company that builds products for devs would take such an aggressively anti-dev approach to shutting down a core service.
I've been working with Scala professionally for the last 8 years and I consider it pretty stable. Code I've written for Scala 2.10/2.11 still compiles with 2.13.
I think the biggest change for me was the redesigned collections-library, but that was rather simple migration.
That said; there are a few breaking changes with the migration to 3.0 - especially if you rely on unsupported features of the compiler, namely macros. Macros have been widely used in the past and will not be supported anymore.
This automatically puts Java on my list of tools I'd prefer to avoid for new serious projects. (Legacy projects; if it's working and it isn't an issue yet, maintenance.)
It is not a big deal as long as it’s still run as independent project. There are plenty of other big players interested in keeping reference implementation vendor-neutral.
You can use AdoptOpenJDK or Azul or whatever, but you will be using code largely from Oracle. I don't think there is any problem with that, but the OP said "never touch anything from Oracle".
Despite Oracle being the primary contributors, there are other big companies (IBM, Apple, Microsoft, etc.) [1] supporting OpenJDK.
And this are only the big companies, there are so much medium/little companies just using Java as a language without actively sponsoring/supporting the OpenJDK project.
IMHO, there is no possible way that the OpenJDK (and Java) arent going to be enhanced further for many many years.
Java is not only driven by Oracle, there are even independent JVMs. And then, there is OpenJDK, which is supported by many different big companies (Oracle, IBM, Apple, Microsoft, etc.) [1]
As long as you are just _using_ the JDK, I see no problem regarding that Oracle may sue you. And besides that, I see no problems about Oracle _owning_ Java (idk if you really can say that Oracle _owns_ Java, I mean OpenJDK is open-source and free).
As a Java developer:
- I have no trouble reading java and have a hard time reading the 'less verbose' languages. There's way too much implied meaning and information only gleamed through tooling or backtracing, like determining the type of a variable that is declared with var
- IDE support for Scala is half as good as Java and I suspect a good reason is the language. The auotcomplete in intelliJ is almost as bad as it is for python and the IDE really struggles to understand the code; CPU usage when scala is open is MUCH higher than Java.
- On all the Java apps I've worked on, I've never tuned the JVM. Tuning the VM sounds like focusing on the wrong part of a bottlenecked system. I've never tuned Python or PHP either but they aren't as performant. Regardless, GC gets better every release.
It sounds like your negative views are more about the applications you've worked on than the language or technology.
Yup. As a C++ developer back in the day, I had no trouble reading Java when I first started using it. Indeed it was immediately easier to read than the language I'd spent around a decade with.
> IDE support for Scala is half as good as Java and I suspect a good reason is the language. The auotcomplete in intelliJ is almost as bad as it is for python and the IDE really struggles to understand the code;
This is not my experience. I found the IntelliJ autocompletion to work very well with Scala. There are nice code-suggestions, highlights for implicit parameters, refactoring works as a breeze. What exactly are you missing?
> CPU usage when scala is open is MUCH higher than Java.
The Scala autocomplete list often loads with a huge list of awful suggestions then moments later adds a bunch of useful options. We are using scala exclusively to write tests for our java code; we are using scalatest for this. The autocomplete for a lot of the (to me, as a non-seasoned scala developer) screwy operator overloaded 'syntax' just doesn't work at all. IDEA does show compile errors etc in 'realtime' (I put that in quotes because it takes a lot longer to catch up with bad scala code than it does bad java code).
>- The programs are very verbose for the functionality they provide.
That's true for 2005, not 2021, with var, type inference, closures, streams, and other such features. And since forever getters/setters are auto-generated by the IDE (including Emaca and Vim) and can just be ignored, and Java today has Records which don't need them.
>- If you do want to use Java ecosystem, there is Scala.
Now you have exponential problems. Scala has less support, slower builds, and features Scala-devs are eager to abuse to make the code unreadable.
>- Finally, if you have to run medium to large java programs, you need to constantly tune the JVM.
Production algorithmic trading app, 100k LOC, 8 GB heap, 258 threads, right now only using 105% CPU; Java 11, and this is the complete extent of JVM tuning we have done:
-Xmx8g -XX:+ExplicitGCInvokesConcurrent
Back in the Java 1.x days, you often did need to do careful JVM tuning. But for the past few years, you haven't. The ergonomics are enough for a very broad range of workloads.
And to add to what you wrote for those that are not familiar with those types of apps: "Production algorithmic trading apps" is among the worst case regarding to peformances / pauses / and tuning needs.
> Now you have exponential problems. Scala has less support, slower builds, and features Scala-devs are eager to abuse to make the code unreadable.
Unfortunately, the Scala compiler is quite a bit slower than javac. In practice this doesn't hurt quite so much anymore; incremental builds make working even with large code bases quite snappy. Full-rebuild; get a coffee.
The build tools for Scala have _massively_ improved in the last 5 years. IntelliJ support is superb and VS Code with metals is shaping up very nicely.
I agree that since Scala is a unopinionated language, you need to be strict in what you allow your devs to do. Code reviews and agreements on levels of abstraction and concepts used is mandatory.
I've worked with multiple teams in the last 8 years and this discipline is important when working with Scala. Doing so will give you the opportunity to write clean, maintainable and readable code in a very powerful language.
Plenty of things are simpler and easier to read in Scala really: lambdas, constructors, case classes, named and default arguments, for comprehensions, collections, operators on non-primitive types, ...
Sure, you can find libraries using complex type-level machinery, macros and so on. But wading through complex Java libraries that overuse OO design patterns isn't particularly approachable either.
The GC comment was true of older versions of the JVM but newer versions are much better. And by newer I mean versions released in the last 5 years or so. So not that new.
There are one or two knobs left but those are fundamental to GC technology and it's not even obvious they're bad to have. GC lets you trade off memory against CPU time in ways manual memory allocation does not. You can throw memory at your program and it'll run faster, or you can constrain it and it'll run slower, but that's not a decision the developer can always reasonably make. It's in some ways inherently an ops/deployment/end user thing.
Other GCd languages either:
1. Have knobs too (Go/.NET both have knobs), just usually not very good ones.
or
2. Are so slow (Ruby, Python) that GC tuning is really the least of your worries and they just don't expose it at all.
or
3. Are JavaScript, in which case everyone pretends that running a VM designed exclusively for laptops and mobile phones on the server isn't a giant waste of resources. V8 doesn't do GC tuning because its only real customer is web browsers where users can't do that, and heaps are small anyway.
Java ended up getting a totally unfair rap about GC because it actually was fast enough that GC performance mattered, and was interested in power users on the server where exposing knobs can make sense. Other competitors don't even try, but this doesn't make them better. After all, nothing stops you just ignoring the knobs and plenty of users do exactly that.
I use Kotlin so that I don't have to use Java. But it's still far from the "This is the Language I want to commit the rest of my career to."
Language development looks a lot like the startup path anymore. Claim you fill a need. Focus on growth growth growth by adopting features from as many communities as possible as fast as possible. If it's trendy, add it! Have a flashy web page. Find some venture capital by getting a big org to underwrite/champion you. Figure out how to really solve problems and fix everything once you've got critical community.
- It forces us to go through the ceremony and verbosity of static typing, yet blows away lots of the benefit by pervasive use of `null` and `Object`. Compare this to ML or Haskell, where there's less ceremony (Hindley-Milner type inference) yet more safety (no `null` or down-casting)
- Checked exceptions have a similar ceremony and verbosity problem, yet the pervasiveness of unchecked exceptions prevents us actually having much confidence that calls will succeed. Compare this to effect systems, even rudimentary ones like Haskell's (`Maybe`, `Either`, `IO`, etc.): if a function doesn't return one of these 'effect actions', we can be pretty sure that it will succeed (the only unchecked exceptions I've encountered in Haskell are pretty catastrophic things like OutOfMemory).
- It needs to be compiled ahead-of-time, which requires more tooling, makes automated testing more annoying (we have three different failure-reporting mechanisms: app compile error, test compile error, test failure), tools like REPLs are second-class afterthoughts, etc. Yet the resulting bytecode still requires an interpreter (JVM), which takes a while to spin up, and makes deployment and packaging harder (we don't have a self-contained binary).
- It pushes an OOP style, but requires that we keep subverting it; e.g. pervasive use of using structured-programming constructs like `for` (which other OO languages like Smalltalk avoid in favour of method calls), which requires we break encapsulation/implementation-hiding (e.g. if we loop with an 'Iterator', we need to know whether anything we call will use that same Iterator).
- It seemingly pushes a high-level, highly-abstracted design (methods calling other methods, classes maintaining their invariants, etc.); but then throws threading into the mix, which breaks things into such low-level pieces that even 'i++' needs to be thought of in terms of constituent parts (read, increment, write, return).
I agree that Scala's better (e.g. reducing a lot of the typing ceremony; making it easier to remain high-level/abstracted (e.g. encouraging 'map' and friends rather than effectful loops), etc.); it inherits some of Java's problems (and doesn't even flag checked exceptions!), but it's nice enough to tilt the balance in many cases.
As a simple example, `x.equals(y)` accepts an arbitrary Object y. This one example has ramifications all over the place, e.g. I had a bug recently where I was checking if an element was in a collection, using `x.contains(y)`. That .contains method seems to use .equals, since it allows y to be any Object. In my case x was a collection of MyType values whilst y was a MyWrapper<MyType> which I forgot to unwrap. Rather than giving a type error, this check was always returning false.
Since then I've defined a .has method which requires the argument to have the same type as the collection, which completely avoids such problems.
Fun fact, this also happens in Scala - try to List.contains an object from a type different than that stored in the list. Compiles, returns false always.
Those are ancient warts that can never be changed. Almost any static analysis suite will warn you about using equals and contains with incorrect types.
Alt insert generate equals method, select fields, ready.
Or use a record. It is such a minuscule part of the language, that it simply doesn’t matter compared to every other line of code, lib, ecosystem. You may imagine how much more productive you are that this language has sane equals, but it is not even a reasonable constant factor.
> Alt insert generate equals method, select fields, ready.
This sounds like you're not programming in the Java language, you're programming in some sort of graphical macro language which compiles down to Java (presumably built-in to an IDE of some sort?).
The fact that people resort to such things is evidence that this is a valid criticism of the Java language.
For data only classes, records are an existing solution.
For non-data classes you have to specify what equals means. Is two database connections to the same db equals? No, even though they may have the exact same fields.
Not really following or agreeing with most of your arguments here but on the subject of Checked/UnChecked exception I agree. Java would have been better off with simply Checked exceptions and errors and no RuntimeExceptions. The current lovefest for unchecked exceptions in Java is very unfortunate. New features like lambdas don't work well with checked exceptions and there seems to be little urgency in rectifying those shortcomings either. Instead everyone is just switching things to use unchecked exceptions. For people running stuff in web containers I suppose it hardly matters, a single request fails, no big deal but for other types of programs having checked exceptions is invaluable.
Java is fine; just fine. It’s not flashy or fun, comes with 25 years of CRUD, and so many ancient, enterprise codebases you’ll never run out of soul-sucking positions to bring your toolbox. Except they moved to the new hot CRUD framework and you’ll have to learn it all again.
Perhaps verbosity isn't the right word, but having to put every function in a class (in a correspondingly-named file) feels extremely cumbersome to people who grew up with languages that just have functions and weren't exposed to Java early on.
No true scotsman? Even if you want to argue that Java CAN be made more terse, the vast majority of Java that exists today is incredibly verbose. Even running a Java program is verbose. Java is the only language I've used where it's more common to have a shell script that starts your Java program than just running ./helloworld.
And yes, Go is less verbose than Java. Go might require some boilerplate, but it is certainly much less verbose than Java.
Every significant Java codebase I've worked in has had incredible amounts of magic. Between AOP, DI frameworks, APT, reflection, proxies, SPI, Lombok compiler hacks, dynamic classloaders, etc., there is a LOT of magic flying around and it can be quite hard to understand what will happen at runtime.
I’m not a backend java dev but whenever I take a look at java web projects which use spring/jsf/jsp etc frameworks, docs say to handle a request, write a method with that signature, we’ll call it when there is a http request. I always want to know enterence/exit points of a network message but that is impossible with these fancy frameworks. It is pure magic.
This is what drove me away from Java; the ungodly amount of magic that's required to make it economic. If it all works, it's fine. But as soon as something fails... Get yourself ready from some frustrating hours.
Java style verbosity hurts readability. That’s the most important issue with Java imho.
Take a look at a http server one in Java and one in C. Readability difference is crazy.
My company is in transition from Java to C, for bunch of stuff just for performance reasons. So, I debug similar projects time to time both in Java and C, http server, in memory cache, iot server etc. After seeing both, I just think although Java has great tooling, it drives developers to write unreadable code.
We should keep in mind the kind of features, performance, observability the jvm can provide, compare that with the other runtimes and then see if the script to execute is too much :)
Go's error handling is painfully verbose. Go's lack of generics leads to passing empty interfaces everywhere (come on proposal!). Don't act like go doesn't have it's warts. If it wasn't backed by google it wouldn't be nearly as popular as it is.
Nobody who has ever written error handling in Go could possibly downvote this comment. Holy moly, the error checking after EVERY interesting method call. Talk about verbose.
You can write verbose code in any language, but most other languages don't consider it normal to name a class LangDetectLanguageIdentifierUpdateProcessorFactory. (Random example from an open source framework.)
Namespacing in reverse dns order is something Java got right. It naturally segments things and you can immediately see the relative provenance of classes.
It’s just impossible to use without editor support. Nobody who cares for their sanity can type out those package names manually. I think even Gosling said as much.
Just trying to find files relevant to some functionality is incredibly difficult without full-text searching all the files. Namespacing is fine but why must the entire path be reflected in directory structures?
To prevent half assed refactoring in the first place where only namespaces and classes get refactored while folders and filenames remain as they were. It would just further confuse new devs on the project.
Java has such a system but people write long class names anyway, because people don't like to have too many types with identical names distinguished only by namespace. You can do it but it's a bit questionable to what extent you should.
>The sheer verbosity of Java is just unbearable when you're used to Python/Go/Swift/etc.
I'm used to Python (and some Go) for decades, and the verbosity of Java is a non-issue to me.
I'd rather have the speed, type safety, and refactoring tools support, over Python... (not to mention the much better packaging situation).
I'd still prefer Python for smaller programs, basically because of the startup time and quick write/try cycle. But for larger stuff, I'm not so sold, and I've been doing them (in Python) for decades...
Java was heavily hyped back in the 1990s and 2000s. It's still a decent language and has a number of things to recommend it, but today we have things like Go and Rust.
I think it really fell out of favor due to Oracle's litigious handling of it. As soon as Oracle bought it I remember people actually cancelling Java projects and changing languages.
Another problem is how complex and verbose it got. Original late-90s Java was pretty clean but eventually the ecosystem fell in love with enterprise style cruft and overengineered everything. It's less a problem with the language than the community though. Like C++, you do not have to use every pattern and language feature... but many people think you do and write ridiculously complicated verbose code.
Back in the day, Java came from Sun, who were generally pretty cool about it.
Oracle bought Sun in 2010, things looked okay for a year or two, then it started to get scary.
The situation now is not scary: there is a community process to manage the language and library definitions, the JDK is open source, with Oracle contributing, there are other significant contributors (notably RedHat and IBM ... so now just IBM), and there are multiple freely-available high quality binary releases of the same source.
It could potentially get scary again. If Oracle stop contributing to the open source JDK, and instead work on a closed-source version of their own, then it's not clear that there is enough developer power among the remaining contributors to keep things moving at a healthy speed. But then, if that happened, maybe users would abandon Java rather than pay Oracle, so it would be a suicidal move for Oracle. Or, if that happened, other contributors could step up contributions to hoover up customers from Oracle. But it's not entirely reassuring to be depending on game theory like this.
Except that if you actually code for money, neither of those have many jobs available. Heck, in many cities I've looked _any_ jobs available. Java is still one of the most employable tools out there simply because it has a lot of jobs. Sometimes the hype-train of HN makes me think that people here are just coding for a hobby or their own start-up and entirely forget how the real world actually works.
HN is indeed full of startup warriors. Go and Rust are popular for new fangled stuff, but you are correct that there are a massive number of Java jobs around.
Ah another new dev enamored with IntelliJ. You'd think one day they'd realize that it's the IDE they love, not the language. But in my observation, they never do.
Reminds me of a rationalization I heard once about how people pick their brand of cigarettes. They all taste like crap until you're finally addicted, then the one you happen to smoke at the time is now your brand.
Every new language / stack now gets compared to Java with IntelliJ because that's what they learned. Can't tell 'em any different.
IntelliJ is nice, don't get me wrong. You can't really get a nice (for 2020) experience out of Java without it, because it's an absolute slog of a language. Just... so... much... ... ... ... everything. IntelliJ cuts through all that. You can get a nice for 2005 experience with Eclipse. Without an IDE, Java really falls down.
Java is a phenomenal piece of kit, the amount of engineering that went into the JVM is insane. But people took the lessons from Java and put them into newer languages, that don't have the problems Java does that require an IDE.
My love is in the language that IDEs don't and can't really add much to, Ruby. Emacs give me all I need.
Even Emacs handles Java pretty well these days, with lsp-mode and jdt.ls (powered by...Eclipse). I've been using it for the past year and it works great.
Exactly, tooling is underhyped, programming languages do not exist in a vacuum. Intellij is at the top of the power continuum as far as I'm aware. It is a perfectly valid to pick Java just for this single reason imo.
If you feel that way about Java, I'd love to know how you feel about C. Fast, runs everywhere, tons of interoperability, fairly compact language, your choice of compiler, etc.
Also, congrats on graduating from CU! Just graduated last semester.
Java is not hyped because it is a tool. Like a microscope, it just does what it supposed to do.
IMO, if you want to get a descent job in a large company working on backend systems, you want to learn: Java, C/C++ or recently Go.
You will be able to build pretty much anything, from a micro service to self driving car.
If you want to stick to startups, you can do well with anything else till it growth, experienced engineers are hired and rewrite it in one of those languages.
Mastering a more powerful tool prepares me for more appealing roles solving harder problems. Time spent on a weak tool is just wasted; it'll never get better and neither will I.
Java has become reasonable though I'd always reach first for Scala or Kotlin (maybe Clojure?) I'd like to work with Rust but it seems hard for an employer to cost-justify the dev work to avoid paying for G1.
It is matter of perception. All tools suck in some ways, all codebases are have bad stuff (except toy projects of obsessed perfectionists). We just deal with it :)
You just asked "Why would any reasonable person care what they spent half of their waking hours of their life doing?"
The fact that you don't care does not make everyone other than you not a reasonable person.
Frankly I don't see how any reasonable person could fail to develop some preferences, but I bet you would not like it if I called you unreasonable, or perhaps just unsophisticated.
I care about security and Java code is unreadable, extremely verbose, extremely bloated. I don't see a single situation where Java is a more appropriate language than something else.
So, you are stating that Java language is not applicable to any situation.
Here is one: there is a database written in Java and you need to implement more features. There is 10000000 lines of code in the companies source and new code should be the same. I can go on and on.
Personal advice - if you want growth, drop preferences. When FAANG interviews nobody even asking what is your preferred language as nobody cares.
The "learn Go" part always puzzles me. In a city of 15 million (Buenos Aires), I can find about ~3 jobs for Go, but ~800 for Java. Clearly Go isn't going to be paying anyones bills anytime soon. At least not in this part of the world.
I agree, my first reaction on seeing the title was "Underhyped? Really? You must be joking."
The reason Java can be a nice language/runtime today is the sheer amount of resources available to be poured on it due to all the hype in the 90s. It was supposed to save us from all the effort porting our software to many operating systems and processor architectures (the computing world was much less homogeneous back then). It was supposed to run everywhere without modification, from the smallest smartcard to the biggest mainframe. It was supposed to not only run within our web browser, but also be the implementation language of our web browser, or even the whole operating system. It was supposed to magically be faster than even C and C++ (those who used Java back then can recall how slow it was; for instance, hanging the whole browser for a whole minute while the JVM started up was not uncommon). Everything was supposed be written in Java; it was not good enough to call a native library for whatever functionality you wanted, it had to be rewritten in pure Java.
Java was a mediocre language. All that hype led to a virtuous cycle, which allowed it to grow into what it is today.
> It was supposed to not only run within our web browser, but also be the implementation language of our web browser, or even the whole operating system
Tbf with Android that came to pass, at least until the applet apocalypse
Look at their age. We've arrived in a world were young developers rediscover old tools and missed the time when Sun Microsystems brute forced Java down the throat of everyone.
Heck, here were native Java CPUs, Java Smartcards and different editions like JavaME for what today is branded IoT devices.
I cannot get the "write once - run everywhere"-slogan out of my head to this day. I don't even want to imagine a world where Java Applets actually "won" the internet and we would have proprietary multimedia applets instead of <audio> and <video> tags or even just CSS...
I recall that we rapidly turned the "write once run everywhere (WORE)" slogan into "WORN- write once, run nowhere" thanks to all the platform-specific changing that always occurred.
Open JDK is pretty good now - Im migrating our prod env away from Oracle JDK soon. The smoke test env running Open JDK has passed all tests. No reason to stay on Oracle anymore. There are other JDK makers and they work great.
OpenJDK is pretty nice, it's the "CentOS" of the Java world. Which, given the recent events around CentOS, should give one pause. If Oracle ever closes the language again, will development follow one of these other JDK makers, or will they all trail the "official" Java like in the past (GCJ/Classpath, Harmony, and so on)?
I was a Java developer for about 15 years, then switched to Node and Typescript about 4 years ago.
I think this author is going to be up for a rude awakening when it comes to the benefits of nominal typing, as this is the area that I couldn't disagree with more. I've commented about this before, but structural typing in Typescript makes it so much easier to refactor and to get one existing piece of code to confirm to another existing piece of code. Refactor projects in Java could sometimes literally take months when you had a major version upgrade from some important dependency and now you had to replace all your Foo1 objects with Foo2 objects, even though the interfaces themselves were largely the same.
I just find myself sooooo much more productive in the Node/Typescript ecosystem than I ever felt in Java.
I think the problem is the cohorts your talking about. There is the dimension of how long you've been programming and how large your software projects are. The folks that gravitate to environments like Java are usually in the high experience large software environment. The other quadrants typically gravitate towards the terse and rapid development platforms.
I didn't care for Java when I learned with it in school, found it verbose.
Working with it as a dev, my opinion improved. A lot of the new FP inspired APIs make logic much terser, and the OOP stuff can make implementing certain architectural patterns very clean.
The other great thing about Java is that nearly every conceivable question has been answered, as far as day to day development. Not so for newer languages.
My biggest pain point with java is the type system. Like, you basically need to write or consume a library to work with tuples.
Java generics just aren't powerful enough to express that a higher order function's exceptions depend on its args, so pretty much everyone has given up on specific checked exceptions.
Yeah, that sort of works, though I’m not sure a function that throws two distinct exception could be compatible with a generic method that takes functions throwing three distinct exceptions (that may sound crazy but some java.security crypto stuff does it).
Looking back on it now I think our revulsion to simply using "throws Exception" ought to be re-examined. In practice, while it's nice to know exactly what kinds of exceptions are being thrown it could be the emphasis on this actually holds us back. What's more important is whether an Exception could be thrown at all versus none.
I do think Java has a bad rep as a "dry, corporate, enterprise" language, but I think there is an ecosystem around Java that is pretty awesome and you can build incredible applications with Java if you want to.
Java has a branding problem. Java (and Oracle) missed the wave of the last 15 years when tech became "cool." If you were new to tech/programming and wanted to pick up a language, which of these three would you pick, based on the website?
Java just doesn't have the cool factor that other languages have. A little rebranding could go a long way to reinvigorating the language in the eyes of newcomers. And I say that because the author of this blog post is a newcomer. Experiened developers know that, despite the ugly Oracle branding, Java is a good language with a sophisticated ecosystem of tools surrounding it. He seems to be mostly enamored with the developer experience of IntelliJ + Java + Maven. And while it is great, that experience is possible with most programming languages.
Disclaimer: I haven't used Java since my early University classes 10+ years ago.
The website is a leftover from when you had to download Java to run programs. Microsoft Silverlight homepage have a similar simplistic feel[1]. I expect it to be updated at some point once there is no need for people to download a JRE.
To be fair, lots of websites were far better in 2010 than today’s white space filled, massive typography, bright colored potpourri of rounded corners, scroll jacked bullshit. Full screen, infinite scroll, hamburger menus. So many awful contemporary design choices.
Don’t pool it all together with this Java website - which sucks but not because it was from 2010.
> I actually laughed out loud at the Java.com homepage. I was so surprised, I expected a sleek, modern homepage but instead I got a portal to 2010.
The Java download button looks clickable without me having to hover over it. The Kotlin "get-started" link doesn't look clickable, because it's next to a different link that has a different style (both actually are clickable). The Scala one has a download link that also doesn't look clickable.
Rubbing salt into the wound, if you click on the second link for Kotlin ("learn more"), the back button doesn't work.
Summary
Java website: made as obvious as possible, prominent download and search interface on main page; type in your search and press enter.
Kotlin: Links differ in appearance from each other, back button broken for some links, which don't even look like links. Cannot type in a search term until after visually finding and clicking a search icon. Then you type in your search term (two-step process).
Scala: download link looks like neither a link nor a button. Never found a search button. At least "Back" works.
I have to say, the Java landing page works best. That your personal preference is for less obvious and less simple user interfaces doesn't make the simple and easy to use interface a bad choice.
I maintain that that lull between 1.6 (2006) and 1.7 (2011) did a large amount of harm to Java. Changing too fast is bad; stasis is also bad. They've played catch up pretty well with features that proved themselves useful in other languages quite well in recent years, but it really fell behind over that five year stretch.
What is really going on here is that there isn't a "the Java website". There is no single organisation or project behind Java which could put such up a website. Similarly, where is the C++ website? The C website?
java.com was originally the website aimed at end-users who need to install Java to use desktop applications written in Java. It looks like it's from 2010 because that's when the last of those went extinct.
This is both hilarious and a great point. Java has no "cool factor". HN headlines will add "written in Rust/Go/Julia/Elixir" for coolness points. If you put "written in Java", it would actually make it seem less cool.
Personally, I wonder if/when Java will become the next COBOL: nobody wants to learn it, feels extremely awkward and obtuse compared to whatever is current then, but there will be loads of old code that needs maintaining.
Certainly feels like it's on that track now...
I'd admit it is very successful, since C++ already existed, it's a commercial miracle. But if you're still promoting Java in 2021, I'd say you're very shortsighted.
Being excited about Java is like being excited about dirt—not any particular dirt, just dirt in general. Yes, practically everything that grows grows in dirt, and anybody can walk on dirt, and in a pinch you can throw it at people or dig a hole and crawl in. Dirt.
Java was designed by people who had absolutely no intention or desire to ever use it. They cribbed parts from other languages they didn't really understand, and changed details in ways that make no sense on their own, or with other things they changed for actual reasons.
Their estimation of its expected users was very low, so they made everything dull and squishy so nobody could do much harm whether by mistake or deliberately.
It got billions of dollars more hype than it deserved on merit. Its privileged place in the corporate world, like its good tooling support, are direct products of that hype. The hype it got on first release, beyond the (very large amount of) money backing it, comes from a peculiar twist of history: right then, millions of programmers were sharecropping on Microsoft's plantation, and saw Java as their 40 acres and a mule. It was a balky mule, but it promised freedom from switching to a whole new app framework literally every 2nd year.
Since then, a very large number of libraries have been made to package most common operations. It's barely adequate for making libraries, but people have put a great deal of effort in because of the big user base.
"I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product.":
I think that Java is more like “concrete” than dirt. Fairly gray, unexciting and utilitarian, but nevertheless much of the world is reliably built on it.
I align with most of these purists. But I don't think the verbosity matters. Its not a bottleneck when you're using Java because you shouldn't be in a position to care about such things. Hell, it's probably beneficial in the extensive SDLC you're probably working in.
Sure, java has its place and enables fine productivity in enterprise dependent workloads & scale; but that scale's complexity is often nominal, because what's unique about a traditional java-based system? Why would you use Java to be unique... the jvm is perfectly magical? nah.
Don't generalize engineering, lol, "feels good"... I think you mean "personally comfortable" which is what the oracles and jet-brains want you to feel. There is no art in java.
I'd struggle to invest so deeply or engrain myself in an enterprise setup vs whatever personal/business circumstances Id be in that situation. If you really want to be hip in that type of world go .NET
Java has gotten better over the years (borrowing good ideas from Scala) and is maintainable. They make a huge effort to keep Java backwards compatible, even across major releases.
I depend on some ancient Java libs and they still work just fine. It's a huge relief when major version bumps don't break everything.
Ah, someone who wasn't around to see the years of real Java hype.
I've had to work with Java professionally for a number of projects over the years, and honestly the only use for it I've actually agreed with as "good" is on Android -- and as we know, Google tweaked it, battles ensued, yadda yadda ...and even they are moving away from it.
The shitshow that owns it is good enough to avoid it, let alone the language itself.
807 comments
[ 4.1 ms ] story [ 380 ms ] threadI would just recommend learning another programming language :)
>by crystallizing type definitions and guaranteeing type guards by default.
Not so crystallizing if you know.. if you've ever used a Java List, Set or a Map. i.e., List<icouldbeanythinginhere>. such guarantee. wow.
Honestly, I'd prefer TS with strict mode over Java any day because nullability is explicit, don't have to watch out for the dreaded NullPointerExceptions left and right.
While it is true the generics are more or less syntactic sugar, I have never seen a ClassCastException due to this in all my years.
Nothing is exciting about it since it's so common. I personally dislike Java since I just find it hard , you'll never want for work as a skilled Java developer
Anyway I looked it up, seems it's a legit usage, my bad.
Akin to "for want of a horse"
Another way to think of it is simply another slightly different meaning for the word "want". Just like in "for want of a horse", or "was found wanting", you can replace the word "want" with the word "lack" in all these examples.
"You'll never lack for work", "the project stalled for lack of engineers", "the code was found lacking"
"Want" may be used as a drop-in for "lack" in each of those.
You could also just say "lack work" instead of "lack for work". But that doesn't really make the "for" redundant. Though I can't explain the reason why not.
Maybe the "for" in "lack for X" or "want for X" is like the "for" in "look for X" or "wish for X"
> You could also just say "lack work" instead of "lack for work". But that doesn't really make the "for" redundant. Though I can't explain the reason why not.
I think it's just that "want" in its original usage is a noun. "Wanting" in "found wanting" is really a gerund of "have a want," not a gerunding of "want." "Wanting" as a gerunding of the verb "want" doesn't necessarily imply a lack. "Wanting to go to the park on Wednesday" doesn't mean you lack anything.
And I've heard good things about Dlang but I've never used it myself, I'll have to check it out some more.
Java is the most in-demand technology in my home country, Estonia. Java also has around 800 open positions at any given time where I live now (Buenos Aires, Argentina). In fact, pretty much everywhere I've looked, Java is consistently one of the best ways to get a job simply because it has the most jobs available.
HN favourites like Go and Rust? I haven't yet found a city in Europe that would have more than 10 job offerings for either of them.
However, the sausage is still made Java. Amazon, Google, and Apple are, as far as a I know, primarily Java shops. It's just no one ever starts a blog with "Here's something cool I did in Java".
Outside of USA, a little digging I did via Glassdoor:
Buenos Aires, Argentina: - Rust: ~5 jobs - Go: ~3 jobs - Java: ~800 jobs
Lisbon, Portugal: - Rust: ~6 jobs - Go: ~30 jobs - Java: ~278 jobs
Barcelona, Spain: - Rust: ~1 job - Go: ~50 jobs - Java: ~751 jobs
These are just places I've lived at and while I can see Go slowly becoming a thing, Rust is still half a decade away from anything tangible for the real world I would say. So if anyone asks me what should they become an expert in for the next 10 years, I would not hesitate to say Java.
Additionally, pretty much all the distributed data processing tools run on the JVM, which is a big deal if that's what you do for a living.
Python, JS and C/c++ are full of idiosyncrasies.
Java allows students to quickly get up and running and focus on the 'CS'.
That said, Python might be more practical for anything applied in school.
If you extend your consideration to build systems and other tooling, it's easy to see that students have a lot to overcome with Java as an intro language.
I think purpose-built languages like the HtDP languages or Logo are better choices. Students can get started with zero faff, learn the essential concepts, and move on.
Java is a fine choice for higher level courses, with students that are already capable programmers.
Yes - 'Logo' is a good choice for the most entry-level users, maybe for high schoolers who are taking CS as a 'required' part of the curriculum, but anything beyond that Java is fine.
I think Generics, Java9++ 'Modules', jar files and class files might be the idiosyncrasies to worry about.
That said, it's weird that in 2021 we don't have a universally 'basic' programming language that is essentially the 'vanilla' of programming.
Somewhere inside JS/Python/TS/Java/Dart I think is that 'basic vanilla' imperative language I think.
- The programs are very verbose for the functionality they provide. There are countless lines of getters, setters, and trivial constructors. While IDE helps to write them, it makes reading existing programs slow and frustrating. Lombok helps, but very few programs use it.
- If you do want to use Java ecosystem, there is Scala. It also has strong type system, nice IDE support and big ecosystem of third-party libraries, but is much more expressive and easier to read and write that Java.
- Finally, if you have to run medium to large java programs, you need to constantly tune the JVM. Unfortunately, you can't "confidently trust the JVM to do what's best" -- you need to get familiar with GC algorithms, manual heap sizing, GC tracing options and so on.
Java still has plenty of uses because it has so much code written in it, but luckily, the new projects are using it less and less. I really look forward to the day when I can stop tuning -Xmx option in start.sh files!
3 month warning that they'd blow up the ecosystem. I have no idea why a company that builds products for devs would take such an aggressively anti-dev approach to shutting down a core service.
I think the biggest change for me was the redesigned collections-library, but that was rather simple migration.
That said; there are a few breaking changes with the migration to 3.0 - especially if you rely on unsupported features of the compiler, namely macros. Macros have been widely used in the past and will not be supported anymore.
Oracle owns Java.
This automatically puts Java on my list of tools I'd prefer to avoid for new serious projects. (Legacy projects; if it's working and it isn't an issue yet, maintenance.)
Never touch anything from Oracle.
Then you will be fine.
Oracle is the company that wants you to buy a license for your MariaDB(!) instance running on a small AWS instance! Yep, that happened.
Source: have worked with Java for years, three of those around Oracle products.
But OpenJDK is Oracle's. They are the primary contributors to the project, and they really made it 100% open-source.
[1] https://en.wikipedia.org/wiki/OpenJDK#Collaboration_with_IBM...
- IDE support for Scala is half as good as Java and I suspect a good reason is the language. The auotcomplete in intelliJ is almost as bad as it is for python and the IDE really struggles to understand the code; CPU usage when scala is open is MUCH higher than Java.
- On all the Java apps I've worked on, I've never tuned the JVM. Tuning the VM sounds like focusing on the wrong part of a bottlenecked system. I've never tuned Python or PHP either but they aren't as performant. Regardless, GC gets better every release.
It sounds like your negative views are more about the applications you've worked on than the language or technology.
This is not my experience. I found the IntelliJ autocompletion to work very well with Scala. There are nice code-suggestions, highlights for implicit parameters, refactoring works as a breeze. What exactly are you missing?
> CPU usage when scala is open is MUCH higher than Java.
That is true. MUCH higher.
That's true for 2005, not 2021, with var, type inference, closures, streams, and other such features. And since forever getters/setters are auto-generated by the IDE (including Emaca and Vim) and can just be ignored, and Java today has Records which don't need them.
>- If you do want to use Java ecosystem, there is Scala.
Now you have exponential problems. Scala has less support, slower builds, and features Scala-devs are eager to abuse to make the code unreadable.
>- Finally, if you have to run medium to large java programs, you need to constantly tune the JVM.
No, you really don't.
Production algorithmic trading app, 100k LOC, 8 GB heap, 258 threads, right now only using 105% CPU; Java 11, and this is the complete extent of JVM tuning we have done:
-Xmx8g -XX:+ExplicitGCInvokesConcurrent
Back in the Java 1.x days, you often did need to do careful JVM tuning. But for the past few years, you haven't. The ergonomics are enough for a very broad range of workloads.
And to add to what you wrote for those that are not familiar with those types of apps: "Production algorithmic trading apps" is among the worst case regarding to peformances / pauses / and tuning needs.
Unfortunately, the Scala compiler is quite a bit slower than javac. In practice this doesn't hurt quite so much anymore; incremental builds make working even with large code bases quite snappy. Full-rebuild; get a coffee.
The build tools for Scala have _massively_ improved in the last 5 years. IntelliJ support is superb and VS Code with metals is shaping up very nicely.
I agree that since Scala is a unopinionated language, you need to be strict in what you allow your devs to do. Code reviews and agreements on levels of abstraction and concepts used is mandatory.
I've worked with multiple teams in the last 8 years and this discipline is important when working with Scala. Doing so will give you the opportunity to write clean, maintainable and readable code in a very powerful language.
https://scala-ci.typesafe.com/grafana/dashboard/db/scala-ben...
The Scala 3 compiler has much fewer passes though.
You either haven't used Scala, or you haven't used Java.
Sure, you can find libraries using complex type-level machinery, macros and so on. But wading through complex Java libraries that overuse OO design patterns isn't particularly approachable either.
There are one or two knobs left but those are fundamental to GC technology and it's not even obvious they're bad to have. GC lets you trade off memory against CPU time in ways manual memory allocation does not. You can throw memory at your program and it'll run faster, or you can constrain it and it'll run slower, but that's not a decision the developer can always reasonably make. It's in some ways inherently an ops/deployment/end user thing.
Other GCd languages either:
1. Have knobs too (Go/.NET both have knobs), just usually not very good ones.
or
2. Are so slow (Ruby, Python) that GC tuning is really the least of your worries and they just don't expose it at all.
or
3. Are JavaScript, in which case everyone pretends that running a VM designed exclusively for laptops and mobile phones on the server isn't a giant waste of resources. V8 doesn't do GC tuning because its only real customer is web browsers where users can't do that, and heaps are small anyway.
Java ended up getting a totally unfair rap about GC because it actually was fast enough that GC performance mattered, and was interested in power users on the server where exposing knobs can make sense. Other competitors don't even try, but this doesn't make them better. After all, nothing stops you just ignoring the knobs and plenty of users do exactly that.
Scala has a whole slew of problems of it's own. IMHO, Kotlin is where all the Java refugees on the JVM continent are at.
Language development looks a lot like the startup path anymore. Claim you fill a need. Focus on growth growth growth by adopting features from as many communities as possible as fast as possible. If it's trendy, add it! Have a flashy web page. Find some venture capital by getting a big org to underwrite/champion you. Figure out how to really solve problems and fix everything once you've got critical community.
- It forces us to go through the ceremony and verbosity of static typing, yet blows away lots of the benefit by pervasive use of `null` and `Object`. Compare this to ML or Haskell, where there's less ceremony (Hindley-Milner type inference) yet more safety (no `null` or down-casting)
- Checked exceptions have a similar ceremony and verbosity problem, yet the pervasiveness of unchecked exceptions prevents us actually having much confidence that calls will succeed. Compare this to effect systems, even rudimentary ones like Haskell's (`Maybe`, `Either`, `IO`, etc.): if a function doesn't return one of these 'effect actions', we can be pretty sure that it will succeed (the only unchecked exceptions I've encountered in Haskell are pretty catastrophic things like OutOfMemory).
- It needs to be compiled ahead-of-time, which requires more tooling, makes automated testing more annoying (we have three different failure-reporting mechanisms: app compile error, test compile error, test failure), tools like REPLs are second-class afterthoughts, etc. Yet the resulting bytecode still requires an interpreter (JVM), which takes a while to spin up, and makes deployment and packaging harder (we don't have a self-contained binary).
- It pushes an OOP style, but requires that we keep subverting it; e.g. pervasive use of using structured-programming constructs like `for` (which other OO languages like Smalltalk avoid in favour of method calls), which requires we break encapsulation/implementation-hiding (e.g. if we loop with an 'Iterator', we need to know whether anything we call will use that same Iterator).
- It seemingly pushes a high-level, highly-abstracted design (methods calling other methods, classes maintaining their invariants, etc.); but then throws threading into the mix, which breaks things into such low-level pieces that even 'i++' needs to be thought of in terms of constituent parts (read, increment, write, return).
I agree that Scala's better (e.g. reducing a lot of the typing ceremony; making it easier to remain high-level/abstracted (e.g. encouraging 'map' and friends rather than effectful loops), etc.); it inherits some of Java's problems (and doesn't even flag checked exceptions!), but it's nice enough to tilt the balance in many cases.
Who is pervasively using Object? You are talking about a language that hasn't existed for a decade.
Since then I've defined a .has method which requires the argument to have the same type as the collection, which completely avoids such problems.
My `.has` method uses cats.Eq and is monkey-patched on to the Iterable interface:
Yet not the most important static analysis suite, which is included in the compiler, and enforced on all code: the type checker ;)
This sounds like you're not programming in the Java language, you're programming in some sort of graphical macro language which compiles down to Java (presumably built-in to an IDE of some sort?).
The fact that people resort to such things is evidence that this is a valid criticism of the Java language.
No, Java is just about as hyped as it needs to be. Which is to say, it's more or less fine. Not great, not terrible. Middle of the road at best.
No true scotsman? Even if you want to argue that Java CAN be made more terse, the vast majority of Java that exists today is incredibly verbose. Even running a Java program is verbose. Java is the only language I've used where it's more common to have a shell script that starts your Java program than just running ./helloworld.
And yes, Go is less verbose than Java. Go might require some boilerplate, but it is certainly much less verbose than Java.
So, less magic is better. I will take Java codebase over Scala or Python every time, unless it is a toy script which is 100 lines
AOP sucks because it is paaaain to debug, proxies are magic. There is Dagger that solve some stuff
Who needs CPP macros when you've got reflection?
https://software-mastery.teachable.com/p/uncommon-sense
FYI: I am NOT an author of this course.
Take a look at a http server one in Java and one in C. Readability difference is crazy.
My company is in transition from Java to C, for bunch of stuff just for performance reasons. So, I debug similar projects time to time both in Java and C, http server, in memory cache, iot server etc. After seeing both, I just think although Java has great tooling, it drives developers to write unreadable code.
No, this is utter, utter nonsense. I have written plenty of both, and it's not even close.
If you are going to press this extraordinary claim, you need to supply at least some evidence for it.
Com.prout.shit.lol...
It’s just impossible to use without editor support. Nobody who cares for their sanity can type out those package names manually. I think even Gosling said as much.
Saying this as someone who Java after Python and other languages.
I'm used to Python (and some Go) for decades, and the verbosity of Java is a non-issue to me.
I'd rather have the speed, type safety, and refactoring tools support, over Python... (not to mention the much better packaging situation).
I'd still prefer Python for smaller programs, basically because of the startup time and quick write/try cycle. But for larger stuff, I'm not so sold, and I've been doing them (in Python) for decades...
Manual for loops? No generics?
I think it really fell out of favor due to Oracle's litigious handling of it. As soon as Oracle bought it I remember people actually cancelling Java projects and changing languages.
Another problem is how complex and verbose it got. Original late-90s Java was pretty clean but eventually the ecosystem fell in love with enterprise style cruft and overengineered everything. It's less a problem with the language than the community though. Like C++, you do not have to use every pattern and language feature... but many people think you do and write ridiculously complicated verbose code.
Thanks for the info. Didn’t know this. I use AdoptOpenJDK and am grateful the free version is so fully featured.
I’d imagine back in the day Oracle Java reigned supreme and their licensing terms were a real concern.
Oracle bought Sun in 2010, things looked okay for a year or two, then it started to get scary.
The situation now is not scary: there is a community process to manage the language and library definitions, the JDK is open source, with Oracle contributing, there are other significant contributors (notably RedHat and IBM ... so now just IBM), and there are multiple freely-available high quality binary releases of the same source.
It could potentially get scary again. If Oracle stop contributing to the open source JDK, and instead work on a closed-source version of their own, then it's not clear that there is enough developer power among the remaining contributors to keep things moving at a healthy speed. But then, if that happened, maybe users would abandon Java rather than pay Oracle, so it would be a suicidal move for Oracle. Or, if that happened, other contributors could step up contributions to hoover up customers from Oracle. But it's not entirely reassuring to be depending on game theory like this.
Except that if you actually code for money, neither of those have many jobs available. Heck, in many cities I've looked _any_ jobs available. Java is still one of the most employable tools out there simply because it has a lot of jobs. Sometimes the hype-train of HN makes me think that people here are just coding for a hobby or their own start-up and entirely forget how the real world actually works.
Reminds me of a rationalization I heard once about how people pick their brand of cigarettes. They all taste like crap until you're finally addicted, then the one you happen to smoke at the time is now your brand.
Every new language / stack now gets compared to Java with IntelliJ because that's what they learned. Can't tell 'em any different.
I think my emotions are misplaced: I might just like IntelliJ.
Java is a phenomenal piece of kit, the amount of engineering that went into the JVM is insane. But people took the lessons from Java and put them into newer languages, that don't have the problems Java does that require an IDE.
My love is in the language that IDEs don't and can't really add much to, Ruby. Emacs give me all I need.
VSC has a pretty good Java experience.
Certainly the emacs mode does: https://projects.eclipse.org/projects/eclipse.jdt.ls
[1]: https://github.com/redhat-developer/vscode-java/issues/1132
Also, congrats on graduating from CU! Just graduated last semester.
IMO, if you want to get a descent job in a large company working on backend systems, you want to learn: Java, C/C++ or recently Go. You will be able to build pretty much anything, from a micro service to self driving car.
If you want to stick to startups, you can do well with anything else till it growth, experienced engineers are hired and rewrite it in one of those languages.
I really don’t care what language I’m using if it it doing the job. I use Java, Java Script, Go, Python, Scala when appropriate.
Java has become reasonable though I'd always reach first for Scala or Kotlin (maybe Clojure?) I'd like to work with Rust but it seems hard for an employer to cost-justify the dev work to avoid paying for G1.
The fact that you don't care does not make everyone other than you not a reasonable person.
Frankly I don't see how any reasonable person could fail to develop some preferences, but I bet you would not like it if I called you unreasonable, or perhaps just unsophisticated.
I’m talking about picking a tool that does the job according to the requirements (speed, memory, debuggability), not based on what some YouTuber said.
We are engineers and paid for results. It help with carrier to embrace it.
Here is one: there is a database written in Java and you need to implement more features. There is 10000000 lines of code in the companies source and new code should be the same. I can go on and on.
Personal advice - if you want growth, drop preferences. When FAANG interviews nobody even asking what is your preferred language as nobody cares.
The reason Java can be a nice language/runtime today is the sheer amount of resources available to be poured on it due to all the hype in the 90s. It was supposed to save us from all the effort porting our software to many operating systems and processor architectures (the computing world was much less homogeneous back then). It was supposed to run everywhere without modification, from the smallest smartcard to the biggest mainframe. It was supposed to not only run within our web browser, but also be the implementation language of our web browser, or even the whole operating system. It was supposed to magically be faster than even C and C++ (those who used Java back then can recall how slow it was; for instance, hanging the whole browser for a whole minute while the JVM started up was not uncommon). Everything was supposed be written in Java; it was not good enough to call a native library for whatever functionality you wanted, it had to be rewritten in pure Java.
Java was a mediocre language. All that hype led to a virtuous cycle, which allowed it to grow into what it is today.
Tbf with Android that came to pass, at least until the applet apocalypse
Heck, here were native Java CPUs, Java Smartcards and different editions like JavaME for what today is branded IoT devices.
I cannot get the "write once - run everywhere"-slogan out of my head to this day. I don't even want to imagine a world where Java Applets actually "won" the internet and we would have proprietary multimedia applets instead of <audio> and <video> tags or even just CSS...
Given their insidious licensing and litigious nature, I wouldn’t touch Java with a ten meter pole.
theamk's post about
> There are a few reasons to avoid Java today.
Hard agree, and had the same thought BECAUSE Oracle.
I think this author is going to be up for a rude awakening when it comes to the benefits of nominal typing, as this is the area that I couldn't disagree with more. I've commented about this before, but structural typing in Typescript makes it so much easier to refactor and to get one existing piece of code to confirm to another existing piece of code. Refactor projects in Java could sometimes literally take months when you had a major version upgrade from some important dependency and now you had to replace all your Foo1 objects with Foo2 objects, even though the interfaces themselves were largely the same.
I just find myself sooooo much more productive in the Node/Typescript ecosystem than I ever felt in Java.
Working with it as a dev, my opinion improved. A lot of the new FP inspired APIs make logic much terser, and the OOP stuff can make implementing certain architectural patterns very clean.
The other great thing about Java is that nearly every conceivable question has been answered, as far as day to day development. Not so for newer languages.
My biggest pain point with java is the type system. Like, you basically need to write or consume a library to work with tuples.
Java has a branding problem. Java (and Oracle) missed the wave of the last 15 years when tech became "cool." If you were new to tech/programming and wanted to pick up a language, which of these three would you pick, based on the website?
- Java: https://www.java.com/en/
- Kotlin: https://kotlinlang.org/
- Scala: https://www.scala-lang.org/
Java just doesn't have the cool factor that other languages have. A little rebranding could go a long way to reinvigorating the language in the eyes of newcomers. And I say that because the author of this blog post is a newcomer. Experiened developers know that, despite the ugly Oracle branding, Java is a good language with a sophisticated ecosystem of tools surrounding it. He seems to be mostly enamored with the developer experience of IntelliJ + Java + Maven. And while it is great, that experience is possible with most programming languages.
Disclaimer: I haven't used Java since my early University classes 10+ years ago.
[1] https://www.microsoft.com/silverlight/
Don’t pool it all together with this Java website - which sucks but not because it was from 2010.
I abhor and loathe modern web design.
I just remember the Java.com homepage from visiting it in computer lab in 2011 so I could play Minecraft.
The Java download button looks clickable without me having to hover over it. The Kotlin "get-started" link doesn't look clickable, because it's next to a different link that has a different style (both actually are clickable). The Scala one has a download link that also doesn't look clickable.
Rubbing salt into the wound, if you click on the second link for Kotlin ("learn more"), the back button doesn't work.
Summary
Java website: made as obvious as possible, prominent download and search interface on main page; type in your search and press enter.
Kotlin: Links differ in appearance from each other, back button broken for some links, which don't even look like links. Cannot type in a search term until after visually finding and clicking a search icon. Then you type in your search term (two-step process).
Scala: download link looks like neither a link nor a button. Never found a search button. At least "Back" works.
I have to say, the Java landing page works best. That your personal preference is for less obvious and less simple user interfaces doesn't make the simple and easy to use interface a bad choice.
What is really going on here is that there isn't a "the Java website". There is no single organisation or project behind Java which could put such up a website. Similarly, where is the C++ website? The C website?
java.com was originally the website aimed at end-users who need to install Java to use desktop applications written in Java. It looks like it's from 2010 because that's when the last of those went extinct.
C website: http://www.open-std.org/jtc1/sc22/wg14/
- https://www.oracle.com/java/technologies/javase-downloads.ht...
- https://jdk.java.net/
- https://openjdk.java.net/
Java was designed by people who had absolutely no intention or desire to ever use it. They cribbed parts from other languages they didn't really understand, and changed details in ways that make no sense on their own, or with other things they changed for actual reasons.
Their estimation of its expected users was very low, so they made everything dull and squishy so nobody could do much harm whether by mistake or deliberately.
It got billions of dollars more hype than it deserved on merit. Its privileged place in the corporate world, like its good tooling support, are direct products of that hype. The hype it got on first release, beyond the (very large amount of) money backing it, comes from a peculiar twist of history: right then, millions of programmers were sharecropping on Microsoft's plantation, and saw Java as their 40 acres and a mule. It was a balky mule, but it promised freedom from switching to a whole new app framework literally every 2nd year.
Since then, a very large number of libraries have been made to package most common operations. It's barely adequate for making libraries, but people have put a great deal of effort in because of the big user base.
"I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product.":
<http://blog.plover.com/prog/Java.html>
Sure, java has its place and enables fine productivity in enterprise dependent workloads & scale; but that scale's complexity is often nominal, because what's unique about a traditional java-based system? Why would you use Java to be unique... the jvm is perfectly magical? nah.
Don't generalize engineering, lol, "feels good"... I think you mean "personally comfortable" which is what the oracles and jet-brains want you to feel. There is no art in java.
I'd struggle to invest so deeply or engrain myself in an enterprise setup vs whatever personal/business circumstances Id be in that situation. If you really want to be hip in that type of world go .NET
I depend on some ancient Java libs and they still work just fine. It's a huge relief when major version bumps don't break everything.
I've had to work with Java professionally for a number of projects over the years, and honestly the only use for it I've actually agreed with as "good" is on Android -- and as we know, Google tweaked it, battles ensued, yadda yadda ...and even they are moving away from it.
The shitshow that owns it is good enough to avoid it, let alone the language itself.