Comment by oftenwrong | Hacker News Reader

Comment by oftenwrong | Hacker News Reader

Parent Full thread

You were certainly bitten by the Java ecosystem, but I would agree that you hold some responsibility. Adopting Spring Boot so casually is really quite questionable. It's essentially opting to build your application within a giant, bonkers codebase. In the golang community there is a held value of using the standard library and tools, which is helped those being very good. I would suggest that Java is a better experience if you follow that same approach. If you want to serve HTTP, use the jdk.httpserver module. If you want to make HTTP requests, use java.net.http. If you want to interact with the filesystem, use java.nio.file. To build, use the included tools in the JDK. When it comes to cases where a third party dependency is warranted, such as use cases for Tika, you will have to deal with some questionable design decisions, but it's much easier when you have just a few libraries that you use by hand, and no insane framework trying to stitch everything together for you. For getting those dependencies, you are going to be acquiring them from public maven repositories, but I would suggest using Coursier or Maven Resolver instead of actually using Maven.

> Adopting Spring Boot so casually is really quite questionable.

The thing is, you don't always get that choice, at least in a way that wouldn't generate much opposition. If Spring Boot is what people use in most of the projects, opting for something else would generate lots of questions about that "inconsistency", especially as a part of the same team/project where services already exist that are written with it.

Same as not opting for ASP.NET with .NET, Laravel with PHP, Django with Python, Ruby on Rails, Express.js with Node.js and so on. Same as for picking .NET in a "Java shop" or Java in a ".NET shop" or even wanting to use Vue when most other projects are made with React etc. I'm not saying that Spring Boot is always the right choice (god no, honestly everything from Dropwizard to the likes of Javalin and Quarkus etc. have their use cases), just that you'd have to be able to make that choice yourself in the first place, which isn't always the case.

Same for Tika and other dependencies, which are often necessary evils: if you need to handle files and get their MIME types, will you just estimate what a file could be by looking at its extension, or do you actually want to look at the contents? And if you look at the contents, will you attempt the lazier approach ("Huh, this is an MS Office container type, no idea what's inside of it") or will you actually look for something more accurate ("Oh hey, this is an MS Office container type, with a Word document inside of it")? Then it becomes, do you want to spend the time reinventing that yourself or just have it done by the end of the day with an external dependency?

Not that Go is immune from that, you'd still probably want to just use https://github.com/gabriel-vasile/mimetype instead of building your own.

Aside from that, it's nice that Go isn't so "enterprise" oriented (yet?) and that the standard library is so strong (whereas Java only got a built in server around JDK 21 IIRC).

Edit: oh, also on my silly little list of jagged edges of Java, there's also the whole JUL, Log4j, Apache Commons Logging, Logback and SLF4J situation, whereas Go just has https://pkg.go.dev/log and it's nice. Not a horrible indictment or anything, I still use Java more or less daily, alongside other languages.

I agree with your sentiments. It's not always possible or worth it to go again the dominant culture of Java and most Java shops is against it. I have lost more of these kinds of battles than I have won.

I see Boot as a major risk for long term maintainability unless you are willing to keep Boot experts on staff. This is relevant: https://news.ycombinator.com/item?id=33185010

I wouldn't say the same for Tika, which I have used many times. It has a relatively small and readable codebase, excluding the parsers it depends on, and does not impose much upon its host code. While complex, it is significantly more feasible to fork or adopt it, if necessary.

To your point, the typical golang library, from what I have seen, is closer to being something manageable.

The Java community is too accepting of hacks (or hack-like things) such as bytecode manipulation, annotation processing, classpath scanning, classloader tricks, reflection, excessive reliance on not-quite-code configuration, etc. There are legitimate use cases for these techniques, but they should be used sparingly, and with great care.

The logging situation is emblematic of Java's tendency to on third-party solutions even for basic, primary concerns. The development and build tooling is another major example. Whereas golang provides tools that are standard, powerful and beloved, the JDK only provides low-level tools that are fairly half-baked and require significant orchestration for typical tasks. Same situation with JUnit instead of having a sensible, built-in approach like go test. The list goes on...

Reply on news.ycombinator.com