Hacker News Reader

Comment by pram | Hacker News Reader

I've been maintaining a Go app for about 9 years now and I can just upgrade the Go version + mod for vulnerabilities (GitHub tells me about them automatically idk) and it works with no changes 99% of the time. I can't overstate how this makes maintaining it very stress-free.

My JS apps on the other hand...

View on HN

My few tiny steps in JS world were alienating in that sense: having a brand new install of all tools, doing a “npx create-react-app” and got greeted with “congrats, your app is initialised, it has 13 vulnerable dependencies”.

Tbf those are development deps rather than production server deps, and the vuln will be something like "DOS possible if you let users craft their own regex string as input to lib.foo(re) in a server ctx" rather than "by using this in development to build your static js app, people get remote access to your dev machine."

It is a bit silly then that it reports them as vulnerabilities by default.

Worse CRA goes from saviour to deprecated, "use nextjs or vite instead" in a blink. Meta should maintain it. Nextjs will probably morph again in the future so you hope investing in learning vite is the answer. JS has this way.

Meanwhile Rails is so old it is thinking it needs to find a partner, settle down and buy a picket fenced house.

Unfortunately, in Rails, your major breaking changes without a migration path come from the core team.

create-react-app is not maintained AFAIK

The very first Go code I ever wrote, way back in 2011, still compiles and runs perfectly. It's glorious.

    package main

    import "fmt"

    func main() {
        fmt.Println("Hello world")
    }

Ha! Slightly more complex than that ;-)

https://gist.github.com/erinok/4399bbb1ea535deac051781eb9177...

I've had similar experiences, but I've noticed my Node.js applications which have few-to-no dependencies behave in the same way as my Go apps in that regard. I might get some deprecation logs from Node letting me know about future changes, but generally they do just work. The apps with a heavy dependency graph are a different story however.

This is still a feather in Go's cap given the fact that the standard library offers so much out of the box. I don't find myself reaching for dependencies that often.

I shudder to think the amount of thousands of engineering hours are spent in my FAANG to keep our Java services just running as-is with updates.

And now we're moving more to Typescript on Node...UGH.

I thought Java was robust. What's the hassle?

Not OP, but typically Spring and transitive dependencies. Some package that you don’t even use is pulled in and has a CVE. Or you upgrade major Spring versions and the API changes underneath you.

Have people considered frameworks implementing JAX-RS instead? Or does the breakage happen specifically in extensions to Spring?

The only inconvenience I have experienced upgrading a Quarkus backend is renaming javax.* package imports to jakarta.*. Hopefully the next major version requires just as little effort (if not less).

I am sure there would have been a lot more work if the project used extensions like the Kubernetes client. But overall, I have had the best experience with tools like Maven (for Java) and Leiningen (for Clojure). It helps to avoid libraries that hack or access JDK internals (e.g. Lombok, or ancient libraries using sun.* internal packages for reflection)

The main problem is Spring Boot and some other Spring projects like Security.

If you would use Spring MVC directly, it is very possible that one could upgrade Spring versions for many years with minimal or no changes at all.

However Spring Boot regularly breaks code. And given the fact that it's very popular, it means that any Java upgrade is pain. You need to rewrite code, sometimes a lot of code.

If you just use JAX-RS, probably simple Spring setup would suffice, but people usually want to slap database, security stuff and other things and everything is provided by Spring, so it's not apples-to-apples comparison.

I recommend Spring Boot, it provides a "blessed" set of dependencies that work with each other. When you want to upgrade, you just need to increase one version (the Spring Boot version).

if you don't pull in 50 jars to replace the "new" keyword (aka spring DI), then this ceases to be a problem

This Spring hater (me) thinks that's a fair summary. It also eliminates much of the safety the compiler can give you for free. You will only find out during Spring init, or even later, that your program is broken.

Java is fairly robust and plenty of libraries are very low-velocity.

JVM itself, however, has had several breaking changes recently. So a lot of organizations are stuck on an ancient version of the language.

Not really true imo.

I speak from the experience of supervised the upgrade of thousands of services from JDK8 to JDK17

There’s few quirks added but:

1. JDK17 will happily run JDK8 code without any changes 2. Most of the issues I observed were due to project jigsaw (and were resolved by adding —add-opens as needed)

I would expect 17 > 21 upgrade to have basically no issues as an upgrade in place

I hate Java but backwards compatibility isn’t one of the reasons why I hate it

This unfortunately is not true for large codebases. The language and the basic library are extremely stable, but the overall runtime is not. So the 8->17 switch resulted in lots and lots of regressions.

So companies either pay Oracle to maintain the old JDK8, or use something like Amazon Corretto. It's so bad that there are companies promising JDK8 support until 2031 at least.

And yeah, upgrades past 17 are easy.

> It's so bad that there are companies promising JDK8

Come on, that's absolutely not the reason behind. That just means that there are banks and such that still run goddamn windows XP completely firewalled off from the internet just because. Similarly, for some companies not touching that ancient codebase and just having it safely run worth the hassle and the money.

Java is the most backwards compatible language and it is not even a close competition.

> Similarly, for some companies not touching that ancient codebase and just having it safely run worth the hassle and the money. > Java is the most backwards compatible language and it is not even a close competition.

It's amazing to have two contradicting sentences right next to each other.

> Java is the most backwards compatible language and it is not even a close competition.

In competitions consisting of Java, PHP and Python, I presume?

In competitions of real world code in a language that has been in use for close to 30 years, and I can find a java 1.1 program that will both compile as source on the latest version, AND the original compiled version itself will run on a modern JDK as is.

And I assume this mythical 1.1 program does of course do a lot more than System.out.println and the reason that it took until recently, in part thanks to the Log4J fiasco, for 8 (almost 11 years old) to no longer be the most widely used version, was just superstition?

I've been working with Java for the last decade and for the past 5Y used the latest LTS versions in a very regulated environment (we have very strict patch deadlines for most CVEs). Rarely we hit issues with migrating to different versions of our dependencies. The most painful one was a small API change in Spring that revealed that we were doing something very bad so it took me 1-2D in between meetings to investigate. It is true though that every few weeks we are hit by a new CVE and we have to patch a lib version, but TBH this is what I expect from a language that has so many eyes on it's ecosystem.

A lot of BigCo people's (myself included) perception of Java is tainted by the challenges of old, inherited code bases. Java has been ubiquitous for a long time, and it's not surprising to accumulate code bases that have been underserved maintenance-wise over the years. Updating dependencies on a Java 8 codebase isn't much fun, especially because semvar wasn't widely followed back in those days.

> GitHub tells me about them automatically idk

GitHub tells you about published CVEs which represent a small fraction of actual patched security vulnerabilities in the wild, which typically never get a CVE.

I'm still stuck in JS world - it's difficult to get a Go job if it's not already your day job - and I hate it.

Currently I'm adding a React Native component library to an NX monorepo where I want it to work with Storybook for which I need to add Expo but I can't just run the generator, I need to extract the relevant bits from a template project and cross my fingers it works.

I long to go back to the simplicity of my Go project where I'd start my day by running `make watch` and it would just work. (mind you, it took me a while to find a file watcher that worked properly)

You can run govulncheck as part of your CI pipeline too

If JS apps are the standard you measure against you'll be happy with most things.

Except 'enterprise' Java, the indirection there is insane if you're using e.g. Spring. I last worked with it five or so years ago and I had no idea what I was doing.

Don't get it. Is it because your Go app relies in fewer dependencies? If so, it's just a matter of numbers I believe. JS apps tend to rely on more dependencies on average... but that doesn't need to be that way. I have plain JS apps that still work like the first day (even better than Go apps, since there's no compilation step involved).

TypeScript apps on the other hand, yeah, they tend to be more fragile (at least from my perspective: the tsc package has dozen of dependencies, so anything can go wrong)

You can do that in practically any language however that doesn’t mean it’s easy nor the norm.

JavaScript has a culture of move fast and break things. Whereas Go has a culture of moving slow and backwards compatibility.

It also helps that Go has a pretty extensive stdlibs whereas JavaScript is really more like several distinct language ecosystems wrapped around a common specification. So what works on one JavaScript runtime might not even work on another.

> but that doesn’t need to be that way

It kind of does though. If you need to do something with security implications, reinventing the wheel is usually higher risk than using a popular dependency. So it’s not like you can realistically avoid this issue. At least not without causing bigger problems.

It’s also not just a coincidence that Go apps have far fewer dependencies. The comprehensiveness of the std lib (along with officially maintained /x/ packages) means that you need fewer direct dependencies. And just as importantly for the overall size of the tree, all the dependencies that you do need themselves have fewer dependencies. This can easily mean an order of magnitude difference in total transitive dependencies for a significant project.

Reply on news.ycombinator.com