10 ms·

Java's adequate. It's like a Toyota Corolla (insert your boring car of choice here if you don't feel this one works for the analogy). Not the prettiest, not the

Java's adequate. It's like a Toyota Corolla (insert your boring car of choice here if you don't feel this one works for the analogy). Not the prettiest, not the fastest, not the most efficient. But it gets you from point A to point B with little fuss or muss. I totally get why companies adopt and standardize on it. Do I use it for personal projects? Nope. Because it's not fun to "drive". For that, I pick the equivalent of a Mazda Miata (insert exciting car of choice), which for me is usually a Lisp.

NoSorryCannot 4y ago
Whoever invented the car analogy should pay for what they did.
- deleted 4y ago
  [deleted]
- jgust 4y ago
  Bagging on car analogies is like driving a Hellcat, it's not practical.
- deleted 4y ago
  [deleted]
- bil7 4y ago
  do you have some other anology we should all switch to? maybe a ferrari level analogy that's way better?
- mindslight 4y ago
  Indeed. All cars suffer the same speed limits and traffic, so how effective your car is ultimately depends on how you drive within those constraints. The analogy slyly condenses everything down to some car-manufacturer-marketing version of "fun", betraying both spirited drivers and whatever topic it is applied to. Since we're throwing out analogies, Java-the-language is more like a riding lawnmower. It is capable of getting you to your destination, but will be slow and painful the entire time. There is probably some external constraint that you'll be forced to endure this, like losing your license.
  - shagie 4y ago
    This was something / part of the plot of The First $20 Million Is Always the Hardest. I recall the main character getting a car (turned out to be rented) that was really fast and taking the team out driving on 101 in rush hour traffic to make this point.
- mgkimsal 4y ago
  I think the car analogy is just extending a base analogy. There could be other siblings. Perhaps AnimalAnalogy could extend BaseAnalogy and we could talk about animals instead? ;)
  - enragedcacti 4y ago
    If you think about it, the car analogy really is the Corolla of analogies.
- bee_rider 4y ago
  Car analogies aren't intrinsically bad, they are just the go-to analogy when someone wants to jam an analogy where it isn't needed. Analogies in general should be used sparingly, and only in an explanatory setting. Instead people use them as a rhetorical device in arguments, which usually reduces the argument to arguing about the analogy (and you can usually shuffle around the parts of an analogy to flip the meaning somehow). Here it is fine I think, the writer of the comment is just explaining their point of view.
  - drewcoo 4y ago
    > Car analogies aren't intrinsically bad What can I say? They get me from claim A to claim B. So are you saying that analogies should only be used like secondary steering wheels?
    - aeonik 4y ago
      They only get you from claim A to claim B when there is enough traffic to invest in roads and if people follow the rules. A more versatile set of analogirs are of course ATVs, Aircraft, or even the humble legs.
    - bee_rider 4y ago
      Analogies should only be used like trains: An efficient, well thought out path from point A to B on a vehicle that is piloted by a pro. Car analogies look appealing -- they look more flexible, but this can also lead to people taking overly circuitous routes to get to the point... maybe the driver just doesn't know what they are doing, maybe the road system is poorly optimized because it needs to hit lots of points, or maybe the driver is like a sneaky cab driver that intentionally takes an inefficient path to increase the fare. The wider availability also leads to a situation where cars are mostly piloted by random people with no particular qualifications other than a basic license. This can result in lots of car crashes. Of course, it is also possible for a train to get derailed, but this is a rare occurrence. On the other hand a derailing can result in more damage... ah... hmm, I forget where I was going with this...
- dls2016 4y ago
  I remember an intermediate OO class in Java 20 years ago... the existence of the El Camino was proof of the terribleness of both multiple inheritance and car analogies.
  - cutler 4y ago
    .... with gave birth to ShapePoint analogy.
  - bigtunacan 4y ago
    I would love to see the El Camino resurrected, especially as an AWD EV. Sign me up!
- pushingice 4y ago
  The car analogy is the Ford Model T of analogies.
halfmatthalfcat 4y ago
What does that make Scala? A RAV4?
- yurodivuie 4y ago
  Still a Corolla, with left-hand drive and manual transmission.
- btmcnellis 4y ago
  A Pontiac Aztek.
- gclaramunt 4y ago
  Lexus
- falcolas 4y ago
  I'm going to catch hell for this, I just know it. A Chrysler PT Cruiser. Odd looking, beloved by its fans, and a reasonably adequate (if quirky) to drive.
- speed_spread 4y ago
  Scala is a ring of four Corollas welded by the edges of their rooftops so that rolling over only changes the set of wheels you're using. Also, all wheels are omni directional so you can drive sideways when required.
kaba0 4y ago
I don’t know, probably some truck would be a better analog. It ain’t sexy, but it was made to be a blue collar language, and it is the one that ships cargo nigh everywhere.
- perardi 4y ago
  To really nitpick the analogy: Java is a Ford Transit cargo van. It’s primarily used by enterprise shops. You’d never brag you about driving a van. It’s not fashionable. It’s kinda ugly. But…it gets the job done.
  - topaz0 4y ago
    Speak for yourself. I brag about driving a 2013 transit connect.
- mgomez 4y ago
  You're not alone as someone else made a similar observation in a previous thread[1]: > To me Java is like a garbage truck. You get to work, start it up, do a nearly invisible but absolutely essential duty, then, at the end of the day, you turn it off and go home. No one dreams about garbage trucks or puts one in a car show but they’re there and ready to go right back to work when you are. [1] https://news.ycombinator.com/item?id=26834177 https://news.ycombinator.com/item?id=26834177
throwawaymaths 4y ago
Corollas don't come with all sorts of weird (now aging) buzzword-driven preferences like nudging you towards xml, factories, etc.
- falcolas 4y ago
  Personal rant: I've never understood the hate towards XML. It's a practical and flexible markup language that does not depend on whitespace or quoting every bloody thing. Plus, every markup language invented since has had to re-invent XML things that, surprise surprise were actually needed. Paths, schemas, comments, etc. I get frustrated with JSON because of things I could do in XML that I can't do in JSON without breaking the spec. And that doesn't even cover how annoyingly verbose anything done in JSON is. Anyways.
  - aeze 4y ago
    You consider JSON to be more verbose than XML? I'm curious to hear why.
  - gen220 4y ago
    I think people dislike XML precisely because it's so flexible and unopinionated. It means that when you're parsing a new XML source, you have to look for data that might be encoded in two or three little niches. God help you if it's encoded in each of them, and if the data therein is contradictory. Basically, it's easy to "hold it wrong" in a way that harms consumers.
    - falcolas 4y ago
      > I think people dislike XML precisely because it's so flexible and unopinionated. You're probably right. > Basically, it's easy to "hold it wrong" in a way that harms consumers. I feel a bit like this could equally apply to things like GraphQL. I spend more time reading the docs on how someone's internal data model is built than I do writing GraphQL queries. And if I get that data model slightly wrong, my query's garbage. But that's probably a separate, vendor specific (coughnewrelic), rant.
jeroenhd 4y ago
My problem with Java is that C# exists which does huge portions of the stuff Java excels at just… better. Before, .NET only ran on Windows which disqualified it from many serious applications server deployments. Today, this is no longer the case for everything but cross platform GUI libraries, and even those are an option if you're okay with not having Linux support. It's more akin to the old car you had just before you bought your Corolla. It was also pretty decent, but it was starting to have issues. The JVM ecosystem is quite expansive and it's capable of running many things that would be a pain to develop in house (or pay a third party developer for). However, Java isn't the only popular JVM language anymore and you're no longer forced to use Java to interact with its surrounding ecosystem. The language and the ecosystem around it aren't going to go away for at least a decade, but I think it'll slowly move the way of COBOL and FORTRAN: perfectly good languages, with perfectly good situations they outperform their competitors in, practically exclusively used for niche use cases and legacy software systems.
- pron 4y ago
  > but I think it'll slowly move the way of COBOL and FORTRAN That could be true of any language that's achieved great popularity, but in 2022 Java is the language that dominates server-side development (by plurality, not majority), it is a technological leader in areas of compilation, garbage collection, and low-overhead in-production profiling, no other single language looks posed to seriously challenges Java's dominant position on the server (as PHP seemed for a while), and, at 27, it is more popular than COBOL was in its (rather short) heyday. But it is true that Java is among a select set of languages (alongside Python, JavaScript, and C) that have managed to achieve a level of success sufficient to become "a COBOL" or "a Fortran" someday.
  - amanaplanacanal 4y ago
    Aren't most of those benefits from the JVM rather than Java itself?
    - pron 4y ago
      First of all, what most people call "the JVM" is really called Java. Java = libraries + VM + tools + language. Of the ~8 MLOC in the JDK, the Java language compiler and Javadoc make up around 200KLOC; the VM makes up about 1.5M. What is sometimes colloquially known as "the JVM" is really everything except the language, of which the actual JVM is pretty small. Second, while the JDK is pretty modular (e.g. you can use the runtime and tools but not the frontend compiler as "JVM languages" do), we design every feature by looking at the platform as a whole. E.g. the relatively new records feature is implemented in the language, libraries, and VM. That's why some newer Java platform languages have more baggage than the Java language, because their features are not harmonious with the direction of the libraries and VM (e.g. Kotlin's coroutines and data classes). Finally, it is true that back in the '90s, James Gosling set out Java's strategy to put most innovation in the runtime and keep the language very conservative (he called it "a wolf in sheep's clothing"), and we follow that strategy to this day, because it's turned out to be very successful. While there are lots of programmers who want more adventurous, feature-rich languages -- and many of them hang out here -- the vast majority of programmers don't. Many more people complain that the Java language is changing too quickly than changing too slowly. So it is thanks to the conservative language that the platform is so popular, which allows us to have the resources to innovate in the runtime. So while <10% of people using Java do so with another language (no single alternative language has gained more than 5% of the platform's ecosystem) -- and we're happy we can accommodate everyone -- the conservative language is a necessary component of making the runtime state-of-the-art. A combination of an innovative runtime and a conservative platform is what most people want, and that combination is the main benefit.
hedora 4y ago
I'm going to go with "Java is like a 2006 Chrysler 300". I'm basing this on this list of the most popular fleet vehicles in the US: https://www.fuelexpress.net/blog/just-for-fun/4597-2/ https://www.fuelexpress.net/blog/just-for-fun/4597-2/ The Corolla is known for reliability and fuel economy. It's the car you'd buy for your fleet so you could ignore it, and then you would ignore it, and some day, people would start assuming you are going out of business or something because all your fleet vehicles are from the late 90s. On the other hand, the 300 claims to be those things, but has terrible fuel economy, and apparently likes to unexpectedly spin out. They claim that new ESP magically fixes the problem, even though they've been claiming such things for years. It's actually supposed to be a luxury car or something, but apparently for some reason it is used as a fleet vehicle, where it is a poor fit. Also, since it is a Chrysler, I assume it is unreliable. Oh look, I'm right: https://cars.usnews.com/cars-trucks/chrysler/300/2011/reliability https://cars.usnews.com/cars-trucks/chrysler/300/2011/reliab... (In fairness, the newer ones are supposedly reliable. Sort of like how Java is supposedly pause free now.) Filling out the rest of the analogy: fuel economy => Java startup costs, and asymptotic / constant factor slow downs because it doesn't support zero cost abstraction. spinning out => The GC, of course magic ESP => The next GC solves the pause / thrashing issues (promised every year since at least 1998) reliability => Constant API churn, the 8 => 11 => 17 => 20 treadmill, and (of course) log4j. targeting luxury segment => Java targeting toasters, IoT and web browsers back in the 90s, but only being able to run on hilariously overbuilt and power hungry enterprise boxes instead. Also, the classloader's open world assumption.
- kaba0 4y ago
  I have very vague knowledge of cars, but I know for a fact that your characterization of Java is just bad, no matter how good you car analogy-creation may be. I won’t even correct the others, but how come Java is unreliable? Like, I have a hard time thinking of anything in the category of computer programs that would fair better.
  - hedora 4y ago
    Have you ever had to maintain an old enterprisey Java thing? It's pure hell. Basic dependencies (like JUnit) break API compatibility every few years, and then they stop distributing the old version for new JVMs, so you're forced to port your code. The GC falls over in production at the least convenient times. People somehow decide everything should be stringly-typed, and that the best choice between .properties, xml and JSON is "all of the above, and also this in-house DSL". There's this common pattern called "vendoring" where you load multiple incompatible versions of the same library into the same JVM, and exploit loopholes in classloader semantics to prevent it from noticing, and ungracefully exiting (which is what it really, really should do). There's no way to use language improvements and static analysis to improve program semantics over time (like there is in, say C++) because none of the language level abstractions are sound. For example, you have a line like "static Foo foo = new Foo()". Guess what? foo can be null sometimes. Here's an unrelated problem: Think you have a function that doesn't throw exceptions? Nope. Some third party garbage can throw errors during normal operation instead. Think that eliminating down casts in your program means it won't throw ClassCastException on unexpected lines? That hasn't been true since generics were invented. Think Optional gets rid of null pointer exceptions? Nope. Instead, it's actually a tri-value null. After all, you can always create null references to an Optional (and, looping back to the beginning of the paragraph, you can't avoid creating null references to Optionals in idiomatic code!) I could go on for hours.
adrian_b 4y ago
I am not convinced that Java is adequate. I do not know if the problems are related to the Java language or to the typical Java programmers, but Java is the only programming language where I have seen a strong correlation between the programming language used to implement some application and a low quality of that application. During decades of experience with various programs, whenever I was surprised that a program seemed to be abnormally slow, or it had an unusually ugly GUI, or it had a GUI that was impossible to customize, e.g. it was impossible to change the default font or the size of the font, or it had various other annoying features seldom encountered in other programs, I discovered that it was written in Java. Most of these annoying programs where commercial programs, some of them very expensive programs. The most recent Java problem that I have encountered was last year, when I could not install some expensive program, because the installer crashed immediately. After some time wasted to discover the reason, the conclusion was that the installer was written in Java and it always crashed immediately on any computer to which a 30-bit monitor was connected. That program had both Windows and Linux versions, but both crashed in the presence of a 30-bit monitor, so the Java installer was of the kind "write once, crash anywhere". The workaround was to disable the GUI of the installer and make an installation from the command line. There are some 15 years since I use only 30-bit monitors, but this was the first time when I have seen such a behavior (probably because I avoid Java programs, due to past experiences). Googling has shown that this was actually a well known bug in Java installers, which had not been solved in a long time.
- valbaca 4y ago
  I'm with you, even as a Java developer I can immediately recognize when something was written in Java: it's ugly and slow. When it crashes, you know they missed a NPE or tried to use multiple threads.
  - gorjusborg 4y ago
    > I'm with you, even as a Java developer I can immediately recognize when something was written in Java Sure, if we are talking about desktop applications and we ignore the exceptions (Intellij / Minecraft).
valbaca 4y ago
Hit too close with the analogy: Been a Java dev for ten years and I drive a Toyota Corolla.... ...but also in my spare time I play around with Clojure and dream of buying a '69 SS Camaro
- nly 4y ago
  Admit it, you never will.
  - TheRealDunkirk 4y ago
    Well, maybe, like me, by the time you can afford it, your knees and back don't align with getting in and out of one.
- falcolas 4y ago
  I appear to be you, just with a Subaru BRZ. It's a manual, it's fun as hell.
skybrian 4y ago
I wouldn’t use Java again because I am done dealing with the brokenness of Maven and Gradle. They are the opposite of “little fuss and muss.” The Go build tools fit your analogy better.
- SureshG 4y ago
  > The Go build tools fit your analogy better. Go uses two build tools for any non-trivial projects. One write in go.mod and another in Make :D (see this - https://github.com/kubernetes/kubernetes/tree/master/build/root https://github.com/kubernetes/kubernetes/tree/master/build/r...)
  - skybrian 4y ago
    I think Hugo might be a better example, as a medium-sized non-trivial project: https://github.com/gohugoio/hugo https://github.com/gohugoio/hugo There is a Docker file and some shell scripts, but you build the executable using "go install".
- chii 4y ago
  > dealing with the brokenness of Maven people shit on maven, but i say it's much better than many other built tooling - npm, make, or custom scripts. The only thing need getting used to is that you cannot and should not stray from the maven model - fit your project's built into the maven model, rather than try to twist maven to do your bidding.
  - skybrian 4y ago
    Maybe I haven't built anything large enough to feel the pain, but I find npm acceptable. Go's module system seems more secure, but I had little fuss using npm to build a simple web app.
- peterashford 4y ago
  You dont have to use those tools, you know
drewcoo 4y ago
> It's like a Toyota Corolla This is only an invitation to car-shedding!
- falcolas 4y ago
  So it was. So it was indeed.
baldfat 4y ago
I personally use Racket (Lispish) just because it is so much fun to build whatever I want and customize it. It just feels good to have my small projects just fit me perfectly.
- cutler 4y ago
  What's the relevance with respect to Java, though, which is designed for managing projects in large teams?

NoSorryCannot 4y ago

Whoever invented the car analogy should pay for what they did.

deleted 4y ago
[deleted]
jgust 4y ago
Bagging on car analogies is like driving a Hellcat, it's not practical.
deleted 4y ago
[deleted]
bil7 4y ago
do you have some other anology we should all switch to? maybe a ferrari level analogy that's way better?
mindslight 4y ago
Indeed. All cars suffer the same speed limits and traffic, so how effective your car is ultimately depends on how you drive within those constraints. The analogy slyly condenses everything down to some car-manufacturer-marketing version of "fun", betraying both spirited drivers and whatever topic it is applied to. Since we're throwing out analogies, Java-the-language is more like a riding lawnmower. It is capable of getting you to your destination, but will be slow and painful the entire time. There is probably some external constraint that you'll be forced to endure this, like losing your license.
- shagie 4y ago
  This was something / part of the plot of The First $20 Million Is Always the Hardest. I recall the main character getting a car (turned out to be rented) that was really fast and taking the team out driving on 101 in rush hour traffic to make this point.
mgkimsal 4y ago
I think the car analogy is just extending a base analogy. There could be other siblings. Perhaps AnimalAnalogy could extend BaseAnalogy and we could talk about animals instead? ;)
- enragedcacti 4y ago
  If you think about it, the car analogy really is the Corolla of analogies.
bee_rider 4y ago
Car analogies aren't intrinsically bad, they are just the go-to analogy when someone wants to jam an analogy where it isn't needed. Analogies in general should be used sparingly, and only in an explanatory setting. Instead people use them as a rhetorical device in arguments, which usually reduces the argument to arguing about the analogy (and you can usually shuffle around the parts of an analogy to flip the meaning somehow). Here it is fine I think, the writer of the comment is just explaining their point of view.
- drewcoo 4y ago
  > Car analogies aren't intrinsically bad What can I say? They get me from claim A to claim B. So are you saying that analogies should only be used like secondary steering wheels?
  - aeonik 4y ago
    They only get you from claim A to claim B when there is enough traffic to invest in roads and if people follow the rules. A more versatile set of analogirs are of course ATVs, Aircraft, or even the humble legs.
  - bee_rider 4y ago
    Analogies should only be used like trains: An efficient, well thought out path from point A to B on a vehicle that is piloted by a pro. Car analogies look appealing -- they look more flexible, but this can also lead to people taking overly circuitous routes to get to the point... maybe the driver just doesn't know what they are doing, maybe the road system is poorly optimized because it needs to hit lots of points, or maybe the driver is like a sneaky cab driver that intentionally takes an inefficient path to increase the fare. The wider availability also leads to a situation where cars are mostly piloted by random people with no particular qualifications other than a basic license. This can result in lots of car crashes. Of course, it is also possible for a train to get derailed, but this is a rare occurrence. On the other hand a derailing can result in more damage... ah... hmm, I forget where I was going with this...
dls2016 4y ago
I remember an intermediate OO class in Java 20 years ago... the existence of the El Camino was proof of the terribleness of both multiple inheritance and car analogies.
- cutler 4y ago
  .... with gave birth to ShapePoint analogy.
- bigtunacan 4y ago
  I would love to see the El Camino resurrected, especially as an AWD EV. Sign me up!
pushingice 4y ago
The car analogy is the Ford Model T of analogies.

halfmatthalfcat 4y ago

What does that make Scala? A RAV4?

yurodivuie 4y ago
Still a Corolla, with left-hand drive and manual transmission.
btmcnellis 4y ago
A Pontiac Aztek.
gclaramunt 4y ago
Lexus
falcolas 4y ago
I'm going to catch hell for this, I just know it. A Chrysler PT Cruiser. Odd looking, beloved by its fans, and a reasonably adequate (if quirky) to drive.
speed_spread 4y ago
Scala is a ring of four Corollas welded by the edges of their rooftops so that rolling over only changes the set of wheels you're using. Also, all wheels are omni directional so you can drive sideways when required.

kaba0 4y ago

I don’t know, probably some truck would be a better analog. It ain’t sexy, but it was made to be a blue collar language, and it is the one that ships cargo nigh everywhere.

perardi 4y ago
To really nitpick the analogy: Java is a Ford Transit cargo van. It’s primarily used by enterprise shops. You’d never brag you about driving a van. It’s not fashionable. It’s kinda ugly. But…it gets the job done.
- topaz0 4y ago
  Speak for yourself. I brag about driving a 2013 transit connect.
mgomez 4y ago
You're not alone as someone else made a similar observation in a previous thread[1]: > To me Java is like a garbage truck. You get to work, start it up, do a nearly invisible but absolutely essential duty, then, at the end of the day, you turn it off and go home. No one dreams about garbage trucks or puts one in a car show but they’re there and ready to go right back to work when you are. [1] https://news.ycombinator.com/item?id=26834177 https://news.ycombinator.com/item?id=26834177

throwawaymaths 4y ago

Corollas don't come with all sorts of weird (now aging) buzzword-driven preferences like nudging you towards xml, factories, etc.

falcolas 4y ago
Personal rant: I've never understood the hate towards XML. It's a practical and flexible markup language that does not depend on whitespace or quoting every bloody thing. Plus, every markup language invented since has had to re-invent XML things that, surprise surprise were actually needed. Paths, schemas, comments, etc. I get frustrated with JSON because of things I could do in XML that I can't do in JSON without breaking the spec. And that doesn't even cover how annoyingly verbose anything done in JSON is. Anyways.
- aeze 4y ago
  You consider JSON to be more verbose than XML? I'm curious to hear why.
- gen220 4y ago
  I think people dislike XML precisely because it's so flexible and unopinionated. It means that when you're parsing a new XML source, you have to look for data that might be encoded in two or three little niches. God help you if it's encoded in each of them, and if the data therein is contradictory. Basically, it's easy to "hold it wrong" in a way that harms consumers.
  - falcolas 4y ago
    > I think people dislike XML precisely because it's so flexible and unopinionated. You're probably right. > Basically, it's easy to "hold it wrong" in a way that harms consumers. I feel a bit like this could equally apply to things like GraphQL. I spend more time reading the docs on how someone's internal data model is built than I do writing GraphQL queries. And if I get that data model slightly wrong, my query's garbage. But that's probably a separate, vendor specific (coughnewrelic), rant.

jeroenhd 4y ago

My problem with Java is that C# exists which does huge portions of the stuff Java excels at just… better. Before, .NET only ran on Windows which disqualified it from many serious applications server deployments. Today, this is no longer the case for everything but cross platform GUI libraries, and even those are an option if you're okay with not having Linux support. It's more akin to the old car you had just before you bought your Corolla. It was also pretty decent, but it was starting to have issues. The JVM ecosystem is quite expansive and it's capable of running many things that would be a pain to develop in house (or pay a third party developer for). However, Java isn't the only popular JVM language anymore and you're no longer forced to use Java to interact with its surrounding ecosystem. The language and the ecosystem around it aren't going to go away for at least a decade, but I think it'll slowly move the way of COBOL and FORTRAN: perfectly good languages, with perfectly good situations they outperform their competitors in, practically exclusively used for niche use cases and legacy software systems.

pron 4y ago
> but I think it'll slowly move the way of COBOL and FORTRAN That could be true of any language that's achieved great popularity, but in 2022 Java is the language that dominates server-side development (by plurality, not majority), it is a technological leader in areas of compilation, garbage collection, and low-overhead in-production profiling, no other single language looks posed to seriously challenges Java's dominant position on the server (as PHP seemed for a while), and, at 27, it is more popular than COBOL was in its (rather short) heyday. But it is true that Java is among a select set of languages (alongside Python, JavaScript, and C) that have managed to achieve a level of success sufficient to become "a COBOL" or "a Fortran" someday.
- amanaplanacanal 4y ago
  Aren't most of those benefits from the JVM rather than Java itself?
  - pron 4y ago
    First of all, what most people call "the JVM" is really called Java. Java = libraries + VM + tools + language. Of the ~8 MLOC in the JDK, the Java language compiler and Javadoc make up around 200KLOC; the VM makes up about 1.5M. What is sometimes colloquially known as "the JVM" is really everything except the language, of which the actual JVM is pretty small. Second, while the JDK is pretty modular (e.g. you can use the runtime and tools but not the frontend compiler as "JVM languages" do), we design every feature by looking at the platform as a whole. E.g. the relatively new records feature is implemented in the language, libraries, and VM. That's why some newer Java platform languages have more baggage than the Java language, because their features are not harmonious with the direction of the libraries and VM (e.g. Kotlin's coroutines and data classes). Finally, it is true that back in the '90s, James Gosling set out Java's strategy to put most innovation in the runtime and keep the language very conservative (he called it "a wolf in sheep's clothing"), and we follow that strategy to this day, because it's turned out to be very successful. While there are lots of programmers who want more adventurous, feature-rich languages -- and many of them hang out here -- the vast majority of programmers don't. Many more people complain that the Java language is changing too quickly than changing too slowly. So it is thanks to the conservative language that the platform is so popular, which allows us to have the resources to innovate in the runtime. So while <10% of people using Java do so with another language (no single alternative language has gained more than 5% of the platform's ecosystem) -- and we're happy we can accommodate everyone -- the conservative language is a necessary component of making the runtime state-of-the-art. A combination of an innovative runtime and a conservative platform is what most people want, and that combination is the main benefit.

hedora 4y ago

I'm going to go with "Java is like a 2006 Chrysler 300". I'm basing this on this list of the most popular fleet vehicles in the US: https://www.fuelexpress.net/blog/just-for-fun/4597-2/ https://www.fuelexpress.net/blog/just-for-fun/4597-2/ The Corolla is known for reliability and fuel economy. It's the car you'd buy for your fleet so you could ignore it, and then you would ignore it, and some day, people would start assuming you are going out of business or something because all your fleet vehicles are from the late 90s. On the other hand, the 300 claims to be those things, but has terrible fuel economy, and apparently likes to unexpectedly spin out. They claim that new ESP magically fixes the problem, even though they've been claiming such things for years. It's actually supposed to be a luxury car or something, but apparently for some reason it is used as a fleet vehicle, where it is a poor fit. Also, since it is a Chrysler, I assume it is unreliable. Oh look, I'm right: https://cars.usnews.com/cars-trucks/chrysler/300/2011/reliability https://cars.usnews.com/cars-trucks/chrysler/300/2011/reliab... (In fairness, the newer ones are supposedly reliable. Sort of like how Java is supposedly pause free now.) Filling out the rest of the analogy: fuel economy => Java startup costs, and asymptotic / constant factor slow downs because it doesn't support zero cost abstraction. spinning out => The GC, of course magic ESP => The next GC solves the pause / thrashing issues (promised every year since at least 1998) reliability => Constant API churn, the 8 => 11 => 17 => 20 treadmill, and (of course) log4j. targeting luxury segment => Java targeting toasters, IoT and web browsers back in the 90s, but only being able to run on hilariously overbuilt and power hungry enterprise boxes instead. Also, the classloader's open world assumption.

kaba0 4y ago
I have very vague knowledge of cars, but I know for a fact that your characterization of Java is just bad, no matter how good you car analogy-creation may be. I won’t even correct the others, but how come Java is unreliable? Like, I have a hard time thinking of anything in the category of computer programs that would fair better.
- hedora 4y ago
  Have you ever had to maintain an old enterprisey Java thing? It's pure hell. Basic dependencies (like JUnit) break API compatibility every few years, and then they stop distributing the old version for new JVMs, so you're forced to port your code. The GC falls over in production at the least convenient times. People somehow decide everything should be stringly-typed, and that the best choice between .properties, xml and JSON is "all of the above, and also this in-house DSL". There's this common pattern called "vendoring" where you load multiple incompatible versions of the same library into the same JVM, and exploit loopholes in classloader semantics to prevent it from noticing, and ungracefully exiting (which is what it really, really should do). There's no way to use language improvements and static analysis to improve program semantics over time (like there is in, say C++) because none of the language level abstractions are sound. For example, you have a line like "static Foo foo = new Foo()". Guess what? foo can be null sometimes. Here's an unrelated problem: Think you have a function that doesn't throw exceptions? Nope. Some third party garbage can throw errors during normal operation instead. Think that eliminating down casts in your program means it won't throw ClassCastException on unexpected lines? That hasn't been true since generics were invented. Think Optional gets rid of null pointer exceptions? Nope. Instead, it's actually a tri-value null. After all, you can always create null references to an Optional (and, looping back to the beginning of the paragraph, you can't avoid creating null references to Optionals in idiomatic code!) I could go on for hours.

adrian_b 4y ago

I am not convinced that Java is adequate. I do not know if the problems are related to the Java language or to the typical Java programmers, but Java is the only programming language where I have seen a strong correlation between the programming language used to implement some application and a low quality of that application. During decades of experience with various programs, whenever I was surprised that a program seemed to be abnormally slow, or it had an unusually ugly GUI, or it had a GUI that was impossible to customize, e.g. it was impossible to change the default font or the size of the font, or it had various other annoying features seldom encountered in other programs, I discovered that it was written in Java. Most of these annoying programs where commercial programs, some of them very expensive programs. The most recent Java problem that I have encountered was last year, when I could not install some expensive program, because the installer crashed immediately. After some time wasted to discover the reason, the conclusion was that the installer was written in Java and it always crashed immediately on any computer to which a 30-bit monitor was connected. That program had both Windows and Linux versions, but both crashed in the presence of a 30-bit monitor, so the Java installer was of the kind "write once, crash anywhere". The workaround was to disable the GUI of the installer and make an installation from the command line. There are some 15 years since I use only 30-bit monitors, but this was the first time when I have seen such a behavior (probably because I avoid Java programs, due to past experiences). Googling has shown that this was actually a well known bug in Java installers, which had not been solved in a long time.

valbaca 4y ago
I'm with you, even as a Java developer I can immediately recognize when something was written in Java: it's ugly and slow. When it crashes, you know they missed a NPE or tried to use multiple threads.
- gorjusborg 4y ago
  > I'm with you, even as a Java developer I can immediately recognize when something was written in Java Sure, if we are talking about desktop applications and we ignore the exceptions (Intellij / Minecraft).

valbaca 4y ago

Hit too close with the analogy: Been a Java dev for ten years and I drive a Toyota Corolla.... ...but also in my spare time I play around with Clojure and dream of buying a '69 SS Camaro

nly 4y ago
Admit it, you never will.
- TheRealDunkirk 4y ago
  Well, maybe, like me, by the time you can afford it, your knees and back don't align with getting in and out of one.
falcolas 4y ago
I appear to be you, just with a Subaru BRZ. It's a manual, it's fun as hell.

skybrian 4y ago

I wouldn’t use Java again because I am done dealing with the brokenness of Maven and Gradle. They are the opposite of “little fuss and muss.” The Go build tools fit your analogy better.

SureshG 4y ago
> The Go build tools fit your analogy better. Go uses two build tools for any non-trivial projects. One write in go.mod and another in Make :D (see this - https://github.com/kubernetes/kubernetes/tree/master/build/root https://github.com/kubernetes/kubernetes/tree/master/build/r...)
- skybrian 4y ago
  I think Hugo might be a better example, as a medium-sized non-trivial project: https://github.com/gohugoio/hugo https://github.com/gohugoio/hugo There is a Docker file and some shell scripts, but you build the executable using "go install".
chii 4y ago
> dealing with the brokenness of Maven people shit on maven, but i say it's much better than many other built tooling - npm, make, or custom scripts. The only thing need getting used to is that you cannot and should not stray from the maven model - fit your project's built into the maven model, rather than try to twist maven to do your bidding.
- skybrian 4y ago
  Maybe I haven't built anything large enough to feel the pain, but I find npm acceptable. Go's module system seems more secure, but I had little fuss using npm to build a simple web app.
peterashford 4y ago
You dont have to use those tools, you know

drewcoo 4y ago

> It's like a Toyota Corolla This is only an invitation to car-shedding!

falcolas 4y ago
So it was. So it was indeed.

baldfat 4y ago

I personally use Racket (Lispish) just because it is so much fun to build whatever I want and customize it. It just feels good to have my small projects just fit me perfectly.

cutler 4y ago
What's the relevance with respect to Java, though, which is designed for managing projects in large teams?