Hacker News Reader

Comment by Flex247A | Hacker News Reader

I started attending college a year ago. At that time, I didn't know much about programming: just a bit of C and some Python - enough to make first year college projects. After I started frequenting HN, I came across a lot of comments by developers on programming languages, toolchains, libraries, etc. Even though I didn't understand their arguments, I still believed what they said, because I thought they were experienced, so they must be right. Even though I hadn't used the tools personally, I started developing premature opinions on them: Java is verbose, so it must be avoided, PHP is inelegant etc. These opinions also gave a feeling of security: because I thought that I had chosen the right language for programming (Rust!), the right operating system, the right text editor (vim), and the right window manager (i3). This made me arrogant, because I saw myself as above my classmates, who were still using 'inferior' tools and still struggling to grasp the concept of command line arguments. Over time, I realised that I was just basing my beliefs on HN comments, and it is not healthy in the long run. This article helped me a lot towards realising that. Thank you for posting this article :)

Edit: grammar

View on HN

Lots of programming wars is just tribalism. Java is disliked on HN because it represent "enterprise" - big long-lived organizations which maintain a codebase for decades and therefore conservative. A different tribe than the startup tribe HN represent. Java is not in particular more verbose than say C or Rust for solving the same task, it is just a random slight on the language of a different tribe.

HN is a great community, but it has a very narrow perspective on the world.

As a beginner it is fine to chose to master one language first, but in the long run you should not "choose a language", but rater learn to learn any language, and understand they all have their strength and weaknesses.

But there are so many choices of tools and technology in this industry and it is impossible to learn it all. Tribalism makes the world simpler because it narrows your perspective.

Java is miserable to write. You don’t realize this until you work with other languages. It was literally built with guardrails to keep enterprise coders from getting too creative

I can’t speak to the actual act of Java development, but I can speak to Java applications from a sysadmin perspective (15 yr Sr. QA Engineer to a 3 yr Linux admin (don’t ask)) — I’ve got no real beef with Java from the development side, but maintaining some of those stacks in production is pure pain.

Huh? Java is probably the least demanding stack from the sysadmin side - no big chains of library dependencies, no docker, strong backwards compatibility that means you can fearlessly upgrade the language. All you have to do is keep an up-to-date JVM installed on your servers and deploy single-file fat JARs to them.

Until you get an out of memory error. Then you need to start fiddling with the JVM.

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

No language is immune to slow or memory-hungry code. The JVM is probably the easiest runtime to monitor/instrument/profile (and it's not like having no runtime makes that any easier, quite the opposite), and has probably the most tuneable GC going.

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.

There are only a bunch of out of memory errors, though. And they're easy to fix.

Then you get into managing a collection of Java projects where each on ships its own JVM and keystore to obviate version issues.

And then you have to deploy certificates against all that.

I'm not bitter.

The keystore situation is indeed poor. For several years now, it has been possible to do more key management in-app, so you don't need to manage keystores (i have written programs which pull standard PEM-encoded keys from environment variables). But the practice of using a JKS keystore is so ingrained that it's very rare to make use of that.

I think those guardrails often help with the humility the article discusses - they reduce cognitive load, and let you focus on the problem at hand, at the expense of expressing total creativity. It's a tacit admission that we aren't all knowing, and often need help from our tools to save us from ourselves.

I find it's just the opposite - when working in a Java codebase you can't focus on the actual problem because you have to spend so much of your time reading past the needless verbosity - or, often, debugging the crazy reflection framework that your organization has introduced because that verbosity became intolerable.

I think you're both correct.

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.

> crazy reflection framework

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.

That's never been my experience in over 10 years of JVM work - people mainly use reflection or bytecode manipulation (aspectj) to do the kind of things you'd use code generation for. The only exception is thrift/protobuf and that's dumb serialization code that hopefully no-one's editing.

Oh, the last time I've made any extensive use of Java was more than 10 years ago. I've met an off the shelf code generation based platform on the meantime, but luckily it was deemed too expensive so I didn't need to even finish a technical evaluation (much less use the monstrosity).

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.

> It was literally built with guardrails to keep enterprise coders from getting too creative

Just as Go.

Go somehow takes the worst bits of Java in this regard and makes them even worse :(

Yes lets rewrite everything Ruby on Rails and CoffeScript, it is just so much more productive and creative! At least this was the opinion on HN a few years ago. Now of course other tools and languages are fashionable. And nothing against Ruby or CoffeScript per se, but the demands of an enterprise where software lives for decades is just different than for a startup which rewrite the whole stack every six months.

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

Compare writing Java professionally with writing Kotlin professionally. It's like night and day. Same projects, same VM, all that's different is the language.

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.

Could you write your top 3 Java pain points?

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.

Haven't upgraded Java since version 9, so take this with a cube of salt (my suspicion is that many hardcore Java haters were created by Java 5, 6 etc).. but my general issue is the readability. The idioms used to perform 'standard' things are verbose. The worst for me is that it's impossible to catch exceptions in lambdas. The absence of named or optional parameters.

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.

All the problems here are solved till Java 15 in every iteration. A lot of opinion in Java is based on comparing old versions of Java with latest version of other languages

Java, in my experience of having to puzzle out a couple of large codebases in my career (that is, not having been a serious developer) is what happens when a couple of idioms run amok.

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.

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

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

Yeah that's a weird complaint. Java build system situation is better than most other languages. Especially C++ is in stone age comparatively.

Maybe it was more historically true. Then there was the Ant vs. Maven vs. Gradle thing.

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.

Maven and gradle projects can depend on each other, are producing the same kind of artifacts and deploying them to the same repositories. And both can be used in any IDE you like.

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.

>The worst for me is that it's impossible to catch exceptions in lambdas.

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.

You're right. It's been a while and I forgot the exact issue. I looked it up on StackOverflow, to refresh my memory [1]. It is indeed possible to thow exceptions within a lambda.

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...

I have worked in Java shops my entire career (Travelocity, Orbitz, Expedia, Southwest, Bank of America) and have lots of pain points. In these cases Java is used to prop up a web server and typically with Spring.

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).

> 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.

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.

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

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).

Shitty, poorly-run corporate behemoths (a) are shitty and poorly-run and (b) use Java, because it's an industry standard. You are making the error of thinking that the latter consequence causes the former.

> Shitty, poorly-run corporate behemoths (a) are shitty and poorly-run and (b) use Java, because it's an industry standard. You are making the error of thinking that the latter consequence causes the former.

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

Interestingly, the old COBOL/CICS/DB2 stacks do not seem to have this problem (and they are run pretty much only by corporate behemoths). Why is that?

less hardware to throw around = better (simpler) codebase

Bear in mind that I've written almost no Java since 8, so this may well be out-of-date.

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.

"more hardware than any other language"

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.

> 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.

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.

Problem is not with programming languages. It is with lack of programming principles. For eg. Consistency, Readability, Maintainability. Software requirements keep changing with time & so if we do not do continuous refactoring, we see a decay. Also in enterprises team ownership keeps changing & we miss the accountability. This erodes software. People need to give a damn to maintain software.

I know this is just flamebait, but I write a lot of Rust, Python, Java, C++, Ruby, Typescript, etc. Java is fantastic to write in. What guardrails are you talking about?

My guess? Lack of first class functions and macros. Maybe higher kinded types.

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.

Java itself may lack macros, but by the time you get in reflection and libraries with XML and compile-time magic to work around the lack of macros and the whole thing is a giant plate of spaghetti, maybe macros were no' so bad after all.

Those would've been my guesses too, but Java's had first class functions in the form of anonymous classes since 1.1, and as the other commenter mentioned reflection takes care of a lot of macro use cases.

That's like a mason or an engineer complaining that the bricks are too boring and predictable :)

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.

> It was literally built with guardrails to keep enterprise coders from getting too creative

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

A programming language is one of the more important tools as a software developer. Having to use a suboptimal tool is neither productive nor fun. You can't always have the latest tool of course, but Java is quite outdated in many regards (even though starting to catch up a bit recently).

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

General statements like "...Java is quite outdated in many regards..." without providing any specifics are a sign of mentioned tribalism. Such general statements don't bring quality to the discussion, because nobody can really check whether Java is really so outdated or not.

I replied specifically to

> 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.

If I personally dislike XYZ I could write "XYZ is quite [outdated/boring/miserable/painful/awful/uncreative] in many regards". But people here are more interested in (specific) advantages and disadvantages than my personal taste...

As a person who has learned and used several programming languages (not exceptionally many, but enough to be able to start new projects with "hmm, so which language I already know will be the best for this"), I have never taken these language wars seriously. It's actually kinda surprising to me that some people apparently do. Do they take vim vs. Emacs holy wars the same way?

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 think "language wars" is exaggerated a bit. Yeah, maybe some people see it as a "war", but for me it's just about tooling. When I say "gas-powered cars are outdated in many regards" then I just mean that they e.g. don't accelerate as fast and are noisier. Some people make a war out of that though, that's true.

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".

I'm not personally a Java fan, but "java is quite outdated" is a quite outdated statement itself.

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.

I acknowledge that it improved recently and I'm not saying it is a bad language. But it is missing a lot of features and convenience that the majority of newer language add. Java prefers to put a lot of emphasis on compatibility, which also has its merits. But the language itself (not ecosystem/tooling) is outdated in many areas. I stand by that.

Most important tool is the programmer. Suboptimal programmers are worse than suboptimal tools, because suboptimal programmers create suboptimal tools.

I’m sorry but Java is an awful language that is mostly used because you are forced to, or because that’s the only language you know. There are much better modern alternatives.

What an extremely typically HN comment.

It might be what us typical for now, but hopefully if we recognize it as a bad comment it won’t be in the future…

Much like "1 + 1 = 2"

You can read this to see how modern java differs from the java 15 years ago: https://wittchen.io/posts/an-opinionated-guide-to-modern-jav...

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

Parallel Universe blog is 404'd :(

> mostly used because you are forced to, or because that’s the only language you know

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.

Try reading the blog again.

> Java is disliked on HN because it represent "enterprise" - big long-lived organizations which maintain a codebase for decades and therefore conservative.

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

> Java is disliked on HN because it represent "enterprise" - big long-lived organizations which maintain a codebases for decades and therefore conservative

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.

I actually see Java looking at itself and realizing where it need to catch up to other languages these days. As someone who grew up with Java 5/6/7, the current pace seems breakneck with much-welcomed improvements.

Agreed! Most of my professional experience is in Java, and the biggest issue I've experienced in the java community is precisely this lack of humility. Usually that comes in the form of people believing that Spring is the best framework for java backend development, regardless of your needs, because it's the biggest, most popular framework. Arguments do not work on these people, at all, they start countering technical arguments with "I work at BigTech Inc. and we use Spring, so clearly you don't know what you're talking about"

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 original argument that developers who look down on Java lack humility is not disproved by the counter-argument that Java developers also lack humility.

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.

Weirdly my perception of Java (and C#) is actually a bit of what you describe, but often a lot more one of drifters who know/care just enough to get a salary and continue to drag their bad legacy habits and patterns with them from role to role.

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 more esoteric a language is, I find the more _passion_ the average developer has for that language, it's libraries, and tooling.

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.

> If they weren't passionate, why use an esoteric language?

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.

> 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.

Yes it is very much a double edged sword. The other risk associated with highly passionate Devs is that one day the work your business values no longer accommodates what tooling they want to work with, or they themselves change tack sporadically after discovering something new. I've had amazing JavaScript developers quit on me because they got bored of using react and wanted to pursue a role in Vue, for example.

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

Many IT workers are smug. Programmers, network admins, DBAs, sysadmins, architects. They all think they know something that other people don't (which is sometimes true!) and then transmute that feeling into a sense of superiority, which funnily enough ends up limiting them.

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.

"waves of unprocessed shit"

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.

It does, at least, mean that (most of) our work is honorable and honest: keep shit out of the drinking water, keep the lights on, provide data products to businesses or people in or people for them to make informed decisions about the (business) world around them.

It's not just HN, and it's not just Java. Actually it's not just software development, it's almost everything - movies, music, sports. A is better than B because. C sucks. In certain contexts this is ok, the fun is in the pointless argument, but engineering should be more serious than that. Alan Kay referred to the whole field as a pop culture, and I can see his point.

> HN is a great community

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.

I see that attitude as a symptom of professional boredom. Some people like shipping products, some people like solving problems. Sometimes people who like problems build complex products to solve imaginary problems.

> Sometimes people who like problems build complex products to solve imaginary problems.

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

I agree about the vocal people being the ones that influence the conversation. I hope there can be some way to fix this problem. I’ve been reading Hacker News avidly since close to when it started, and I comment occasionally when I feel like I have something unusual to offer. But mostly I don’t influence the site even though I’ve spent multiple thousands of hours here, and I wish that could be better somehow.

I try to offer the types of things that I'd like to see. Basic modeling.

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

It's not "making it all about me," but it is about not projecting onto others, and trying to bring my own life experience into things.

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.

> HN is a great community, but it has a very narrow perspective on the world.

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

Tribalism is social nonsense. I taught myself C in 92 and Java 1.0 in 96. That Java was extremely verbose compared to C for chaining calls or just normal method calls. Rust is also verbose for constructing types and performing type manipulations. C is verbose for getting things done because of its low-level nature. As productivity and safety goes, I'd choose Rust over Java or C as a systems language for most purposes. The JVM is a secure foundation for running applications in multiple languages. Clojure, Kotlin, JRuby make excellent replacements for the Java language while still on the JVM.

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.

> tribalism

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.

> Java is disliked on HN because it represent "enterprise" - big long-lived organizations which maintain a codebase for decades

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.

de jure -> du jour

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

>Java is disliked on HN because it represent "enterprise" - big long-lived organizations which maintain a codebase for decades and therefore conservative.

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

>As a beginner it is fine to chose to master one language first, but in the long run you should not "choose a language", but rater learn to learn any language, and understand they all have their strength and weaknesses.

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 :)

The flip side of having "premature opinions" is that, at the very least, you gained a lot of data points early on :).

It's kind of like with assembling a tricky 1000-piece jigsaw puzzle. You assemble the frame first (like everyone always does), and wonder how to fill it in. You could pick the most obvious feature on the reference picture, start there and focus on expanding it piece by piece until the picture is done. But what I imagine most people do is first speculatively placing all the pieces that seem trivial to match to corresponding picture features, in order to reduce the number of unplaced pieces quickly, and give themselves lots of starting points to expand their solution in parallel. This approach is useful despite it commonly turning out later that some of such early starting points are placed completely wrong - puzzle blobs get easier to position correctly once they grow in size.

It's a long way of saying, if you keep track of confidence levels of your beliefs, instead of taking everything you read on the Internet as certain, even off-hand remarks on HN can be useful in navigating the enormous space of technologies and philosophies that form the software industry.

To be fair though, there are better and worse tools. There are legitimate reasons to say that PHP should be avoided and that Rust is a good choice. It's just important to understand how much weight these opinions have and understand why they apply.

If you are building a bulk file rename tool, it doesn't matter how you do it as long as it works. If you are handling untrusted data from remote sources, then you may want to consider if C is a good idea.

I agree with your points completely. Some tools are just better designed. I was talking about the premature opinions I had on these tools before I had even used them, or seen them in action. This is a problem as it limits my teamworking capabilities. For example, I decided to do the first year programming project all by myself as I thought nobody else could do it.

Edit: added an example

I have a somewhat funny anecdote on this. One of our sister cities had a tool for handling city-water or something along those lines, that was build in ASP Web-forms.

All the city engineers were perfectly happy with it, but the developers behind it were worried that ASP web forms were becoming obsolete. Not really an illegitimate concern I supposed, but what they did was hire a company to rebuild it in AngularJS.

So now they have a technology nobody else uses around here, while web forms simply turtles on because of how much legacy it has in various places that aren’t upgrading it.

> the right operating system, the right text editor (vim), and the right window manager (i3).

As a TA I see a lot of people who also made these same decisions, maybe just add Arch Linux and zsh to complete the cliche. So you don't have tl worry, as this is actually relativly commom.

But I don't think it is wrong to have intuitions based on stories, as long as these don't prevent you from trying out said tools or languaged yourself. They can be right, but they might also be outdated. Just stay curious.

Curiosity is what caused me to frequent HN :)

I find this interesting because I've always been suspicious of anything hailed as the next big thing and obvious right choice. I've deliberately tried a lot of alternatives.

And yet, after many years, as I've finally stabilized on a set of tools and workflows I feel really works for me, it happens to include Vim and Zsh. Of all the programming languages I've used the one I've enjoyed the most is indeed Rust. I have even come to really enjoy Unity after ending up at a company which uses it.

One thing is if you tried out different things and decide to use whatever tools you like, the other thing is seeing people use, eg. vim and just copying it without understanding why. The reason this perplexes me is that so many people end up with a working but ineffective workflow, for no real reason.

I know precisely what you mean. I've seen a few posts from people about how they finally transitioned away from Vim (or C++, or ...) after many months and then detail a long list of its flaws, all of which showcasing that they did not try to actually learn Vim, but rather try to work around it being Vim.

It's a bit different from other tools and if it's not your cup of tea that's perfectly understandable. But why would you torture yourself like that if you're not willing to give it a fair chance?

Edit: there are of course also those who do give it a shot, do learn the Vim way™, and then conclude it's not for them. That's great, I have no problem with that.

That's a very good way to put it, I might steal it at some point...

I wouldn't say the primary takeaway from this post is to remind programmers to be humble. It's a takeaway, yes. But humility comes and goes, and reminders often take the form of bugs in your code that you didn't expect.

I would argue the post is primarily about complexity, and in school you probably haven't seen how complex software can get because most projects have to be started and finished within two to three months. Once you start working, you'll quickly discover that the complexity of existing systems can be overwhelming, but this is normal.

After 3-6 months working on a complex codebase, ideally with a team to help you, you'll have some idea of how the complex system works, and even if that idea is wrong (in many, many places), it will help guide future changes to the system.

The point then, of reminding programmers to have humility, is less about hearsay on the internet and more about the need for tools and languages to make life easier for the individual programmer trying to read the code, then plan, make and deploy changes to a live system. If you're lucky, you'll feel like the system makes sense but changes too quickly. If you're unlucky, the system will make little sense and it'll be entirely your job to fix it or put up with it. Usually, hopefully, there's a middle-ground, where the system works well enough you don't have to make changes, but you're probably not entirely satisfied with it either.

Humility can also be the reminder that just because a system looks broken (to you) doesn't mean it needs fixing right this second. If you can spare the time, it's almost always better to try and understand an existing system's quirks before you set out to redesign it and end up re-implementing some of the same quirks yourself.

I'll echo mentions elsewhere in this thread and suggest John Ousterhout's A Philosophy of Software Design as a good book on the subject of complexity and API design, but to newcomers to the field, I'll leave the warning that it doesn't cover TDD as much as it could and it also doesn't cover modern Scrum/Agile practices and how development fits in with product design and company goals. But I still highly recommend it.

I also recommend listening to podcasts like Changelog[1] in which developers are talking through how they approach problems etc., and trying to back up what you don't understand online by watching YouTube conference talks, ideally ones with examples in them from the real world.

Usenix talks, for example, tend to cover a lot of real-world engineering-at-scale challenges. The more you hear how programmers often make mistakes, the more the lessons around humility will sink in. :)

[1]: Re. changelog, and the subject of both mistakes and TDD, https://changelog.com/gotime/174 was a great listen also. Testing has gone from niche to mainstream back to "the best projects do it, but maybe only when forced," and it's interesting to listen to modern takes on what to test and when.

To have access to (or sense to use) better tools for given task is good. To be smug about it is bad. Actually, drop everything about technology in this discussion: being prideful is just bad.

Personally, I dislike Java, and I never got good enough at it to develop any worthwhile opinions. That said, I really despise PHP, but spent 20 years, writing it, and doing a fairly good job, because it was the best tool to give me the results I needed.

I feel that if we will use a tool, we need to take the time to become proficient with it.

Here's an article that I reference fairly often. It's sort of a "reality check": https://veekaybee.github.io/2019/05/10/java8/

"we need to take the time to become proficient with it."

I have thought this for a long time.

I have reckoned that it takes me at least six months full-time to come to grips with a new programming language (I'm 65 now, I learn slower, I'm retired, and I'll be damned if I'll learn any more).

Over the years, I've worked in teams dominated by young whippersnappers who are very keen to learn the latest language/library/framework. But they don't allocate 6 months; they seem to think they can press their new tool into production after just 6 days' practice. The result was unsually unmaintainable code.

I understand the motivation of the whippersnappers; they expect to change jobs within the next 6-12 months, and they want to be able to put the latest hot shit on their CV. But we ended up with systems that only a couple of people in the team could read, let alone maintain.

Write Simple Code. Don't Be Clever.

Good for you! I think one of the more important lessons is to realise that the programming community can be very disconnected from reality. This is especially true for HN with its heavy focus on “interesting”. Judging by HN, things like Erlang, Rust and previously Go, would see a lot of attention and so would the Kubernetes way of doing CI/CD. Interestingly there hasn’t been a single Rust, Erlang or Go job offering available in the region of the world where I live since I started tracking them out of interest after a similar discussion on HN in 2019.

There are however a constant demand for JAVA, C# and PHP developers. Because that’s the languages that are used in my region of the world, and as interesting as something like Rust might be, you’d have a hard time actually finding a job working with it. Even JavaScript isn’t that outspread here, if what you’re after is a full-time JavaScript job, because there is almost always a JAVA, C# or PHP backend to go along with it. You can of course find C++ job, there aren’t many, but there are some and I’m sure some of those places actually use Rust behind the scenes, but they don’t advertise it.

Anyway, I think my point is that there can be a big disconnect between HN and what you’re actually going to end up working with, and you’re likely not going to work with just one toolset for your entire career either. Before I became a manager, I spent almost a decade working mainly with .Net, but with the rise of things like Azure Services I stated working more and more with Python and Powershell, these days I almost exclusively work with Python as I’m mostly handling data for BI or management purposes and let the programming get done by my developers. We have recently picked up PHP though, which you likely wouldn’t think would happen in 2021 if you go by how dead PHP is supposed to be. Well, it so happened that there is a big open source project in my country that utilises Drupal to create a “forms generating” CMS system, that we want to be capable of building modules for, which means we needed someone to learn PHP.

Another really valuable lesson in humility I learned, and it took me years to do so, is related to the arrogance many software developers adopt when we get into the real world and start building things with the business side. Because our skill-set is so linked to dissecting and understanding problems, some of us adopt the unfortunate habit of thing we know... well everything. I’ve been arrogant enough to think I understood how our payment business process worked better than our director of payments, and of course I didn’t, but it was just so used to handling problems that I though I did. If you can, do better than me and apply your humility to everything, not just tool chains.

> JAVA

It's just "Java".

Unless you're mad at it.

You sound a lot like me in the early parts of my career. Strong opinions are worth something when you're just getting started out, I can't quantify what they're worth but they do something beneficial in terms of speed. The downside is that anyone with perspective on their side is probably laughing (maybe giggling) at your strong opinions.

If your journey is anything like mine you will end up driving yourself lower and lower into the stack until you wear yourself out. Ideological buoyancy will take over and you'll float somewhere higher, but you'll be much more knowledgeable and valuable as a result. All that to say, don't be too hard on yourself.

> Java is verbose, so it must be avoided, PHP is inelegant etc

I think that these opinions are mostly correct, but you and anyone else would learn a lot if you chose to actually try Java and PHP and experience this verbosity and inelegancy first-hand, as opposed to just hearing about it.

I think that important part is "opinions also gave a feeling of security".

I see it all the time in my daily life, people are insecure and mostly want some confirmation that choices they made are good ones.

They buy a car and then they start saying that other car brands are bad or breaking so easily. They cannot face the truth if their car turns out to be a crap. Seems totally like programming language bros, and some people cannot stand that in other language they could make more money. So what? There are probably people using that language that make less then them.

I don't want to live such life, I want to make mistakes and pay for them if needed. Lots of choices are reversible or can be changed, be flexible.

100% agree that humility is important. And realising that at young age is great :) However, with over 25 yrs dev experience, I do believe its true that Java is verbose (and some of its frameworks hideously so), and PHP is inelegant. Both languages have improved a lot over the years, thanks to a bunch of smart people working on them. Having now decided your opinions were premature, you may one day come to the same conclusion based on experience. Python, OTOH, well, that's a lot of fun. Has its issues, but, overall nice to develop with.

Hacker News shows me the "Gell-Mann Amnesia effect" quite vividly. When people here discuss topics that I know a lot about, I often quickly realize that more than half of the people commenting are saying nonsense. When people here discuss topics that I know little about, I am often impressed by the jargon and tone of utter conviction.

I am hopeful that you have misread the consensus that vim is most commonly used by those on HN... emacs is obviously the better choice and needs to be perceived as the best/most popular to keep the community active :)

Rust is a good choice. It will serve you well.

In my experience, I can learn a new language (and general style) serviceably well, in just a few weeks, but it can take years to learn the language in-depth, with the language being a “moving target,” as it evolves. I decided to specialize in Swift, and still have a lot to learn (I’ve been programming in Swift since the day it was announced, in 2014). Part of the reason for the time it’s taking, is because I have been using it to ship products, which slows exploration and research.

What really takes time, is platform SDKs and frameworks. They can be real rabbitholes, with all kinds of idiosyncrasies and caveats. They, too, are generally “moving targets.”

Good luck in your endeavors. I really enjoy programming.

The more you learn, the more you grasp the massive quantity of knowledge that you don't have. You can't learn or improve if you think you know everything.

I would say humility is the most important quality for an engineer to have if they want to be able to grow as an engineer. I've come across a small number of engineers that have lacked humility and acted as if they knew everything and they were a nightmare to work with. The first instinct they have when they approach most problems that they come across is that the issue can't possibly be caused by their code and you have to provide an unreasonable amount of evidence or a smoking gun to convince them to investigate their code. They design solutions as if they know the perfect way and they seem to lack empathy for users or others that may have to maintain that code.

> PHP is inelegant etc. ... who were still using 'inferior' tools

Well... PHP is inelegant, and there's a reason that it's been abandoned. However, it's actually worthwhile to spend some time discovering that for yourself - if not about PHP per se, then about a different "blunt" tool. Part of the modern computer science discipline is working through exactly why so many simple-seeming solutions fall apart - it isn't obvious, and it's really important to internalize.

"Well... PHP is inelegant, and there's a reason that it's been abandoned."

Abandoned? 79% of websites are still running on PHP. Let's postpone the funeral.

Good for you. It's takes most people a lot longer to come to that realization.

> Even though I didn't understand their arguments, I still believed what they said, because I thought they were experienced, so they must be right. Even though I hadn't used the tools personally, I started developing premature opinions on them

> This made me arrogant, because I saw myself as above my classmates

As others have said, "good" and "bad" depend on the use-case; everything has pros and cons; but some things are still objectively better than others (e.g. if tool A supports more data formats than tool B, whilst being just as fast, just as secure, just as supported, etc. then A is a "Pareto improvement" over B; there is no reason to choose B for a new project).

Whilst it's common to explain why something is "bad" (e.g. PHP encourages 'stringly typed programming', which makes SQL injection and cross-site-scripting vulnerabilities more likely); it's also important to explain why such "bad" tools are nevertheless widely used. For example, PHP is widely supported by free/cheap web hosts, is easy to set up (just copy a .php file to the server) and run (the URL is the .php file's path); it runs concurrently without needing shared state/threading/etc.; it has a built-in Web framework ('$_GET', '$_POST', 'echo', etc.); it can be embedded inside HTML files; and so on. This all helped it grow a large community in the Web 2.0 days, and lead to useful applications like Wordpress and MediaWiki, whose 'plugins' got many people into programming. This community of pragmatic (but often inexperienced) developers and their ability to quickly churn out Web apps has sustained itself to today; whilst the developers have matured, applications/libraries/frameworks have grown much more complex, the demands on the language are more diverse, and the language maintainers add new features and fix some of the language's underlying problems.

I still consider PHP to be a particularly bad language, and would need an incredibly compelling reason to choose it for new project. Yet I know there are many reasons why people have chosen it, and continue to do so. Those aren't necessarily "pros" for the language, e.g. it often comes down to historical inertia and 'what we know', which is much less important for those just starting out, or working in a different field (e.g. data scientists), or facing a different context (e.g. Web apps implemented client-side, fetching data from managed cloud services).

If we see the arguments against, but don't know much of the context or reasons things still get used, it's easy to make the assumption that others made bad choices due to ignorance. I think this is similar to Chesterton's Fence https://en.wiktionary.org/wiki/Chesterton%27s_fence i.e. we should understand the reasons why someone did things in a particular way before we scoff at their poor life choices (after all, sometimes those reasons make it even more hilarious!).

> PHP encourages 'stringly typed programming', which makes SQL injection and cross-site-scripting vulnerabilities more likely

Every language phasing the web is stringly typed, I have seen unproper filtering and escaping in all languages I worked professionally with.

> Every language phasing the web is stringly typed

Heh, not even close. Off the top of my head I can think of Ur/Web as an extreme example ( http://www.impredicative.com/ur ), and slightly more mainstream systems like Yesod ( https://www.yesodweb.com ). I've worked professionally with Haskell, although not for Web stuff. These days I mostly work with Scala, which has a similar typing mindset to ML/Haskell, but unfortunately inherits a lot of stringly typed legacy from Java. We use an in-house library that provides zero-cost newtypes to distinguish between different semantically-distinct data types, many of which just-so-happen to be representable as subsets of String (e.g. GET parameter names, GET parameter values, POST bodies, etc.). This makes it a type error to try and e.g. concatenate different sorts of data together.

W.r.t. "escaping", I tend to avoid it entirely since it's inherently unsafe:

- "Escaping" doesn't distinguish between its input and output types; they're both just "String", and we have to make assumptions about the contents of each (i.e. it's unsafe)

- Having the same input and output types makes it possible to "double-escape" by accident. This discourages the use of escaping, just-in-case it happens to be done elsewhere; hence it's very common to end up without any escaping taking place.

- Having the same input and output types makes escaping functionally unnecessary: anything we do to an escaped string could also be done to an unescaped string, so it's up to us to remember that it's needed (i.e. it's unsafe).

The whole idea of "escaping a string" betrays a flawed approach to the problem. Instead of throwing everything into the same representation, then manually trying to figure out whether or not a value comes from a particular subset of that representation or not, it's much easier and safer to avoid lumping them all together in the first place. If our inputs have a certain type (e.g. HTTP.Get.Val) and we can only output certain other types (e.g. JSON, Map[HTTP.Header.Key, HTTP.Header.Val], etc.), then the processing which turns input into output is forced to specify any necessary conversions. Whilst such conversions may involve escape sequences, having them associated to particular types is more akin to serialisation.

Heck, at my first PHP job we largely solved this problem not by 'filtering and escaping', but by modifying the PHP interpreter to distinguish between 'clean' and 'dirty' strings (with literals being clean, and $_GET, etc. being dirty). Operations like concatenation would propagate 'dirtiness', and output functions like 'echo' would crash if given a dirty string. Traditional 'escaping' functions would convert dirty strings to clean ones, and crash when given a clean string. Having this be dynamic was more annoying than ahead-of-time compile errors, but it still did a pretty good job.

There's pretty much no excuse for stringly typed languages/libraries/etc. when such such trivial solutions exist, other than the historical inertia of legacy systems.

Web consists of strings, not types. Somewhere in your pipeline you have string-to-type, if you don't do that correctly you will either have data loss, injection or xss, true for every language.

It is true that some languages makes it easier to go string-to-type than others, but I can do all of that in PHP by creating my own types too.

Web consists of bytestreams, not strings. Somewhere in your pipeline you have bytestream-to-string, if you don't do that correctly you will either have data loss, injection or xss, true for every language.

It is true that some languages makes it easier to go bytestream-to-string than others, but I can do all of that in PHP by creating my own types too.

---

Web consists of bitstreams, not bytestreams. Somewhere in your pipeline you have bitstreams-to-bytestreams, if you don't do that correctly you will either have data loss, injection or xss, true for every language.

It is true that some languages makes it easier to go bitstreams-to-bytestreams than others, but I can do all of that in PHP by creating my own types too.

---

Web consists of voltage fluctuations, not bitstreams. Somewhere in your pipeline you have voltage-fluctuations-to-bitstreams, if you don't do that correctly you will either have data loss, injection or xss, true for every language.

It is true that some languages makes it easier to go voltage-fluctuations-to-bitstream than others, but I can do all of that in PHP by creating my own types too.

---

Web consists of excitations of the electromagnetic field, not voltage fluctuations. Somewhere in your pipeline you have excitations-of-the-electromagnetic-field-to-voltage-fluctuation, if you don't do that correctly you will either have data loss, injection or xss, true for every language.

It is true that some languages makes it easier to go excitations-of-the-electromagnetic-field-to-voltage-fluctuations than others, but I can do all of that in PHP by creating my own types too.

---

Web consists of entanglement of energy quanta, not excitations of the electromagnetic field. Somewhere in your pipeline you have entaglement-of-energy-quanta-to-excitations-of-the-electromagnetic-field, if you don't do that correctly you will either have data loss, injection or xss, true for every language.

It is true that some languages makes it easier to go entanglement-of-energy-quanta-to-excitations-of-the-electromagnetic-field than others, but I can do all of that in PHP by creating my own types too.

---

...

Nice to see that you agree with me that the web does not consist of proper types and you as a programmer must make that choice. You have your custom library that makes this happen and that is something you and your team has implemented.

Reply on news.ycombinator.com