I work on mainframes and dislike Java. Conservatism is not a problem, my problem is I perceive lot of Java people being pretty smug, and they are just because Java is #1. (And I also worked in C#, so I know the difference. Java itself is not the thing that makes people smug about it, it's the position on the popularity ladder.)

I mean, if your approach is, we use this old and tested language, it has many warts, but works for us.. good.

If you go, well, we use this language, because it's #1, and therefore it's clearly the best in the world.. no, thanks. I know Forth and Lisp and Haskell, and I know the world out there, which you don't, so I know for a fact there are innovations that didn't make it to Java yet, or pretty badly.

To me, humility in programming is (partly) don't think your tool is the best just because it's the most popular one at the moment.

Finally, this perception of Java is changing (it is being slowly dethroned by Python and JS and other contenders), and with that will come more pragmatism (less of crazy OOP and patterns cargo cults), which will actually make it more likable in the future.

The more esoteric a language is, I find the more _passion_ the average developer has for that language, it's libraries, and tooling.

Now I'm not saying the passionate Java and/or C# devs don't exist - they certainly do, C# is my bread-and-butter and I like to think I still have a flicker of passion for my work - only that there is a vast ocean of driftwood developers making it more difficult to find the sharks.

Haskell (my perception of), for example, has demonstrated some of the strongest devoted (to themselves _and_ Haskell) developers I'm yet to meet. That market is just nothing but developers who love their toolset and just want to write and learn amazing code.

The risk with this type of developer is they often prioritize their toolset and amazing code over the actual businesses needs. I’ve seen it lead to the wrong tool being used for the job.

A couple years later when these devs move on the business has a harder time maintaining the code they leave behind.

There are always drifters to be hired, which has some value.

But I'll take hiring (and the implied difficulty in finding) a dozen of those kind of Devs over drifters all the same.

If they weren't passionate, why use an esoteric language? If you want an easy time, something mainstream will be easier. It isn't like anything is actually impossible to implement in C; there are just trade offs in number of bugs and time to implement. Both of which are minor impediments vs algorithm and program architecture. Anything newer than C is just bonus modern features.

Because it is kitsch. Ruby suffered this fate in the mid 00s IMHO. It gained a lot of traction because of Rails and suddenly the recruitment space is flooded with hacks and bootcampers.

All programming languages are garbage to me now. Even my favorite languages. Most systems, networks, databases, are garbage to me. Frameworks, architectures, patterns, paradigms, protocols, standards, conventions..... all garbage.

I now see the whole system as like a municipal waste treatment plant. If we work really hard, the highest thing we can aspire to is to prevent waves of unprocessed shit from exploding out a release valve into a nearby stream. Our work should be unglamorous and practical, because ultimately someone's going to have to drink our water, and making sure it doesn't have shit in it should be our highest priority.

I totally agree.

I also agree that the disputes about language choices is tribalisitic. There's nothing wrong in principle with Java. But Java nuts do love creating factory-factory-factories. Layer upon layer of abstractions really doesn't confer simplicity.

Most recently, I've been a PHP developer. It's objectively an awful language, that has grown by accretion, and was never designed. But it's quick to write, reasonably easy to read, and there's pretty good documentation online, and a million tons of chunks of example code.

So my choice of language is essentially tribal; the details of the language aren't really important, as long as it's not getting in the way. It's the kinds of people that use the language that matters to me.

Java's reputation as a corporate language is well-deserved; and (with exceptions) the type of people that use it seem to be corporate drones, that don't mind spending a week writing a factory-factory-factory that nobody needs.

Java as a language does have problems, but if you use it right, it can be pretty nice to work with. The verbosity issue is kind of a double edged sword, on the one hand there's lots of typing, on the other hand, I find it (the verbosity) can help make code very readable and easy to understand, at least if well written.

The common factor is developers lacking humility and comforting themselves with Tribal Tool-ism.

The tools are not the issue - the attitude around them is.

It's more of an anthropological and political problem than a technological issue.

Of course there is no one ultimate definitive best language, and there may not even be a definitive ultimate best language for specific kinds of problems.

But the anthropology around Tool-ism is fascinating, and under-researched.

And it's very relevant to the real-world effectiveness of CS, because irrational professional beliefs in both tooling and management can have very harmful and expensive real-world consequences.

HN feels like white collar GPT-3. It predictably likes things that are more abstract, less practical, and promise novelty while replacing the incumbent. It also used to be a very self-serving chamber for startup investors. Honestly I come for the randomness but as community it's really the point of view of vocal people only.

While I'm critical, I'm guilty of this. Well said.

I'm very much into encouraging folks to connect at a "human" level, and not treat each other as abstractions.

I also like practicality and experience. I've found that I feel as if I'm contributing, by telling stories. I'm of "a certain age," so I have a lot of them; including embarrassing ones.

    "Good judgment comes from experience. Experience comes from bad judgment."
    --Attributed to Nasrudin, but I read it from Will Rogers

I have become a bit despairing of what has happened to the culture of the tech industry. I feel as if what used to be a fun, exploratory place has become a voracious, hyper-competitive gladiatorial arena; complete with lords on the sidelines, giving thumbs up and thumbs down.

I know that it seems as if I may be looking back with rose-colored glasses, to those that have always known the industry as it is now, but I assure you. It was once quite different. We had fun, and we shared information, and we were pretty damn nerdy.

When I was reading the various accolades about Dan Kaminsky, it actually choked me up. He was the type of person that seemed to be everywhere. The people who were really good at stuff didn't use it as a hammer to pound others; they shared their passion and exuberance.

I try, in a rather awkward way, to do that, myself. I'm quite capable of being a super-negative "black hole," but I won't do that. I wouldn't want to live in a world like that, so I won't contribute it.

Being negative is an easy way to get lots of clicks and shares, but it fouls everything it touches.

Don't you say? Isn't everybody out there writing rust on neovim?

Exactly. But what I found is that refactoring java-monoliths can be a very interesting and intellectually stimulating task.

Apart from the juvenility of social memia, there is the fact that programming languages are themselves buggy, opinionated expressions of how to solve a problem. Given enough followers, some languages become very like a temple that sees no ill within its own walls.

A programmer must be able to reason clearly about the code, or something (or some opinion) has become dogma.

There are many good programming languages. Leaving tribe and tribalism brings maturity.

JVM and CLR runtimes have an enormous amount of production experience baked into them. BEAM also would be fine.

It's a toolbox with tools that are better suited for some jobs than others, and it also depends which ones a group of developers know.

Yet HN commenters tend to like the React ecosystem, which at this point is pretty close to Web Development Enterprise Edition.

It's one of the few languages out there capable of producing a codebase that lasts for so long. That annoying verbosity and enforcement of naming conventions and directory structure mean that the Next Guy (or Gal) to come into the project and probably figure out what's going on. Most codebases written in other languages are constantly rewritten in the language de jure.

"by law" -> "of the day", "current"

Exactly. Languages come and go. But if you understand the fundamentals - why things work the way they do - it makes it much easier to move between languages, programming models and whatever the latest fad is. Being adaptable is a far more valuable skill over time. Nope, it's not easy - but rarely are things of value easy (it's why they are valuable - ha!). It is easier to start out early with this perspective and continually building on it throughout your carrier than trying to pick it up mid stream later on in life, so the sooner you start the better! I've never considered myself "done" when it comes to reading or learning. Like those sharks that die if they stop swimming - that's a good way to envision your long term intellectual health :)

Creativity and cleverness is a double-edged sword, which is exactly what Dijkstra is talking about.

Distaste for Java isn't elitism or arrogance, it's just that the language is so damn painful to write.

If you start your career with Java (as I did), dipping your toe into another[0] language for the first time feels like Neo being ejected from the matrix and waking up to reality.

You realize your eyes are finally open, you're awake, and you can see that all that pain was just what Java saddles you with, and wasn't "the way programming is done (TM)".

[0] depends on which language, of course. Java to C# isn't a big jump.

I started working in C++, moved to Java, used several other languages commercially (Python, JS, PHP, Groovy, Kotlin), and about dozen other languages for personal projects including the hip ones like Clojure, Prolog, Ruby.

My first programming languages were C64 BASIC and Turbo Pascal. I've written some Ada and SML.

And I just don't understand the Java hate.

Pain points:

* Stack traces seem to run to 500+ lines and nobody reads them.

* The processes, release management, and integration of code in a Java environment is glacial slow and obtuse featuring very low automation and many large teams of dev ops. The very idea continuous deployment is absent. Code releases occur at regular intervals quarterly or monthly if you are super fast and it feels like moving a continent. All of that slowness and super man power also applies to everything else not written in Java like riding on the back of a retardant elephant.

* Java applications running enterprise web servers are monolith beasts like the Great Wall of China wrapping the Pacific. Refactoring in those applications feels like inventing a new language while sinking in quicksand. Writing a JavaScript application in a massive MVC framework feels like that too but Java is orders of magnitude worse.

* What I really don’t understand is that Java is such a fast language but large enterprise web server applications written in Java always feel so slow in user experience in production. It just feels like something from the late 90s. That slow becomes the baseline experience to internal development by which all user experience ultimately suffers. There is no reason pages from these servers should take 5-20 seconds to fully load in the browser even though the page is a light smattering of static text with sprinkles of CSS and JS. I have an application in TypeScript that emulates the front half of an operating system and it fully loads in the browser in 0.3-0.8 seconds (averaging around 0.65 seconds).

My personal suspicion is that the programming style used in Java (OOP and patterns) together with the fact that everything is a reference, and everything is implemented in Java itself way down, kills the cache locality, which is the thing that makes modern computers fast.

Yes, you can write fast Java programs, if you keep abstractions to a minimum, use arrays rather than objects when allocating, and take advantage of the JIT compiler. But these are more lab conditions (which are great for benchmarks) rather than the real world conditions. I think finally having a proper record type in Java will help to fix this.

Other programming languages make it "more inconvenient" to apply such managament/programming practices.

ok, you have a point here :) when you have libraries for filtering stacktraces you know something is wrong

> the processes, release management, and integration of code in a Java environment is glacial slow and obtuse featuring very low automation and many large teams of dev ops. The very idea continuous deployment is absent

that is the exact opposite of my experience - maven infrastructure beats anything C++ or Python have, and in every Java project I worked on we had CI (mostly BitBucket+Jenkins but I've also seen Apache Continuum and Team City and we had CI even back in svn/cvs era).

> large enterprise web server applications written in Java always feel so slow in user experience in production

Also not my experience, I've worked on an intranet app for warehouses that used jboss 4, jbpm 3 and plsql at the backend and a very small custom c# client running on remote Windows CE terminals. We had transactional and persistent business processes drawn as graphs invoking PL/SQL on the server, it was pretty nice. And the full roundtrip between pressing a key on a remote terminal and rendering the received response was under 150 ms. That's for all the layers: - c# client -> intranet -> SOAP on jboss -> EJB3 -> jbpm -> hibernate -> JDBC -> PL/SQL and back

And it was around 2008 - in the age of spinning disks :) Certainly it was good enough for us and actually faster than previous simple code that we were replacing (remotes telnetted to a C++ text-only server that connected to the same business logic in PL/SQL). ORM cache wins covered all the performance loses caused by additional abstraction layers.

We didn't use html/js/front-end templating engines tho, at the time most people used JSF or similar and it sucked. We had a custom XML protocol that was rendered by the C# client and it was very fast.

Of course it wasn't that demanding - under 500 users all on the same local network. But without any thought spent on optimization (other than enabling 2nd level cache in hibernate) it was a pretty good result.

> There is no reason pages from these servers should take 5-20 seconds to fully load in the browser even though the page is a light smattering of static text with sprinkles of CSS and JS.

well yeah, something's wrong. I bet on data layer or passing each request through 20 microservices on different continents (this is the most recent fashion in server-side programming and it sucks).

Mind you, I'm only saying that after having spent 2 years in Kotlin. The Stockholm syndrom is real: you don't realize how much better things can be from the inside. Programming has become enjoyable again, my work 'feels' cleaner, more readable. Null safety makes reasoning about code that much easier. I can switch to functional programming when it's convenient. I keep all the tooling from Java, including the amazing IntelliJ IDE.

At the end of the day, choices are a matter of arbitration. Do I want the speed of C, the ecosystem and resource pool of Java, the locality / mathematical guarantees of functional languages, and the IntelliJ IDE? Sure. But they don't exist in one language.

So when I'm programming embedded, it's C. When I'm creating a complex data treatment pipeline for machine learning, it's Scala. And when I'm making a CRUD application that will have to support a team of 15 developers hacking on it for a decade, I'll go with Kotlin.

I don't take issue with your comment overall, but this is not true. You can catch exceptions within lambdas, and you can define functional interfaces that declare that they throw checked exceptions.

My issue is that for something as everyday as "throwing exceptions", you have to define a separate interface, or catch it inside the lambda. The first option being the Evil Verbosity everyone is on about, the second essentially rendering the exception useless as an instrument.

[1] : https://stackoverflow.com/questions/18198176/java-8-lambda-f...

Inversion of control, interfaces, and OO make wandering a codebase feel like being lost in a bureaucracy.

Then we het to the issue of projects being coupled to IDEs. "Oh, this is an Eclipse project." "Oh, this is IntelliJ".

All of that chrome and tailfin leads to projects that take longer to boot than the OS.

The disdain for Java may be less about the language per se than the attendant mindset.

We use Maven projects, and edit them in whatever people prefer to use.

This would not be such a complaint (look at the explosion of build systems everywhere) if Java were less touted as "write once, run anywhere".

Build systems and configuration management are two hard problems.

And ant is prehistory.

In C++ they don't even have Maven equivalent (only thousands build systems but no universal way of naming/deploying/running projects or specifying dependencies).

In Python there's several maven-like systems that are incompatible and don't have the concept of universal project identifier or repositories.

In JS and Rust they basically copied the Maven system and changed it a little.

Clojure uses Maven wrappers with lispy syntax for pom files.

I struggle to find a language where this is solved better than in Java.

With that in mind, though, the biggest gripe I have, by far, is its needless verbosity. It always feels like I need a huge amount of boilerplate and repeated keystrokes to get things done. My fingers literally get more sore writing Java than anything other language.

Lack of extension methods is probably my next complaint, because you end up fumbling about writing a lot of code to address what should be

Lack of null-safety would be the next one, too. I'd say around 90% of my runtime errors are due to improper null handling, so this would cut down a huge source of errors.

On par would be painful deployment (and to a degree, package management). For some reason Java always felt like it needed an industrial-size team to get anything actually up and running, and needed more hardware than any other language. That might not be fair, but I think it's definitely fair to say that deployment is not Java's strong point.

This is my biggest complaint about OOP development in general and languages like Java and C# that are heavily invested in OOP paradigms are miserable for me as a result.

It doesn't, in fact; but configuring a Java application to run well with minimal resources is a problem that isn't a programming problem, it requires a separate skillset. So you end up with build specialists, and deployment specialists, which in turn results in long deployment timetables.

And then you have to deploy certificates against all that.

I'm not bitter.

Or until you realize that you have a 99th percentile latency of multiple seconds...

I guess enabling your users to do that might be work for a sysadmin, but that's more a reflection of those users having higher expectations for Java than for other runtimes - providing your users with the same capability in other stacks is never easier than Java, and often significantly harder.

The first one is annoying, not really something a professional software developer would care about for more than 10 minutes while creating a new product.

Macros can be major footguns, they're something that can only be realistically used efficiently and safely in large code bases by actual senior engineers. So the jury's still out how much they really increase productivity for the averaged developer.

Higher kinded types seem great, but it seems that they're not easy to implement and they also slow compilation down a bunch (someone please correct me on this). These seems hard to bolt on to an existing language, so Java can't be faulted much.

There's a place for "artistic licence languages" like Ruby or Clojure and I like them for experimenting, but when you want to build a house you want the bricks to be boring.

I find that the language itself is quite good, simple to use and has some nice features and performance... but the issues you mention are also there, however they're part of the frameworks and individual codebases.

Did the Java community get over their love of code generation already? Last time I used it, I'd debug the crazy 1000's of computer generated lines that people changed here and there.

Anyway, that is great news. That unexplainable love for code generation was one of the things holding the language back. It's always good to see things improve.

Just as Go.

You say that like it's a bad thing...

I think it has nothing to do with being "enterprise".

I mean, plenty of arguments used in those wars are perfectly reasonable. PHP isn't elegant. Java is verbose. C++ is overcomplicated beyond salvation. JavaScript is shit. Those are all facts ;) However, they still can and often are the best choices for a given project. Is PHP pleasant to write in and think about? Heck no, but deploying it is exceptionally easy and sometimes that's much more important. I wouldn't ever think of using JavaScript as an example of good language design, but it accidentally turned out to be flexible enough to become the lingua franca of the Web and is here to stay. No amount of drooling over Rust will change the fact that you're going to have a hard time with it on some platforms where having a proper C++ toolchain available is ubiquitous. And sometimes the way Java code use to be structured is exactly the perfect fit for a project you're working on to ensure its long-term maintainability despite of the fact that people who work on it come and go in your startup all the time (so having access to a healthy pool of Java developers to hire from who's pretty much already familiar with your project despite of never seeing it before is a huge advantage).

If those tools really were "suboptimal" they wouldn't exist anymore. They do, because they aren't - if anything, they may be poorly chosen to do a specific job.

I agree with everything you said.

> If those tools really were "suboptimal" they wouldn't exist anymore

A tool (such as a language) can certainly be suboptimal on its own but still be productive because of the package of the language, the ecosystem, the knowledge that people have etc.

My point is, even if Java would offer the best package, it is still valid to criticise the shortcomings of the language and dislike this part of the package. It doesn't have to be "hate because of enterprise".

> Java is disliked on HN because it represent "enterprise"

which I think is not true. Maybe for some people, but there is valid criticism too.

I am happy to give examples, but I am disappointed that you call my response "tribalism". It really is not meant like that.

Sure, it's not as fast to add stuff as C#, and also surely anyone looking for a fight can nitpick, but it has most modern features you'd expect a modern language to have.

Also the JVM is highly optimized, more stable and faster than most other runtimes (and it can run must of the other languages).

This probably describes 99% of all programming done today, no matter the language.

Not everyone is a polyglot programmer able to choose their tech stack at their company.